gdb boxing round & gdb winning

[wedgetail]

I want to inspect RAM memory which in WinHex is easy enough, but I do not have this for Linux.

gdb is already installed but I am not familiar with this, so a good manual read indicates that (gdb) x/..... is a start

[root@localhost 120202-Maurice_USB_boot problem]# gdb
GNU gdb (GDB) 7.1-2pclos2010 (PCLinuxOS release 2010)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i586-mandriva-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb)

(gdb) x
Argument required (starting display address).
(gdb) x 00:7e00
A syntax error in expression, near `:7e00'.

(gdb) x 007e00
0x7:    Cannot access memory at address 0x7

(gdb) x 0x007e00
0x7e00: Cannot access memory at address 0x7e00

(gdb) x 0xbfffa000
0xbfffa000:     Cannot access memory at address 0xbfffa000

(gdb) x/5i
   0xbfffa004:  Cannot access memory at address 0xbfffa004

(gdb) x 00x7e00
Invalid number "00x7e00".

(gdb)

I have not started with the options yet as until the address is valid I do not see the point.

It most be simple, there are deliberate mistakes in the addressing above just to see.

What is the trick 

[AS]

I want to inspect RAM memory which in WinHex is easy enough, but I do not have this for Linux.

Try hexdump 

Code: [Select]

hexdump -c < file

gdb is already installed but I am not familiar with this, so a good manual read indicates that (gdb) x/..... is a start

I doubt gdb might be useful in this specific case.

AS

[wedgetail]

AS

My understanding is that hexdump takes a file as input and then can spew out a formatted version to stdout in konsole. If I have file with the binary data that is no problem In  that case I can just transfer the file to Windows and use my WinHex.

Okteta I can use as it running under linux, not as powerful as Winhex.  

What I want to do is, look at the pc RAM memory but as I am not really familiar with Linux memory mapping I am at a loss.  fx bootcode is loaded in around 0x7C00 to run as I understand ( or some other segment) that is what I would like to look at.

I was hoping for a nice GUI and just enter the address and bingo.  ghe gdb x seemed to the thing, but I get invalid address, the x command wants an address? The manual indicates for example that x <start address> <end address> and done.  Since I can't even get one single address valid I am in somewhat of a bind.   
Am I missing something about hexdump ??

[AS]

AS

My understanding is that hexdump takes a file as input and then can spew out a formatted version to stdout in konsole. If I have file with the binary data that is no problem In  that case I can just transfer the file to Windows and use my WinHex.

Okteta I can use as it running under linux, not as powerful as Winhex.  

What I want to do is, look at the pc RAM memory but as I am not really familiar with Linux memory mapping I am at a loss.  fx bootcode is loaded in around 0x7C00 to run as I understand ( or some other segment) that is what I would like to look at.

I was hoping for a nice GUI and just enter the address and bingo.  ghe gdb x seemed to the thing, but I get invalid address, the x command wants an address? The manual indicates for example that x <start address> <end address> and done.  Since I can't even get one single address valid I am in somewhat of a bind.   
Am I missing something about hexdump ??

I was hoping for a nice girl and just enter the address and bingo.    It appears that the real life is a little different. 

[wedgetail]

AS

Your encrypted answers are very good.    Took me a little while to decode, but please not everytime? 

As I understand you: If you want to start at 0x7c00  Find the device /dev/mem and then dd if=/dev/mem of=test1.bin bs=512 count=80 skip=62.  You vary the skip and count to suit.  Now you can use the hexdump -c < test1.bin or okteta.

I decided to use okteta, and well yes there sits the bootcode and it is GRUB.

Errrh a simple little partition table reader/converter to match? All this hex manipulation is a bit heavy when used to WinHex doing the job 

I can dd the table out in hex of course but ...

[AS]

The meaning of my "plain" answer was/is: it's not that simple!  

Errrh a simple little partition table reader/converter to match? All this hex manipulation is a bit heavy when used to WinHex doing the job  

Now that you have learned about dd, transfer the partition table to the right location of a USB disk/stick and then use fdisk -l  

Alternatively look here for a detailed description of the partition table: http://en.wikipedia.org/wiki/Master_boot_record
Only 4 x 16 bytes = 64 bytes  

[wedgetail]

AS

1.. about USB stick, had not tweaked to that one yet, certainly fine for the primary partition table, I am going to look for one of the sticks that did not have a partition table and plonk it there and see.

2.. I am sidetracked a bit and plowing my way through the EBR the extended boot records, always been a bit hazy on those, but seems simple when you know.

Never really thought of going to the Wiki as my bible has been Starman site:

http://thestarman.pcministry.com/asm/mbr/PartTables3.htm

this is where I am at the moment   

[wedgetail]

AS

I tried to dd the partition table onto the USB, and I can read the USB with Konqeror but fdisk -l fails. A pity I quite liked the idea

Code: [Select]

Unable to seek on /dev/sdc
[root@localhost gert]#
Back to pencil and paper.

USB table modified with boot hard disk partition table:

Code: [Select]

[root@localhost ]# hexdump -C < 99-primary_partition_table.bin
00000000  80 01 01 00 07 fe ff ff  3f 00 00 00 af c7 45 04  |........?.....E.|
00000010  00 fe ff ff 83 fe ff ff  ee c7 45 04 40 3e 7e 03  |..........E.@>~.|
00000020  00 fe ff ff 83 fe ff ff  2e 06 c4 07 40 3e 7e 03  |............@>~.|
00000030  00 fe ff ff 05 fe ff ff  6e 44 42 0b 53 15 2e 69  |........nDB.S..i|
00000040

[root@localhost ]#


USB Original table:

Code: [Select]

[root@localhost ]# hexdump -C < usb-original-partition.bin
00000000  80 02 04 00 06 3f ff c8  81 00 00 00 3f 9d 3b 00  |.....?......?.;.|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000040
[root@localhost ]#


[AS]

AS

I tried to dd the partition table onto the USB, and I can read the USB with Konqeror but fdisk -l fails. A pity I quite liked the idea

Code: [Select]

Unable to seek on /dev/sdc
[root@localhost gert]#

Consider that /dev/sdc is a block device ... then you need to write one block.  
Prepare your  512 byte 'block' as a file and then:

Code: [Select]

dd if=file of=/dev/sdc
should work!

Back to pencil and paper.

USB table modified with boot hard disk partition table:

Code: [Select]

[root@localhost ]# hexdump -C < 99-primary_partition_table.bin
00000000  80 01 01 00 07 fe ff ff  3f 00 00 00 af c7 45 04  |........?.....E.|
00000010  00 fe ff ff 83 fe ff ff  ee c7 45 04 40 3e 7e 03  |..........E.@>~.|
00000020  00 fe ff ff 83 fe ff ff  2e 06 c4 07 40 3e 7e 03  |............@>~.|
00000030  00 fe ff ff 05 fe ff ff  6e 44 42 0b 53 15 2e 69  |........nDB.S..i|
00000040

[root@localhost ]#


USB Original table:

Code: [Select]

[root@localhost ]# hexdump -C < usb-original-partition.bin
00000000  80 02 04 00 06 3f ff c8  81 00 00 00 3f 9d 3b 00  |.....?......?.;.|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000040
[root@localhost ]#


Sorry, you don't explain what are 99-primary_partition_table.bin and usb-original-partition.bin, although those seems like is the 64 byte of the 4 primary partitions ...

[djohnston]

AS

1.. about USB stick, had not tweaked to that one yet, certainly fine for the primary partition table, I am going to look for one of the sticks that did not have a partition table and plonk it there and see.

2.. I am sidetracked a bit and plowing my way through the EBR the extended boot records, always been a bit hazy on those, but seems simple when you know.

Never really thought of going to the Wiki as my bible has been Starman site:

http://thestarman.pcministry.com/asm/mbr/PartTables3.htm

this is where I am at the moment   

Man, you're really serious about Maurice's USB boot problem, aren't you?    Here's wishing you success!

[wedgetail]

AS

First thanks for drawing my attention to hexdump, I was not going to worry too much about this one but I overlooked the importance of -C that is capital C, it is quite good useful for smaller sections of code, as I have done here.  Though Okteta is GUI based and quicker and easier better for large files.

About the previous post, yes you did have to do a bit sleuth work with what I presented.  The post was meant to convey that I did successfully install the new primary or boot sector partition table, ie the 64 bytes right at the end of the sector.

usb-original... the partition table that was on the USB stick and the 99-primary.... the new

This new partition table is the one from my 1000 GB booting hard drive.  

About the block-device I was lucky as I accidentally ended up using 512 bytes file size or bigger.  What I have posted is also a re-read of the USB sticks new partition table.  What is more important, thinking about block-device I realised I am completely forgetting that a USB stick can not be written to on a byte by byte inside, I hope I will remember this later on.

What I will do is repeat the exercise and be more explicit and use the whole boot sector.  I will then later save the whole post for my record.  Posting forces me to be a bit more careful.  

djohnston
Now and then I get bitten by bits   additionally I have been meaning for a long time to look at GRUB in 'detail' so it was an opportune moment to do a bit of digging.  Further I have/had a really funny USB stick problem that must be more than 2 years in the making it seems.  Discovered when I had trouble with Just18 liveHDD creator, the stick was only used as a notepad to record the work, not part of the process. I found a test for that and I would like to find a test for this odd behaviour people have with some USB sticks.

When time comes I will ask for a boot sector or more from one of your sticks  

[wedgetail]

I have a 1 GB USB stick with a paper tag GoogleSketch, I will use this for the exercise. First I am going to save the first 512 bytes from this device: /dev/sdc.  I am going to use dd to make a file with the 512 bytes, and okteta to read the file while I will use hexdump -C to print out for use in post.  I use Konqueror to open the GoogleSketch directory and then F4 to open konsole, starting in this directory, saves typing.

[root@localhost GoogleSketch]# dd if=/dev/sdc of=gs-original-boot-512bytes.bin bs=512 count=1
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.00109525 s, 467 kB/s
[root@localhost GoogleSketch]#

The content of this file is, where * one or more identical lines so be careful and look at the offset address (get yourself a pop up hexadecimal to decimal converter)

[root@localhost GoogleSketch]# ls
gs-original-boot-512bytes.bin
[root@localhost GoogleSketch]#

[root@localhost GoogleSketch]# hexdump -C <gs-original-boot-512bytes.bin

00000000  fa 33 c0 8e d0 bc 00 7c  8b f4 50 07 50 1f fb fc  |.3.....|..P.P...|
00000010  bf 00 06 b9 00 01 f2 a5  ea 1d 06 00 00 be be 07  |................|
00000020  b3 04 80 3c 80 74 0e 80  3c 00 75 1c 83 c6 10 fe  |...<.t..<.u.....|
00000030  cb 75 ef cd 18 8b 14 8b  4c 02 8b ee 83 c6 10 fe  |.u......L.......|
00000040  cb 74 1a 80 3c 00 74 f4  be 8b 06 ac 3c 00 74 0b  |.t..<.t.....<.t.|
00000050  56 bb 07 00 b4 0e cd 10  5e eb f0 eb fe bf 05 00  |V.......^.......|
00000060  bb 00 7c b8 01 02 57 cd  13 5f 73 0c 33 c0 cd 13  |..|...W.._s.3...|
00000070  4f 75 ed be a3 06 eb d3  be c2 06 bf fe 7d 81 3d  |Ou...........}.=|
00000080  55 aa 75 c7 8b f5 ea 00  7c 00 00 49 6e 76 61 6c  |U.u.....|..Inval|
00000090  69 64 20 50 61 72 74 69  74 69 6f 6e 20 54 61 62  |id Partition Tab|
000000a0  6c 65 00 45 72 72 6f 72  20 4c 6f 61 64 69 6e 67  |le.Error Loading|
000000b0  20 4f 70 65 72 61 74 69  6e 67 20 53 79 73 74 65  | Operating Syste|
000000c0  6d 00 4d 69 73 73 69 6e  67 20 4f 70 65 72 61 74  |m.Missing Operat|
000000d0  69 6e 67 20 53 79 73 74  65 6d 00 00 00 00 00 00  |ing System......|
000000e0  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  96 dd c7 4f 00 00 80 02  |...........O....|
000001c0  04 00 06 3f ff c8 81 00  00 00 3f 9d 3b 00 00 00  |...?......?.;...|
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

[root@localhost GoogleSketch]#

The highlighted blue is the boot sector partition table. In this case there is only one partition, the first 16 bytes

[root@localhost GoogleSketch]# fdisk -l /dev/sdc

Disk /dev/sdc: 2017 MB, 2017525248 bytes
64 heads, 63 sectors/track, 977 cylinders, total 3940479 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x4fc7dd96

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1   *         129     3907007     1953439+   6  FAT16
[root@localhost GoogleSketch]#

fdisk-l reports 1 partition this is fine.

Now to get hold of the booting hard drives first sector, the boot sector

[root@localhost GoogleSketch]# dd if=/dev/sda of=bootHDD-original-boot-512bytes.bin bs=512 count=1
1+0 records in
1+0 records out
512 bytes (512 B) copied, 7.5059e-05 s, 6.8 MB/s
[root@localhost GoogleSketch]#

What is the content:

[root@localhost GoogleSketch]# ls -l
total 8
-rw-r--r-- 1 root root 512 Feb  9 12:09 bootHDD-original-boot-512bytes.bin  < --- this one
-rw-r--r-- 1 root root 512 Feb  9 11:46 gs-original-boot-512bytes.bin
[root@localhost GoogleSketch]#

[root@localhost GoogleSketch]# hexdump -C <bootHDD-original-boot-512bytes.bin

00000000  eb 48 90 00 00 00 47 52  55 42 50 1f fc be 1b 7c  |.H....GRUBP....||
00000010  bf 1b 06 50 57 b9 e5 01  f3 a4 cb bd be 07 b1 04  |...PW...........|
00000020  38 6e 00 7c 09 75 13 83  c5 10 e2 f4 cd 18 8b f5  |8n.|.u..........|
00000030  83 c6 10 49 74 19 38 2c  74 f6 a0 b5 07 b4 03 02  |...It.8,t.......|
00000040  ff 00 00 20 01 00 00 00  00 02 fa 90 90 f6 c2 80  |... ............|
00000050  75 02 b2 80 ea 59 7c 00  00 31 c0 8e d8 8e d0 bc  |u....Y|..1......|
00000060  00 20 fb a0 40 7c 3c ff  74 02 88 c2 52 be 7f 7d  |. ..@|<.t...R..}|
00000070  e8 34 01 f6 c2 80 74 54  b4 41 bb aa 55 cd 13 5a  |.4....tT.A..U..Z|
00000080  52 72 49 81 fb 55 aa 75  43 a0 41 7c 84 c0 75 05  |RrI..U.uC.A|..u.|
00000090  83 e1 01 74 37 66 8b 4c  10 be 05 7c c6 44 ff 01  |...t7f.L...|.D..|
000000a0  66 8b 1e 44 7c c7 04 10  00 c7 44 02 01 00 66 89  |f..D|.....D...f.|
000000b0  5c 08 c7 44 06 00 70 66  31 c0 89 44 04 66 89 44  |\..D..pf1..D.f.D|
000000c0  0c b4 42 cd 13 72 05 bb  00 70 eb 7d b4 08 cd 13  |..B..r...p.}....|
000000d0  73 0a f6 c2 80 0f 84 ea  00 e9 8d 00 be 05 7c c6  |s.............|.|
000000e0  44 ff 00 66 31 c0 88 f0  40 66 89 44 04 31 d2 88  |D..f1...@f.D.1..|
000000f0  ca c1 e2 02 88 e8 88 f4  40 89 44 08 31 c0 88 d0  |........@.D.1...|
00000100  c0 e8 02 66 89 04 66 a1  44 7c 66 31 d2 66 f7 34  |...f..f.D|f1.f.4|
00000110  88 54 0a 66 31 d2 66 f7  74 04 88 54 0b 89 44 0c  |.T.f1.f.t..T..D.|
00000120  3b 44 08 7d 3c 8a 54 0d  c0 e2 06 8a 4c 0a fe c1  |;D.}<.T.....L...|
00000130  08 d1 8a 6c 0c 5a 8a 74  0b bb 00 70 8e c3 31 db  |...l.Z.t...p..1.|
00000140  b8 01 02 cd 13 72 2a 8c  c3 8e 06 48 7c 60 1e b9  |.....r*....H|`..|
00000150  00 01 8e db 31 f6 31 ff  fc f3 a5 1f 61 ff 26 42  |....1.1.....a.&B|
00000160  7c be 85 7d e8 40 00 eb  0e be 8a 7d e8 38 00 eb  ||..}.@.....}.8..|
00000170  06 be 94 7d e8 30 00 be  99 7d e8 2a 00 eb fe 47  |...}.0...}.*...G|
00000180  52 55 42 20 00 47 65 6f  6d 00 48 61 72 64 20 44  |RUB .Geom.Hard D|
00000190  69 73 6b 00 52 65 61 64  00 20 45 72 72 6f 72 00  |isk.Read. Error.|
000001a0  bb 01 00 b4 0e cd 10 ac  3c 00 75 f4 c3 00 00 00  |........<.u.....|
000001b0  00 00 00 00 00 00 00 00  20 8a 20 8a 00 00 80 01  |........ . .....|
000001c0  01 00 07 fe ff ff 3f 00  00 00 af c7 45 04 00 fe |......?.....E...|
000001d0  ff ff 83 fe ff ff ee c7  45 04 40 3e 7e 03 00 fe |........E.@>~...|
000001e0  ff ff 83 fe ff ff 2e 06  c4 07 40 3e 7e 03 00 fe  |..........@>~...|
000001f0  ff ff 05 fe ff ff 6e 44  42 0b 53 15 2e 69 55 aa  |......nDB.S..iU.|
00000200

[root@localhost GoogleSketch]#

The matching partitions shown by fdisk -l because of the extended partition holding lots of logical partitions there is the question will it be valid to install this on the USB stick "just to read the partition table"

Code: [Select]

[root@localhost GoogleSketch]# fdisk -l /dev/sda

Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x8a208a20

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *          63    71682029    35840983+   7  HPFS/NTFS
/dev/sda2        71682030   130287149    29302560   83  Linux
/dev/sda3       130287150   188892269    29302560   83  Linux
/dev/sda4       188892270  1953520064   882313897+   5  Extended
/dev/sda5       188892333  1212891434   511999551    7  HPFS/NTFS
/dev/sda6      1212891498  1221068519     4088511   82  Linux swap / Solaris
/dev/sda7      1221068583  1245631904    12281661   83  Linux
/dev/sda8      1245631968  1294453439    24410736   83  Linux
/dev/sda9      1294453503  1333523519    19535008+  83  Linux
/dev/sda10     1333523583  1382345054    24410736   83  Linux
/dev/sda11     1382345118  1421399069    19526976   83  Linux
/dev/sda12     1421401118  1463344157    20971520   83  Linux
/dev/sda13     1463346206  1495217744    15935769+  83  Linux
/dev/sda14     1495217808  1540440719    22611456   83  Linux
/dev/sda15     1540442768  1582385807    20971520   83  Linux
/dev/sda16     1582387856  1624330895    20971520   83  Linux
[root@localhost GoogleSketch]#

A repeat of the table that I did have in the earlier experiment, apart from the offset has changed the content is the same.

[root@localhost ]# hexdump -C <99-primary_partition_table_1.bin
00000000  80 01 01 00 07 fe ff ff  3f 00 00 00 af c7 45 04  |........?.....E.|
00000010  00 fe ff ff 83 fe ff ff  ee c7 45 04 40 3e 7e 03  |..........E.@>~.|
00000020  00 fe ff ff 83 fe ff ff  2e 06 c4 07 40 3e 7e 03  |............@>~.|
00000030  00 fe ff ff 05 fe ff ff  6e 44 42 0b 53 15 2e 69 |........nDB.S..i|
00000040  55 aa                                             |U.|
00000042
[root@localhost ]#

A this stage I am leaning towards this may be a bit much to ask of fdisk -l  to handle this USB stick configuration.

Thinking .... ... may take some time ..

[djohnston]

When time comes I will ask for a boot sector or more from one of your sticks  

I believe I have immunity under the National Secrets Act.