Linksys E900 Software Download for Mac
CFE on bcm47xx devices allows running/installing firmware using a lot of dissimilar methods. Usually only few of them are available, depending on the choice of manufacturer who compiled and installed CFE. Almost of the methods crave access to the CFE console which means you need to adhere a serial console. To get a prompt just keep CTRL+C pressed (or ESC for some models) while powering the device up.
Below is the (hopefully) completed list of methods. The best idea is to find a one looking the best/easiest and cheque if it works on your device.
Some CFEs start TFTP server for few seconds right after hardware initialization. This is probably the only method of installing firmware with CFE that doesn't crave serial panel. You simply accept to requite CFE 1-3 seconds to initialize the switch and then set your IP and start sending the firmware. If you have a serial panel, you can identify TFTP server running with the following letters:
_tftpd_open(): retries=0/3 _tftpd_open(): retries=1/3 _tftpd_open(): retries=two/three
Unfortunately even if this method is available for you, it may not work. For case on Linksys E900 information technology fails after uploading firmware with the:
CMD: [boot -raw -z -addr=0x80001000 -max=0x1851e50 -fs=retentiveness :0x807ae1b0] Loader:raw Filesys:memory Dev:eth0 File::0x807ae1b0 Options:(goose egg) Loading: PANIC: out of retentiveness!
Please note that CFE may require a device specific firmware prototype (with a special header), otherwise (when using a generic .trx) information technology may fail with the:
CMD: [flash -ctheader -mem -size=0x4c1000 0x807ae1b0 flash1.trx] Reading from 0x807ae1b0: Code Pattern is incorrect! (E900) The file transferred is not a valid firmware image.
CFE about always contains wink control that may behave like both: TFTP client and server. The generic usage is following:
wink [options] source-file [destination-device]
This is very important to pass [destination-device] argument or CFE will write to the flash0 device overwriting the CFE! To run into a list of available devices endeavour prove devices command.
Regarding [options] there is ane of import one chosen -noheader and if you lot happen to be Linksys owner, there is likewise -ctheader:
-noheader Override header verification, flash binary without checking -ctheader Check header of CyberTAN
By default CFE validates received firmwares checking if they incorporate a device-specific header. That won't permit installing firmware created for a dissimilar device. If you want to install trx firmware directly (image without an extra device-specific header), you may use -noheader option.
TFTP client
In this scenario nosotros will tell CFE to connect to the remote TFTP server, download firmware and install it on the flash. This means that source-file should be fix to host:path/firmware.bin format. Instance usage:
flash -noheader 192.168.1.2:bin/brcm47xx/openwrt-brcm47xx-squashfs.trx flash0.trx flash -ctheader 192.168.1.two:bin/brcm47xx/openwrt-e900_v1-squashfs.bin flash0.trx
Unfortunately on some devices this method makes CFE hang right after downloading the firmware and it gets never written to the flash.
TFTP server
It'southward too possible to brand flash start a TFTP server that will accept firmware for few seconds. The flim-flam is to put : every bit a source-file. Example usage:
Example file to ship: flash -noheader : flash0.trx openwrt-brcm47xx-squashfs.trx flash -ctheader : flash0.trx openwrt-e900_v1-squashfs.bin
Using upgrade command
Some manufacturers provide an upgrade command that is commonly but an alias to the parametrized wink executed in a loop. Of course it'southward much less flexible that the flash command, but also has some advantages like:
The near common (and probably safe) usage is to call it with lawmaking.bin parameter:
CFE> upgrade lawmaking.bin CMD: [upgrade lawmaking.bin] CMD: [flash -ctheader : flash1.trx] Reading :: _tftpd_open(): retries=0/iii
Another possible parameters:
boot.bin Usually works the same way equally lawmaking.bin linux.bin Doesn't e'er work ("flash0.0: Device not found") cfe.bin Alarm! Writes to the flash1.kick, y'all don't desire to utilise it! Unfortunately only few manufacturers decide to enable it, only it's probably the near user friendly mode of installing firmware. 
Every bcm47xx CFE has a pocket-size NVRAM backup that is used to restore the main NVRAM when information technology gets deleted or corrupted. If you want to change that backup NVRAM, see changing defaults page.
bcm63xx CFE is totally different when compared with bcm47xx. The NVRAM is totally different, without any settings stored outside the CFE partition, they are totally embedded into CFE. The CLI has dissimilar commands, probably with less options. And almost always there is a spider web server available for flashing. Less options merely more fool-proof.
To access CFE yous need to adhere a serial console. To get a prompt just printing whatsoever key while powering the device up.
This is a typical output when starting up the CFE and inbound the CLI:
DGND3700 Boot Code V1.0.8 CFE version one.0.37-104.4 for BCM96368 (32bit,SP,Be) Build Engagement: Monday Feb 21 17:59:46 CST 2011 (finerain@moonlight) Copyright (C) 2000-2009 Broadcom Corporation. Parallel flash device: name AM29LV320MT, id 0x2201 size 32768KB Total Wink size: 32768K with 256 sectors ethsw: found bcm53115! Chip ID: BCM6368B2, MIPS: 400MHz Main Thread: TP0 Full Retentiveness: 134217728 bytes (128MB) Boot Address: 0xb8000000 Lath IP address : 192.168.one.i:ffffff00 Host IP address : 192.168.one.2 Gateway IP address : Run from flash/host (f/h) : f Default host run file name : vmlinux Default host flash file name : bcm963xx_fs_kernel Kicking delay (0-nine seconds) : one Board Id (0-eleven) : 96368MVWG Number of MAC Addresses (1-32) : ten Base MAC Accost : xx:4e:7f:c0:b5:4c PSI Size (1-64) KBytes : 24 Enable Fill-in PSI [0|1] : 0 System Log Size (0-256) KBytes : 0 Primary Thread Number [0|1] : 0 *** Printing any key to end auto run (1 seconds) *** Auto run 2nd count down: 1 CFE> CFE>
It'due south probably the most user friendly style of installing firmware. Merely sometimes some manufacturers decide to disable it (very uncommon).
The default IP address of CFE is almost always 192.168.1.1. You should use a static IP in your PC since there isn't DHCP server bachelor when running CFE.
For accessing this spider web interface:
-
Unplug the power source
-
Press the RESET button at the router, don't release it yet!
-
Plug the power source
-
Wait some seconds
-
Release the RESET push button
-
Browse to
http://192.168.1.ane -
Ship the new firmware and wait some minutes until the firmware upgrade cease.
Note: The RESET push doesn't work in some routers. There are some alternatives to terminate CFE before loading the current firmware when the RESET push button didn't work:
In modernistic SoC releases, Broadcom is integrating a Secure Boot arrangement based in a chain of trust.
The following information is deduced from the sources available and therefore must exist taken with circumspection.
Upwards to date, there are three generations of Secure Boot that embraces the following models:
Mechanism
-
The SoC has as manufacturing plant settings, most probably in the OTP fuses, the individual key unique per each model and as well 2 keys AES CBC (ek & iv). This is the Root of Trust which is known by OEM.
-
During kick, the PBL (Primary Boot Loader coded in the SoC) will search for storage peripherals e.one thousand. NAND or NOR SPI. If institute and then loads a minor portion from offset of storage into memory. Exact amount may depend on model and storage but most typically 64kb. In the sources this clamper is chosen CFEROM.
-
One time loaded the CFEROM, the PBL will analyse the structure, which is a compound of unlike chunks: valid header, magic numbers, signed credentials, CRC32, actual compiled code, etc. In the cease, the PBL will decide if CFEROM meets the construction required and it is properly signed. If this is and then, so the PBL will execute the compiled code encapsulated. Note that this code is usually not encrypted and therefore tin can exist detected with naked eyes.
-
Typically, CFEROM will start PLL's and full memory bridge. Well-nigh probably doesn't need to run a storage driver since it is already working. And so it will leap to CFERAM location as coded
-
CFERAM binary is encoded in JFFS2 filesystem. It must see a sure structure as CFEROM. The compiled code is unremarkably LZMA compressed and AES CBC encrypted, rendering the resulting binary absolutely meaningless.
Secure modes
Several modes can exist chosen inside the CFEROM, putting appropiate headers:
CFEROM structure
The actual implementation differs depending on the generation and the storage media, but roughly this guidelines are true:
GEN1
WIP
GEN2
| Kickoff | Length | Clamper | Element | Value | Comments |
|---|---|---|---|---|---|
| 0x0 | 0x14 | Unauth header | |||
| 0x0 | 0x4 | Magic number 1 | 0x0001B669 | In decimal = 112233 | |
| 0x4 | 0x4 | Magic number 2 | 0x0006CC7E | In decimal = 445566 | |
| 0x8 | 0x4 | Version | 0x00000001 | ||
| 0x0c | 0x4 | SBI_length | variable | Length in bytes of Unauth Header + SBI | |
| 0x10 | 0x4 | JAM CRC32 | variable | JAM CRC32 of all the previous elements | |
| 0x14 | variable | SBI | |||
| 0x14 | 0x2 | type | 0x00 | This seems a legacy field | |
| 0x16 | 0x2 | ver | 0x00 | This seems a legacy field | |
| 0x18 | 0x2 | len | 0x00 | This seems a legacy field | |
| 0x1a | 0x2 | config | 0x00 | This seems a legacy field | |
| 0x1c | 0x180 | mfg.oem.bin | variable | Bodily construction has been reversed. | |
| 0x19c | 0x100 | mfg.oem.sig | variable | SHA256 signature of mfg.oem.bin. Key must be in SoC | |
| 0x29c | 0x180 | op.cot.bin | variable | Unknown pregnant "OP" | |
| 0x41c | 0x100 | op.cot.sig | variable | SHA256 signature of op.cot.bin. Primal must be in SoC | |
| 0x51c | variable | cferom.bin | variable | This is the actual machine code that will be executed | |
| SBI_length-0x104 | 0x100 | SHA256 sig | variable | This is the SHA256 signature of all the previous SBI elements. Cardinal is the one declared in mfg.oem.bin | |
| SBI_length-0x4 | 0x4 | JAM CRC32 | variable | This is the JAM CRC32 of all the previous SBI elements except SHA256 sig. |
From the sources, we can opposite the structure of mfg.oem.bin:
| Kickoff | Length | Chunk | Element | Value | Comments |
|---|---|---|---|---|---|
| 0x0 | 0x148 | mfg.oem.bin | |||
| 0x0 | 0x6 | Signature header | 0x000000010242 | This seems like a magic give-and-take | |
| 0x6 | 0x2 | Mid | 0x1234 | This value must match the SoC. We know for case that bcm68380 has 0xffd0 | |
| 0x8 | 0x100 | KrsaMfgPub.bin | variable | Modulus of the new public key that we want to use | |
| 0x108 | 0x20 | mfg.ek.enc | This is an encrypted file of the new AES CBC fundamental. The encryption key must be in SoC | ||
| 0x128 | 0x20 | mfg.iv.enc | This is an encrypted file of the new AES CBC key. The encryption key must exist in SoC |
GEN3
In the search of the RoT password
If the PBL password was known, nosotros could develop whatever bootloader with or without the CoT feature. It is almost likely that this will never be exposed being Broadcom and so obscure with their products.
However, nosotros must remain attentive to the GPL bundles that pop up from time to time.
More precisely, in the following repo RoT lies a capital slice of information.
Basically the readme.txt file is maxim that at least for GEN3:
The file Krot-mfg-encrypted.pem is aes-128-cbc encrypted with the same pass-phrase that encrypts the files bcm63xx_encr*.c located in the cfe/cfe/board/bcm63xx_btrm/src direcotry. After the file is decrypted, the pem file contains both the private and public portion of the RSA key Krot-mfg.
This means:
Therefore nosotros must focus on finding "bcm63xx_encr3_clr.c" in social club to support GEN3 CoT. We might call up that there must be a file "bcm63xx_encr2_clr.c" for GEN2 and so on.
Sources
If you want to install a firmware using TFTP, follow these steps (as an culling to the higher up install process).
This is a session of flashing via TFTP:
CFE> f 192.168.1.35:firmware.bin Loading 192.168.1.35:firmware.bin ... Finished loading 2686980 bytes Flashing root file organization and kernel at 0xbfc10000: .......................................... . *** Epitome flash done *** ! Resetting board...\0xff
At the begining of CFE, exterior the NVRAM expanse at that place exist 3 interesting parameters:
| Offsets | parameter | possible values | size | |
|---|---|---|---|---|
| 0x010-0x013 | BpGetSdramSize | 8MB 1 Chip 16MB 1 CHIP 32MB 1 CHIP 64MB ii Chip 32MB 2 CHIP 16MB 2 CHIP 64MB 1 CHIP | 0 1 2 3 4 5 6 | 4 bytes (unsigned long) |
| 0x014-0x017 | BpGetCMTThread (Main Thread) | core0 core1 | 0 1 | iv bytes (unsigned long) |
| 0x570 | CFE Version | any | ||
NVRAM
The NVRAM is located between offsets 0x580 to 0x97F. The size is 1KB (1024 bytes).
In this motion picture you tin run into the NVRAM highlighted:
| NVRAM version<five (usually found in BCM6338, BCM6348, BCM6358) | |||
|---|---|---|---|
| Offsets | parameter | size | |
| 0x580 | NVRAM Version | 4 bytes | |
| 0x584 | BOOT LINE | east=192.168.1.i (Lath IP) h=192.168.1.100 (Host IP) g= (Gateway IP) r=f/h (run from flash/host) f=vmlinux (if r=h) i=bcm963xx_fs_kernel d=3 (delay, 0=forever prompt) p=0 (boot prototype, 0=latest, ane=previous) | 256 bytes |
| 0x684 | Board ID | 16 bytes | |
| 0x694 | reserved | 8 bytes | |
| 0x69C | Number MAC Addresses | 4 bytes | |
| 0x6A0 | Base MAC Accost | six bytes | |
| 0x6A6 | reserved | 2 bytes | |
| 0x6A8 | CheckSum | 4 bytes | |
| 0x6AC | — EMPTY — | 724 bytes | |
 | Not all bcm63xx CFEs share this structure, some CFEs seem to have additional parameters like PsiSize, Country, SerialNumber, etc. As a result of this the CheckSum maybe located at different offsets and therefore the adding is dissimilar. The EMPTY space isn't used to calculate the CheckSum |
| NVRAM version>=5 (commonly found in BCM6328, BCM6362, BCM6368, BCM6816) | |||
|---|---|---|---|
| Offsets | parameter | size (bytes) | |
| 0x580 | NVRAM Version | 4 | |
| 0x584 | BOOT LINE | due east=192.168.1.1 (Board IP) h=192.168.i.100 (Host IP) g= (Gateway IP) r=f/h (run from wink/host) f=vmlinux (if r=h) i=bcm963xx_fs_kernel d=3 (delay, 0=forever prompt) p=0 (boot image, 0=latest, 1=previous) | 256 |
| 0x684 | Board ID | 16 | |
| 0x694 | Main Thread | 4 | |
| 0x698 | Psi size | 4 | |
| 0x69C | Number MAC Addresses | four | |
| 0x6A0 | Base of operations MAC Address | 6 | |
| 0x6A6 | reserved | 2 | |
| 0x6A8 | old CheckSum | iv | |
| 0x6AC | gpon Serial Number | 13 | |
| 0x6B9 | gpon Countersign | eleven | |
| 0x6C4 | wps Device Pivot | 8 | |
| 0x6CC | wlan Params | 256 | |
| 0x7CC | Syslog Size | iv | |
| 0x7D0 | Nand Part Ofs Kb | xx | |
| 0x7E4 | Nand Role Size Kb | 20 | |
| 0x7F8 | Voice Board Id | 16 | |
| 0x808 | afe Id | viii | |
| 0x810 | Unused | 364 | |
| 0x97C | CheckSum | 4 | |
NVRAM versions >=5 e'er accept the checksum placed at the stop of the NVRAM.
At the cease of the flash exterior the CFE, there exists a PSI division (Contour Storage Information), nigh 16KB size. In Openwrt this area is protected with a partition chosen nvram. Do not confuse with the CFE NVRAM!!
There isn't whatever interaction betwixt CFE and PSI except for restoring it to defaults or erasing this area. The settings nowadays in this surface area are only used past the OEM firmware.
Linksys E900 Software Download for Mac
Posted by: olsonchle1942.blogspot.com
0 Comments