My first attempt to investigate MN-100.
First look on PCB: CPU - AMD5106 processor (for some reason without proper marking - MS conspiracy?).
Flash memory - Intel 28F160C3BC70. Pleasant surprise! It is 2MBytes flash!! See specification
Connectors - ready to use UART 10-pin connector. Solder place to mount 14-pin JTAG connector (unfortunately my soldiering skills will not be enough to put it in place)
First look on Software: For some reason Micro$oft doesn't offer a an individual files for firmware upgrades for variety of MS labeled broadband network equipment, but rather have a one (12M!) downloadable (MSBNDownload.exe) for all its gears - wireline and wireless - MN-100 up to MN-720. When installed , MSBNDownload extract from itself an individual firmware files and MSBNUpdate.exe update utility. MN100_00.01.11.017_RUNTIME.dlf is a latest firmware for MN-100.
OPEN ISSUE : I have no information about internals of the DLF format ! Mast be resolved ASAP MN-500 firmware is stored in similar format. MN-700 and MN-740 are seen to use different format (two individual files per gear - one for bootloader, one for runtime) .
MSBNUpdate is seen as used uPnP protocol for equipment discovery and update. Further investigation required
First look on bootloader: Connecting rs232 level shifter to the 10-pin UART connector. Usual terminal configuration : 115200 bits per second, 8 data bits, parity - none, 1 stop bit.
Booting immediately unveil VxWorks usual bootloader - normal boot sequence maybe interrupted by pressing any key. When in monitor mode (after interrupt) , menu of low level monitor commands is shown. NOTE: some of the commands maybe extremely dangerous - the fact learned by sad experience (see bellow).
Command "p" prints current boot parameters. Command "c" maybe used to change boot configuration. Sub-menu of "c" change mode offers to set up local IP address and remote TFTP and/or BOOTP servers. This is a usual futures of the "standard" VxWorks bootloader and maybe used for fast image load when new image designed or debugged. (functionality require verification).
As I mention before, trying monitor commands is a dangerous business. Almost immediately I manage to corrupt original image and my MN-100 refuses to load. Bootloader verifies integrity of the image and report it as broken. At this stage , it report setup of the Ethernet port and await for "UI restoration procedure" or something similar (sorry, I didn't store log). Unfortunately, I didn't find how to use MS utilities to correct damaged flash.
Fortunately, I find "x" (xmodem download) command. Usually, it's used to download image into RAM and execute it, but in this bootloader it implemented differently - it maybe used only to program code image in the flash (no other options provided). I had used it with MN100_00.01.11.017_RUNTIME.dlf file and seen sucessful image verification and stored in flash starting from 0x20040000 (see details). Note: useful options for future Linux re-flashing if we manage to get internal structure for DLF files.
Under normal conditions , bootloader unpack runtime image from 0x2004000 into ?? and pass control to the 0x1000.
Interesting note: despite the fact that MN-100 PCB has no wireless capabilities, bootloader monitors offers a number of wireless specific test and configuration commands.
First look on original firmware: Finally, after image repairing, I had been able to proceed with runtime image analysis. It is VxWorks system and may be interrupted by any key. After key interrupt, a usual VxWorks monitor is offered - type "help" for details.
Most interesting commands: "d" is to display memory and "l" to disassemble part of the memory code. Interesting to note that runtime code includes symbol table and "l" sometimes provides a greet level of details. "i" command shows a list of all running tasks.
I had used "d" to get values of CPU registers. I'll use it soon to update register map page.
Command "l" is useful to get original bootloader code in the flash. (note: I have no JTAG support to get it other way and analyse outside). Note two distinctive parts of boot code - one started at 0x20000000, another at 0x20008000.
|Boot||0x00000000||BOOT initial boot kick start|
|Boot - 2||0x00008000||BOOT second part of the boot code|
|Code Image||0x00040000||768k ?||CODE|
|end of ROM||0x00200000||Total-2M||end of ROM|
Spend my valuable time updating register values table. Now it represents a registers values at middle of original firmware execution (steady state)
A few interesting reports from MN-100 debug monitor
-> pc value = 1081956 = 0x108264 = semQPut + 0xc0 -> i NAME ENTRY TID PRI STATUS PC SP ERRNO DELAY ---------- ------------ -------- --- ---------- -------- -------- ------- ----- tExcTask _excTask 67b06c 0 PEND 131408 67afa0 0 0 tLogTask _logTask 678750 0 PEND 131408 678684 3d0001 0 tShell _shell 5cde68 1 READY e3690 5cdb08 1c0001 0 tDhcpcTask _dhcpcMon 5b6844 40 PEND 108264 5b67a0 0 0 tDnsProxy _dns_proxy_D 5b27c8 40 PEND+T 108264 5b2658 3d0004 82 tDhcpsTask _dhcpsStart 5ae9a0 40 PEND 108264 5ae900 0 0 tHTDM _httpd 589370 40 PEND 108264 589204 0 0 tHTRQ _ProcessHttp 5871c4 40 PEND 131408 5870e4 0 0 tNetTask _netTask 638564 50 READY 108264 6384e4 0 0 reset _Prd_PreRese 556e9c 99 PEND 108264 556e3c 0 0 nvram _nv_Task 5bdc74 100 READY ddc68 5bdbdc 0 0 fpi _fpi_Task 5bb8d0 100 READY ddc68 5bb858 0 0 sntpMain _sntpMain 58ea70 100 DELAY ddc68 58e9b0 0 65 SSDP_Beacon_BeaconStart 55d1f4 100 DELAY ddc68 55cf6c 0 584 SSDP_readTa_SsdpReadTas 55a048 100 PEND 108264 559ac4 0 0 value = 0 = 0x0
Runtime code is started at 0x1000
Some of interesting functions:
Check symbol table for something started from "download". Bingo! find download_ProcessImage function. Look like is used to burn flash when a new image downloaded via HTTP. It then calls prd_CheckImage to validate correctness of the Image file.
Deep analysis of prd_CheckImage unveil the internal structure of *.DLF file
*.DLF file structure
|Offset||Description||Value from MN*.dlf|
|0||TF - Type of file||2|
|4||DL - Data Length
|8||DC - Data CheckSum (byte)
DC+ = (byte)file[i];
|HC - header checksum:
HC+ = (byte)header[i];
|data file - unknown compression|
Decided to check other symbols in vicinity of download_ProcessImage and prd_CheckImage
0x000b8eb4 download_ConfigInit text 0x000b9004 download_Action text 0x000b9020 download_SetAction text 0x000b90a8 download_Mode text 0x000b90c4 download_SetMode text 0x000b9134 download_FileName text 0x000b91c0 download_SetFileName text 0x000b926c download_ProcessImage text 0x000b9330 download_ProcessWlanFirmware text ----- 0x000c3094 prd_ResetTask text 0x000c3138 prd_Reload text 0x000c3178 Prd_PreResetTask text 0x000c323c Prd_ResetInit text 0x000c32e4 prd_FactoryReset text 0x000c3350 prd_CheckImage text 0x000c3544 prd_UpdateImage text 0x000c368c prd_CompareImage text 0x000c3764 prd_DownloadCfgImg text 0x000c397c prd_info_SerialNo text 0x000c39e8 prd_info_HardwareVer text 0x000c3a54 prd_info_BootCodeVer text 0x000c3ad4 prd_info_RuntimeCodeVer text 0x000c3b38 prd_info_RuntimeCodeDate text 0x000c3b9c prd_info_GetLanMacAddr text 0x000c3c1c prd_info_GetWanMacAddr text =======