Google Fiber Jack Shell and GPON Configuration

Written 2020-08-12

Tags:UART Shell Google 

After looking inside a Google Fiber Jack, I found a similar 0.1 inch header strip like was present on the Google Fiber Network Box. Guessing the pinouts to be the same (Ground at one end connected to ground plane, then PCB-TX, then PCB-RX), and the baud to be the same(115200), I was presented with U-boot. After politely asking U-boot to stop the autoboot sequence, I found I was unable to enter single-user mode through the normal methods(single,1,init=/bin/sh) and attempting to do so led the unit to boot normally, without even a login prompt.

After adding debug=1, we can see more printouts during startup, and a login prompt, but now we need the password.

Back to U-boot. We can use 'sf' to read Serial Flash into RAM, and 'md.b' to print RAM over the bootloader console. Equipped with 32MB of Flash, and not wanting to risk byte-drop by increasing the baud-rate, dumping the flash takes several hours, but after converting both line-endings then hex to binary, I'm greeted with a 33554432 byte file, which is exactly correct.

After running binwalk several times recusively and a little manual extraction, I'm able to locate the shadow file and hashes within. A quick run through hashcat with a wordlist reveals the passwords. I won't post the password here, but I was disappointed I didn't guess it.

After rebooting Linux with debug=1 and logging in, we can see:

JAAG45202481# cat /sys/devices/platform/gpon/info/infoGpon 

ONT Full Information:
SN[VENDOR ID]:                 4A:41:41:47 [JAAG]
SN[Serial Number]:             45:20:24:81
ONU ID:                        255
ONU STATE:                     1 [INITIAL]
INIT STATE:                    TRUE
OMCC Valid:                    FALSE
OMCC Port:                     65535
BER Interval:                  0
SD Threshold:                  9
SF Threshold:                  5
Guard Bits:                    0
Preamble Type1 Size:           0
Preamble Type2 Size:           0
Preamble Type3 Pattern:        0xAA
Preamble Type3 Range Size:     0
Preamble Type3 Oper Size:      0
Delimiter:                     0x00AB5983 [0x00AB5983]
Internal Delay:                6532 [0x1984]
Equalization Delay:            0 [0x0] (HW:0x0)
Final Delay:                   32
Const Idle Ploam:              [0xFF040000][0x00000000][0x00000000]
Const Serial Number Ploam:     [0xFF014A41][0x41474520][0x24810505]
Serial Number Mask Enable:     FALSE
Serial Number Mask Match Mode: NO MATCH
Debug Mode:                    FALSE
Overhead Manual Mode:          FALSE
JAAG45202481# uname -a
Linux GFiberONU #3 Fri Apr 4 12:48:22 PDT 2014 armv5tel

Installing Debian 10 on a PowerMac G5

Written 2020-07-03

Tags:PowerPC Debian Apple Linux 


Press power button

Enter OpenFirmware

As soon as the mac chimes, press and hold ALT+WIN+O+F or Apple+Option+O+F to enter openfirmware.

Insert the Debian disk

Boot the installer bootloader

Type "boot cd:,\install\yaboot"

Select installer kernel and boot the installer

At the boot prompt press enter or type "install" then enter

Run through some Debian installer steps

At this point we should be greeted with the familiar Debian text-based installer. Most of this is bog-standard, but there's a few gotchas later.

Select Partitioning Method

Unless you're familiar with PowerPC bootloading, just use a guided method. Powermacs require a special partition to be set up, this is the easiest way to do so.

More standard Debian installer steps

Skip the apt mirror setup

We need to switch to a debian-ports mirror. However, there's no keychain for debian-ports loaded into the installer. For now, we're going to skip this and fix it later. But the process for doing so is not exactly clear, so I have documented it below: At this point the installer should continue until it complains that it cannot access the security repositories. Pick continue then wait while the installer selects and installs software.

Configure Popularity-Contest

I recommend participating in the package usage survey, to give feedback to the Debian project about what packages you use, but you are free not to.

Select software package

Just joking, there is only one package included with the CD, 'standard system utilities', which you probably want. Hit continue.

Wait for the CD to eject, take it out, but do not reboot. Time to fix what we broke

At this point, we're going to add a ports mirror, and install SSH in case the GPU fails.

What to do if you have an NVIDIA GPU and the screen turns black on reboot

In short, we need to create this file: /etc/modprobe.d/blacklist-nvidia-nouveau.conf, with the following contents:
blacklist nouveau

With SSH

Without SSH

Widespread re-use of SSH Host Keys in Ethereum Mining Rig Operating Systems

Written 2020-04-10

Tags:Cryptocurrency Ethereum Crypto SSH 

How this started

A friend came to me last fall wondering how their newly set up mining rig kept getting rooted. This happened over a few different mining OSs. Eventually we found an old firewall rule allowing inbound SSH access, and the mining rig had lost the DHCP lottery and SSH was exposed. Rather than close the hole immediately we decided to do some logging. We set up a new, fresh install and waited. Mostly, we got the usual SSH scanners hitting the box, but rarely our attacker would log in with the right default password on the first try. That's strange - default passwords change per mining OS, so how would they know what OS was running?

I myself have a GPU rig, for machine learning and other purposes. But while it's idle to me, it mines. Strangely, I noticed that the SSH host-keys on my box predated the software installation, which made me curious who generated them.

With these two bits of knowledge, I discovered a widespread key-reusage bug, worked with the mining OS groups, and filed several CVEs.

What exactly are SSH host keys?

SSH host keys provide a mechanism so that a server can be fingerprinted and identified to a client as a trusted entity, worthy of being fed a password through a login attempt. In other words:


The SSH key should be unique per host, both to prevent a bad actor compromising one machine being able to impersonate another, and to prevent a bad actor from enumerating identifiable hosts by looking for known public keys.

The Problem

Several Linux-based Ethereum mining platforms constructed host-keys prior to disk image generation. This means that a large number of systems share the SSH host keys. In addition to being able to impersonate servers, we can search or use an SSH host-public-key scanner to identify hosts accessible on the public IPv4 space. It also means that it is fairly easy to construct a dictionary mapping public key to default credentials for some mining OSs.

The Extraction Process

For each mining image, the disk image was downloaded, and testdisk was run to extract the SSH keys. Testdisk had trouble with a few images, so the remaining ones were booting in a VM. SSH keys were then searched on to confirm the presence of IPv4 exposes hosts.


It seems attackers have weaponized SSH host keys, both as a means of identifying hosts, and identifying default exploits like unchanged default usernames and passwords. Additionally, most appliances or IoT devices should not be exposed on IPv4/6 for ingress from the general internet. This sentiment was echoed by some mining OS vendors who did not recognize shared host keys as an issue until presented with results showing their miners were easily identifiable online. Finally, a secure automatic update path is a must - without this miners will remain exposed until manually patched, likely with many miners unaware they are exposed.

Affected Platforms and Keys and Host Counts

PlatformSSH Host Key(Search Shodan For This) Host Count(when found)

Responsible Disclosure

An effort was made to contact the authors of each identified OS, and publication was delayed four months in an effort to allow vendors to patch their distributions:
Platform CVE Initial Report Outcome
MinerStat CVE-2019-19750 Sept 8, 2019 Fixed issue promptly.
nvOC CVE-2019-19752 Dec 1, 2019 Devs on bitcoin talk said it would be fixed in next release.
EasyMine CVE-2019-19751 Sept 23, 2019 Fixed Dec 5, 2019
SimpleMiningOSCVE-2019-19753 Sept 8, 2019 Declined to fix, pinged again, said they would consider.
HiveOS CVE-2019-19754 Sept 9, 2019 Said thank you for submitting, they would consider it. Never heard back.
EthOS CVE-2019-19755 Dec 1, 2019 Stated in IRC they would ask developers to fix it
MinerBabe CVE-2020-5200 Dec 3, 2019 Said they would fix it, but did not say anything about fixing the SSH login key shipped in the image.

JSON and KML now available for OpMap

Written 2020-03-20

ULS Search now has options for JSON and KML output.

Setting up ESP8266 for sample-based profiling and debugging

Written 2020-02-22

Tags:Espressif Xtensa ESP8266 

This weekend I finally got my ESP8266 working with OpenOCD's JTAG sample-based profiling. There were four problems, one with the Arduino Core, two with OpenOCD, and a similar bottleneck to ESP32.

First, the Arduino Core defaults all GPIO-capable pins into GPIO inputs. This very quickly disables the JTAG pins. The solution is simply:


Next, OpenOCD's reg command was returning no registers, because they were marked as exist=false. Also OpenOCD's profiler looks for a register, PC, but the ESP8266 only implemented pc, and OpenOCD's profiler is case-sensitive.

This is fixed in my OpenOCD port.