http://www.f-secure.com/weblog/archives/00001393.html

-- 
                                                          - Warp

Post a reply to this message

> http://www.f-secure.com/weblog/archives/00001393.html

Don't most BIOSs have some "prevent write to MBR" function?  Would malware 
like this be able to get around that?

Post a reply to this message

scott wrote:

> Don't most BIOSs have some "prevent write to MBR" function?

Ususally, yes. And usually, it's "off" by default. (When you unpack a 
brand new PC, what's the first thing you do? Install an OS.)

> Would malware like this be able to get around that?

Unlikely. But this measure isn't commonly enabled.

More interesting is that it can touch the MBR from Windoze in the first 
place...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On Wed, 12 Mar 2008 13:02:28 +0000, Invisible wrote:

> Ususally, yes. And usually, it's "off" by default. (When you unpack a
> brand new PC, what's the first thing you do? Install an OS.)

That depends on what type of machine you bought.  If you go out and 
purchase a brand-name computer, the OS is already installed.

If you build your own, this is true, but most machines the OS is already 
pre-installed.

Jim

Post a reply to this message

> That depends on what type of machine you bought.  If you go out and 
> purchase a brand-name computer, the OS is already installed.
> 
> If you build your own, this is true, but most machines the OS is already 
> pre-installed.

True. But I'd wager that MBR protection is probably turned off on most 
machines out there.

(Similarly, most have a BIOS write-protect feature so malware can't 
reflash the BIOS. And that's usually off. But then, any such malware 
would only work for one brand of motherboard anyway since there's no 
standard interface for that kind of thing...)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v7 <voi### [at] devnull> wrote:
> True. But I'd wager that MBR protection is probably turned off on most 
> machines out there.

  What actually happens if some software (for example an OS installer)
tries to modify the MBR and it has been bios-protected?

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Orchid XP v7 <voi### [at] devnull> wrote:
>> True. But I'd wager that MBR protection is probably turned off on most 
>> machines out there.
> 
>   What actually happens if some software (for example an OS installer)
> tries to modify the MBR and it has been bios-protected?

Varies by BIOS.

I believe what it *actually* does is yell "hey, somebody changed this!" 
rather than actually _prevent_ the change from happening. But again, it 
depends on what the BIOS writer has programmed it to do. To be honest, 
I've never tried it myself...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v7 <voi### [at] devnull> wrote:
> I believe what it *actually* does is yell "hey, somebody changed this!" 

  How does it do that? The bios cannot have sufficient info about the
graphics card in order to show a message on screen, especially if the
graphics card is currently in non-vga mode.

-- 
                                                          - Warp

Post a reply to this message

>> I believe what it *actually* does is yell "hey, somebody changed this!" 
> 
>   How does it do that? The bios cannot have sufficient info about the
> graphics card in order to show a message on screen, especially if the
> graphics card is currently in non-vga mode.

No - it displays a message during the POST sequence. (And waits for a 
keypress.)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v7 <voi### [at] devnull> wrote:
> No - it displays a message during the POST sequence. (And waits for a 
> keypress.)

  What's that?

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Orchid XP v7 <voi### [at] devnull> wrote:
>> No - it displays a message during the POST sequence. (And waits for a 
>> keypress.)
> 
>   What's that?

Power On Self Test.

In other words, the text-mode screen that briefly flashes past when you 
first power on the system. (That's why it waits for a confirmation 
keypress - otherwise you'd never SEE the damn thing!)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v7 <voi### [at] devnull> wrote:
> Warp wrote:
> > Orchid XP v7 <voi### [at] devnull> wrote:
> >> No - it displays a message during the POST sequence. (And waits for a 
> >> keypress.)
> > 
> >   What's that?

> Power On Self Test.

  And how would it detect at that stage if something modified the MBR?
And even if it did, wouldn't it be too late? The modification and thus
the damage already happened.

-- 
                                                          - Warp

Post a reply to this message

On Wed, 12 Mar 2008 18:45:07 +0000, Orchid XP v7 wrote:

>> That depends on what type of machine you bought.  If you go out and
>> purchase a brand-name computer, the OS is already installed.
>> 
>> If you build your own, this is true, but most machines the OS is
>> already pre-installed.
> 
> True. But I'd wager that MBR protection is probably turned off on most
> machines out there.

Very likely.

> (Similarly, most have a BIOS write-protect feature so malware can't
> reflash the BIOS. And that's usually off. But then, any such malware
> would only work for one brand of motherboard anyway since there's no
> standard interface for that kind of thing...)

Actually, I don't think it'd be that hard - it wouldn't be a single brand 
of motherboard - there's only 3 or 4 major BIOS brands out there these 
days, if that.

Jim

Post a reply to this message

On Wed, 12 Mar 2008 16:05:06 -0500, Warp wrote:

> Orchid XP v7 <voi### [at] devnull> wrote:
>> No - it displays a message during the POST sequence. (And waits for a
>> keypress.)
> 
>   What's that?

POST = Power On Self Test.  I'm really surprised you don't know that, 
it's a very common thing for people who work with computers to know. 

<again, scnr>

Jim

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote
> Orchid XP v7 <voi### [at] devnull> wrote:

> > No - it displays a message during the POST sequence. (And waits for a
> > keypress.)

>   What's that?

You push down on a key until it registers or bottoms out. There's usually an
audible click too.

Post a reply to this message

Invisible wrote:
> More interesting is that it can touch the MBR from Windoze in the first 
> place...

Why's that interesting? Run "diskpart" (which comes with Windows) and 
tell it to look at the MBR.  Or google mbrfix, and have a program 
that'll read *and* write.

Indeed, read the first 512 bytes from the file \\.\physicaldisk0 to look 
at your MBR.  I just couldn't get it to open for writing.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Warp wrote:
>   And how would it detect at that stage if something modified the MBR?

It stores in the CMOS the checksum of the previous MBR.

> And even if it did, wouldn't it be too late? The modification and thus
> the damage already happened.

MBRs are pretty standard. You know your system is hosed, so instead of 
continuing you boot the CD and rewrite the MBR. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

somebody wrote:
> "Warp" <war### [at] tagpovrayorg> wrote
>> Orchid XP v7 <voi### [at] devnull> wrote:
> 
>>> No - it displays a message during the POST sequence. (And waits for a
>>> keypress.)
> 
>>   What's that?
> 
> You push down on a key until it registers or bottoms out. There's usually an
> audible click too.

BURN!  :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

scott wrote:
>> http://www.f-secure.com/weblog/archives/00001393.html
> 
> Don't most BIOSs have some "prevent write to MBR" function?  Would malware 
> like this be able to get around that?

This only applies to software that uses the BIOS for disk I/O. Basically
this means bootloaders and somtimes first-level bootstrap routines (DOS
also). Modern OS's always have their own hardware drivers for disks.

Basically anything that can gain supervisor privileges on a windows system
can do whatever it wants with the hardware, even bypassing the OS's own
driver if need be (the latter requires that it understand the hardware of
course).

Post a reply to this message

>> True. But I'd wager that MBR protection is probably turned off on most
>> machines out there.
>
>  What actually happens if some software (for example an OS installer)
> tries to modify the MBR and it has been bios-protected?

ON mine I get a blue screen alerting me that something is trying to 
overwrite the MBR, and do I want to allow the write or not.

Post a reply to this message

>> I believe what it *actually* does is yell "hey, somebody changed this!"
>
>  How does it do that? The bios cannot have sufficient info about the
> graphics card in order to show a message on screen, especially if the
> graphics card is currently in non-vga mode.

I would imagine it goes something like this:

Interrupt 13 handler (file I/O) code inside BIOS:

Check if trying to write to MBR (always on the same place)
If not, write as usual to the drive, return
Change screen mode to 720x480 (or whatever that one is the BIOS uses at 
startup) using an interrupt 10 call
Display some text on the sceeen using the same routines as the BIOS setup 
screen etc
Wait for keyboard input (note this totally hangs the system)
If user agrees, write the data as normal to the disc
If not, just exit the interrupt handler

Post a reply to this message

On Thu, 13 Mar 2008 09:51:41 +0100, scott wrote:
> I would imagine it goes something like this:
>
> Interrupt 13 handler (file I/O) code inside BIOS:

No modern OS uses 16-bit BIOS interrupts.

I have understood so that the MBR write protection simply
discards any writes addressing the MBR, silently.

-- 
Joel Yliluoma - http://iki.fi/bisqwit/

Post a reply to this message

>> I would imagine it goes something like this:
>>
>> Interrupt 13 handler (file I/O) code inside BIOS:
>
> No modern OS uses 16-bit BIOS interrupts.

Well yeh I doubt it does, but that's how I understood the BIOS MBR 
write-protect feature to work that I'd seen in the past on my system.

Post a reply to this message

Jim Henderson <nos### [at] nospamcom> wrote:
> POST = Power On Self Test.  I'm really surprised you don't know that, 
> it's a very common thing for people who work with computers to know. 

  I program computers, I don't build them.

-- 
                                                          - Warp

Post a reply to this message

scott wrote:
>>> I believe what it *actually* does is yell "hey, somebody changed this!"
>>
>>  How does it do that? The bios cannot have sufficient info about the
>> graphics card in order to show a message on screen, especially if the
>> graphics card is currently in non-vga mode.
> 
> I would imagine it goes something like this:
> 
> Interrupt 13 handler (file I/O) code inside BIOS:
> 
> Check if trying to write to MBR (always on the same place)
> If not, write as usual to the drive, return
> Change screen mode to 720x480 (or whatever that one is the BIOS uses at 
> startup) using an interrupt 10 call

You can't call an interrupt from within an interrupt (at least, you 
couldn't when I was messing with them, but that was 12 years ago... of 
course, I doubt they've changed much since then).

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

scott <sco### [at] laptopcom> wrote:
> Interrupt 13 handler (file I/O) code inside BIOS:

  Any current OS will override the default interrupt handlers created
by BIOS. There's just no way BIOS can catch a write attempt to the disk
by simply having an interrupt handler. If it needs to catch it, there
has to be some other way. It probably nees cooperation from the disk
controller logic or something.

-- 
                                                          - Warp

Post a reply to this message

Chambers wrote:
> You can't call an interrupt from within an interrupt (at least, you 
> couldn't when I was messing with them, but that was 12 years ago... of 
> course, I doubt they've changed much since then).

I think this is what interrupt priority levels are all about. Depends on 
the CPU of course.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

On Thu, 13 Mar 2008 09:42:55 -0500, Warp wrote:

> Jim Henderson <nos### [at] nospamcom> wrote:
>> POST = Power On Self Test.  I'm really surprised you don't know that,
>> it's a very common thing for people who work with computers to know.
> 
>   I program computers, I don't build them.

When I was starting out in the computer business, I was programming and 
using just IBM PS/2s, not building them.  But I knew what it was, and 
everyone I knew knew what it was.

It's just so surprising that such a fundamental element of computers is 
something you don't know.  I thought everyone knew what it was - even my 
mother knows what POST stands for, and she is functionally computer-
illiterate....(OK, not really, but you get my point)

Jim

Post a reply to this message

Jim Henderson <nos### [at] nospamcom> wrote:
> It's just so surprising that such a fundamental element of computers is 
> something you don't know.

  I'm feeling like Andrew like now. ;)

  Of course I know that the bios makes tests (at least by default) when
booting. I just didn't know what "POST" means.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Jim Henderson <nos### [at] nospamcom> wrote:
>> It's just so surprising that such a fundamental element of computers is 
>> something you don't know.
> 
>   I'm feeling like Andrew like now. ;)
> 
>   Of course I know that the bios makes tests (at least by default) when
> booting. I just didn't know what "POST" means.

Mmm, humility? >:-)

Nobody knows *everything*, even about a specific topic. So let's all 
just chill, k people? ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On Sun, 16 Mar 2008 17:25:10 -0500, Warp wrote:

> Jim Henderson <nos### [at] nospamcom> wrote:
>> It's just so surprising that such a fundamental element of computers is
>> something you don't know.
> 
>   I'm feeling like Andrew like now. ;)
> 
>   Of course I know that the bios makes tests (at least by default) when
> booting. I just didn't know what "POST" means.

:-)

Jim

Post a reply to this message

On Mon, 17 Mar 2008 09:42:36 +0000, Invisible wrote:

> Nobody knows *everything*, even about a specific topic. So let's all
> just chill, k people? ;-)

That was my point to Warp. ;-)

Jim

Post a reply to this message

Warp wrote:
>   Of course I know that the bios makes tests (at least by default) when
> booting. I just didn't know what "POST" means.

Me, I always wondered why the first thing the computer does is POST and 
not PRE.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

On Wed, 19 Mar 2008 19:04:48 -0700, Darren New wrote:

> Warp wrote:
>>   Of course I know that the bios makes tests (at least by default) when
>> booting. I just didn't know what "POST" means.
> 
> Me, I always wondered why the first thing the computer does is POST and
> not PRE.

LOL, good one, Darren.  After last week, I needed a good laugh. :-)

Jim

Post a reply to this message