Netgear CG3100; progress and things of note

[Swyter]

Hi, Joseph. As a weird weekend project I started fiddling with some Netgear CG3100 cable-modem/router/access-point.

I wanted something neat to do some black-box format reversing with, and I have documented most of the structures as a 010 Editor binary template which can be found here: https://github.com/Swyter/netgear-cg3100-config-decoder

I have been interested since opening the GatewaySettings.bin and seeing what looked like only half of the bytes being XOR'ed and the rest seemed plain text; I could even spot the SSID and password. Adding an extra character to the Wi-Fi password displaced everything in the config file by one byte, revealing in plain text the other half. Decoding it was both easy and hard, because the zero-padded zones made it clear that the byte key was incremental and lined up with the byte offset, what took me a lot of time was figuring out that I had to subtract, not XOR. After that I scratched my head about the output still being garbled, but it was just a matter of swapping the two bytes of each ushort in what seems like an unintentional artifact of working on 16-bit blocks, I think.

The header seemed to fit the length of an MD5 checksum, but nothing seemed to match. Then I found out your program suite and documentation. That gave me the neat 2Pslc;u(egmd0-'x salt and a way of enabling SSH and Telnet.

So, yeah. I've had fun. There are some things I wanted to talk about:

1. I noticed that this version of the FIRE block doesn't seem to get parsed by your bcm2cfg program, I have documented most of it. It may be a Netgear extension. Maybe that helps a bit.
2. For some reason Netgear occasionally adds some trailing 01 or 00 byte at the end of the file when the byte count ends up being odd, breaking bcm2cfg's check-summing. The solution is to only check-sum the real size (i.e. until the end of the struct) as stated in the header at offset 0x4C (or 0x5C with the MD5 hash prefix from normal files).
3. The bootloader seems locked, here is the boot-up log that I grabbed by hooking up three dupont cables to a populated header via some USB UART adapter (pinout is GND/TXD/RXD/3v3 when looking from the back/Ethernet side, leave 3v3 disconnected). I'm interested in dumping the firmware: https://github.com/Swyter/netgear-cg3100-config-decoder/blob/master/netgear-cg3100-boot-cm-serial-log.txt
4. I enabled SSH and Telnet in all the interfaces and they do show up now, but SSH seems to be configured to only accept public-key-auth and Telnet doesn't like any of the credentials in the config file. Tried some of the SNMP dumping and key-getting shenanigans shown in the repo and while I could get some of the credentials I couldn't dump anything. Any help here would be neat.

Let me know what you think. ¯\_(ツ)_/¯

[jclehner]

Hi, I've already implemented this encryption method in the past (source), but it's not being used by any profile at the moment.

I'd be interested in a sample GatewaySettings.bin file, so I can test the code on my end.

Your best bet for dumping the firmware is the serial console - it's possible that this can be enabled via a crafted GatewaySettings.bin file. Is SNMP enabled on the device?

[Swyter]

Yeah, SNMP has shown up at some point in the past, I think some responses were erroring out due to some permission-related error. But I managed to list a bunch of interesting "keys".

I'll get you a cleaned out config file to take a look this weekend or whenever I sort out the mess.

[Swyter]

@jclehner Here you go, I altered and redacted some fields a bit, recomputed the checksum and re-encoded it. Hope you don't mind, the structure should be more or less in place. Also noticed that bcm2cfg interprets the NETGEAR_GUEST string that follows net2 as a bunch of MAC addresses, seems like there's another guest network afterwards. Let me know if you need something else.

[Swyter]

@jclehner Woo! Managed to dump the 16MB of flash (some Spansion FL128P SOIC-16 chip) using a Pi Pico with the Libreboot serprog firmware and their handy guide on Linux: sudo flashrom -p serprog:dev=/dev/ttyACM0,spispeed=16M --read router_flash.bin -c S25FL128P......0

Here are the files: router_flash.zip

I have some teeny SUDAKE SDK08 test clips and previously tried to read it in-circuit, but it seems like I couldn't provide enough current, because the poor Pico was probably unintentionally powering the whole board due to the shared 3V3 voltage rail. So it wasn't detected and I gave up last year until now.

I was going to lift the VCC pin and try again, but bent it by mistake. So ended up desoldering the whole thing by using a bunch of blobs of solder and raising each side with a toothpick. Ended up lifting some pads due to overheating, so I probably won't be able to power the router on again, unless I get good at fixing it.

But hope that the dump helps. I've learned a lot to get there, so this is already a success in my book, connecting those test clips to the SMD leads was interesting. :)

[jclehner]

Nice work! I've pushed a few commits - there were some issues with the implementation of the "encryption" for this device, but I've adapted them to match your python scripts. bcm2cfg should now be able to read and write GatewaySettings.bin files from this device.

[jclehner]

If you find the time, please enter the bootloader menu, and then see if the following works (after compiling from source, using the latest commits):

bcm2dump -L io.log -vv dump /dev/YourSerialAdapter flash bootloader bootloader.bin