OpenWrt Forum Archive

Topic: Dumping flash via uboot

The content of this topic has been archived on 20 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

I have this router which was custom flashed and paired with a 4gb usb external root. The problem is I want to know what is on its filesystem, but the partitions are encrypted only to be decrypted at boot with cryptsetup.

I have access to serial and I know where the decryption keys are since the path is displayed during init boot, but the serial root console is disabled.

With this being the case I am trying to dump the flash memory so that I can uncompress it and take the keys so I can mount the USB drive myself in a full linux environment to take a look at what this router is hiding.

I know for the most part of what I need to do and have been semi successful, although I need a bit of help working with uboot.

My plan of attack is to dump the flash via the `md` command and then use Ruby scripting to take the hex dump, clean it up, and convert it into a binary firmware image, which I can further reverse from there.

My problem is I don't quite understand how `md` works. I have it dumping partial flash memory but I don't understand how to make it dump the entire memory.

Here are the environment and version of uboot.

hornet> printenv

bootargs=console=ttyS0,115200 root=31:02 rootfstype=squashfs init=/sbin/init mtdparts=ar7240-nor0:256k(u-boot),64k(u-boot-env),2752k(rootfs),896k(uImage),64k(NVRAM),64k(ART)
bootcmd=bootm 0x9f020000
bootdelay=1
baudrate=115200
ethaddr=0xba:0xbe:0xfa:0xce:0x07:0x41
ipaddr=192.168.1.111
serverip=192.168.1.100
stdin=serial
stdout=serial
stderr=serial
ethact=eth0

Environment size: 362/65532 bytes

hornet> ?
?       - alias for 'help'
bootm   - boot application image from memory
cp      - memory copy
erase   - erase FLASH memory
help    - print online help
md      - memory display
mm      - memory modify (auto-incrementing)
mtest   - simple RAM test
mw      - memory write (fill)
nm      - memory modify (constant address)
printenv- print environment variables
progmac - Set ethernet MAC addresses
reset   - Perform RESET of the CPU
setenv  - set environment variables
tftpboot- boot image via network using TFTP protocol
version - print monitor version

hornet> version
U-Boot 1.1.4 (Aug 17 2012 - 15:21:03)

hornet> help md

md [.b, .w, .l] address [# of objects]
    - memory display

I know the start of the flash kernel is 0x9f020000, but how to I tell `md` to read the entire flash. If I run `md.b 0x9f020000` by itself it prints something like the first 40 bytes. If I supply a [# of objects] variable in hex it does read more, but how can I tell it to read only the full firmware image and not any further into memory, because I have a feeling if I supply to large of a hex number it will start reading past the firmware into other regions of memory.

Any help is appreciated!

Thanks.

Edit:: Would it work if I specified the beginning of the firmware image, and then the total size of the flash memory on the router? Or is the beginning of the firmware image where it boots, not the real beginning of the flash. I am basically only wanting to extract the firmware binary.

Edit2:: The router seems to be a unmodded mr3020 if it matters.

I found this on the wiki page

Bytes transferred = 3932160 (3c0000 hex)
hornet> erase 0x9f020000 +0x3c0000

First 0x2 last 0x3d sector size 0x10000                                                                                                        61
Erased 60 sectors
hornet> cp.b 0x80000000 0x9f020000 0x3c0000
Copy to Flash... write addr: 9f020000

Does this mean that 0x3c0000 is the size of the flash?

(Last edited by abduct on 30 Apr 2015, 00:12)

Yes, 0x3c0000 is size of flash.

Now I'm really interested which device you got? I never heard of any device so far having firmware encrypted, sounds really interesting.

(Last edited by valentt on 30 Apr 2015, 00:32)

valentt wrote:

Yes, 0x3c0000 is size of flash.

Now I'm really interested which device you got? I never heard of any device so far having firmware encrypted, sounds really interesting.

Thanks I managed to dump it to a log file and I am in the process of converting the hex dump into a binary firmware image.

And yea I found it interesting as well. It's not that the firmware itself is encrypted, but the files on the thumbdrive it came with have encrypted partitions that it mounts at boot. I am trying to figure out what they are trying to hide so desperately that warrants disabling serial root console, have no external network facing services running, and encrypting the partitions holding it's data.

This was a custom flashed pocket router (tp link mr3020) that has some sort of software preloaded on a flash drive.

(Last edited by abduct on 30 Apr 2015, 03:55)

You didn't find encrypted devices lying on the street smile Is it one of RIPE Atlas probes? Then it makes sense to have their code encrypted so nobody messes with results.

valentt wrote:

Yes, 0x3c0000 is size of flash.

No, FLASH size is 4 MB (0x400000).

abduct wrote:

[...]
My plan of attack is to dump the flash via the `md` command and then use Ruby scripting to take the hex dump, clean it up, and convert it into a binary firmware image, which I can further reverse from there.

My problem is I don't quite understand how `md` works. I have it dumping partial flash memory but I don't understand how to make it dump the entire memory.
[...]

uboot> help md
md [.b, .w, .l] address [# of objects]

So:

md.b 0x9F000000 4194304

Will print entire FLASH. Example:

9F000000: 10 00 00 FF 00 00 00 00 10 00 00 FD 00 00 00 00    ................
9F000010: 10 00 01 8E 00 00 00 00 10 00 01 8C 00 00 00 00    ................
9F000020: 10 00 01 8A 00 00 00 00 10 00 01 88 00 00 00 00    ................
9F000030: 10 00 01 86 00 00 00 00 10 00 01 84 00 00 00 00    ................
9F000040: 10 00 01 82 00 00 00 00 10 00 01 80 00 00 00 00    ................
9F000050: 10 00 01 7E 00 00 00 00 10 00 01 7C 00 00 00 00    ...~.......|....
9F000060: 10 00 01 7A 00 00 00 00 10 00 01 78 00 00 00 00    ...z.......x....
9F000070: 10 00 01 76 00 00 00 00 10 00 01 74 00 00 00 00    ...v.......t....
9F000080: 10 00 01 72 00 00 00 00 10 00 01 70 00 00 00 00    ...r.......p....
9F000090: 10 00 01 6E 00 00 00 00 10 00 01 6C 00 00 00 00    ...n.......l....
9F0000A0: 10 00 01 6A 00 00 00 00 10 00 01 68 00 00 00 00    ...j.......h....
9F0000B0: 10 00 01 66 00 00 00 00 10 00 01 64 00 00 00 00    ...f.......d....
9F0000C0: 10 00 01 62 00 00 00 00 10 00 01 60 00 00 00 00    ...b.......`....
9F0000D0: 10 00 01 5E 00 00 00 00 10 00 01 5C 00 00 00 00    ...^.......\....
9F0000E0: 10 00 01 5A 00 00 00 00 10 00 01 58 00 00 00 00    ...Z.......X....
9F0000F0: 10 00 01 56 00 00 00 00 10 00 01 54 00 00 00 00    ...V.......T....
9F000100: 10 00 01 52 00 00 00 00 10 00 01 50 00 00 00 00    ...R.......P....
9F000110: 10 00 01 4E 00 00 00 00 10 00 01 4C 00 00 00 00    ...N.......L....
9F000120: 10 00 01 4A 00 00 00 00 10 00 01 48 00 00 00 00    ...J.......H....
9F000130: 10 00 01 46 00 00 00 00 10 00 01 44 00 00 00 00    ...F.......D....
[...]

First column: address
Next 16 columns: data (1 byte every column, HEX)
Last column: ASCII

pepe2k wrote:
valentt wrote:

Yes, 0x3c0000 is size of flash.

No, FLASH size is 4 MB (0x400000).

So:

md.b 0x9F000000 4194304

Hi, Thanks for the clarification. Is that the size I would need in order to dump the firmware+filesystem. I am looking to try to extract the filesystem using binwalk/firmware-mod-kit, although I am having troubles with my current dump of the flash.

Binwalk/FMK detects everything and it seems to extract the data after decompressing the image, but it leaves me with two IMG files of file system type JFFS2 which I can't seem to mount. Usually binwalk/FMK extracts the contents to a directory by itself so I am not sure if I have captured the complete image, or if there is something else wrong.

valentt wrote:

You didn't find encrypted devices lying on the street smile Is it one of RIPE Atlas probes? Then it makes sense to have their code encrypted so nobody messes with results.

It isn't a ripe atlas probe although that is an interesting project. I might sign up to help out.

I did it!

1) using minicom -C capturefile.txt
2) using vi to trim the crap from the files
3) do over 1&2 a few times for good luck then diff the files to make sure you got no crap being injected from poor grounding on your serial comms (pl2303's are fussy)
4) and using a wonderful python3 script on github that converts the output of md.p to binary also checking the ascii lines up with the binary

https://github.com/gmbnomis/uboot-mdb-dump/issues/1

also note that md.b takes hex for the length argument - 8mb flash = 0x800000. Be sure to back up your art partition separately as well repeating steps 1-4. It's location varies, check your printenv for commandline partition info etc.
https://forum.openwrt.org/viewtopic.php?id=41449

The discussion might have continued from here.