AV Users cleansing computers - You are being ILLOGICAL

Jim, I think a format is enough to cleanse the dirt under the "carpet", right? There's no need to deep delete... Anything that isn't recorded by the file system is considered free space, I don't think it'll do any harm...

zzz2496

You make some really good points Jimbo...that's pretty much the most effective way to do it. However, I wouldn't go as far as to say that it will work 100% of the time. There will always be that one little nasty virus that hangs on with everything it's got. If it's not out there yet, it will be.

Reminds me of the attached picture.

jimbo45 said:

zzz2496 said:

Jim, I think a format is enough to cleanse the dirt under the "carpet", right? There's no need to deep delete... Anything that isn't recorded by the file system is considered free space, I don't think it'll do any harm...

zzz2496

Hi there

Deep delete is actually necessary since some of the nastier worms etc get into the "control" sectors of the disk which aren't normally seen by the file system which is why they are hard to detect.

A Format is not sufficient -- all that does is clear out the DIRECTORY (or the Table of Contents) -- the data and hence the Virus is still on the HDD drive. It's relatively simple to recover data from a Disk that has been formatted -- even the old DOS UNFORMAT command was quite good in the past.


I'd recommend the deep format any day -- it's about the best you can do without buying new HDD's.

Hi Blackrose --- agree -- a picture is worth 1000's of words.

Cheers
jimbo

I understand about the deal about deleting things won't entirely delete the data off the disk (thus undelete products works). But I mean, the virus/malware is there, there's no doubt about it... but if it's not registered by the FS, the OS can't execute it, right? I mean, our Operating System can only see files that is indexedby the file system, if it's recorded/indexed by the fs, the OS can execute it, be it a virus, a malware, a word processor, anything. It's the same concept as memory pointers and heap memory.

Btw, what do you mean by "control" sectors? File system in Windows literally is the MFT file (and it's accompanied files). A binary file that can hide it self from the OS yet can still run it self, you mean a rootkit? Rootkits are wiped off the disk when you format it. Most of rootkits will load it self at OS start, loading it self to the memory, or at least the "start-up" part to the memory, and that small program will read the disk by LBA address to load the "main program". I know, I tried that once in my test system (a VM). If I load the VM disk and have a program to analyze the content, the rootkit is still there, yet when I reinstall the OS, the rootkit doesn't "reload" it self... Deep delete is a bit over the top IMHO...

zzz2496

jimbo45 said:

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.