On Wed, 06 Aug 2014 17:04:33 -0400, Wolf K  wrote:

> On 2014-08-06 12:00 PM, David W. Hodgins wrote:
>> I totally disagree. The bios and mbr both do contain code, but they are
>> both just blocks of code, with no names, no index, and each can only
>> contain the code (though the mbr also contains the partition table).
>
> If there is no index, then how can you change the boot sequence? BIOS

Are you serious? The boot menu is showing and interpreted by the code
loaded from the bios (or in more modern systems uefi).

> has to have some ind of index to user-changeable data. An index to data
> is a file system. The partition table on MBR is located at fixed
> locations, a structure that constitutes a primitive file system. There
> is a good deal more to BIOS and MBR than "blocks of code". As I've
> pointed out before: BIOS is in fact a collection of small programs plus
> data. BIOS has been growing, too, as more and more functions have been
> added to it.

In a dos style bios, all it does is the power on self test (POST),
then (with some bios code), present the option of selecting the
boot device. Once the boot device has been selected, all the bios
does is load the code from the first sector and then transfer
control to it. It's up to the code in the first sector whether or
not additional sectors are loaded too.

>> When the computer starts, it loads the block of code stored in the
>> bios, and then runs it. It does not search through a file system to
>> decide which "file" to load, as it doesn't yet have any code to run
>> that could search a file system.
>
> IOW, it addresses a storage location, copies a block of data from there
> into RAM, and then treats that block of code as a program. The fact that
> this storage location is physically on a chip instead of a disk is
> immaterial. The simplest BIOS would simply fetch the block of data from

I do not agree. Whether the code is loaded from a chip, or a file system
on a disk, is the whole point of this discussion.

> track 0 (and possibly more) on the disk. That would mean that every
> bootable disk would have to come preloaded with information about where
> to find the bootloader, etc. That could be done, in fact was done with
> bootable floppies, which some of you may be old enough to remember.

The bios will only load the code from sector 0, of track 0.

> I think what's at issue here is the notion that what an OS does is
> somehow fundamentally different from what BIOS does. It ain't. The
> process is always the same: fetch data, and deal with it. BIOS is a
> minimal OS: it does very little, but that little is essential. Mess up
> the code, and the computer will not boot.

I do not agree. A file has a name, and is stored in a file system.
The bios is just a chunk of code stored on a chip. It does not have
a file name, and is not accessible using regular disk io.

> There is also the notion that a "real" file has to have a name in order
> to be accessible to the OS. It doesn't. Basically, a directory is a set
> of pointers to blocks of data, ie, the files. Names are added for human
> convenience. The OS doesn't need them. You can in fact read the BIOS
> from any OS, given a suitable utility. You can even write to BIOS, given
> a suitable utility. This utility is in practice packaged with the BIOS
> update.

The i/o calls to write to a disk or do a bios update are quite different.

> A filemanager could be written to allow you to see the files that
> constitute the BIOS, the MBR, etc. There are of course good reasons
> that's not done. But the malware makers have no scruples about reading
> and writing these files. The fact the filemanager can't see them is a
> bonus from their POV. Rootkit removers do the same as the malware
> installers: they read and write to BIOS, the MBR, and other hidden files
> in order to destroy the evil stuff residing there.

There are not multiple files in the bios. It's one chunk of code, and
that is all there is.

> I fail to see why a file needs a name etc, and needs to be found by a
> file manager, in order to be a "true" file. In fact, I think this usage

It is possible to have unnamed files (at least in linux), but the
file does have to have a name when it's created. The file can then
be unlinked, making it inaccessible to regular file browsers, but
won't be deleted until all programs accessing it are closed.

> misleads people, as the Subject of this thread the subsequent discussion
> illustrates. Of course the malware consists of files. If you think these
> files are somehow not files, it may be difficult for you to understand
> a) how they can do their evil work; and b) how they can be destroyed.

As before, the mbr, and the bios are not files.

> Granted, in common usage "file" means "a block of data with a name,
> locatable by the OS". In most contexts, this is the proper usage. But
> when it comes to malware that hides from the OS, it is IMO bad usage. In
> such contexts, nit-picking insistence on technical precision is important.

Understanding the difference is needed when removing malware. Removing a
root kit installed in the mbr is different then removing a virus from a
file the os has access to.

> Have a good day.

You too.

Regards, Dave Hodgins

-- 
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)
--- NewsGate v1.0 gamma 2