Vendor open source release

[Malvineous]

Interesting work here! FYI the vendor has made an open source release at https://sourceforge.net/projects/c8200-cable-modem.arris/files/

I haven't tried building it yet but it looks like it might be missing some information, however they do have an e-mail address you can contact for open source questions, so it may be possible to fill in any gaps too with their help.

[net-wayfarer]

Thanks for the heads up! I have added the source file and such to my fork.

Due to the lack of interest/activity on this project, I am all ears to new contributors, especially those with spare hardware to experiment tinkering with. I haven't heard anything new from @rikka0w0 for few years, but am aware that this particular variant is even more locked down compared to the US variant/SB8200. Especially there's probably no headers to directly access the serial console. Interests were further hampered when NBN released firmware that disabled the internal LAN/WebUI.

Asides from that, the last time when I was more actively researching, I discovered the source codes and wiki from RDK-B via rdkcentral.com may help shed insight on the files cm_dyn.bin as well as potentially cm_perm.bin.

[Malvineous]

Interesting! I poked around with a spare unit I have, but as it's spare because it was replaced as faulty, it's difficult to know whether what I'm seeing is correct or not. For example I can only ping the unit for a few seconds after powerup, whereas last time I tried this with my own modem, I could still access the web interface until it finished connecting to the HFC network.

This spare unit does not have any serial console connectors, nor any unpopulated headers for them. With trial and error I was able to find some sort of UART that spewed out messages like this:

   0:00:00.000: LNA type selected is 3
   0:00:00.000: LAN mode 0 is selected 
   0:00:00.000: #############BWFE_3x7x_P_CPPM_Init
   0:00:00.000: Chip ID: 3390, Family: 3390, Rev: 0x10
   0:00:00.000: BCM3390, F/W Ver: 10.4.7018.1 Git Commit ID: d31e0330
   0:00:00.000: Sys. F/W: ROM CRC: 0xE229EB20, (Pre-stored: 0xE229EB20)
   0:00:00.000: Sys. F/W: App CRC: 0x0D3F9162, (Pre-stored: 0x0D3F9162)
   0:00:00.000: BLNA_P_BCM3432_Set_Power 8
   0:00:00.099: BWFE_P_PowerUp (coretype 0)
   0:00:00.099: BWFE_3x7x_P_Init
   0:00:00.099: ********************************************************************
   0:00:00.099: ***************3390/3158 START AIF INITALIZATION********************
   0:00:00.099: ********************************************************************
   0:00:00.105: Digital PLL tuning...
   0:00:00.105: Digital PLL tuning achieved in 40 us
   0:00:00.113: BLNA_P_BCM3432_Set_Power 8
   0:00:00.165: MDAC = 3 Slice= 1 Ping
   0:00:00.165:                  EQ_Tap0 =  -0.000148  EQ_Tap1 =   1.006978  EQ_Tap2 =  -0.018477  EQ_Tap3 =  -0.000367 DC_Tap =  -0.490317
   0:00:00.165:                 ERR_DMX0 =   0.000383 ERR_DMX1 =   0.000384 ERR_DMX2 =   0.000384 ERR_DMX3 =   0.000381 AvgErr =   0.000383
   0:00:00.175: MDAC = 3 Slice= 1 Pong
   0:00:00.175:                  EQ_Tap0 =   0.000120  EQ_Tap1 =   1.005930  EQ_Tap2 =  -0.018159  EQ_Tap3 =   0.000230 DC_Tap =  -0.397662
   0:00:00.175:                 ERR_DMX0 =   0.000388 ERR_DMX1 =   0.000383 ERR_DMX2 =   0.000381 ERR_DMX3 =   0.000383 AvgErr =   0.000384

There are no Linux kernel messages so I'm guessing this is the eCos UART, but not sure. I have it listed as C37205 which I think was the label next to the PCB pad that was transmitting these messages.

I had a look at the firmware dump but all I could get out of it was those bin files. There should be a Linux kernel and an initramfs image somewhere too, but I haven't found that yet - it doesn't seem to be in any of the public ROM dumps, so either it's compressed somehow or there's another flash chip that hasn't been dumped yet.

[net-wayfarer]

If you could momentarily ping the device at the beginning, it would have booted into its "rootfs" as it would have gained networking capability, looking at SB8200.bootlog. It might have disabled ping and such sounds more like it was configured that way rather than being a hardware fault. At any rate I am rather envious of your position. I don't have a spare modem to test, nor the necessary tools needed for obtaining the data out of the ROM.

As for that BCM3432, the closest thing I could find about it is that it seems to be related to the cable/coax transceiver (and here). The ROM data is deffo elsewhere on the board, not in the part where you have provided. Though nice find either way.

From memory, the firmware dump provided by @rikka0w0 seemed to contain information about the DTB (and here) was the best I could find. All that is just describes the hardware features to the kernel. The rootfs data (where it should contain features such as networking, userland binaries like ls and webUI) is also missing, but I am suspecting that would be compressed using squashfs considering how CM8200P2 is a very nerfed variant of SB8200.

Naturally the kernel and initramfs/initrd would also be compressed, most likely bzipped.

[net-wayfarer]

I also had a very brief look at the zip file that you mentioned at the beginning, the one that is on sourceforge, it is also missing data about rdp_runner.tar.gz. So in all likely case, the provided sources only has components where it was shared under open source license, but proprietary components aren't offered.

That is kinda a given considering the way broadcom works, hardly surprising. I doubt contacting commscope directly would be beneficial as they are also likely to be bound to broadcom's NDA and various other agreements. It also reminded me of the components freely accessible as a normal user on RDK central website; whatever components that shares open source license would be shared in a more free manner, but all others are kept a trade secret, unless you're one of their big customers, like comcast in the US. The stuff that is hosted on RDKcentral under comcast are private, but I do suspect they have a huge involvement in the whole DOCSIS technology as a consumer of broadcom.

In a more sarcastic way I am reminded of the situation with pfizer vaccine shots and how it is rolled out here in Australia.

At any rate, I speculate webUI and certain userland customisations are possible, considering that the toolchain is available. However, customising the internal hardware configuration is highly unlikely, as there was at least one precedence with hacking cable modems in the past over in stateside. So in a broad way of describing it, it might be possible to do limited modifications to the modem, but nothing fancy like making use of locked frequencies.

[Malvineous]

I don't think the pings I am seeing are from the rootfs, as they appear too soon after powerup (within seconds) so I suspect it's the bootloader. Many Linux-based routers will give you a few seconds to TFTP an image to boot as a means of recovery so I think this is what it is. The line in the bootlog you linked to is when the network interface comes up, but it won't respond to pings until an address is configured after that. My guess is that they configure the kernel to ignore pings before adding the 192.168.100.1 IP address, or possibly they don't even add the IP at all now.

The Linux kernel already compresses itself (along with the initramfs image) so usually it's just included in the flash memory as-is, as there would be little point doubly-compressing it. But it means it can usually be found pretty easily in a ROM dump via signature matching. I am surprised though if they are using multiple flash chips, as that seems like the design was cobbled together from parts rather than designed neatly from the ground up.

It is true CommScope may not be able to help, but it probably can't hurt to ask. I would do so myself except I haven't had a chance to properly look at what's needed to build the image.

If you want a spare CM8200 to test with, have a look on eBay and Gumtree. They seem to show up there from time to time as people forget they are supposed to leave them behind when they move, and then sell them cheap when they realise they can't use them at their new place. You have to search for terms that people use when they don't know what it is, like "nbn box" or similar. I've seen a few on there for under $20.

My interest in getting into the firmware is that the CM8200 can bond its two Ethernet interfaces to give a 2 Gbps link (within the limitations of bonding) so I am curious whether this would allow you to exceed 1 Gbps on an NBN gigabit plan. I don't think there would be any risk with the law because NBN already limit you to an average speed of 750 Mbps, so I imagine if you could hit 2 Gbps you'd just get shaped to 750 Mbps quicker. So since you aren't getting anything extra for free I don't think anyone would have a major issue, although if you drew too much attention to it and had everyone reflashing their modems it might be a different story.

[rikka0w0]

I think the Linux console was previously available on unsoldered header J2501 (same as SB8200). There are two unsoldered components near J2501, they should be resistor jumpers, and I just short-circuited them. Out of the 4 pins, two are obviously Vcc and GND. The rest two must be Rx and Tx for UART. Channel 0 goes to the 3.3V Vcc, and the other two channels go to the other two pins. Upon power-on, one pin goes high for about 1.36 seconds. Just before it goes back to low, the other pin goes high for 15uS. Then both pins are low. No further activities have been observed.

https://snipboard.io/ZCw5nk.jpg

Since there's a clear sign that the SoC is controlling the UART headers, this makes me feel that the serial ports are disabled on purpose.

I had a look at the source code, it contains a 3.14 Linux kernel and some utilities for building the rootfs. I will try to build it once I have time.

I have 4 used CM8200, which I can give you for free if you need it for testing. I'm in Sydney.

[Malvineous]

It could well be that the UART headers are disabled on purpose. Do you get any output from the eCos UART? I do on my test unit, but it has not been active for a few years so it would no doubt be running older firmware.

Unfortunately those PCB headers have been removed on the latest "non diag" models. Not even the vias are there any more. So unless there's some other place that the traces go through there's little chance of accessing them on later models. Here's a pic of my sample unit to illustrate:

[rikka0w0]

That's a bad news to hear. But I'm wondering how they flash the firmware in the first place? According to some rumors, the modem will attempt to communicate with a certain local IP address (start with 172) and start the firmware flashing utility if succeed. If that's true, there is a chance that the UART interface does not support firmware flashing at all. Perhaps we should leave the UART alone and patch the rootfs and/or the kernel in the NAND flash directly. Someone has dumped the SB8200's firmware, there's a kernel and rootfs.

[Malvineous]

I'm sure the modem supports TR-069 which would allow NBNCo to remotely push firmware updates out to every device. Many cable and DSL modems have supported this protocol for years.

If you can get a Linux console on the UART then you should be able to reflash the firmware, as it's as simple as copying a file into a /dev/mtdblock file, which will flash it to the chip. Getting that Linux console is the tricky bit. But doing so means you can reflash a device without opening it which would be useful.

Where is the kernel and rootfs in the dumped firmware? I have only seen the one dump in these git repos and it doesn't seem to contain a kernel or rootfs. Where did you see those?

[rikka0w0]

Where is the kernel and rootfs in the dumped firmware? I have only seen the one dump in these git repos and it doesn't seem to contain a kernel or rootfs. Where did you see those?

I only dumped the SPI Flash, which contains the DTB and some other files (not related to linux). There is a NAND flash on the PCB, from the SB8200's boot log, it can be sure that the kernel and the rootfs is stored inside the NAND flash. Currently I'm working on my thesis submission, once I finish this, I will try to dump the rootfs. My plan is to desolder the NAND flash chip and use an FT2232 USB adapter to bit-bang the chip. According to the internet articles, it is easy to dump the "raw" data of the NAND chip, but the "raw" data contains more than the "real" data, e.g., ECC, a table for bad blocks... The good news is that there are only less than ten combinations, so we can try out each one and find out which format it is using. After we compile our own kernel or customized the rootfs, we generate a new "raw" binary blob and flash it back to the NAND. (I'm an electrical engineer with plenty tools for soldering)

[Malvineous]

I don't have a spare modem to test, nor the necessary tools needed for obtaining the data out of the ROM.

If anyone is interested, I just picked up another spare CM8200B for $0.99 plus shipping. There are another couple available on eBay at the moment:

• https://www.ebay.com.au/itm/385004647168
• https://www.ebay.com.au/itm/385004609650

[rikka0w0]

I have 3 spare CM8200B.

If I'm correct, the rootfs and kernel should be in the NAND, the bootloader and the device tree should be in the SPI flash.

[Verequies]

Unsure if this is still ongoing. But I have managed to dump the CM8200B NAND. Its a Macronix 3V, 1G-bit NAND Flash Memory.

I have ran a binwalk but so far unable to figure out where to go. But definitely no straight forward rootfs.

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             Linux kernel ARM boot executable zImage (big-endian)
6422528       0x620000        Linux kernel ARM boot executable zImage (big-endian)
55154969      0x3499919       MySQL ISAM index file Version 4
57008228      0x365E064       CRC32 polynomial table, little endian
57045067      0x366704B       mcrypt 2.5 encrypted data, algorithm: "lMn", keysize: 93 bytes, mode: "M",
57659064      0x36FCEB8       mcrypt 2.5 encrypted data, algorithm: "P", keysize: 27725 bytes, mode: "x",
59853188      0x3914984       mcrypt 2.5 encrypted data, algorithm: "D", keysize: 19282 bytes, mode: "n",
63028963      0x3C1BEE3       eCos RTOS string reference: "ecos"
67462872      0x40566D8       bix header, header size: 64 bytes, header CRC: 0xFFF90000, created: 1977-12-05 06:23:25, image size: 238056704 bytes, Data Address: 0xE60EA00, Entry Point: 0xC983A00, data CRC: 0x0, image name: ""
67662701      0x408736D       TROC filesystem, 1227376974 file entries
70941300      0x43A7A74       SHA256 hash constants, big endian
71115944      0x43D24A8       Cisco IOS microcode, for ""
72670659      0x454DDC3       eCos RTOS string reference: "ecosttpokrof iht rg s puo"
102101542     0x615F226       mcrypt 2.5 encrypted data, algorithm: ":", keysize: 27904 bytes, mode: ")",
103995782     0x632D986       mcrypt 2.5 encrypted data, algorithm: "5C", keysize: 10541 bytes, mode: "0",
105761700     0x64DCBA4       Sega MegaDrive/Genesis raw ROM dump, Name: "s/dldragalsk30ev",
106315592     0x6563F48       Sega MegaDrive/Genesis raw ROM dump, Name: "s/dldragalsk30ev",
106745868     0x65CD00C       Sega MegaDrive/Genesis raw ROM dump, Name: "CT_BASDPGIKCERON", "c",
107756810     0x66C3D0A       mcrypt 2.5 encrypted data, algorithm: "8", keysize: 22645 bytes, mode: "-",
108413472     0x6764220       Sega MegaDrive/Genesis raw ROM dump, Name: "PO_DTM_Thc",
110506764     0x696330C       MySQL MISAM compressed data file Version 5
110864276     0x69BA794       CRC32 polynomial table, little endian
111143913     0x69FEBE9       ZBOOT firmware header, header size: 32 bytes, load address: 0x97494F52, start address: 0x366465EA, checksum: 0x84626E6C, version: 0x74989D2A, image size: 17130528 bytes

[Verequies]

Made a bit of progress. After reading this article, it is clear that the endianess is wrong. Following this guide I converted the NAND dump from Big Endian to Little Endian.

Reran binwalk and got the following:

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             Linux kernel ARM boot executable zImage (little-endian)
27120         0x69F0          gzip compressed data, maximum compression, from Unix, last modified: 1970-01-01 00:00:00 (null date)
6623232       0x651000        Linux kernel ARM boot executable zImage (little-endian)
6648304       0x6571F0        xz compressed data
6648736       0x6573A0        xz compressed data
13246464      0xCA2000        UBI erase count header, version: 1, EC: 0x9, VID header offset: 0x800, data offset: 0x1000

Definitely a clear rootfs there.

[rikka0w0]

Made a bit of progress.

Great to hear that! Is that a raw flash dump (with OB data)? Theoretically if we replace that Linux Kernel with our own, we can run OpenWrt. Would you like to share the dumped flash content? Also, did you have a look at the serial interface? My one is not interactive and seems to be disabled.

[yeehawitsjakester]

Hey there, sorry to pop in on an old thread. Saw this from Whirlpool and DSLReports, I wanted to contribute in any way I can. I've got a North American(?) Arris CM8200A (which seems to resemble pretty closely to the CM8200P2 I see in your photos, Rikka). I've got my own dump on the SPI Flash memory as well I have been scanning through using both Binwalk and Bless Hex Editor.

Modem is using a Spansion S34ML01G200TFV00 NAND it seems with a Broadcom BCM3390ZRKFSBC.

Saw this modem for 10$ at a local thrift store and it looks almost close to the modems issued by a local small-town ISP here so it peeked my interest to tear it apart and look in the software.

Any modification attempts or new flashes I would be happy to test, although currently looking for tools to flash the NAND (I only have a CH341A for the SPI right now). Question I have before I really tear this apart is, is there a current method to read/write on the NAND? Looking into using an Arduino since I see this method here and there but also curious if it would be possible using the SPI flash at all.

Should note I am relatively new to some of this stuff, kinda learning along the way but happy to help.

[rikka0w0]

Hey there, sorry to pop in on an old thread.

The project is still going on, and helps are always welcomed! Start a pull request if you want to add more information to this repo.

I recently ported OpenWrt to a xDSL modem(also uses broadcom soc): https://openwrt.org/inbox/toh/sagem/f_st3864op

and I gained a lot of experiences on the broadcom stuff...

I think we need to figure out:

1. what kind of bootloader the cable modem is using? CFE perhaps?
2. the eCos and Linux definitely are running on different cores. Are they on independent CPUs or on different cores of the same CPU?
3. do they share the same bootloader?
4. does the bootloader enforce signed firmware?

Someone managed to run linux on a BCM3380 device: https://openwrt.org/toh/cisco/epc3925?s[]=bcm3380

This tool might be useful: https://github.com/jclehner/bcm2-utils