Hojo_Norem wrote:
The command line above will only touch the first 512 bytes of the drive because of the count=1 option. It does not physically blank the entire drive. This command line was a modification on what I found by simply googleing 'dd boot sector'. (For the first link found. A few results down features a near exact version of the line above.)
I missed the use of
count=1. Apologies. The rest of my advice still stands.
Hojo_Norem wrote:
I've been reading up on GPT partition tables. Changing the
bs=512 to
bs=32K should be enough to get both the MBR and primary GPT, even on 4K sector drives.
As being 'effectively' blanking the drive, bad choice of words on my part. Still, from the point of view from the OS installers, they should see only a completely blank drive and the act of repartitioning and formatting will do the rest. Sure, forensic examination would be able to pull some of the old data off the drive before it gets overwritten, but I thought the point of this thread was to get rid of a virus, not how to secure erase a hard drive.
EDIT:
Found this command line while googling for 'dd erase gpt':
Code:
sudo dd if=/dev/zero of=/dev/sdXXX bs=4096 count=35 seek=$(($(blockdev --getsz /dev/sdXXX)*512/4096 - 35))
As I understand it, this line should zero out the backup GPT table at the end of the drive. Be sure to replace
sdXXX with the actual drive.
Several things with this:
1. BSD and other OSes do not have
blockdev. There are other ways to get this information, but on the BSDsit usually involves looking at
dmesg or
camcontrol identify and writing down the LBA count yourself. On Solaris this is an even bigger PITA. On OS X (despite being BSD-based) I have absolutely no idea but I wouldn't be surprised if it involved interactive commands.
I should note that when I say "LBA count" I am referring specifically to LBA48, not the older LBA28 count.
Wikipedia has details on this if you're curious. (I'll be happy once all mention of CHS addressing finally dies)
2. LBA counts -- per ATA as well as SCSI (to my knowledge) -- are always advertised in counts of 512. The reason for this has to do with logical vs. hardware sector size (yes they are separate/different). Even "gigantic" drives (4TB, etc.) will show a tremendously large LBA count (vs. a smaller one due to 4K sectors). At present, and has been such for several years, all 4K sector disks (that refers to "Advanced Format" drives, as well as SSDs) advertise their logical sector size as 512 -- and they have to, for legacy compatibility. I have yet to see anywhere in the market a drive which advertises a logical sector size of 4096. Here's an example of an Advanced Format drive:
Code:
ada1: <WDC WD3003FZEX-00Z4SA0 01.01A01> ACS-2 ATA SATA 3.x device
ada1: Serial Number WD-WCC130512011
ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada1: Command Queueing enabled
ada1: 2861588MB (5860533168 512 byte sectors: 16H 63S/T 16383C)
...
device model WDC WD3003FZEX-00Z4SA0
firmware revision 01.01A01
serial number WD-WCC130512011
...
sector size logical 512, physical 4096, offset 0
LBA supported 268435455 sectors
LBA48 supported 5860533168 sectors
3. Somewhat of an expansion of #2: I find it cute that someone tried to work in
bs=4096 because they started thinking about "4K sector drives" when in fact that really has no bearing on the situation right now. They should've just left it off and used 512, because that's really all that matters. They added "fancy math" (multiplication/division) to make something more complex than it needed to be. (Reminder:
blockdev --getsz returns LBA48 count (or LBA28 count if no LBA48 support is available), and that's always 512 byte sectors, not 4096).
4. That command will erase 4096*35=143360 bytes of data presumably at the end of the drive (backup GPT), which is overkill. The backup GPT is only 35 LBAs long; that's 35*512=17920 bytes.
The hullabaloo you'll find in Linux communities about sector size (4096 vs. 512) and LBA counts and other whatnots all have to do with partition alignment, but in several articles (in fact, almost all articles I've read (I skimmed a lot of them today)) this is never mentioned. For performance reasons, drive partitions with drives that use 4096 physical sector sizes must be aligned on a 4K boundary.
It's more complex with SSDs, because SSDs actually care more about NAND page alignment -- more specifically NAND erase block size -- than they do "sector size" (per se). The default norm at this point is to align things at 1MByte (1048576 byte) boundaries, because different SSD manufacturers use different NAND page sizes and different erase block sizes. The biggest problem is that none of the manufacturers actually disclose what their NAND page size nor erase block sizes are, so everyone is just flailing around trying to make the best out of the situation. It's highly suspected that newer SSDs are using larger erase block sizes (2MBytes or 4MBytes), but again, nobody knows because the manufacturers don't disclose the info.
Anyway that's enough from me for now, as somehow I managed to injure my back while typing this... LOL. Getting old sucks. Plus this is way, way off topic.
TL;DR -- If you get a virus, zero the entire drive (from LBA 0 to the last LBA). Don't just "format it". Zero it, reinstall Windows from scratch, and do bare metal recovery backups regularly. And stop using Internet Explorer for god's sake -- still the #1 vector for malware and viruses that I know of. (I speak from experience, as my mother, who is quite technically adept, still managed to get malware and mysterious shit on her PC despite using anti-virus/anti-malware software from Avast. It all came via Internet Explorer. Switched her to Chrome and that's been the end of it.)