Re: It's getting very rough out there.

Post #343,615 by Ashton 6/12/11 4:12:02 AM Reply	Re: It's getting very rough out there. re Even if you format the disk and reinstall completely, it's still infected. I presume you mean that, via the boot-kit the MBR-dance remains, faking-out the new 'install' as before. So then, if HD is removed, erased say, in a *nix box and all bits set to (00000 or whatever) -- is that sufficient? (Or is the base-format itself changed by the boot-kit, such that the special n sectors appear to be "(B)ad", also a clue?) Would latest SpinRite handle the mangled sectors via its recovery scrubbing, then ID-ing the oddly-formatted "secret/Bad" sectors? Maybe seeing the 'damage' as merely a need for a sector-level base-format rewrite. Would that process not restore hygiene, or am I missing something more subtle? (You say 'unallocated space', mayhap some few bytes in-between Partitions, thus never available for normal data R/W?) I don't know how SpinRite treats such anomalous places, though clearly the entire base-format is rewritten on every full run, cylinder by cylinder. Which should catch these moles I'da thunk.. In any event, for 99% of users who would comprehend none of this -- how long, do ya guesstimate? before the IntarWeb majority has an epiphany == generally comes to realize that the game has entered a new dimension / that Redmond still flunks security 101 ... and a (very)-critical-mass goes viral with multiple horror stories ?? And we haven't yet had WCW-1, yet [World-Cyber-War] -- the practical application of [n!] writ Large. YPB--millions, eh?
Post #343,619 by scoenye 6/12/11 10:52:02 AM Reply	It shouldn't Assuming the repairs are attempted after cold booting from clean CD or flash drive, the pre boot code will not be run. If anything, it is because the standard formatting tools do not touch the boot sector as it is not part of any partition. The bootsector needs to be reset separately (e.g. via fdisk). Spinrite and the secure erase tools that write over the entire HDD will clean it out as well.
Post #343,621 by Andrew Grygus 6/12/11 12:44:56 PM Reply	Re: It's getting very rough out there. If you look with allocation tools like fdisk, there's usually about 8 megs of unalocated space. That's where the infection would place its file system. Kaspersky's tdsskiller utility is supposed to detect these infections and clean them up. Haven't tried that yet, because I got this one by another means. Only by doing so was I able to find out what to look for to fix it. I ran Combofix in Safe Mode. It found root kit activity as usual and started its special reboot for clean-up (which doesn't work in this case). I killed the reboot, booted into Recovery Console and replaced the MBR using fixmbr (which runs only from the recovery console). I then rebooted into Safe Mode. The startup was intercepted by Combofix as usual but this time it detected TDS4 infection and killed it. I don't know if fdisk would cure this problem - it might, but it might not. If I really wanted to be sure, I'd hook the drive to another system and use a disk editor to overwrite the whole MBR with $00.
Post #343,638 by folkert 6/12/11 7:28:34 PM Reply	dd if=/dev/zero of=/dev/hda bs=1048576 count=1024 That will get past the 1024 limit just fine... Though 100MB should be fine.
Post #343,682 by jake123 6/13/11 11:18:25 PM Reply	Re: dd if=/dev/zero of=/dev/hda bs=1048576 count=1024 That's exactly what I thought of when I read Andrew's post. God, I've become a Unix junkie. What has happened to me? ;)
Post #343,686 by folkert 6/14/11 12:13:04 AM Reply	Hey... you see that... + That is the world's smallest digital violin playing for you.

Welcome to IWETHEY!