Knit Hats For Babies: May 2020

May 22, 2020

Hacktivity 2018 Badge - Quick Start Guide For Beginners

You either landed on this blog post because

you are a huge fan of Hacktivity
you bought this badge around a year ago
you are just interested in hacker conference badge hacking.

or maybe all of the above. Whatever the reasons, this guide should be helpful for those who never had any real-life experience with these little gadgets.

But first things first, here is a list what you need for hacking the badge:

a computer with USB port and macOS, Linux or Windows. You can use other OS as well, but this guide covers these
USB mini cable to connect the badge to the computer
the Hacktivity badge from 2018

By default, this is how your badge looks like.

Let's get started

Luckily, you don't need any soldering skills for the first steps. Just connect the USB mini port to the bottom left connector on the badge, connect the other part of the USB cable to your computer, and within some seconds you will be able to see that the lights on your badge are blinking. So far so good.

Now, depending on which OS you use, you should choose your destiny here.

Linux

The best source of information about a new device being connected is

# dmesg

The tail of the output should look like

[267300.206966] usb 2-2.2: new full-speed USB device number 14 using uhci_hcd
[267300.326484] usb 2-2.2: New USB device found, idVendor=0403, idProduct=6001
[267300.326486] usb 2-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[267300.326487] usb 2-2.2: Product: FT232R USB UART
[267300.326488] usb 2-2.2: Manufacturer: FTDI
[267300.326489] usb 2-2.2: SerialNumber: AC01U4XN
[267300.558684] usbcore: registered new interface driver usbserial_generic
[267300.558692] usbserial: USB Serial support registered for generic
[267300.639673] usbcore: registered new interface driver ftdi_sio
[267300.639684] usbserial: USB Serial support registered for FTDI USB Serial Device
[267300.639713] ftdi_sio 2-2.2:1.0: FTDI USB Serial Device converter detected
[267300.639741] usb 2-2.2: Detected FT232RL
[267300.643235] usb 2-2.2: FTDI USB Serial Device converter now attached to ttyUSB0

Dmesg is pretty kind to us, as it even notifies us that the device is now attached to ttyUSB0.

From now on, connecting to the device is exactly the same as it is in the macOS section, so please find the "Linux users, read it from here" section below.

macOS

There are multiple commands you can type into Terminal to get an idea about what you are looking at. One command is:

# ioreg -p IOUSB -w0 -l

With this command, you should get output similar to this:

+-o FT232R USB UART@14100000  <class AppleUSBDevice, id 0x100005465, registered, matched, active, busy 0 (712 ms), retain 20>
    |   {
    |     "sessionID" = 71217335583342
    |     "iManufacturer" = 1
    |     "bNumConfigurations" = 1
    |     "idProduct" = 24577
    |     "bcdDevice" = 1536
    |     "Bus Power Available" = 250
    |     "USB Address" = 2
    |     "bMaxPacketSize0" = 8
    |     "iProduct" = 2
    |     "iSerialNumber" = 3
    |     "bDeviceClass" = 0
    |     "Built-In" = No
    |     "locationID" = 336592896
    |     "bDeviceSubClass" = 0
    |     "bcdUSB" = 512
    |     "USB Product Name" = "FT232R USB UART"
    |     "PortNum" = 1
    |     "non-removable" = "no"
    |     "IOCFPlugInTypes" = {"9dc7b780-9ec0-11d4-a54f-000a27052861"="IOUSBFamily.kext/Contents/PlugIns/IOUSBLib.bundle"}
    |     "bDeviceProtocol" = 0
    |     "IOUserClientClass" = "IOUSBDeviceUserClientV2"
    |     "IOPowerManagement" = {"DevicePowerState"=0,"CurrentPowerState"=3,"CapabilityFlags"=65536,"MaxPowerState"=4,"DriverPowerState"=3}
    |     "kUSBCurrentConfiguration" = 1
    |     "Device Speed" = 1
    |     "USB Vendor Name" = "FTDI"
    |     "idVendor" = 1027
    |     "IOGeneralInterest" = "IOCommand is not serializable"
    |     "USB Serial Number" = "AC01U4XN"
    |     "IOClassNameOverride" = "IOUSBDevice"
    |   }

The most important information you get is the USB serial number - AC01U4XN in my case.
Another way to get this information is

# system_profiler SPUSBDataType

which will give back something similar to:

FT232R USB UART:

          Product ID: 0x6001
          Vendor ID: 0x0403  (Future Technology Devices International Limited)
          Version: 6.00
          Serial Number: AC01U4XN
          Speed: Up to 12 Mb/sec
          Manufacturer: FTDI
          Location ID: 0x14100000 / 2
          Current Available (mA): 500
          Current Required (mA): 90
          Extra Operating Current (mA): 0

The serial number you got is the same.

What you are trying to achieve here is to connect to the device, but in order to connect to it, you have to know where the device in the /dev folder is mapped to. A quick and dirty solution is to list all devices under /dev when the device is disconnected, once when it is connected, and diff the outputs. For example, the following should do the job:

ls -lha /dev/tty* > plugged.txt
ls -lha /dev/tty* > np.txt
vimdiff plugged.txt np.txt

The result should be obvious, /dev/tty.usbserial-AC01U4XN is the new device in case macOS. In the case of Linux, it was /dev/ttyUSB0.

Linux users, read it from here. macOS users, please continue reading

Now you can use either the built-in screen command or minicom to get data out from the badge. Usually, you need three information in order to communicate with a badge. Path on /dev (you already got that), speed in baud, and the async config parameters. Either you can guess the speed or you can Google that for the specific device. Standard baud rates include 110, 300, 600, 1200, 2400, 4800, 9600, 14400, 19200, 38400, 57600, 115200, 128000 and 256000 bits per second. I usually found 1200, 9600 and 115200 a common choice, but that is just me.
Regarding the async config parameters, the default is that 8 bits are used, there is no parity bit, and 1 stop bit is used. The short abbreviation for this is 8n1. In the next example, you will use the screen command. By default, it uses 8n1, but it is called cs8 to confuse the beginners.

If you type:
# screen /dev/tty.usbserial-AC01U4XN 9600
or
# screen /dev/ttyUSB0 9600
and wait for minutes and nothing happens, it is because the badge already tried to communicate via the USB port, but no-one was listening there. Disconnect the badge from the computer, connect again, and type the screen command above to connect. If you are quick enough you can see that the amber LED will stop blinking and your screen command is greeted with some interesting information. By quick enough I mean ˜90 seconds, as it takes the device 1.5 minutes to boot the OS and the CTF app.

Windows

When you connect the device to Windows, you will be greeted with a pop-up.

Just click on the popup and you will see the COM port number the device is connected to:

In this case, it is connected to COM3. So let's fire up our favorite putty.exe, select Serial, choose COM3, add speed 9600, and you are ready to go!

You might check the end of the macOS section in case you can't see anything. Timing is everything.

The CTF

Welcome to the Hacktivity 2018 badge challenge!

This challenge consists of several tasks with one or more levels of
difficulty. They are all connected in some way or another to HW RE
and there's no competition, the whole purpose is to learn things.

Note: we recommend turning on local echo in your terminal!
Also, feel free to ask for hints at the Hackcenter!

Choose your destiny below:

  1. Visual HW debugging
  2. Reverse engineering
  3. RF hacking
  4. Crypto protection

Enter the number of the challenge you're interested in and press [

Excellent, now you are ready to hack this! In case you are lost in controlling the screen command, go to https://linuxize.com/post/how-to-use-linux-screen/.

I will not spoil any fun in giving out the challenge solutions here. It is still your task to find solutions for these.

But here is a catch. You can get a root shell on the device. And it is pretty straightforward. Just carefully remove the Omega shield from the badge. Now you see two jumpers; by default, these are connected together as UART1. As seen below.

But what happens if you move these jumpers to UART0? Guess what, you can get a root shell! This is what I call privilege escalation on the HW level :) But first, let's connect the Omega shield back. Also, for added fun, this new interface speaks on 115200 baud, so you should change your screen parameters to 115200. Also, the new interface has a different ID under /dev, but I am sure you can figure this out from now on.

If you connect to the device during boot time, you can see a lot of exciting debug information about the device. And after it boots, you just get a root prompt. Woohoo!

But what can you do with this root access? Well, for starters, how about running

# strings hello | less

From now on, you are on your own to hack this badge. Happy hacking.

Big thanks to Attila Marosi-Bauer and Hackerspace Budapest for developing this badge and the contests.

PS: In case you want to use the radio functionality of the badge, see below how you should solder the parts to it. By default, you can process slow speed radio frequency signals on GPIO19. But for higher transfer speeds, you should wire the RF module DATA OUT pin with the RX1 free together.

Networking | Routing And Switching | Tutorial 4 | 2018

Welcome to my 4th new tutorial of the series of networking. In this blog you'll the content about network switches. You'll learn about how to make a communication successful and secure in the same network (LAN) by using STP. As Spanning tree protocol (STP) we used in multi-switched networks. Why we use this protocol in multi-switched network etc.

What is Switch?

A switch is an intelligent device used to connect multiple devices within the same network. The intelligence of is that it requires Media Access Control (MAC) address for communication and doesn't allow broadcast. Let's understand the whole thing by a little example, consider there is a network having 3 end devices name Device-A, Device-B,Device-C connected with each other respectively with the help of switch. When a Device-A sends data to Device-C so that data will only forwarded by switch to Device-C not to Device-B.

What is Media Access Control (MAC) address?

A Media Access Control (MAC) address is 48-bit unique physical address given to network interface controller (NIC) or network adapter, for communication within the same network which is given by its manufacturer. It is made up of hexadecimal numbers like a1:b1:cc:ac:2e:f1.

What is STP?

STP stands for Spanning tree protocol which is basically used in bridge and switches to prevent loops when you have a redundant links in the Ethernet networks. If the loop is present in the Ethernet network so the whole network will suffer because there will MAC instability in the MAC table, duplicate frames generation and so on. Let's move to the video for further detail.

Remotely sniffing signals for later analysis:

In the the previous blogs, we sniffed signals and replayed them to perform actions. In this blog we are going to take a look at a signal and reverse it to create a physical device that will act as a replacement for the original device. Depending on the scenario this may be a better approach if you plan to enter the facility off hours when there is no signal to capture or you don't want to look suspicious.

Recon:

Lets first use the scanning functionality in RFCrack to find known frequencies. We need to understand the frequencies that gates usually use. This way we can set our scanner to a limited number of frequencies to rotate through. The smaller rage of frequencies used will provide a better chance of capturing a signal when a car opens the target gate. This would be beneficial if the scanning device is left unattended within a dropbox created with something like a Kali on a Raspberry Pi. One could access it from a good distance away by setting up a wifi hotspot or cellular connection.

Based on research remotes tend to use 315Mhz, 390Mhz, 433Mhz and a few other frequencies. So in our case we will start up RFCrack on those likely used frequencies and just let it run. We can also look up the FCID of our clicker to see what Frequencies manufactures are using. Although not standardized, similar technologies tend to use similar configurations. Below is from the data sheet located at https://fccid.io/HBW7922/Test-Report/test-report-1755584 which indicates that if this gate is compatible with a universal remote it should be using the 300,310, 315, 372, 390 Frequencies. Most notably the 310, 315 and 390 as the others are only on a couple configurations.

RFCrack Scanning:

Since the most used ranges are 310, 315, 390 within our universal clicker, lets set RFCrack scanner to rotate through those and scan for signals. If a number of cars go through the gate and there are no captures we can adjust the scanner later over our wifi connection from a distance.

Destroy:RFCrack ficti0n$ python RFCrack.py -k -f 310000000 315000000 390000000

Currently Scanning: 310000000 To cancel hit enter and wait a few seconds

Currently Scanning: 315000000 To cancel hit enter and wait a few seconds

Currently Scanning: 390000000 To cancel hit enter and wait a few seconds

e0000000000104007ffe0000003000001f0fffe0fffc01ff803ff007fe0fffc1fff83fff07ffe0007c00000000000000000000000000000000000000000000e0007f037fe007fc00ff801ff07ffe0fffe1fffc3fff0001f00000000000000000000000000000000000000000000003809f641fff801ff003fe00ffc1fff83fff07ffe0fffc000f80000000000000000000000000000000000000000000003c0bff01bdf003fe007fc00ff83fff07ffe0fffc1fff8001f0000000000000000000000000000000000000000000000380000000000000000002007ac115001fff07ffe0fffc000f8000000000000000000000000000000000000000

Currently Scanning: 433000000 To cancel hit enter and wait a few seconds

Example of logging output:

From the above output you will see that a frequency was found on 390. However, if you had left this running for a few hours you could easily see all of the output in the log file located in your RFCrack/scanning_logs directory. For example the following captures were found in the log file in an easily parseable format:

Destroy:RFCrack ficti0n$ cd scanning_logs/

Destroy:scanning_logs ficti0n$ ls

Dec25_14:58:45.log Dec25_21:17:14.log Jan03_20:12:56.log

Destroy:scanning_logs ficti0n$ cat Dec25_21\:17\:14.log

A signal was found on :390000000

c0000000000000000000000000008000000000000ef801fe003fe0fffc1fff83fff07ffe0007c0000000000000000000000000000000000000000000001c0000000000000000050003fe0fbfc1fffc3fff83fff0003e00000000000000000000000000000000000000000000007c1fff83fff003fe007fc00ff83fff07ffe0fffc1fff8001f00000000000000000000000000000000000000000000003e0fffc1fff801ff003fe007fc1fff83fff07ffe0fffc000f80000000000000000000000000000000000000000000001f07ffe0dffc00ff803ff007fe0fffc1fff83fff07ffe0007c000000000000000000000000000000000000000000

A signal was found on :390000000

Analyzing the signal to determine toggle switches:

Ok sweet, now we have a valid signal which will open the gate. Of course we could just replay this and open the gate, but we are going to create a physical device we can pass along to whoever needs entry regardless if they understand RF. No need to fumble around with a computer and look suspicious. Also replaying a signal with RFCrack is just to easy, nothing new to learn taking the easy route.

The first thing we are going to do is graph the capture and take a look at the wave pattern it creates. This can give us a lot of clues that might prove beneficial in figuring out the toggle switch pattern found in remotes. There are a few ways we can do this. If you don't have a yardstick at home you can capture the initial signal with your cheap RTL-SDR dongle as we did in the first RF blog. We could then open it in audacity. This signal is shown below.

Let RFCrack Plot the Signal For you:

The other option is let RFCrack help you out by taking a signal from the log output above and let RFCrack plot it for you. This saves time and allows you to use only one piece of hardware for all of the work. This can easily be done with the following command:

Destroy:RFCrack ficti0n$ python RFCrack.py -n -g -u 1f0fffe0fffc01ff803ff007fe0fffc1fff83fff07ffe0007c

-n = No yardstick attached

-g = graph a single signal

-u = Use this piece of data

From the graph output we see 2 distinct crest lengths and some junk at either end we can throw away. These 2 unique crests correspond to our toggle switch positions of up/down giving us the following 2 possible scenarios using a 9 toggle switch remote based on the 9 crests above:

Possible toggle switch scenarios:

down down up up up down down down down
up up down down down up up up up

Configuring a remote:

Proper toggle switch configuration allows us to program a universal remote that sends a signal to the gate. However even with the proper toggle switch configuration the remote has many different signals it sends based on the manufacturer or type of signal. In order to figure out which configuration the gate is using without physically watching the gate open, we will rely on local signal analysis/comparison.

Programming a remote is done by clicking the device with the proper toggle switch configuration until the gate opens and the correct manufacturer is configured. Since we don't have access to the gate after capturing the initial signal we will instead compare each signal from he remote to the original captured signal.

Comparing Signals:

This can be done a few ways, one way is to use an RTLSDR and capture all of the presses followed by visually comparing the output in audacity. Instead I prefer to use one tool and automate this process with RFCrack so that on each click of the device we can compare a signal with the original capture. Since there are multiple signals sent with each click it will analyze all of them and provide a percent likelihood of match of all the signals in that click followed by a comparing the highest % match graph for visual confirmation. If you are seeing a 80-90% match you should have the correct signal match.

Note: Not every click will show output as some clicks will be on different frequencies, these don't matter since our recon confirmed the gate is communicating on 390Mhz.

In order to analyze the signals in real time you will need to open up your clicker and set the proper toggle switch settings followed by setting up a sniffer and live analysis with RFCrack:

Open up 2 terminals and use the following commands:

#Setup a sniffer on 390mhz
Setup sniffer: python RFCrack.py -k -c -f 390000000.

#Monitor the log file, and provide the gates original signal
Setup Analysis: python RFCrack.py -c -u 1f0fffe0fffc01ff803ff007fe0fffc1fff83fff07ffe0007c -n.

Cmd switches used

-k = known frequency

-c = compare mode

-f = frequency

-n = no yardstick needed for analysis

Make sure your remote is configured for one of the possible toggle configurations determined above. In the below example I am using the first configuration, any extra toggles left in the down position: (down down up up up down down down down)

Analyze Your Clicks:

Now with the two terminals open and running click the reset switch to the bottom left and hold till it flashes. Then keep clicking the left button and viewing the output in the sniffing analysis terminal which will provide the comparisons as graphs are loaded to validate the output. If you click the device and no output is seen, all that means is that the device is communicating on a frequency which we are not listening on. We don't care about those signals since they don't pertain to our target.

At around the 11th click you will see high likelihood of a match and a graph which is near identical. A few click outputs are shown below with the graph from the last output with a 97% match. It will always graph the highest percentage within a click. Sometimes there will be blank graphs when the data is wacky and doesn't work so well. This is fine since we don't care about wacky data.

You will notice the previous clicks did not show even close to a match, so its pretty easy to determine which is the right manufacture and setup for your target gate. Now just click the right hand button on the remote and it should be configured with the gates setup even though you are in another location setting up for your test.

For Visual of the last signal comparison go to ./imageOutput/LiveComparison.png

----------Start Signals In Press--------------

Percent Chance of Match for press is: 0.05

Percent Chance of Match for press is: 0.14

Percent Chance of Match for press is: 0.12

----------End Signals In Press------------

For Visual of the last signal comparison go to ./imageOutput/LiveComparison.png

----------Start Signals In Press--------------

Percent Chance of Match for press is: 0.14

Percent Chance of Match for press is: 0.20

Percent Chance of Match for press is: 0.19

Percent Chance of Match for press is: 0.25

----------End Signals In Press------------

For Visual of the last signal comparison go to ./imageOutput/LiveComparison.png

----------Start Signals In Press--------------

Percent Chance of Match for press is: 0.93

Percent Chance of Match for press is: 0.97

Percent Chance of Match for press is: 0.90

Percent Chance of Match for press is: 0.88

Percent Chance of Match for press is: 0.44

----------End Signals In Press------------

For Visual of the last signal comparison go to ./imageOutput/LiveComparison.png

Graph Comparison Output for 97% Match:

Conclusion:

You have now walked through successfully reversing a toggle switch remote for a security gate. You took a raw signal and created a working device using only a Yardstick and RFCrack. This was just a quick tutorial on leveraging the skillsets you gained in previous blogs in order to learn how to analyze RF signals within embedded devices. There are many scenarios these same techniques could assist in. We also covered a few new features in RF crack regarding logging, graphing and comparing signals. These are just a few of the features which have been added since the initial release. For more info and other features check the wiki.

HTML5 Games On Android

On my last hollidays, I made two HTML5 games, and published on android market. Nowadays javascript has powerful libraries for doing almost everything, and also there are several compilers from java or c code to javascript, converting opengl c code to html5 canvas, but definitely, javascript execution is slower than dalvik applications, and of course much slower than arm c libs. For improving the speed of sounds and images loader, I have used javascript asynchronous execution and scheduling priority has been controlled with setTimeout/setInterval which deprioritize or priorize a code block. This games are published on the android market here: Android Planets and here: Far Planet

More information

October 2019 Connector

OWASP
Connector

October 2019

Communications | Projects | Events | Community | Membership

COMMUNICATIONS

Letter from the Vice Chairman of the Board

Dear OWASP Community,

Two of the primary initiatives the foundation staff has been working on over the past few months were the two back to back Global AppSec Events in DC and Amsterdam. This was a huge undertaking by everyone involved. We are pleased to announce that the survey feed back is positive and both events were well attended. I was in attendance of Global AppSec Amsterdam and it was great meeting and speaking with old friends and meeting new ones. I would also like to take this opportunity, on behalf of the board to thank OWASP staff for their efforts in making the two conferences so successful.

To continuing on with the events theme; I'm really happy to announce the locations of our 2020 OWASP Global AppSec Conferences. The first one will be June 15 - 19, 2020 in Dublin and the second will be October 19 - 23, 2020 in San Francisco. Dublin is not an exotic trip for me, more of a 10 minute tram ride. Hopefully you will join us, while also making the most of the culture and scenery that Ireland has to offer.

Last but not least, the OWASP Global Board of Directors election results where released Thursday October 17, 2019. I'd like to first thank everyone who has put their trust in me by voting me back onto the board for the next two years. I hope I do you justice.

I would also like to thank the large number of candidates that were willing to give of their personal time and run to be part of the Global OWASP Board. This is a testament of the dedication and commitment of our members to continue to grow and evolve to the next level as an organization. I encourage those that were not elected will still be involved in making a positive change by volunteering to be part of a committee. The board and staff need all the help they can get to push through change. I hope you will join us in this journey. We can not be successful without the help of the community.

Until next time,
Owen Pendlebury
Vice Chairman, OWASP Global Board of Directors

OWASP Global Board Election Results

The newly elected 2020 OWASP Board Members:
Grant Ongers
Owen Pendlebury
Sherif Mansour
Vandana Verma Sengal

Congratulations, and thank you to all the candidates that participated and the OWASP members that voted.

OWASP Foundation Global AppSec Event Dates for 2020

Global AppSec Dublin, June 15 - 19, 2020

Global AppSec San Francisco, October 19 - 23, 2020

Visit our website for future announcements.

EVENTS

You may also be interested in one of our other affiliated events:

REGIONAL EVENTS

Event	Date	Location
BASC 2019 (Boston Application Security Conference)	October 19,2019	Burlington, MA
LASCON X	October 24 - 25, 2019	Austin, TX
OWASP AppSec Day 2019	Oct 30 - Nov 1, 2019	Melbourne, Australia
German OWASP Day 2019	December 9 - 10, 2019	Karlsruhe, Germany
AppSec California 2020	January 21 - 24, 2020	Santa Monica, CA
OWASP New Zealand Day 2020	February 20 - 21, 2020	Auckland, New Zealand
Seasides 2020	March 3 - 5, 2020	Panjim Goa, India
SnowFROC 2020	March 5, 2020	Denver, CO

GLOBAL PARTNERSHIP EVENTS

Event	Date	Location
BlackHat Europe 2019	December 2 - 5, 2019	London

BlackHat Europe 2019 London at EXCEL London
2019 December 2-5
Visit the OWASP Booth 1015
Business Hall December 4 & 5
December 4, 10:30 AM - 7:00 PM
December 5: 10:00 AM - 4:00 PM

OWASP Members are eligible for € 200.00 discount , email marketing@owasp.org for code to use when registering.

PROJECTS

Projects were well-represented at the previous two Global AppSec conferences in DC and Amsterdam this past month. Both events featured the popular Project Showcase and I heartily thank the leaders of the projects who participated:

Secure Medical Device Deployment Standard
Secure Coding Dojo
API Security Project
Dependency Check
SAMM
SEDATED
DefectDojo
Juice Shop
ModSecuity Core Rule Set
SecurityRAT
WebGoat

These leaders put on a great set of presentations and, in many cases, the room was standing room only. Thank you!

The project reviews that were done in DC and Amsterdam are still being evaluated and worked on; if you are waiting on answers, please have patience. I hope to have them finalized by November.

The website migration continues moving forward. The process of adding users to the proper repositories is an on-going effort. If you have not given your GitHub username, please drop by the Request for Leader Github Usernames form. A nice-to-accomplish goal would be to have the projects and chapters in their new website homes within the next 30 days.

Harold L. Blankenship
Director of Technology and Projects

COMMUNITY

Welcome to the New OWASP Chapters
Sacramento, California
Marquette, Michigan
Ranchi, India
Paraiba, Brazil
Calgary, Canada

CORPORATE MEMBERS

Premier Corporate Member

Contributor Corporate Members

*Ads and logos are not endorsements and reflect the messages of the advertiser only. *

Join us

Donate

Our mailing address is:
OWASP Foundation
1200-C Agora Drive, #232
Bel Air, MD 21014

Unsubscribe

This email was sent to *|EMAIL|*
why did I get this? unsubscribe from this list update subscription preferences
*|LIST:ADDRESSLINE|*

Knit Hats For Babies

May 22, 2020

Hacktivity 2018 Badge - Quick Start Guide For Beginners

Let's get started

Linux

macOS

Linux users, read it from here. macOS users, please continue reading

Windows

The CTF

More articles

Networking | Routing And Switching | Tutorial 4 | 2018

What is Switch?

What is Media Access Control (MAC) address?

What is STP?

Remotely sniffing signals for later analysis:

Recon:

RFCrack Scanning:

Example of logging output:

Analyzing the signal to determine toggle switches:

Let RFCrack Plot the Signal For you:

Possible toggle switch scenarios:

Configuring a remote:

Comparing Signals:

Open up 2 terminals and use the following commands:

Analyze Your Clicks:

Graph Comparison Output for 97% Match:

Conclusion:

Read more

HTML5 Games On Android

More information

October 2019 Connector

COMMUNICATIONS

EVENTS

PROJECTS

COMMUNITY

CORPORATE MEMBERS