Figuring out the bootloader password

Some online documents indicated the Accton bootloader had a menu with which you can interrupt the booting process and upload files, recover from failed flash, change bootorder, etc.

This was also the case for our testsubject, but none of the passwords found online worked and just resulted in a continuing boot:

Image Loader 3.1.0.1
Diagnostics 3.1.0.0
User Mode

--- Performing Power-On Self Tests (POST) ---
DUMMY Test 1 ................. PASS
UART Loopback Test ........... PASS
DRAM Test .................... PASS
Timer Test ................... PASS
PCI Device 1 Test ............ PASS
I2C Bus Initialization ....... PASS
Switch Int Loopback Test ..... PASS
Crossbar Int Loopback Test ... PASS
Fan Speed Test ............... PASS
Done All Pass.
------------------ DONE ---------------------
Password : mercury
Loading Runtime Image File : op1.bix

I had already learned earlier about a few backdoor passwords by running string on the uncompressed .bix firmware. If I repeatedly paste ‘d3bug1191’ during startup, it will put me into a backdoor menu:

----------------------------------------
Main menu of backdoor:

 * ipfilter
 * cos
 * acl
 * hrdrv
 * devhrdrv
 * TNPD
 * cli3com
 * HTTP
 * snmp
 * SSH
 * SNTP
 * TFTP
 * dns
 * smtp
 * sys_mgr
 * sysmgr
 * NETIF
 * NETCFG
 * IPCFG
 * ROUTE
 * ICMP
 * IP
 * P2MEM
 * IML
 * 802.1x
 * userauth
 * igmpsnp
 * GVRP
 * vlan
 * xstp
 * lacp
 * swctrl
 * cfgdb
 * leddrv
 * fs
 * lan
 * lhash
 * SYSFUN
 * MREF
 * MEM
 * nmtrdrv
 * AMTRDRV
 * devswdrv
 * swdrv
 * ISC
 * IUC
 * stkmgmt

 exit --- To exit from backdoor.

Key in the CSC name:

Which itself, also allowed access a Broadcom shell:

Key in the CSC name: swdrv

==========SWDRV BackDoor Menu================

 0. Exit
 1. Port related
 2. Spawn Chip Task
 3. Enter Chip Backdoor
=================================================
     select =2
==========SWDRV BackDoor Menu================

 0. Exit
 1. Port related
 2. Spawn Chip Task
 3. Enter Chip Backdoor
=================================================
     select =3
Enter Broadcom backdoor
BCM.0>

The broadcom backdoor at first did not seem to be able to interface with anything useful. For instance, the output of a file listing is empty:

BCM.0> dir
BCM.0>

But I did notice it had a function to dump the physical memory of the device. Some dumping of 0x10000 and comparing it with the uncompressed firmware showed it was indeed reading the CPUs physical memory:

BCM.0> help dump
Usage (Dump): Usages:
 DUMP [File=<name>] [Append=true|false] [raw] [hex] [all] [chg]
 <TABLE>[.<COPYNO>] <INDEX> [<COUNT>]
 If raw is specified, show raw memory words instead of fields.
 If hex is specified, show hex data only (for Expect parsing).
 If all is specified, show even empty or invalid entries
 If chg is specified, show only fields changed from defaults
 (Use "listmem" command to show a list of valid tables)
 DUMP PCIC                     (PCI config space)
 DUMP PCIM [<START> [<COUNT>]] (CMIC PCI registers)
 DUMP SOC [ADDR | RVAL | DIFF] (All SOC registers)
 ADDR shows only addresses, doesn't actually load.
 RVAL shows reset defaults, doesn't actually load.
 DIFF shows only regs not equal to their reset defaults.
 DUMP MW [<START> [<COUNT>]]   (System memory, 32 bits)
 DUMP MH [<START> [<COUNT>]]   (System memory, 16 bits)
 DUMP MB [<START> [<COUNT>]]   (System memory, 8 bits)
 DUMP SA                       (ARL shadow table)
 DUMP L2TAB                    (BCM API shadow table)
 DUMP DV ADDR                  (DMA vector)
 DUMP PHY [<PHYID>]            See also, the 'PHY' command.
BCM.0> dump mh 0x10000 0x10
00010000: 7c63 1a78 7c60 0124 7c63 1a78 3c80 4c00
00010010: 3884 0064 9080 0900 3c20 0001 3821 0000
BCM.0>

PC:/tmp$ dd if=s3h03_00s56p07.bin bs=80 skip=1 | gunzip | xxd | head -2
0000000: 7c63 1a78 7c60 0124 7c63 1a78 3c80 4c00  |c.x|`.$|c.x<.L.
0000010: 3884 0064 9080 0900 3c20 0001 3821 0000  8..d....< ..8!..
PC:/tmp$

In the U-Boot documentation I noticed a Broadcom target. The Broadcom 95xx BMW CPCI Platform, which appears similar to this hardware.  It also has an address map which contains:

0xFFF00000 - 0xFFF80000 - 512K PLCC32 BootRom
                          (AMD AM29F040, ST 29W040B) 

0xFFF00100 -              System Reset Vector

So I dumped this range:

BCM.0> dump mh 0xfff00000 0x10000
fff00000: 4e80 0021 0000 0000 0000 0000 0000 0000
fff00010: 0000 0000 0000 0000 0000 0000 0000 0000
fff00020: 0000 0000 0000 0000 0000 0000 0000 0000
fff00030: 0000 0000 0000 0000 0000 0000 0000 0000
fff00040: 0000 0000 0000 0000 0000 0000 0000 0000
fff00050: 0000 0000 0000 0000 0000 0000 0000 0000
fff00060: 0000 0000 0000 0000 0000 0000 0000 0000
fff00070: 0000 0000 0000 0000 0000 0000 0000 0000
fff00080: 0000 0000 0000 0000 0000 0000 0000 0000
fff00090: 0000 0000 0000 0000 0000 0000 0000 0000
fff000a0: 0000 0000 0000 0000 0000 0000 0000 0000
fff000b0: 0000 0000 0000 0000 0000 0000 0000 0000
fff000c0: 0000 0000 0000 0000 0000 0000 0000 0000
fff000d0: 0000 0000 0000 0000 0000 0000 0000 0000
fff000e0: 0000 0000 0000 0000 0000 0000 0000 0000
fff000f0: 0000 0000 0000 0000 0000 0000 0000 0000
fff00100: 7c63 1a78 7c60 0124 3c60 fff0 3863 0120
fff00110: 7c68 03a6 4e80 0020 0000 0000 0000 0000
etc.

After piping this to a file and feeding this to xxd, I appeared to have a proper dump:

PC:/tmp$ xxd -r loader | strings | grep 'Image Loader'
Image Loader %s
PC:/tmp$ xxd -r loader | strings
...
No runable image exist. Entering File Manager.
Password :
sosupdate
Loading Diagnostic Image File : %s
....
PC:/tmp$

That almost looks too easy, but let’s give it a try:

Image Loader 3.1.0.1

Password : sosupdate
File Name                         S/Up Type Size       Create Time
--------------------------------- ---- ---- ---------- -----------
$binary_cfg_file.bin                0   10     128000  24:00:42
$binary_cfg_file_internal.bin       0   10     128000  24:00:47
$logfile_1                          0    3         64  1193046:28:15
$logfile_2                          0    3         64  1193046:28:15
$watch_dog_log                      0    7         84  24:05:34
Factory_Default_Config.cfg          0    5        455  24:00:57
certificate                         0    8      32256  24:01:29
diag.bix                            1    1     830244  00:17:16
op1.bix                             0    2    3548532  00:21:17
op2.bix                             1    2    4944612  00:12:22
startup1.cfg                        0    5       5725  24:06:40
startup2.cfg                        1    5       5500  24:02:06
--------------------------------- ---- ---- ---------- ----------
Free Space : 22020096
[X]modem Download  [D]elete File  [S]et Startup File
[C]hange Baudrate  [Q]uit
Select>

Success!

Advertisements

2 Responses to “Figuring out the bootloader password”

  1. software Says:

    software…

    […]Figuring out the bootloader password « etherhack[…]…

  2. Ikke Says:

    in my case, SMC 8648T, after CTRL-U it accepted “mercury” as a password. I have the following files in the switch:

    File Name S/Up Type Size Create Time
    ——————————— —- —- ———- ———–
    $logfile_1 0 3 64 1193046:28:15
    $logfile_2 0 3 64 1193046:28:15
    Factory_Default_Config.cfg 0 5 374 24:00:53
    certificate 0 8 31744 24:00:45
    smc8648t_Diag_v2.1.0.4.bix 1 1 853084 00:04:29
    smc8648t_Runtime_v1.3.0.1.bix 1 2 2376640 00:16:45
    startup 1 5 6404 3929:56:39
    ——————————— —- —- ———- ———-
    Free Space : 3801088
    [X]modem Download [D]elete File [S]et Startup File
    [C]hange Baudrate [Q]uit
    Select>

    Which one do I delete to get a default configuration activated ?

    Thank you.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: