CGA4233 support #34
Comments
|
Vodafone sent me the gpl patches for a slimier device cga4233vfg, I think it's probably the same device because I asked for gpl sources for cga4233de. |
|
Do you have access to this device's CM console? |
|
Unfortunately no, but I think cmboot.img, cmrun*.img files in the extracted volumes are the cable modem firmware? |
|
Yes. |
|
I have some cmrun files from I extracted from CGM4231 and CGA4131 firmware, they look slimier(no strings except the file name + no clear disassembly). Maybe it's a new firmware format? |
|
I don't think that it's actually a new file format. I've managed to extract the first few megabytes from these files, using |
|
Hmm, I'm attaching the files I got from other modems here, see if you can make any sense of them. |
|
I've had a look at the ARM bootloader, and found the code which seems to initialize the AES key used by the However, the encryption key The key is also copied to Do you have access to the Linux console? |
|
I recently made a backup of a CGM4331COM bcm3390 (xb7-t) in case you want to review it Pinout SDINBDG4-8G emmc isp 1bit up to 8bit (logic voltage is 3.3v) |
|
@jclehner unfortunately no access to the linux console. + uart seems disabled. Old snmp trick to enable uart didn't work either. @arrobazo and I have been trying to get access to the linux console on his device without success. Let us know if you know any exploits to this generation of technicolor devices. |
|
Hmmm. Since you've provided the dumps, I'm assuming you've got hardware access to the SPI NOR flash? If so, you could try setting Apparently, this clears the "unique-key", causing "secure boot" to be disabled. If I'm understanding these devices correctly, this would also disable encryption of the I haven't got a bcm3390 device myself, so I unfortunately can't test this myself. I have yet to come across a reasonably priced used device. |
|
@arrobazo has access to the spi flash of cga4233-sto, maybe he might be able to give it a try. I have a cga4233de, but I don't have the hardware know how/equipment to dump/flash the nor flash. If you live in Europe, you can often find cga4233de on https://www.ebay-kleinanzeigen.de/ for less than 20eur(I think I got mine for 10eur). |
|
@jclehner Hi, so we managed to get access to the CM console(prefer not to tell how yet). But the console doesn't have the flash/read, etc.. commands, or memory read/write commands. We can't dump the firmware from there. |
|
Actually it looks like we can dump the ram 4 bytes at a time using these mibs(https://github.com/copslock/cisco-kusanagi_mibs.snmplabs.com/blob/48bb18954e5db428383114ff13b372b9d0cccfb2/asn1/BRCM-CABLEDATA-ENGINEERING-MIB#L87-L129). I'll try to write a script to dump the whole ram via snmp. |
@madushan1000 I've finally found someone who was willing to ship it to my country. I'm expecting it to arrive later this week. I'll share any insights here! |
|
Hmm... I've hit the first obstacle unfortunately. The SPI flash on my device uses a TFBGA package, not the SOP I was expecting (and hoping for), so I can't just solder to the pins. @arrobazo, did your device come with the flash in an 8-pin SOP? The UART ports (J1000, and J1701) are dead, as expected. I'm assuming one is for the ARM and one for the MIPS processor, and they appear to use the same pinout as on earlier BCM33xx boards (VCC - GND - TX - RX, with the notch at the bottom). There's another 4-pin header I'm not sure about (J1601), and a potential EJTAG header (J1600). @madushan1000 the MIBs you posted don't work on my device, unfortunately. Also, would you mind sharing how you were able to access the CM console (via email if you don't wanna share publicly)? |
|
@jclehner If they are bga both NAND & SPI, I could say where the through holes are located to simply scratch the pcb and you can solder but I must look at the modem again .... about the method I revealed @madushan1000 , it can be said that it is an exploit at the hw level that I discovered in 2017 with the first d3.1 eCos modem that I had ... no problems I can tell you internally it is an extreme measure of obtaining control of the modem ... xD |
That would be much appreciated! |
|
@jclehner I opened the modem and I see that it has tracks directly to the cpu without through holes, I leave you photos the only way that I see possible would be to scrape these tracks.
Well i think cga4233-sto and cga4233de have the same pcb to show you uart data connect vcc |
Thanks a ton, that confirms my suspicion, but I didn't have the means to desolder the chip. Wish me luck soldering to those tiny traces ;)
Not sure what you mean by this exactly!?
What's BBS? |
Well, if you have experience, it is not difficult, just use some enameled wire as thin as possible 0.1mm at least, there are 4 tracks wp, si, so, clk if I'm not mistaken :P
connect not only tx rx gnd, also connect from your ttl-usb vcc3.3v to uart ports. When I use ttl-usb cp2102, if I don't connect the vcc pin I don't get any information
BBS I think it is an i2c bus, in other modems it is labeled with those acronyms ... there are also other broadcom cpu devices that have that labeling |
Turns out I don't have experience, and I hardware-bricked my device in the process. I've found a new one, but I won't be able to work on this until the end of August! |
if they are thin tracks (never so much) did you break them? Well, I hope you can do it next time. I would weld for you but I am on another continent I think very far I guess hehe luck! ... if madushan1000 still hasn't told you what I did to access factory mode on these d3.1 eCos modems, you can talk to me on discord and I'll give you details (arrobazo #5038) greetings |
|
I've finally gotten around to working on this again a little bit. Didn't break the router this time, and I've now got SPI access to the flash. @arrobazo, while @madushan1000 has given me a general idea, I'd still like to hear the details from you. I'd prefer via email, as I don't wanna setup yet another account (discord in this case). My email is [email protected]. |
|
@jclehner excellent, well there I just sent you an email |
|
So I've been quiet on this topic the past months, but I've made some, albeit slow, progress. I've managed to trash the PCB tracks on my first CGA4233 before I even had the chance to to anything meaningful. I had more success with the second device, and I had SPI access to the flash for quite some time. I managed to enable the SNMP engineering MIBs, but apart from that, I found that there wasn't that much you could do, at least at first glance:
Using the engineering MIB you mentioned, I've added an SNMP backend (still work in progress) to The memory map is partially documented in the GPL'd sources of various BCM3390 modems, which I've uploaded in this repository. The memory ranges accessible from the CM side all appear to have Speaking of enabling the engineering MIBs: eventually, I managed to drop my second CGA4233DE, and sure enough, it ripped out a small portion of one of the flash chip's PCB tracks. Now having ordered my third, I wanted to try something less invasive, which to my surprise turned out quite well: the chip-select line of the flash chip has an unpopulated pad (see below), that is much easier to solder to, than those tiny PCB tracks (and you could even pull this off without soldering at all). Using one of those cheapo 10 EUR 24MHz logic analyzers, I guesstimated that the ARM bootloader and Linux firmware side was finished accessing the SPI flash after around 7 seconds, and then it took some time before the CM firmware (which is launched by Linux) kicked in. TL;DR: you can enable engineering MIBs by booting the device, and then waiting 10 seconds before shorting the chip-select line to ground (and leaving it shorted). The device will boot (the web interface will show various values, such as the modem's serial number as "FAILURE"), and the MIBs will be accessible. Be warned though, as this also trashes the permanent NVRAM, including MAC addresses and DOCSIS certificates! Now that I can dump the CM firmware, it should be relatively easy to get serial console or telnet access (to the CM firwmare). Not sure about the Linux part of it yet though. I'll keep you posted.
|
|
@jclehner were you able to get root credentials for RgLinux console? from eCos_cm (switch_console) |
Not yet. On the firmware I'm currently working on, the |
|
I've been busy these past few months, but thanks to a very kind donation of a few non-DE CGA4233, I've now manged to get root access to the modem's Linux console. Note that this method will not work on the CGA4233DE, as its bootloader doesn't appear to use the As mentioned in my earlier posts, these modems use a per-device unique key, the value of which is determined by 32 bytes located at offset
is transformed to (RAM):
Note that this key is used by both the RG (ARM, little endian) and CM side (MIPS, big endian), but due to byte swapping of 32-bit integers, the key used by the former is
The easiest way to get at this unique key is using the above mentioned engineering MIBs. To enable factory mode, use the method of shorting the SPI's chip-select to ground, as soon as the CM side starts booting (if the CM console is disabled, wait around 8-10 seconds). The important part, if you don't want to loose the NVRAM data (and thus MAC addresses, DOCSIS certificates, serial numbers, and the like), is to keep the CS line shorted until you reboot the device (that way, attempts by the firmware to write to the flash will also be blocked). Now verify that factory mode has indeed been enabled: You now have read/write access to the CM firmware's RAM. Using Now, you'll have to dump the SPI flash. In order to access the Linux console, we need to modify the ARM bootloader's (aka BOLT) environment variables. These are located in the At the moment, The Linux console is disabled by the Now re-encrypt the partition using Make sure to write the partition to both You should now have access to a root shell. Note that the router will reboot after ~60 seconds unless you kick the watchdogs: The busybox version on the router doesn't have the To continue the normal boot process, run More detailed documentation about the BOLT environment variable storage format, and the |
|
Here's a link to the NOR and NAND flash dumps of a CGA4233EU: https://github.com/jclehner/bcm2-dumps/tree/master/cga4233/eu |
Hi, is this the same key used to validate the firmware image (Secureboot)? or is this key just used for nvram? |
|
No. The bootloader images are signed using SHA-256 with 2048-bit RSA. The flash offsets of the public key modulus, signatures and image data are:
I'm starting do doubt this earlier assumption of mine. Since there are 256 bytes between Maybe this blob is another signature that's verified by the CPU itself? It might then copy its unique key to RAM address I'll try flashing a NOR flash image from another device to see if the unique key changes at all... |
is it possible to override this with our own key + signatures? secureboot is not secure unless the key used to validate the signature meets the following condition
it seems like if they store it on the flash, then it may be possible to change. for reference, the Puma7 Intel cable modem chipset stores the public key on the CPU via fuses, which are blown in the factory and cannot be changed after it is fused by the manufacturer with their public key. this meets both conditions (except if you can swap the entire CPU with one which is not fused, then you can violate condition 2) |
|
Any attempt to modify these keys leads to the device refusing to boot. So, as mentioned, I'm assuming that there's a public key stored in the CPU itself, which is used to validate the initial bootloader stage (including the other keys). |
|
Having said all that, I forgot to mention that the root filesystem isn't verified or encrypted at all, only the bootloader and Linux kernel (at least on the device I'm currently working with). There are however different security levels apparently. The CGA4233DE was much more locked down than the EU variant I'm currently working with. On the EU variant, once you have the device's unique AES-256 key (or root access to Linux), you can modify the bootloader environment variables to change the This doesn't work on the DE variant, as its |
Does anyone still happen to have this dump? |
LOL. for both CM (eCos core, maybe not a rootfs..?) and RG? |
|
Small update for anyone interested: The device-unique key can be dumped from the CM bootloader. Its command-line interface can be accessed by pressing The key can be dumped using the following command: Note that, even without the Also, regarding secure boot, and my earlier assumptions regarding the data at flash offset 0x140:
This must indeed be another signature. The contents at this offset do not affect the device key, but the key is apparently copied to |
|
I don't remember the details anymore. Is bootloader uart enabled by default for EU version of the router? I need to dig out my DE version and check. |
It is on my EU devices. Not sure about the DE version, since I haven't got any anymore. |
|
Another (possibly) interesting detail, regarding the BOLT bootloader: this appears to be based on CFE, or if it isn't it does share quite a bit of code. For example, compare this function from bcm63xx-cfe static int ui_cmd_setenv(ui_cmdline_t *cmd,int argc,char *argv[])
{
char *varname;
char *value;
int roflag = ENV_FLG_NORMAL;
int res;
varname = cmd_getarg(cmd,0);
if (!varname) {
return ui_showusage(cmd);
}
value = cmd_getarg(cmd,1);
if (!value) {
return ui_showusage(cmd);
}
if (!cmd_sw_isset(cmd,"-p")) {
roflag = ENV_FLG_BUILTIN; /* just in memory, not NVRAM */
}
if (cmd_sw_isset(cmd,"-ro")) {
roflag = ENV_FLG_READONLY;
}
if ((res = env_setenv(varname,value,roflag)) == 0) {
if (roflag != ENV_FLG_BUILTIN) env_save();
}
else {
return ui_showerror(res,"Could not set environment variable '%s'",
varname);
}
return 0;
}with this BOLT function (decompiled using Ghidra): undefined4 FUN_1361d68c(int *param_1,undefined4 param_2,undefined4 param_3,undefined4 param_4)
{
int iVar1;
int iVar2;
undefined4 uVar3;
int iVar4;
uint uVar5;
iVar1 = FUN_1361ca1a(param_1,0);
if ((iVar1 == 0) || (iVar2 = FUN_1361ca1a(param_1,1), iVar2 == 0)) {
uVar3 = FUN_1361c35e();
return uVar3;
}
iVar4 = FUN_1361c9ec(param_1,"-p");
uVar5 = (uint)(iVar4 == 0);
iVar4 = FUN_1361c9ec(param_1,"-ro");
if (iVar4 != 0) {
uVar5 = uVar5 | 2;
}
iVar4 = FUN_1361c9ec(param_1,"-h");
if (iVar4 != 0) {
uVar5 = uVar5 & 0xfffffffe | 4;
}
iVar2 = s_setenv(iVar1,iVar2,uVar5);
if (iVar2 != 0) {
uVar3 = FUN_1361c2c0(iVar2,"Could not set environment variable \'%s\'",iVar1,param_4);
return uVar3;
}
if (-1 < (int)(uVar5 << 0x1f)) {
FUN_13617d90();
}
return 0;
}Also checkout this newer CFE version, which also includes ARM code. |
@arrobazo provided a nand dump of CGA4233-sto here(nox-x/TG3442DE-Teardown#3 (comment)). I wasn't able to extract the main filesystem(looks like it uses a custom nand controller) but I was able to extract the spi flash dump which seems to store the permnv and dynnv.
I can upload the extracted files, but just run binwalk on the smaller file in the archive and it'll dump a bunch of jffs2 filesystems.
Not sure if this is enough to add support, but please take a look when you have some time :)
The text was updated successfully, but these errors were encountered: