Hi there
Don't forget that ANY hardware can be controlled by TWO different mechanisms -
1) Via the OS API - for example say you want to write to File X then the OS itself will perform the actual call to The I/O device either via a BIOS call or via a kernel module. This is how programs SHOULD be written -- go via the OS interface.
2) Particularly Gaming and Video -- programs often make DIRECT CALLS to the HARDWARE itself bypassing the BIOS calls etc and not dependent on the underlying file system - this is often done where very high speed and throughput are needed.
Anybody with a slight nous of Intel (or AMD) assembler / machine language can do a READ SECTOR disk read -- probably can be done in C++ too -- although I'm not a C++ programmer.
Now if we take a DISK there's a large buffer area built in to each HDD that isn't directly accessible by the file system in the OS. A rogue program only needs to initiate a direct call to the DISK and you can do anything.
Just consider how your OS Bootstrap works
When you press the START key on the computer (or power on switch) the BIOS is set to read and execute ONE instruction located at a specific address (Bootstrap1).
This tells the computer to now read sector XXXX of the disk into memory and start executing the block of code read in. (Bootstrap 2)
This block of code now loads the rest of the OS and Windows can start. -- It's not so simple but you should get the idea -- this code is executed WITHOUT any undelying file system or OS.
If this has been tampered with neither Windows nor your AV program will know anything about it until its TOO LATE.
There's all sorts of pieces a computer has where rogue code can get executed without the OS knowing anything about it until its too late.
Whether wiping Disks is over the top or not -- I'd rather take the extra time on KNOWING I have a reliable computer before doing any BANKING or similar transactions on it.
I wouldn't EVER trust a "merely cleaned" computer with any secure data -- OK YMMV but time is easily regained -- it's not so simple to regain your cash if its been whizzed off into cyberspace.
Better safe than sorry -- and if getting infected is a regular occurrence then perhaps one should look at what they are really doing on their machines.
Cheers
jimbo
I see. Here's the thing, an OS kernel is running in "Ring 0" in system security hierarchy. Everything that goes to any hardware must go through kernel. For a kernel to be able to understand what the hardware under it's governance is through the use of "device drivers". That is the kernel interface to the lower layers (hardware). The kernel also have interfaces to the upper layers, OS API (Direct X, Storage APIs, File management, etc), The user space it self, User space utilities, and many others. As you said, a device that needs a high throughput/low latency data transfers usually bypasses OS's API and use it's own custom interface directly to the kernel it self, most of the time can interface directly to the device drivers.
For a rootkit to be able to hide it self from "Windows", is practically easy business, because Windows have many user space processes that interfaces directly to the kernel. Display drivers are one of the bad example, user space driver installer is another one... A user space process can directly access the graphic driver to do something. From a performance point of view, this is GREAT, the result is MANY GAMES thrived in Windows because developers can tap directly into device driver from a user space initiated process. *nix like OS can't, because the kernel is isolated from user space view, thus it's harder to hid a rootkit in *nix. Not that it's impossible, it's possible, but MUCH HARDER.
Back to the high performance business, games can call to the
device drivers directly, the app can't use a hardware directly, everything must go through the OS's kernel, which contains device driver. Let's say you want to tell the disk to do a write, 4KB data, write to storage LBA 11566. This can't be done if the kernel doesn't have a device driver that enumerates and reports that there's a disk at X point that has 1589787667 LBA addresses (just an example).
All this is the fault of 32bit transition and the lack of technology that can replace BIOS. Back then in the DOS days, you don't need a device driver, everything is handled by BIOS. If you need to access a sound card, you make a request to IRQ 7, DMA channel 5, and just go a head, put your instructions to the stream, that's your sound card right there. Everything is controlled by BIOS. These days, hardware became much more complicated and a PC can contain A LOT MORE compared to back in DOS days, it needs an abstraction layer. BIOS is a 20+ years legacy, it has limited capacity of devices it can enumerate, it has limited address space to enumerate (BIOS is mostly 16 bit software, written in Assembler language). BIOS can't enumerate harddisk more than 504MB capacity, it needs an abstraction layer to be able to access more. It called Logical Block Address table, or LBA. Why do we have LBA? Because BIOS is too stupid to understand...
As for cache in harddisks, those small speedy memory is not accessible at all, it's being controlled by the harddisk's firmware. For boot up process, you are right, there is a special place in harddisk's location, it's called MBR, or INT 13 in BIOS lingo. It's a special place in first few sectors in a sector-based storage system that contains a bootstrap instructions. This is most of the time is the OS's main kernel image (in Windows, it's the NTKRNL.EXE, in Linux, it's the vmlinuz.bin). Once the kernel is loaded, it will start it's initialization process, loading modules and device drivers. Once everything is loaded, it will start re-enumerating everything, from hardware components to filesystems connected to the computer. Once everything is done, it will start the user space process, user profile manager is called, wininit, etc. I understand the process (I've tried compiling my own Linux kernel with my device drivers compiled into the kernel it self and watch the kernel load up back in the day, it's amazing).
Now, this little bootloader, can be overwritten by a virus (it can, back in DOS days) to load a modified version of OS kernel image. In DOS this is doable because MSDOS.SYS is so small and very simple, you can hack away and nothing will go wrong (remember, every device is controlled directly by BIOS). But these days, no one can modify the kernel image and hope that the computer will keep on working... 32bits kernel is one intricate piece of software, one false instruction - everything will stop working, not even a BSOD is generated. Most of the time, rootkits will install a small part of it self directly to the kernel, just like a device driver (but not a device driver). Windows's OS API works on the upper layers of system hierarchy, it can't know what is on the kernel it self, thus the "invisibility". You can't use the OS API to scan the disk and find the rootkit, because it can read what storage driver's reports and it can manipulate the output, let's say if it reads LBA 1156, always report that that LBA is occupied by a system file so that the AV alarm is not triggered.
There's all sorts of pieces a computer has where rogue code can get executed without the OS knowing anything about it until its too late.
True, but first it has to make a "reservation" in the kernel to do it's work, a cleanly formatted system doesn't have such "reservation". Disk wiping is over the top IMHO. If you want to destroy traces of important information hidden in your disks, a deep delete is the only way because the forensics will do EVERYTHING to get ANYTHING back off any disk it got it's hands on, this is human working with objective of getting something by ANY MEANS, you need a deep delete to hide/destroy anything. A rootkit is not human, it's not programmed to do the same like those forensics experts to find it's code buried deep in your disk, it's not that smart... But deep delete is safer from a security stand point, although I'd still say it's not needed. A deleted record is considered non existent by the system. You need a special software that can read data streams and understand a file layout (file header, file content, eof marker, etc), then reports back to the user that it found a file header at LBA xyz, sized 1564366 bytes, probably named "something.doc", then it'll probably asked you with "do you want to restore it?"-kind of question... And you pushed the "OK" button...
From a systemic standpoint, it's not necessary to do a deep delete to wipe a virus/malware/rootkit infection. You just need to make sure that ANY DATA that's being put back doesn't have the "dangerous payload", and make sure that any other computers on the network is also clean from this virus/malware/rootkit infection... But then again, it's your computer, if you want to deep delete - that's your decision, it's not necessary, but still your call
zzz2496
Ps. There's 2 kind of OS kernel, a Macro Kernel and a Micro kernel. A Macro kernel is a kernel that has device drivers compiled into it self. Macro kernel is large, has very limited flexibility on adding more hardware (adding hardware = recompiling the kernel), but VERY FAST and VERY EFFICIENT. A Micro kernel is a very small, modular kernel that has interfaces for device drivers to "attach" to. Windows and modern Linux use Micro kernel. Old UNIX use Macro kernel.
