Using DD to copy uboot

Phishfry

Phishfry

I have troubles figuring out dd syntax for u-boot in the bootsector.

Here they are.

Want to copy existing u-boot bits to image.
gpart show da0
Code: 
=>       63  122142657    da0  MBR  (58G)
         63      32705         - free -  (16M)
So I want to backup the first 16M or from sector 0 to sector 32768
How?
dd if=/dev/da0 of=uboot.img bs=512
Does it really start at 63 sector or sector 0? What is in sector zero if not?
Should I be ending one sector earlier at 32767?

Conversely:
What if I want to blank just the first 16M or u-boot?
dd if=/dev/zero of=/dev/da0 bs=512 seek 32767 ???
 
Assuming that underlying disk has 512 sector size.

To recap: first 16MB spreads in sector interval <0, 32767>, or (16*1024*1024)/512 = 32768 sectors. To copy first 16MB data you do dd if=/dev/da0 of=uboot.img bs=512 count=32768.
If you want to zero down first 16MB you do: dd if=/dev/zero of=/dev/da0 bs=512 count=32768

Phishfry said:
What is in sector zero if not?
Click to expand...
In MBR scheme LBA 0 (sector 0) has MBR bootcode + 4 partition definitions (could be empty). This code is always loaded by BIOS to known memory location and jump is done there (BIOS handovers boot to it). This code is used to load other stages of OS bootloader (or generic bootloader).

In MBR you could use LBA1 for your own use (i.e. start of the partition) but usually some sectors are left free for 2nd stage bootloaders or for the sake of proper partition alignment.

In your gpart output first partition did exist on sectors <63,32767>, was 32705 sectors big but seems to be free.
If you want to zero down only that range you can do: dd if=/dev/zero of=/dev/da0 bs=512 seek=63 count=32705

Before zeroing anything you can check it with hd to see if you are seeking to proper location: dd if=/dev/da0 bs=512 skip=63 count=1|hd.
 
_martin said:
was 32705 sectors big but seems to be free.
Click to expand...
I think I have u-boot lurking in there. It doesn't show up with any tool I know..
file -s looks at partition table.

What raw disk tools exist to check for uboot?

It seems the size of the bootsector varies too. I see 40 sectors sometimes.
Maybe different size MicroSD cards have different bootsectors.
 
Here is the full info of the bitcoin miner SD Card I am probing.
gpart show -p da0
Code: 
>       63  122142657    da0  MBR  (58G)
         63      32705         - free -  (16M)
      32768  122109952  da0s1  ntfs  (58G)

This is a very bizarre disk layout for an aarch64 based miner.
I was not expecting NTFS.
 
hexdump (or hd as I used above in the example) is a tool I'd use to see if anything is there. As we are talking about small size you could even do dd if=/dev/da0 bs=512 count=32000 | hd and look if something "uboot-like" is there.

Since this is MBR it's more likely uboot is squeezed in before any partition starts, so within 0-32768 sector in your output.

Phishfry said:
It doesn't show up with any tool I know.
Click to expand...
If it's squeezed in (similar to 2nd stage of FreeBSD legacy code or legacy grub) tools are not able to detect it. It's just assembly code. MBR, and many other loaders do use jmp instruction as a first instruction (MBR/DOS legacy has metadata at the beginning, code has to jump over it). You could look for that (hexcode eb, or e9.. but of course could be anything else either).
That code most likely has some strings in that you could use match to uboot.

From the full output you shared now there's no other place for uboot to be, it has to be within <63,32767>.

p.s. It's after 2am here, I did so many typos and logical errors in sentences .. I had to re-edit it.
 
Thank You I will research hd.
It seems exactly like the Norton tool from the 90's that I was thinking of.
Binary(or whatever that is) is on the opposite side but exactly the same layout.

Code: 
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 0a  |................|
000001c0  09 02 07 fe ff ff 00 80  00 00 00 40 47 07 00 00  |...........@G...|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00fa0000
32000+0 records in
32000+0 records out
 
Phishfry said:
I was not expecting NTFS.
Click to expand...
That would not be my expectation either. Is it really ntfs ? Does fstyp identify /dev/da0s1as the actual ntfs? Can you mount it?
If this device you're checking out wants to pull some tricks it could be faking the actual partition (though I don't know what would it achieve by doing so).

Yes, hd is very much like that. And its big brother, bvi(1), is one of those tools I like to do magic with. Very handy tool (binary edit but behaves like vi. You are able to block load data, handy for editing live disk data).
 
There is a good chance there is eMMC onboard this Arm64 device and the MicroSD is used for some kind of key storage.
So I could be wrong about u-boot on the MicroSD card.
Now I know how to take a peek at my sectors and preserve that precious 16M area that I usually delete.
 
I took your command out one more zero and look what I found:
Code: 
registered_name:|
012c8cb0  20 5b 5d 0a 20 20 20 20  65 78 63 65 70 74 69 6f  | [].    exceptio|
012c8cc0  6e 20 65 78 69 74 3a 20  7b 7b 7b 7b 62 61 64 6d  |n exit: {{{{badm|
012c8cd0  61 74 63 68 2c 7b 65 72  72 6f 72 2c 65 6d 70 74  |atch,{error,empt|
012c8ce0  79 5f 73 6c 6f 74 7d 7d  2c 5b 7b 6d 69 6e 65 72  |y_slot}},[{miner|
012c8cf0  5f 6b 65 79 73 2c 6b 65  79 73 2c 31 2c 5b 7b 66  |_keys,keys,1,[{f|
012c8d00  69 6c 65 2c 22 6d 69 6e  65 72 5f 6b 65 79 73 2e  |ile,"miner_keys.|
012c8d10  65 72 6c 22 7d 2c 7b 6c  69 6e 65 2c 38 37 7d 5d  |erl"},{line,87}]|

Miner keys. Exactly like the literature said... So there is probably an eMMC onboard.
I have not powered up my device yet. Picking around the edges.
 
If it's not something super secret if you share first blocks of hexdump I can tell you if uboot is there. Share the dd if=/dev/da0 bs=512 count=1024 |hd and I can have a look.
 
dd if=/dev/da0 bs=512 count=1024 |hd
Code: 
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 0a  |................|
000001c0  09 02 07 fe ff ff 00 80  00 00 00 40 47 07 00 00  |...........@G...|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00080000
1024+0 records in
1024+0 records out
524288 bytes transferred in 0.384328 secs (1364168 bytes/sec)
 
Did you zero it down already ? If no let's go for full dump then: dd if=/dev/da0 bs=512 count=32768 | hd .

Btw. this disk does not even have the bootcode in lba0 so this is not the disk that the device uses for legacy boot (if it boots legacy).
 
Even streching it out 5x seems same output.

Code: 
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 0a  |................|
000001c0  09 02 07 fe ff ff 00 80  00 00 00 40 47 07 00 00  |...........@G...|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00274000
5024+0 records in
5024+0 records out
2572288 bytes transferred in 1.884199 secs (1365189 bytes/sec)
 
Same
Code: 
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 0a  |................|
000001c0  09 02 07 fe ff ff 00 80  00 00 00 40 47 07 00 00  |...........@G...|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
01000000
32768+0 records in
32768+0 records out
16777216 bytes transferred in 12.463854 secs (1346070 bytes/sec)
 
So the first 16MB of that disk is empty. You have two partitions defined (starting at offset 0x1be, and 0x1ce), both were marked as Microsoft FS (offset 4 from partition start, byte 0x7 indicating either FAT/NTFS). But they are all empty so, nothing is there.
 
I padded a little more to creep to next disk structure and this was useful.

dd if=/dev/da0 bs=512 count=32770 | hd
Code: 
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 0a  |................|
000001c0  09 02 07 fe ff ff 00 80  00 00 00 40 47 07 00 00  |...........@G...|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
01000000  eb 76 90 45 58 46 41 54  20 20 20 00 00 00 00 00  |.v.EXFAT   .....|
01000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
01000040  00 00 00 00 00 00 00 00  00 40 47 07 00 00 00 00  |.........@G.....|
01000050  80 00 00 00 80 0f 00 00  00 10 00 00 30 47 07 00  |............0G..|
01000060  04 00 00 00 bb d8 74 ef  00 01 02 00 09 08 01 80  |......t.........|
01000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
010001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
01000200  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
010003f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
01000400
32770+0 records in
32770+0 records out
16778240 bytes transferred in 12.358870 secs (1357587 bytes/sec)


Thanks for your help. I am not wasting more time on this.
Those miners are ridiculous. Who knows whats up.
Looks like EXFAT inside NTFS
 
Just for completeness:) : "07" partition type is Microsoft specific but can be both FAT (or exFAT to be precise) or NTFS. That's why gpart is saying that.

The offset 0x1000000, or 16777216 is sector 16777216/512 = 32768 which is start of the partition as shown by gpart. It's start of the exfat metadata. (as you mentioned you creeped into next partition)
 
I see od has a HISTORY:
An od command appeared in Version 1 AT&T UNIX.

Can I assume hd was also in Version 1 AT&T UNIX ?
 
u-boot location depends on the soc
for rockpi-s (probably other rockchip) its has 2 parts
first at 32k and second at 8m offsets
look at the README file in in /usr/local/share/u-boot/u-boot-soc-xxx/README and you'll see the dd command and reverse them
change if with of and seek with iseek or skip
also the offsets may be boot device dependend (ie not the same for sd, mmc, spiflash)
 
Phishfry said:
Can I assume hd was also in Version 1 AT&T UNIX ?
Click to expand...
hd a.k.a. hexdump was not present in v6, nor V7, nor any USG-sourced successor I know of (System III, System V) from AT&T. Nor do I think it was present in V8 and the "Research" variants.

hexdump was in 4.3BSD-Reno. I can't find evidence in Berkeley variants prior to that.

The man page on Debian says "The hexdump command is part of the util-linux package".
 
Phishfry said:
I was wrong the Norton Disk Editor has hex on right hand side too. (Figure 11-4)
Click to expand...
Hex view/editor is pretty much the same nevertheless the version (though I don't like xd/xxd/od outputs that much, I liked hd (hexdump -C) one).
Under DOS I still use DN and its hexview (let I be forgiven for pasting pictures of not that important stuff):

dos-hexview-dn.png
 
covacat said:
also the offsets may be boot device dependend (ie not the same for sd, mmc, spiflash)
Click to expand...
So that is why a separate uboot build is needed for SPI booting.
Different offsets needed for flashing SPI device..
I see some of the defconfigs do build both sd and spi images.
 
I find it quite interesting to look at the hexdump of an unknown disk structure..

I was thinking that I need to add a way to search for text inside binary disk too.

I have found a text tattletale for u-boot rockchip..
In plain text:
RK33
RK35
These designate different Rockchip u-boots.

Question:
So what is the best way to search for plaintext inside binary disk structure?
 
You must log in or register to reply here.
Back
Top