Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.unix.programmer > #975 > unrolled thread

Help, the dog ate my MBR (Linux/Windows dual boot)

Back to article view | Back to comp.unix.programmer

Contents

  Help, the dog ate my MBR (Linux/Windows dual boot) Noob <root@localhost> - 2011-07-22 00:45 -0400
    Re: Help, the dog ate my MBR (Linux/Windows dual boot) Ian Collins <ian-news@hotmail.com> - 2011-07-22 10:50 +1200
      Re: Help, the dog ate my MBR (Linux/Windows dual boot) Noob <root@localhost> - 2011-07-22 01:26 -0400
        Re: Help, the dog ate my MBR (Linux/Windows dual boot) Paul <nospam@needed.com> - 2011-07-21 19:38 -0400
          Re: Help, the dog ate my MBR (Linux/Windows dual boot) Noob <root@127.0.0.1> - 2011-07-22 16:29 +0200
            Re: Help, the dog ate my MBR (Linux/Windows dual boot) Paul <nospam@needed.com> - 2011-07-22 14:28 -0400
    Re: Help, the dog ate my MBR (Linux/Windows dual boot) "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2011-07-21 23:33 -0400
    Re: Help, the dog ate my MBR (Linux/Windows dual boot) BGB <cr88192@hotmail.com> - 2011-07-21 21:26 -0700
    Re: Help, the dog ate my MBR (Linux/Windows dual boot) Noob <root@127.0.0.1> - 2011-07-22 16:25 +0200
      Re: Help, the dog ate my MBR (Linux/Windows dual boot) Bob Willard <BobwBSGS@TrashThis.comcast.net> - 2011-07-22 12:17 -0400
        Re: Help, the dog ate my MBR (Linux/Windows dual boot) Noob <root@127.0.0.1> - 2011-07-22 18:35 +0200
      Re: Help, the dog ate my MBR (Linux/Windows dual boot) Arno <me@privacy.net> - 2011-07-22 18:41 +0000
      Re: Help, the dog ate my MBR (Linux/Windows dual boot) Paul <nospam@needed.com> - 2011-07-22 14:52 -0400
        Re: Help, the dog ate my MBR (Linux/Windows dual boot) The Natural Philosopher <tnp@invalid.invalid> - 2011-07-23 02:23 +0100
      Re: Help, the dog ate my MBR (Linux/Windows dual boot) scott@slp53.sl.home (Scott Lurndal) - 2011-07-22 19:19 +0000
        Re: Help, the dog ate my MBR (Linux/Windows dual boot) Noob <root@127.0.0.1> - 2011-07-23 20:51 +0200
          Re: Help, the dog ate my MBR (Linux/Windows dual boot) Noob <root@127.0.0.1> - 2011-07-24 16:54 +0200
          Re: Help, the dog ate my MBR (Linux/Windows dual boot) Arno <me@privacy.net> - 2011-07-24 15:29 +0000
            Re: Help, the dog ate my MBR (Linux/Windows dual boot) Noob <root@127.0.0.1> - 2011-07-27 11:36 +0200
              Re: Help, the dog ate my MBR (Linux/Windows dual boot) The Natural Philosopher <tnp@invalid.invalid> - 2011-07-27 12:13 +0100
              Re: Help, the dog ate my MBR (Linux/Windows dual boot) scott@slp53.sl.home (Scott Lurndal) - 2011-07-27 20:48 +0000
                Re: Help, the dog ate my MBR (Linux/Windows dual boot) Noob <root@127.0.0.1> - 2011-07-28 10:43 +0200
                Re: Help, the dog ate my MBR (Linux/Windows dual boot) Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-07-29 00:49 +0100
      Re: Help, the dog ate my MBR (Linux/Windows dual boot) Ian Collins <ian-news@hotmail.com> - 2011-07-23 09:44 +1200
      Re: Help, the dog ate my MBR (Linux/Windows dual boot) Franc Zabkar <fzabkar@iinternode.on.net> - 2011-07-23 10:05 +1000
        Re: Help, the dog ate my MBR (Linux/Windows dual boot) Paul <nospam@needed.com> - 2011-07-22 20:58 -0400
          Re: Help, the dog ate my MBR (Linux/Windows dual boot) Franc Zabkar <fzabkar@iinternode.on.net> - 2011-07-23 11:31 +1000
            Re: Help, the dog ate my MBR (Linux/Windows dual boot) Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-07-29 01:18 +0100
          Re: Help, the dog ate my MBR (Linux/Windows dual boot) Franc Zabkar <fzabkar@iinternode.on.net> - 2011-07-23 19:02 +1000
          Re: Help, the dog ate my MBR (Linux/Windows dual boot) Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-07-29 01:37 +0100
        Re: Help, the dog ate my MBR (Linux/Windows dual boot) Franc Zabkar <fzabkar@iinternode.on.net> - 2011-07-23 17:34 +1000
        Re: Help, the dog ate my MBR (Linux/Windows dual boot) Noob <root@127.0.0.1> - 2011-07-23 21:25 +0200
          Re: Help, the dog ate my MBR (Linux/Windows dual boot) Franc Zabkar <fzabkar@iinternode.on.net> - 2011-07-25 08:15 +1000
            Re: Help, the dog ate my MBR (Linux/Windows dual boot) scott@slp53.sl.home (Scott Lurndal) - 2011-07-24 23:08 +0000
              Re: Help, the dog ate my MBR (Linux/Windows dual boot) Franc Zabkar <fzabkar@iinternode.on.net> - 2011-07-25 09:46 +1000
                Re: Help, the dog ate my MBR (Linux/Windows dual boot) scott@slp53.sl.home (Scott Lurndal) - 2011-07-25 02:19 +0000
                  Re: Help, the dog ate my MBR (Linux/Windows dual boot) Paul <nospam@needed.com> - 2011-07-24 22:38 -0400
                    Re: Help, the dog ate my MBR (Linux/Windows dual boot) Franc Zabkar <fzabkar@iinternode.on.net> - 2011-07-25 19:38 +1000
                  Re: Help, the dog ate my MBR (Linux/Windows dual boot) Franc Zabkar <fzabkar@iinternode.on.net> - 2011-07-25 19:34 +1000
              Re: Help, the dog ate my MBR (Linux/Windows dual boot) Michael Press <rubrum@pacbell.net> - 2011-08-03 21:56 -0700
                Re: Help, the dog ate my MBR (Linux/Windows dual boot) John Hasler <jhasler@newsguy.com> - 2011-08-04 08:15 -0500
        Re: Help, the dog ate my MBR (Linux/Windows dual boot) Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-07-29 01:10 +0100
      Re: Help, the dog ate my MBR (Linux/Windows dual boot) gordonb.22upl@burditt.org (Gordon Burditt) - 2011-07-23 17:15 -0500
      Re: Help, the dog ate my MBR (Linux/Windows dual boot) Noob <root@127.0.0.1> - 2011-07-24 16:42 +0200
    Re: Help, the dog ate my MBR (Linux/Windows dual boot) Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-07-29 00:49 +0100
      Re: Help, the dog ate my MBR (Linux/Windows dual boot) Noob <root@127.0.0.1> - 2011-08-01 11:27 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#1029

Noob <root@127.0.0.1> writes:

>I've stopped using Windows' "hibernate" feature.

Now this seems to be a likely candidate.  I could easily imagine
windows modifying the MBR to short-circuit the recovery from
hibernation.

I assume this is a dual boot system and you're using grub to boot
both linux and windows?

scott

[toc] | [prev] | [next] | [standalone]

#1030

Scott Lurndal wrote:

> Noob wrote:
> 
>> I've stopped using Windows' "hibernate" feature.
> 
> Now this seems to be a likely candidate.  I could easily imagine
> windows modifying the MBR to short-circuit the recovery from
> hibernation.

I don't think Windows XP modifies the MBR because I always
get the GRUB2 menu when I boot up, whether I halt XP or send
it to hibernation (aka suspend to disk).

Moreover, as far as I could tell, the MBR had not been
modified, it had been shifted by 14 (?!) bytes...

> I assume this is a dual boot system and you're using grub
> to boot both linux and windows?

Yes I have Windows XP, Fedora 13 (must upgrade), and a swap
partition, all managed by GRUB2.

Regards.

[toc] | [prev] | [next] | [standalone]

#1034

> Now this seems to be a likely candidate.
>
Not really.

> I could easily imagine windows modifying the MBR to short-circuit the 
> recovery from hibernation.
>
Imagination doesn't create truth.  The hibernation resumption is simply 
an alternative to the normal kernel loader, winresume.exe instead of 
winload.exe.  It is invoked by the Microsoft  Boot Manager, that is 
itself run long after the MBR has been involved in the bootstrap 
process, at the point where it would normally invoke the kernel loader.  
Hibernation resumption is not very different to an ordinary BCD entry, 
in fact.

It is, as usual, Linux not Windows that has its dirty little fingers 
into M. Noob's MBR.  Xe has GRUB there.

[toc] | [prev] | [next] | [standalone]

#992

On 07/23/11 02:25 AM, Noob wrote:
>
> I'm starting to think that this might be a hardware problem,
> as both Linux AND the BIOS seem to have had troubles getting
> the MBR consistently. Something else I haven't mentioned:
> when Windows resumes from hibernation, the whole system
> sometime reboots (this started about 2/3 weeks ago), around
> the same time I changed the RAM from 2x512 to 2x1024.
>
> I tested the RAM, no errors after one hour of checking.
> The S.M.A.R.T. counters for the HDD claim the drive is
> "healthy".

How did you test the RAM, memtest86?  The symptoms do point to a memory 
problem.

If you have several GB of RAM it can take a long time to test.  I'd 
leave it to run over night.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#997

On Fri, 22 Jul 2011 16:25:28 +0200, Noob <root@127.0.0.1> put finger
to keyboard and composed:

>> Something trashed my MBR. Now when I boot the PC,
>> I get the dreaded "NON-SYSTEM DISK. PLEASE INSERT
>> SYSTEM DISK AND PRESS ENTER" (or something close).
>
>By MBR, I meant the first sector of my hard disk drive,
>i.e. the boot-strapping code, and the table of primary
>partitions.
>
>> I had used gparted to create three primary partitions
>> (all partitions are aligned to 1 MiB, even though
>> this is not a 4K-sector HDD)
>> partition 1 : 80.00 GiB (for WinXP)
>> partition 2 : 33.75 GiB (for Fedora 13)
>> partition 3 : 765 MiB (for swap)
>
>Short version of the rest of original message : the first sector
>had been shifted by 14 bytes. Weird, right?

ISTM that you are confusing the real, "good" MBR (ie physical sector
0) with GRUB's "bad" MBR. The latter appears to be relocated to some
other LBA(s), not LBA 0.

I expect that the code in the "good" MBR (ie the "real" MBR at LBA 0)
is executed at bootup, after which control is transferred to code in
the "bad" MBR. I say this because those 64 bytes which are normally
assigned to the four 16-byte partition slots are instead occupied by
code and a text string ("Floppy"). There are also JMP instructions (eg
je 0x1c3, jb 0x1ec, jne 0x1e1) that point to locations within this
block.

1B0                                            24 12               $.
1C0  0F 09 00 BE BD 7D 31 C0-CD 13 46 8A 0C 80 F9 00 .....}1...F.....
1D0  75 0F BE DA 7D E8 C9 FF-EB 97 46 6C 6F 70 70 79 u...}.....Floppy
1E0  00 BB 00 70 B8 01 02 B5-00 B6 00 CD 13 72 D7 B6 ...p.........r..
1F0  01 B5 4F E9 E0 FE 00 00-00                      ..O......

As you can see, the unassembled code has INT 13 instructions.

See http://en.wikipedia.org/wiki/INT_13H

-u 1be 1d9
01BE 2412          AND     AL,12
01C0 0F            DB      0F
01C1 0900          OR      [BX+SI],AX
01C3 BEBD7D        MOV     SI,7DBD
01C6 31C0          XOR     AX,AX
01C8 CD13          INT     13

- INT 13 (AH=0) -> Reset Disk Drives

01CA 46            INC     SI
01CB 8A0C          MOV     CL,[SI]
01CD 80F900        CMP     CL,00
01D0 750F          JNZ     01E1
01D2 BEDA7D        MOV     SI,7DDA
01D5 E8C9FF        CALL    01A1
01D8 EB97          JMP     0171


-u 1e1 1f8
01E1 BB0070        MOV     BX,7000
01E4 B80102        MOV     AX,0201
01E7 B500          MOV     CH,00
01E9 B600          MOV     DH,00
01EB CD13          INT     13

The above code reads 1 sector from sector 0, track 0, head 0, drive 0
to a memory buffer at address 0x7000.

01ED 72D7          JB      01C6
01EF B601          MOV     DH,01
01F1 B54F          MOV     CH,4F
01F3 E9E0FE        JMP     00D6

Location 0xD6 contains an INT 13 opcode. Therefore, AFAICT, the above
code reads 1 sector from sector 0, track 79 (=0x4F), head 1, drive 0
to a buffer at address 0x7000.

- Franc Zabkar
-- 
Please remove one 'i' from my address when replying by email.

[toc] | [prev] | [next] | [standalone]

#998

Franc Zabkar wrote:
> On Fri, 22 Jul 2011 16:25:28 +0200, Noob <root@127.0.0.1> put finger
> to keyboard and composed:
> 
>>> Something trashed my MBR. Now when I boot the PC,
>>> I get the dreaded "NON-SYSTEM DISK. PLEASE INSERT
>>> SYSTEM DISK AND PRESS ENTER" (or something close).
>> By MBR, I meant the first sector of my hard disk drive,
>> i.e. the boot-strapping code, and the table of primary
>> partitions.
>>
>>> I had used gparted to create three primary partitions
>>> (all partitions are aligned to 1 MiB, even though
>>> this is not a 4K-sector HDD)
>>> partition 1 : 80.00 GiB (for WinXP)
>>> partition 2 : 33.75 GiB (for Fedora 13)
>>> partition 3 : 765 MiB (for swap)
>> Short version of the rest of original message : the first sector
>> had been shifted by 14 bytes. Weird, right?
> 
> ISTM that you are confusing the real, "good" MBR (ie physical sector
> 0) with GRUB's "bad" MBR. The latter appears to be relocated to some
> other LBA(s), not LBA 0.
> 
> I expect that the code in the "good" MBR (ie the "real" MBR at LBA 0)
> is executed at bootup, after which control is transferred to code in
> the "bad" MBR. I say this because those 64 bytes which are normally
> assigned to the four 16-byte partition slots are instead occupied by
> code and a text string ("Floppy"). There are also JMP instructions (eg
> je 0x1c3, jb 0x1ec, jne 0x1e1) that point to locations within this
> block.
> 
> 1B0                                            24 12               $.
> 1C0  0F 09 00 BE BD 7D 31 C0-CD 13 46 8A 0C 80 F9 00 .....}1...F.....
> 1D0  75 0F BE DA 7D E8 C9 FF-EB 97 46 6C 6F 70 70 79 u...}.....Floppy
> 1E0  00 BB 00 70 B8 01 02 B5-00 B6 00 CD 13 72 D7 B6 ...p.........r..
> 1F0  01 B5 4F E9 E0 FE 00 00-00                      ..O......
> 
> As you can see, the unassembled code has INT 13 instructions.
> 
> See http://en.wikipedia.org/wiki/INT_13H
> 
> -u 1be 1d9
> 01BE 2412          AND     AL,12
> 01C0 0F            DB      0F
> 01C1 0900          OR      [BX+SI],AX
> 01C3 BEBD7D        MOV     SI,7DBD
> 01C6 31C0          XOR     AX,AX
> 01C8 CD13          INT     13
> 
> - INT 13 (AH=0) -> Reset Disk Drives
> 
> 01CA 46            INC     SI
> 01CB 8A0C          MOV     CL,[SI]
> 01CD 80F900        CMP     CL,00
> 01D0 750F          JNZ     01E1
> 01D2 BEDA7D        MOV     SI,7DDA
> 01D5 E8C9FF        CALL    01A1
> 01D8 EB97          JMP     0171
> 
> 
> -u 1e1 1f8
> 01E1 BB0070        MOV     BX,7000
> 01E4 B80102        MOV     AX,0201
> 01E7 B500          MOV     CH,00
> 01E9 B600          MOV     DH,00
> 01EB CD13          INT     13
> 
> The above code reads 1 sector from sector 0, track 0, head 0, drive 0
> to a memory buffer at address 0x7000.
> 
> 01ED 72D7          JB      01C6
> 01EF B601          MOV     DH,01
> 01F1 B54F          MOV     CH,4F
> 01F3 E9E0FE        JMP     00D6
> 
> Location 0xD6 contains an INT 13 opcode. Therefore, AFAICT, the above
> code reads 1 sector from sector 0, track 79 (=0x4F), head 1, drive 0
> to a buffer at address 0x7000.
> 
> - Franc Zabkar

So can someone translate this for me ?

WHY would a disk be set up this way, with what
*altruistic* objective ?

And WHAT software can we expect, to be mucking about in this way ?
The "rootkit of the month" club perhaps ? :-)

    Paul

[toc] | [prev] | [next] | [standalone]

#1000

On Fri, 22 Jul 2011 20:58:01 -0400, Paul <nospam@needed.com> put
finger to keyboard and composed:

>Franc Zabkar wrote:
>> On Fri, 22 Jul 2011 16:25:28 +0200, Noob <root@127.0.0.1> put finger
>> to keyboard and composed:
>> 
>>>> Something trashed my MBR. Now when I boot the PC,
>>>> I get the dreaded "NON-SYSTEM DISK. PLEASE INSERT
>>>> SYSTEM DISK AND PRESS ENTER" (or something close).
>>> By MBR, I meant the first sector of my hard disk drive,
>>> i.e. the boot-strapping code, and the table of primary
>>> partitions.
>>>
>>>> I had used gparted to create three primary partitions
>>>> (all partitions are aligned to 1 MiB, even though
>>>> this is not a 4K-sector HDD)
>>>> partition 1 : 80.00 GiB (for WinXP)
>>>> partition 2 : 33.75 GiB (for Fedora 13)
>>>> partition 3 : 765 MiB (for swap)
>>> Short version of the rest of original message : the first sector
>>> had been shifted by 14 bytes. Weird, right?
>> 
>> ISTM that you are confusing the real, "good" MBR (ie physical sector
>> 0) with GRUB's "bad" MBR. The latter appears to be relocated to some
>> other LBA(s), not LBA 0.
>> 
>> I expect that the code in the "good" MBR (ie the "real" MBR at LBA 0)
>> is executed at bootup, after which control is transferred to code in
>> the "bad" MBR. I say this because those 64 bytes which are normally
>> assigned to the four 16-byte partition slots are instead occupied by
>> code and a text string ("Floppy"). There are also JMP instructions (eg
>> je 0x1c3, jb 0x1ec, jne 0x1e1) that point to locations within this
>> block.
>> 
>> 1B0                                            24 12               $.
>> 1C0  0F 09 00 BE BD 7D 31 C0-CD 13 46 8A 0C 80 F9 00 .....}1...F.....
>> 1D0  75 0F BE DA 7D E8 C9 FF-EB 97 46 6C 6F 70 70 79 u...}.....Floppy
>> 1E0  00 BB 00 70 B8 01 02 B5-00 B6 00 CD 13 72 D7 B6 ...p.........r..
>> 1F0  01 B5 4F E9 E0 FE 00 00-00                      ..O......
>> 
>> As you can see, the unassembled code has INT 13 instructions.
>> 
>> See http://en.wikipedia.org/wiki/INT_13H
>> 
>> -u 1be 1d9
>> 01BE 2412          AND     AL,12
>> 01C0 0F            DB      0F
>> 01C1 0900          OR      [BX+SI],AX
>> 01C3 BEBD7D        MOV     SI,7DBD
>> 01C6 31C0          XOR     AX,AX
>> 01C8 CD13          INT     13
>> 
>> - INT 13 (AH=0) -> Reset Disk Drives
>> 
>> 01CA 46            INC     SI
>> 01CB 8A0C          MOV     CL,[SI]
>> 01CD 80F900        CMP     CL,00
>> 01D0 750F          JNZ     01E1
>> 01D2 BEDA7D        MOV     SI,7DDA
>> 01D5 E8C9FF        CALL    01A1
>> 01D8 EB97          JMP     0171
>> 
>> 
>> -u 1e1 1f8
>> 01E1 BB0070        MOV     BX,7000
>> 01E4 B80102        MOV     AX,0201
>> 01E7 B500          MOV     CH,00
>> 01E9 B600          MOV     DH,00
>> 01EB CD13          INT     13
>> 
>> The above code reads 1 sector from sector 0, track 0, head 0, drive 0
>> to a memory buffer at address 0x7000.
>> 
>> 01ED 72D7          JB      01C6
>> 01EF B601          MOV     DH,01
>> 01F1 B54F          MOV     CH,4F
>> 01F3 E9E0FE        JMP     00D6
>> 
>> Location 0xD6 contains an INT 13 opcode. Therefore, AFAICT, the above
>> code reads 1 sector from sector 0, track 79 (=0x4F), head 1, drive 0
>> to a buffer at address 0x7000.
>> 
>> - Franc Zabkar
>
>So can someone translate this for me ?
>
>WHY would a disk be set up this way, with what
>*altruistic* objective ?
>
>And WHAT software can we expect, to be mucking about in this way ?
>The "rootkit of the month" club perhaps ? :-)
>
>    Paul

In the days of Disk Drive Overlays, eg MaxBlast, the MBR would contain
a dummy partition table. This table would be set up for a 20MB drive,
with 17 sectors per track. The DDO code would call additional code
which hid within the first track, before sector 63. This code would
install itself in memory and provide the needed INT 13 extensions that
were missing from the BIOS. The actual MBR and a full sized partition
table would hide elsewhere within track 0. This is the MBR that the OS
would see.

In any case, one would have to ask, why is the OP's MBR code loading
sector 0, head 1, track 79? What code is in that particular sector?

- Franc Zabkar
-- 
Please remove one 'i' from my address when replying by email.

[toc] | [prev] | [next] | [standalone]

#1037

> In any case, one would have to ask, why is the OP's MBR code loading sector 0, head 1, track 79? What code is in that particular sector?

M. Noob's MBR code is *not* doing that.  Again, go and read the GRUB2 
source.  Read the floppy_probe routine in grub-core/boot/i386/pc/boot.S 
.  Even the name alone is a bit of  a giveaway as to what the routine's 
purpose is.

[toc] | [prev] | [next] | [standalone]

#1002

On Fri, 22 Jul 2011 20:58:01 -0400, Paul <nospam@needed.com> put
finger to keyboard and composed:

>So can someone translate this for me ?
>
>WHY would a disk be set up this way, with what
>*altruistic* objective ?
>
>And WHAT software can we expect, to be mucking about in this way ?
>The "rootkit of the month" club perhaps ? :-)
>
>    Paul

Sorry, I just realised where I made my mistake.

The OP confused me by saying that one day his MBR was bad, whereas on
the next day it was good. He then posted two MBR dumps. I assumed that
the good dump was from his hard drive. Instead it appears to be a
standard MBR template for a floppy diskette. Once again my previous
experience with DDOs led me astray. Seagate's EZ-Drive, for example,
gives you a window of opportunity during the HDD boot process to
select the floppy drive as your boot device (using Ctrl-S, IIRC). This
enables the DDO to load itself into RAM (and enable INT 13 extensions)
before the floppy drive boots.

BTW, I found this article very informative:
http://thestarman.pcministry.com/asm/mbr/GRUB.htm

- Franc Zabkar
-- 
Please remove one 'i' from my address when replying by email.

[toc] | [prev] | [next] | [standalone]

#1038

> So can someone translate this for me ?
>
You can translate it for yourself.  Indeed you can read the untranslated 
original and save yourself even that effort.  GRUB2 is free software.  
Its source code, complete with comments explaining what it is doing, is 
there for the reading.  The file to read is  grub-core/boot/i386/pc/boot.S .

> WHY would a disk be set up this way, with what *altruistic* objective ?
>
Hint: The clue to its quite benign objective is the very name of the 
routine.

> And WHAT software can we expect, to be mucking about in this way ?  
> The "rootkit of the month" club perhaps ? :-)
>
One may think of GRUB2 in those terms if one likes.  It certainly (in 
this case) is installed in the place where MBR computer viruses live.

[toc] | [prev] | [next] | [standalone]

#1001

On Sat, 23 Jul 2011 10:05:47 +1000, Franc Zabkar
<fzabkar@iinternode.on.net> put finger to keyboard and composed:

>01ED 72D7          JB      01C6
>01EF B601          MOV     DH,01
>01F1 B54F          MOV     CH,4F
>01F3 E9E0FE        JMP     00D6
>
>Location 0xD6 contains an INT 13 opcode. Therefore, AFAICT, the above
>code reads 1 sector from sector 0, track 79 (=0x4F), head 1, drive 0
>to a buffer at address 0x7000.

Doh! There is an obvious reason for the existence of the "Floppy" text
string.

Drive 0 is the floppy drive (A:).

Track 79 is the last track of an 80-track diskette.

The drive would have two heads, 0 and 1.

- Franc Zabkar
-- 
Please remove one 'i' from my address when replying by email.

[toc] | [prev] | [next] | [standalone]

#1004

Franc Zabkar wrote:

> Noob wrote:
>
>>> Something trashed my MBR. Now when I boot the PC,
>>> I get the dreaded "NON-SYSTEM DISK. PLEASE INSERT
>>> SYSTEM DISK AND PRESS ENTER" (or something close).
>>
>> By MBR, I meant the first sector of my hard disk drive,
>> i.e. the boot-strapping code, and the table of primary
>> partitions.
>>
>>> I had used gparted to create three primary partitions
>>> (all partitions are aligned to 1 MiB, even though
>>> this is not a 4K-sector HDD)
>>> partition 1 : 80.00 GiB (for WinXP)
>>> partition 2 : 33.75 GiB (for Fedora 13)
>>> partition 3 : 765 MiB (for swap)
>>
>> Short version of the rest of original message : the first sector
>> had been shifted by 14 bytes. Weird, right?
>
> ISTM that you are confusing the real, "good" MBR (ie physical sector
> 0) with GRUB's "bad" MBR. The latter appears to be relocated to some
> other LBA(s), not LBA 0.

I got a copy of the MBR by running
dd if=/dev/sda of=mbr.bin bs=512 count=2

This should get to LBA 0, right?

My partition table is

80 20 21 00 07 fe ff ff 00 08 00 00 00 00 00 0a
00 fe ff ff 83 fe ff ff 00 08 00 0a 00 00 38 04
00 fe ff ff 82 fe ff ff 00 08 38 0e 00 e8 17 00

[toc] | [prev] | [next] | [standalone]

#1013

On Sat, 23 Jul 2011 21:25:06 +0200, Noob <root@127.0.0.1> put finger
to keyboard and composed:

>I got a copy of the MBR by running
>dd if=/dev/sda of=mbr.bin bs=512 count=2
>
>This should get to LBA 0, right?

I'm not a Linux user, but that seems OK to me (it's listed in
Wikipedia as one of the examples). In fact I wondered how you were
capturing these data because often such an offset is the result of the
application adding its own header information. In such cases the file
size would be 1038 (= 2 x 512 + 14), rather than 1024 bytes.

>My partition table is
>
>80 20 21 00 07 fe ff ff 00 08 00 00 00 00 00 0a
>00 fe ff ff 83 fe ff ff 00 08 00 0a 00 00 38 04
>00 fe ff ff 82 fe ff ff 00 08 38 0e 00 e8 17 00

Yes, I understood that from your original post. It's just that you
posted a "good" MBR dump that wasn't your own. That's what led me
astray. Sorry.

Some people have suggested that there may be a problem with your
system RAM, or with the drive's own SDRAM cache.

I wonder if you could disable Linux's HDD cache when performing your
tests. Then you could test the drive's cache memory (8MB) by dd-ing
data in 16MB blocks. In fact it should be sufficient to dd the first
8MB of data twice in succession, and then compare the two results.
This is because part of the 8MB cache is occupied by the drive's
firmware. This would mean that the second read should flush the first
sectors from the cache.

AFAICS, the following commands should do it:

 dd if=/dev/sda of=mbr_1.bin bs=512 count=32768
 dd if=/dev/sda of=mbr_2.bin bs=512 count=32768

Maxtor Diamondmax 10 Product Manual:
http://www.seagate.com/staticfiles/maxtor/en_us/documentation/manuals/diamondmax_10_product_manual_pata.pdf

- Franc Zabkar
-- 
Please remove one 'i' from my address when replying by email.

[toc] | [prev] | [next] | [standalone]

#1014

Franc Zabkar <fzabkar@iinternode.on.net> writes:
>On Sat, 23 Jul 2011 21:25:06 +0200, Noob <root@127.0.0.1> put finger
>to keyboard and composed:
>
>>I got a copy of the MBR by running
>>dd if=/dev/sda of=mbr.bin bs=512 count=2
>>
>>This should get to LBA 0, right?

Yes.  count=1 is sufficient for the MBR itself. 


>I wonder if you could disable Linux's HDD cache when performing your
>tests. Then you could test the drive's cache memory (8MB) by dd-ing
>data in 16MB blocks. In fact it should be sufficient to dd the first
>8MB of data twice in succession, and then compare the two results.
>This is because part of the 8MB cache is occupied by the drive's
>firmware. This would mean that the second read should flush the first
>sectors from the cache.
>
>AFAICS, the following commands should do it:
>
> dd if=/dev/sda of=mbr_1.bin bs=512 count=32768
> dd if=/dev/sda of=mbr_2.bin bs=512 count=32768

Much much much much more efficient to use bs=16m count=1, which will issue a single read
versus 32,768 reads.

If the hard disk is an IDE or SATA drive, you can use the hdparm command to disable
the drive cache.

It is highly unlikely that this is a drive problem, however.   Much more likely that
the scatter gather list entry given by the driver to the SATA/IDE controller is fubared
which implies a memory issue (although I can't figure a 14-byte offset from a single
bit error).

Another possiblity is a corrupted driver or rootkit.

scott

[toc] | [prev] | [next] | [standalone]

#1015

On 24 Jul 2011 23:08:09 GMT, scott@slp53.sl.home (Scott Lurndal) put
finger to keyboard and composed:

>Franc Zabkar <fzabkar@iinternode.on.net> writes:
>>On Sat, 23 Jul 2011 21:25:06 +0200, Noob <root@127.0.0.1> put finger
>>to keyboard and composed:
>>
>>>I got a copy of the MBR by running
>>>dd if=/dev/sda of=mbr.bin bs=512 count=2
>>>
>>>This should get to LBA 0, right?
>
>Yes.  count=1 is sufficient for the MBR itself. 

I believe the OP specified count=2 so that he could account for the
14-byte offset.

>>I wonder if you could disable Linux's HDD cache when performing your
>>tests. Then you could test the drive's cache memory (8MB) by dd-ing
>>data in 16MB blocks. In fact it should be sufficient to dd the first
>>8MB of data twice in succession, and then compare the two results.
>>This is because part of the 8MB cache is occupied by the drive's
>>firmware. This would mean that the second read should flush the first
>>sectors from the cache.
>>
>>AFAICS, the following commands should do it:
>>
>> dd if=/dev/sda of=mbr_1.bin bs=512 count=32768
>> dd if=/dev/sda of=mbr_2.bin bs=512 count=32768
>
>Much much much much more efficient to use bs=16m count=1, which will issue a single read
>versus 32,768 reads.
>
>If the hard disk is an IDE or SATA drive, you can use the hdparm command to disable
>the drive cache.

I was thinking that the OP should disable the OS cache in system RAM
rather than the drive's onboard cache. However, I agree that your idea
has merit also.

>It is highly unlikely that this is a drive problem, however.   Much more likely that
>the scatter gather list entry given by the driver to the SATA/IDE controller is fubared
>which implies a memory issue (although I can't figure a 14-byte offset from a single
>bit error).
>
>Another possiblity is a corrupted driver or rootkit.

If this were the case, then if the OP were to boot from an optical
drive before attempting to boot from the HDD, he should see a good
MBR. If instead he boots first from the HDD, and the corruption or
rootkit takes effect by loading code into RAM, a subsequent soft
reboot (Ctrl-Alt-Del) may result in him seeing a bad MBR rather than
the real one at LBA 0. A hard reset should be OK, though.

>scott

- Franc Zabkar
-- 
Please remove one 'i' from my address when replying by email.

[toc] | [prev] | [next] | [standalone]

#1018

Franc Zabkar <fzabkar@iinternode.on.net> writes:


>I was thinking that the OP should disable the OS cache in system RAM
>rather than the drive's onboard cache. However, I agree that your idea
>has merit also.

With linux, specify "iflag=direct" on the dd(1) command to bypass the
OS cache.

However, given that the OS cache is always page-sized[*] and page-aligned,
I find it quite difficult to believe that something in the OS cache layer
is corrupting data in this fashion.

scott

[*] 4096 bytes on x86 and X86_64.

[toc] | [prev] | [next] | [standalone]

#1019

Scott Lurndal wrote:
> Franc Zabkar <fzabkar@iinternode.on.net> writes:
> 
> 
>> I was thinking that the OP should disable the OS cache in system RAM
>> rather than the drive's onboard cache. However, I agree that your idea
>> has merit also.
> 
> With linux, specify "iflag=direct" on the dd(1) command to bypass the
> OS cache.
> 
> However, given that the OS cache is always page-sized[*] and page-aligned,
> I find it quite difficult to believe that something in the OS cache layer
> is corrupting data in this fashion.
> 
> scott
> 
> [*] 4096 bytes on x86 and X86_64.

Looks like a job for some kind of bootable disk editor (one
which is sans OS). I wonder what's available.

    Paul

[toc] | [prev] | [next] | [standalone]

#1022

On Sun, 24 Jul 2011 22:38:19 -0400, Paul <nospam@needed.com> put
finger to keyboard and composed:

>Looks like a job for some kind of bootable disk editor (one
>which is sans OS). I wonder what's available.

The following disc editor has a DOS version. I would think it should
be OK as long as you don't load smartdrv.

DMDE - DM Disk Editor and Data Recovery Software:
http://softdm.com/download.html

- Franc Zabkar
-- 
Please remove one 'i' from my address when replying by email.

[toc] | [prev] | [next] | [standalone]

#1021

On 25 Jul 2011 02:19:10 GMT, scott@slp53.sl.home (Scott Lurndal) put
finger to keyboard and composed:

>Franc Zabkar <fzabkar@iinternode.on.net> writes:
>
>
>>I was thinking that the OP should disable the OS cache in system RAM
>>rather than the drive's onboard cache. However, I agree that your idea
>>has merit also.
>
>With linux, specify "iflag=direct" on the dd(1) command to bypass the
>OS cache.
>
>However, given that the OS cache is always page-sized[*] and page-aligned,
>I find it quite difficult to believe that something in the OS cache layer
>is corrupting data in this fashion.

I'm suggesting that the OS cache needs to be bypassed so that we can
be certain that the data are coming from the drive on the second pass
with dd. If the OS cache were enabled, then we would just be comparing
the OS cache against itself.

- Franc Zabkar
-- 
Please remove one 'i' from my address when replying by email.

[toc] | [prev] | [next] | [standalone]

#1056

In article <tB1Xp.52981$NY4.46062@news.usenetserver.com>,
 scott@slp53.sl.home (Scott Lurndal) wrote:

> It is highly unlikely that this is a drive problem, however.   Much more likely that
> the scatter gather list entry given by the driver to the SATA/IDE controller is fubared
> which implies a memory issue (although I can't figure a 14-byte offset from a single
> bit error).

Has everything passed me by? 
(Rhetorical question. Answer: yes)
"Fubar" used to be sufficient. 

If you know what "mung" means, Patty at the 
front desk of the assisted living facility
will award you a token for a free game of Bingo.

-- 
Michael Press

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.unix.programmer

csiph-web