Re: MBR partitioning, and content after partition table but before first partition
On 03/08/2017 10:56 PM, Felix Miata wrote:
Was that disk ever used for anything besides Jessie, not new or
wiped first?
The disk was wiped before installing Jesse.
Run strings on it or view in a sector editor and you'll probably see
grub somewhere, if it's a typical Linux installation that puts Grub
in the MBR instead of on a primary partition with its boot flag set,
along with generic code in the MBR.
2017-03-09 20:22:00 root@jesse ~
# dd if=/dev/sda skip=1 count=100 2>/dev/null | file -
/dev/stdin: data
2017-03-09 20:22:38 root@jesse ~
# dd if=/dev/sda skip=1 count=100 2>/dev/null | strings | egrep -i
'[a-z]{5,}'
loading
Error
RBRPQR
&EhALJ
RcVqt
YpmBs
0GXRSh
rswcGnj
#NXxVg
ihfer
zxgKNZT
LsELn
UenvkO
kxgqI&
MstUFX1
g~vqKsu8
Occasionally some of those sectors are used for RAID.
I don't use RAID with that system disk.
On 03/08/2017 11:21 PM, Thomas Schmitt wrote:
Could be GRUB program code. Do you see cleartext messages in the
first 100 blocks ?
See above.
On 03/09/2017 06:30 AM, Jonathan Dowland wrote:
I believe it's part of grub. My limited understanding of how it works
is it's split up into separate stages designed to fit within the
"holes" in a typical MBR layout, each stage having enough code to
initialise some stuff and then jump to the next stage.
I use LUKS swap (random key) and root (passphrase). I think it's the
piece of the boot chain that gives me the LUKS prompt for root (before
the GRUB menu).
My Wheezy system drive also uses LUKS:
2017-03-09 20:32:04 root@cd2533 ~
# dd if=/dev/sdb count=2048 2>/dev/null | hexdump -C | tail
0000cd90 00 0f 7d 74 a2 57 6f 16 d8 61 5a 19 6d c0 63 f3
|..}t.Wo..aZ.m.c.|
0000cda0 ed 86 77 f3 9d 2a 26 87 40 61 e3 7a 05 a7 fc b0
|..w..*&.@a.z....|
0000cdb0 8b 5d e1 b3 99 a4 ad 17 8e f6 dd 5f 1e 1a 06 5d
|.]........._...]|
0000cdc0 8f f3 e9 b6 ec f7 63 18 72 47 d4 aa 3b 5a da 56
|......c.rG..;Z.V|
0000cdd0 ac 2d 95 3a c4 12 53 45 6a 5a 92 21 79 6c d6 ca
|.-.:..SEjZ.!yl..|
0000cde0 93 ec ae fe 96 c3 df cb 61 ca 88 d8 a0 14 7d 53
|........a.....}S|
0000cdf0 31 c4 53 ba 2e aa ee 35 57 46 fd 4b 81 9c 8d 9d
|1.S....5WF.K....|
0000ce00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|................|
*
00100000
2017-03-09 20:34:43 root@cd2533 ~
# dd if=/dev/sdb skip=1 count=2048 2>/dev/null | file -
/dev/stdin: data
2017-03-09 20:36:49 root@cd2533 ~
# dd if=/dev/sdb skip=1 count=2048 2>/dev/null | strings | egrep -i
'[a-z]{5,}'
loading
Error
RBRPQR
wPdwm
piyEst
WmZFH7w
ukdmtI
kAXwU
NQapDd
wkNdR
MKEZH'
GZRCv
vNigR
VpbVk
mXDbl
l8WMhMJ
5ygCtG
PjzpIj$3
flnYG
So, the moral of the story appears to be:
When taking an image of a Debian system drive, be sure to copy the
blocks between the partition table and the first partition, as there
may be boot loader code there.
I can find plenty of "introductory" / "overview" documents, but does
anybody know if/ where the technical details are documented?
2017-03-09 20:46:57 dpchrist@jesse ~
$ apt-get source grub-pc
...
2017-03-09 20:58:13 dpchrist@jesse ~
$ cd grub2-2.02~beta2/docs/
2017-03-09 20:58:17 dpchrist@jesse ~/grub2-2.02~beta2/docs
$ ls -w 72
Makefile.am grub-dev.texi stamp-1
Makefile.in grub.cfg stamp-vti
autoiso.cfg grub.info texinfo.tex
fdl.texi grub.texi version-dev.texi
font_char_metrics.png man version.texi
font_char_metrics.txt mdate-sh
grub-dev.info osdetect.cfg
This document is dated and doesn't cover LUKS, but does indicate that
blocks 1-62 were used for "GRUB stage 1.5":
http://www.pixelbeat.org/docs/disk/
David
Reply to: