Monday, January 16, 2012

EXIF/meta-data Linkage

Been sitting on these for a while (sigh).

Why do we care about meta-data (examining and/or purging)?

Well for starters “dere’s gold in dem dere hills!”

“Did you map all of the USB removable storage devices that had been connected to the system?  You don't need to have the management software installed to copy images and videos (hint, hint) off of a phone...just connect it via a USB cable and copy the images (which will likely have some very useful EXIF data available).”

In addition, there are a number of freeware (and $-$$$$) image viewers/tools that also include meta-data handling embedded in them. This post is focused on meta-data specific tools. I’ll post linkage on some of the other applications that are more in this later class soon.

Cheers.

--Claus V.

Posted by Claus at 0 comments
Labels: , , , ,

Active Directory Linkfest

I’m working hard at getting up to speed on the whole Microsoft Active Directory thing.

Until lately, I’ve not had either the need nor the opportunity to get heavily involved in supporting customers in a full-blow AD environment. Sure, there are some basic “foundational" things I’ve been able to pick up and use, but now we are moving forward into a brave new world and I gotta kick up my expertise a bit. I’ve already purchased and am working through this excellent Active Directory: Designing, Deploying, and Running Active Directory, Fourth Edition (Amazon.com link) book to get the ball rolling.

So expect a few more AD-related posts around here…at least on the front end they will be more resource linking related as I fill out my virtual bookshelf.

The 4sysops - For Windows Administrators website hosted by Michael Pietroforte is my go-to source for the best of tools and tips related to Windows system administration. It is full of great information and resources related to Active Directory items!

Expect more AD-related resource posts moving forward.

If you have any great and free AD-related tools, tips and resources please share in the comments!

Cheers!

--Claus V.

Posted by Claus at 0 comments
Labels: , , , , ,

Sunday, January 15, 2012

Baseline of Windows Files in Incident Handling?

I’ve been sitting on this one for a month or so hoping I could uncover a better solution. Unfortunately I’ve not been as successful as I would like so here it is.

Chris Pogue at SpiderLab’s Anterior blog posted Manipulating Windows File Protection and Indicators of Compromise which contained lots of goodies.

Basically it was a carry on from a previous post on Windows File Protection and malware hunting. In this post Chris shows how WFP can be “subverted” by malware and what clues are available to the incident responder for searching based on his and Harlan Carvey’s prior work.

In Chris’s post he uses an unpublished tool to temporarily disable WFP, change “code” inside a protected system file, then allow WFP to restart, reboots the system and sees if WPF leaves the modded file alone. It did. Chris then documents the changes observed.

I’m focusing on this part here:

let's take a MD5 checksum of dllhost.exe for validation that we have successfully modified our target file.

c:\Windows\System32>md5deep dllhost.exe

a63dc5c2ea944e6657203e0c8edeaf61  c:\Windows\System32\dllhost.exe

OK, next, I ran a strings against the target file so make sure there was not the same string content that I decided to use.  In this case, a series of upper case letter "A"s.

C:\test>strings c:\WINDOWS\system32\dllhost.exe | grep AAAAAAAA

Now, I am going to simply append 20 upper case "A"s to the end of the target file.

C:\test>echo AAAAAAAAAAAAAAAAAAAA >> c:\WINDOWS\system32\dllhost.exe

Let's run strings against the target file to see if the modification took.

C:\test>strings c:\WINDOWS\system32\dllhost.exe | grep AAAAA

AAAAAAAAAAAAAAAAAAAA  <-- This is the results of the grep search.

Now let's check the MD5 checksum of the target file to see if it changed...as you can see by comparing it to the value from our initial MD5, it didn.

C:\test>md5deep c:\WINDOWS\system32\dllhost.exe

6fb2c878750a84946efacfc50c8e1f59  c:\WINDOWS\system32\dllhost.exe

(Note: I think Chris has a typo in the part I have bolded above. I suspect he meant to type “it did” as clearly the MD5 is now changed from the original file MD5 hash.)

While Chris focuses on the MFT and system logs to flag the event for additional attention, I was focusing on the (relatively easier to spot?) MD5 change itself. If you can spot that the change occurred, then maybe you can drill faster into the corresponding logs/records for event clues on the change itself.

Indeed, Rmdarcher commented in the post that one could “…run the System File Checker (sfc.exe)” to look for modifications.  Chris agreed and responded,

“I think the real challenge is not in the identification of the modification, but in the detection of the single file that was modified.

“As I pointed out in the post, and what I still think is the real meat of the issue, is how to tell? How can you tell if a legitimate Windows process has become weaponized. Again, think the best way to even get the point where you can employ something like SFC, is through live analysis, and correlation of data points.”

So what go-to options does a sysadmin have to see if a system’s protected files have been compromised by malware short of combing through the MFT and system logs?

Here are the ones I have come up with so far.

As Rmdarcher commented there is the Windows System File Checker.

That was a good starting point and eventually led me next to the File Checksum Integrity Verifier from Microsoft.

Warning The Microsoft File Checksum Integrity Verifier (FCIV) utility is an unsupported command-line utility that computes MD5 or SHA1 cryptographic hashes for files. Microsoft does not provide support for this utility. Use this utility at your own risk. Microsoft Product Support Services (PSS) cannot answer questions about the File Checksum Integrity Verifier utility.

The File Checksum Integrity Verifier (FCIV) utility can generate MD5 or SHA-1 hash values for files to compare the values against a known good value. FCIV can compare hash values to make sure that the files have not been changed.

With the FCIV utility, you can also compute hashes of all your critical files and save the values in an XML file database. If you suspect that your computer may have been compromised, and important files have been changed, you can run a verification of the file system files against the XML database to determine which files have been modified.
The FCIV utility runs on Microsoft Windows 2000, Windows XP, and Windows Server 2003.

In this case you would need to generate a “baseline” on a known/good system like the one you are comparing against. I imagine you would need to be at the same patch-level as your target system otherwise you run the risk of getting lots of noise to sort through.

In that last link above "Kirill" comments a tip that leads to another tool, FCIV for PowerShell.

http://www.sysadmins.lv/content/scripts/PSFCIV_1.0.ps1

The author, Vadims Podāns, maintains an English blog here: PowerShell Crypto Guy's weblog

Unfortunately, it doesn’t appear any of the FCIV for Powershell related posts are in English. You can hop over to the Russian pages and do some translations to get the meat of Vadims’s work here: FCIV (Russian original pages) or trust Google Translate here Google Translate versions of PowerShellFCIV tagged posts.

The tool I would probably reach for first is OSForensics by PassMark Software. This is a very strong tool in its own right, but the component we are focusing here on is the “Verify / Create Hash”.

From the OSForensics - Download Hash Sets page:

OSForensics allows you to use Hash Sets to quickly identify known safe files (such as operating system and program files) or known suspected files (such as viruses, trojans, hacker scripts) to reduce the need for further time-consuming analysis. You can download some sample hash sets below. They are individually zipped.

  • Office 2007 Enterprise (Vista) hash set (1,313 KB)
  • Office 2007 Enterprise (Win7) hash set (1,978 KB)
  • Common Keyloggers hash set (124 KB)
  • Win7 Ultimate (32-bit) hash set (18,825 KB)
  • Win7 Enterprise (x64) hash set (11,670 KB)
  • Vista Business (32-bit) hash set (8,475 KB)
  • Vista Business (x64) hash set (8,069 KB)
  • XP Professional SP3 (32-bit) hash set (1,889 KB)
  • XP Professional SP2 (x64) hash set (1,456 KB)

This is a nice “baked-in” feature for looking for suspect files. And again, I’m not sure how much “noise” would need to be sifted through based on OS patching updates to the system files.

Another nice feature of OSForenics hashing support is the ability to Import NSRL hash sets from NIST.

There are a lot of great resources on the web related to use of the NSRL hash sets and similar collections.

md5deep and hashdeep (now at version 4.0.0) also provides a mechanism to “…to compute, match, and audit hashsets. With traditional matching, programs report if an input file matched one in a set of knows or if the input file did not match. It's hard to get a complete sense of the state of the input files compared to the set of knowns. It's possible to have matched files, missing files, files that have moved in the set, and to find new files not in the set. Hashdeep can report all of these conditions. It can even spot hash collisions, when an input file matches a known file in one hash algorithm but not in others. The results are displayed in an audit report.”

More on md5deep/hashdeep Audit Mode.

I see that George M. Garner Jr.’s Forensic Acquisition Utilities set includes the following tool that may be of use:

FMData.exe: An original utility to collect files system metadata, to produce and verify security catalogs (cryptographic hash sets) using one or more cryptographic hash algorithms and to verify system binaries using the system file checker (SFC) API.

Finally, there is the application “ICE ECC” from ice-graphics. This is probably an “off-label” application and I’m not sure how well it would work on a C:\Windows\System like directory. Again, you would need to first “baseline” a known/pure system and then you could compare a suspect system against that baseline to look for clues.

If anyone else knows of any ways to either baseline and/or cross-check the hashes on protected Windows System files to ensure their integrity hasn’t been subverted/compromised by an injected malware attack like Chris and Harlan originally discuss, please drop a line in the comments regarding the tool and/or technique.

Much appreciated.

--Claus V.

Posted by Claus at 2 comments
Labels: , , , ,

Bad Habit

Note to self…you so gotta get this one down this new year.

Two spaces after a period: Why you should never, ever do it - Slate Magazine

“Most ordinary people would know the one-space rule, too, if it weren't for a quirk of history. In the middle of the last century, a now-outmoded technology—the manual typewriter—invaded the American workplace. To accommodate that machine's shortcomings, everyone began to type wrong. And even though we no longer use typewriters, we all still type like we do.”

That’s my excuse.

Of all the classes I took in high school, I credit my elective typewriting class for making the greatest contribution to my successes in college and the later transition into a technology career.

With no fear of typing, I was able to sit down at any keyboard with confidence. While no speed-demon at the time, I could touch-type at will and pound out anything needed. I could quickly and confidently organize my thoughts and communicate them. All because of those hours in front of that blue IBM Selectric III typewriter. I never lost that skill though the mechanical feedback isn’t the same anymore and I have to resort to running ClicKey when I really want my fingers to fly across the keys.

Adding that darned double spacing after each sentence was drilled into me in those classes and it is just maddening to abandon.

Here’s hoping for tighter copy this year.

Claus V.

Posted by Claus at 1 comments
Labels:

Sunday, January 08, 2012

Wipies -- Addendum

You may recall that both GSD posts on secure wiping -- Free Wipies and Wipies - Part II (Full Coverage Cleaning) -- were both inspired by a blog post by the TinyApps.Org blogger.

Last night I received a kind message from this dear friend pulling my attention back to the deeper issue raised in that post, and while this isn’t a completely unknown issue, it is one that can be easily overlooked by the best of sysadmins in our zeal to “secure wipe the darn thing” and get on with our other daily grinds.

The TinyApps how-to post ATA Secure Erase (SE) and hdparm shares an added benefit for those who dare to tread that hard-drive wiping technique through the “enhanced secure erase” option.

(Very) Basically the issue comes down to this: hard drives may have bad sectors that have been found and so marked as well as additional “host protected area (HPA)s” both of which can be skipped by many “block-erase” wiping tools and utilities. The end result is the possibility of recoverable data left behind in these areas if a standard block-erase method is used.

So even though you are diligently laying down your randomized data and/or zeros to all the (accessible) sectors of the drive, the drive itself may be actually hiding physical sectors from your software that will not get overwritten no matter how hard you try.

As TinyApps linked for me in the communication, even the almighty Darik's Boot And Nuke clearly says in its FAQ that it must be used with knowledge to address some of these issues:

Does DBAN wipe remapped sectors? - Darik's Boot And Nuke

Does DBAN wipe remapped sectors?

Use the ATA-6 wipe method if you want to wipe remapped sectors. Most methods do not wipe remapped sectors.

Does DBAN wipe the Host Protected Area ("HPA")? - Darik's Boot And Nuke

Does DBAN wipe the Host Protected Area ("HPA")?

No.

Most vendors that are using the HPA have a toggle for it in the BIOS setup program. Future releases of DBAN may override or dishonor the HPA.

Why not now and why not by default?

Some vendors are using the HPA instead of providing rescue media.

Wiping the HPA would surprise and strand people that expect the HPA to have rescue materials, and it often results in OEM technical support marking and abandoning people that do it. The HPA is a low risk because it is not accessible during normal operations.

DBAN defaults are chosen to best protect people with a minimal understanding of this kind of problem. This point is still open for discussion in the help forum and in the appropriate bug ticket.

That’s not to say this information makes DBAN (or any of the others like it) a bad or faulty tool, just one with some limitations (like most all other block-erase wipe tools) that must be fully understood before deciding if its methods are sufficient for the use at hand.

For example, there are forensic drive access/capture tools that can detect these areas and ensure the investigator is able to respond to them.  That’s great news for the good guys and a warning that bad-guys can also take advantage of this as well: HPA/DCO Detection - WiebeTech Forensic Docks

Here (again) are links to two posts about the HPA/remapped sector issue with drive wiping well worth the read:

I suppose one good place to start is pre-inspecting your drive before you get wiping to better understand what you are dealing with.

There are a few Windows-based tools that I am aware of that can let you look at either/both HPA area(s) as well as DCO info (if they exist).  In most cases, these do require specialized booting of the system either directly with a true DOS disk or a Linux tool to access the drive correctly.

So, that brings us back to using a combo of tools and methods to wipe both check for the presence of  HPA/DCO and address/remove them first before using a block-erase wipe tool or to learn some new techniques for an “all-in-one” wipe method to get it all.

For “modern” hard disk drives that support this feature the “enhanced secure erase” method may be the only option short of extreme physical destruction (with prejudice and malice aforethought) of the drive to ensure all data is irrevocably cleared from the drive.

TinyApps “how-to” post is a great starting point at using a Linux Live CD to accomplish the process and what is happening :

It is my understanding that Windows port of hdparm may work as well that is found in Cygwin. I’ve seen some forum posts discuss that some versions (the later ones) are better than earlier ones.

Christian Franke has also provided a native Win32 tool version if you just need it without Cygwin.

So to sum up from my perspective,

  1. If you want to keep the OEM HPA area intact (maybe you have a Dell system with diagnostics loaded there) and plan to recycle the drive/system in your organization, then a simple whole-disk block-erase of the drive may be sufficient.  Updating the DCO information probably isn’t necessary and may help -- in fact -- preserve the previously found “bad sectors” info if it is present.
  2. If you plan on giving the drive/system away then you should strongly consider attempting the “enhanced secure erase” method first to see if your drive supports it. If not, then you may have to settle for either a whole-disk block-erase wipe and hope for the best (that there is no sensitive data in any HPA/DCO areas (if present) or use one of many reliable, complete,  irrevocable, physically destructive methods.

Hopefully I have covered this sufficiently for you to Google on from here.

If not, as always your comments are welcome and appreciated.

And if anyone knows of any additional Windows/DOS/*Nix tools that can handle “enhanced secure erase” wiping of a modern drive, please leave a tip in the comments.

Cheers!

--Claus V.

Posted by Claus at 1 comments
Labels: , , , , , ,

Sunday, January 01, 2012

Make a dual-boot WinPE CD

I’ve been in the workshop for the past several days hammering out a new WinPE product for our technical field-support team.

You may recall from the GSD post WinPE Building and PGP Support Links Updated that I have previously built a highly-customized PGP WDE injected WinPE boot CD to allow our team to manually off-line boot, then authenticate into a PGP v9.x encrypted hard-drive.

Now we are rolling out systems encrypting with PGP Desktop 10.x.  Unfortunately the v10 isn’t backwards-compatible in supporting the v9 encrypted systems.

So I cleared off the workbench and using the techniques I have previously outlined here, built a new customized WinPE boot disk that supports PGP-WDE 10.x.

Only there was one problem; we currently now have a mixed PGP-WDE environment where some systems are running PGP Desktop v9.x and others are running v10.x.

I started to plan just having the techs carry both WinPE boot disks with them.  But that seemed silly.  The WIM files were both very small.  Too bad I couldn’t include both BOOT.WIM files on the same CD as the rest of the CD structure was identical.

Or could I…..?

I knew a suggestion Brett had made earlier that with some BCD file editing on a customized WinPE booting USB stick, that I could multi-boot different WinPE BOOT.WIM.  We outlined that process in this GSD WinPE Multi-boot a Bootable USB Storage device post. I can tell you it works like a charm.

But surely that doesn’t work for WinPE CDs. That’s crazy talk. Right?

Nope. Works fine.

David over at the “ITC Guy’s Doodles” blog has it all laid out, simple as can be (with screen-shots):

David and I are assuming here you already have the WAIK installed and are long-past the steps regarding building a customized WinPE build or two. If not, check out these GSD posts first for some background if needed:

Once you’ve done that and have your primary WinPE folder structure set as well as your custom BOOT.WIM files ready you basically do this:

  1. Launch your WAIK Deployment Tools Command Prompt (in Windows 7 I chose to run it elevated as Administrator).
  2. Change directories to your WinPE building folder (in my case it was C:\winpe_x86 yours may differ adjust recipe accordingly for your WinPE baking altitude).
  3. Copy into the c:\winpe_x86\ISO\sources folder the BOOT.WIM files you want to include. Note they will need to be named different things. Your first/default booting wim can remain “boot.wim” to keep things easy, but the 2nd (and each additional one if so desired) should be named something more descriptive.
  4. Next you will need to edit the BCD file for the booting build which is located in C:\winpe_x86\ISO\boot location.
  5. Follow David’s steps to make a copy of the default boot entry item to a new second one with a different boot guid. Then you need to “fix” some of the copied sub-items to associate with the new guid value.
  6. Finally, you can rename the default boot item description to something more meaningful.

Use oscdimg to build the ISO file and when you boot it, you should now see your different boot image options appear on the boot selection menu!

Sweet!

I’m  not aware of any limitations to the number of different bootable wim files you can have.  I suppose that’s mostly limited to the size of your CD/DVD media (if not USB-booting) as well as the size of the custom WIM files themselves.

So for me, I now have one physical bootable CD with two distinct WinPE boot choices…one for PGP v9 and one for PGP v10 support.  Locked and loaded now baby!

In theory, if you weren’t really comfortable with all this CLI work, you could use one of two GUI based tools to edit the \winpe_x86\ISO\boot\BCD file.

EasyBCD 2.1.2 - NeoSmart Technologies supports WinPE BCD files. There is also a EasyBCD 2.2 Beta Build that may have additional support. Check out the forum as well as this Multiboot WinPE CD - How to specify .WIM forum post for some tips.

In fact, somewhere between eating lunch, listening to a football game, and trying to pay attention to a holiday story Lavie was telling me while I was following David’s steps, my own “descriptions” work for the BCD file got mixed up a bit and I wasn’t getting the custom boot descriptions to appear as desired.

I was able to quickly and easily use the Visual BCD Editor - Windows 7/Vista to clean up the mess I made and get it all put right.  So if you knew what you were doing, you could do it all from the GUI with this tool rather than the CLI.

Anyway, thanks to Bret for his original tip and for David for the game-walkthrough for making a multi-boot WinPE CD.

Cheers.

Claus V.

Posted by Claus at 0 comments
Labels: , , , ,

Wipies - Part II (Full Coverage Cleaning)

I guess in the back of my subconscious, this and yesterday’s post regarding secure wiping could be related to the new year…you know…start things off with a clean-slate?

Yesterday’s post focused on free tools and utilities for secure-wiping (pretty-much) files and folders from a Windows system.

In a much older GSD post I had touched on total-drive secure wiping options.

Since a lot of time has slid by since that 2007 post, I figured I revisit it and see if it needed some updating.  So below you will find a list of tools that address secure wiping of an entire hard-drive.

In the previous post, I already covered by top-two tools for secure-wiping a HDD:

When it comes to secure drive (whole-disk) wiping, I’ve still tended to rely on two tools in particular for their ease-of-use and convenience.

The first is Microsoft Windows DISKPART command “Clean all” which “specifies that each and every sector on the disk is zeroed, which completely deletes all data contained on the disk.”

The pro is that the command is very simple to remember and use, and when coupled with a WinPE disk, is dead-simple to effectively wipe out most all drives I encounter.

The second one I love is the CLI tool “wipe.exe” as found in the Forensic Acquisition Utilities set by George M. Garner.

The pro about this one is that it actually includes a progress indicator so you have some degree of feedback on how far you’ve wiped.

I always verify my zero-out wipes when done. For that I prefer to use the sector-viewer tool HxD to scan through the post-wiped drive to ensure it all come up clean; Frhed - Free hex editor is another nice alternative.

I keep a custom WinPE 3.0 USB stick always handy to off-line boot a target system. By nature, DISKPART and it’s “Clean all” power is baked in.  I’ve also loaded it with the forensic Acquisition Utilities tool set so those are also at hand for a quick “wipe \\.\PhysicalDrive0 -p 1 -w 00” command if I prefer the progress meter.

However, there are a number of additional tools, some more “GUI” than others that bring more to the party in terms of wipe-patterns and passes…if that’s your thing.

So here are the rest I’ve found. Use may be licensed for personal only or may also allow for organizational use. So read the fine print carefully to stay honest.

Darik's Boot And Nuke | Hard Drive Disk Wipe and Data Clearing - (aka DBAN) allows for creation of a boot floppy or boot CD.  It supports SCSI, IDE, PATA, and SATA disks and should be able to wipe just about any file-system from a drive.  You can use one of five preset wipe formats or set custom wipe patterns. If you prefer you can try the method to Create a DBAN USB Flash Drive from Windows over at USB Pen Drive Linux. Other related links (with more screenshots) are Create a Bootable DBAN USB Pen Drive at TrishTech and How to make a bootable dban USB thumbdrive to wipe hard drives at Lee.org.  I’ve had mixed success with making a USB version of DBAN (no issues with the CD version), generally the problem comes like others with the “autonuke” option causing a hang. Some forums suggest disabling “media card” drives in the BIOS or like things. Also, you need to be sure to pull the USB stick in the first 10 seconds of the DBAN loading done otherwise you will likely wipe your USB stick as well if left in.

PC Inspector - Emaxx - Basically you download the app and use it to create a boot disk. Then boot your target system with the boot-disk and type “emaxx -US” to get started.  It isn’t elegant but it can do the job.

Terabyte Unlimited - CopyWipe - This tool can be used to boot a system and perform a secure wipe (and it can also do disk-imaging as well). Download the zip file and unpack.  You can then run the makedisk.exe file to create a boot floppy or boot CD ISO file.  Burn it to disk and you are good to go.  This application provides support for accessing the connected drive via (through) the BIOS, via the BIOS (directly), via USB2 connections,  and for IEEE1394 devices.  You then have an amazing nine (9) wipe options to pick from.  From a quick 1-pass wipe, up to a 35-pass wipe.  Also included is a hardware-based wipe method for drives that support this built-in drive-wipe feature.

Erase hard drive by Active@ KillDisk - This tool comes in both a “limited” free version as well as a “professional” version. The biggest limitation to me in the free version is that it only supports a one-pass zero out of the drive.  That’s enough for me!  In addition, the free version doesn’t appear to easily allow use as a off-line boot/wipe solution. Rather you would have to install the software on your main system, then attach the target drive to be wiped via USB or a free PATA/SATA connection and wipe accordingly. Not a big deal for advanced users, but might be a bit scary to less sophisticated users who could fear accidently wiping their primary system disk.  Fear not. If you carefully read page 10 of the included PDF manual file, there is a link to a zip file that contains a pre-built ISO boot image for free users.

If you are an advanced user and know how to build your own Windows/WinPE boot media disks, you might want to take a look at the Center for Magnetic Recording Research (CMRR)'s Secure Erase (aka HDDErase). You will have to create a boot-disk yourself then add the program file to it, or else download the Ultimate Boot CD ISO file and burn it to disk as it contains this utility (and tons of other clever things as well).  One thing going for Secure Erase is that it also supports "enhanced secure erase" modes on supported drives.  This works to effectively render the data on a drive inaccessible in seconds by changing the in-drive encryption key.  Even though the data is still on the drive, it cannot be read/accessed as the key that interprets that data from the drive has be irrevocably changed.

Ultimate Boot CD is an amazing bit of work. It doesn’t matter if you are an advanced sysadmin or a general PC user, this “all-in-one” project has a great collection of nine hard disk wiping tools. Scroll down the main page a bit to find the list.

SeaTools | Seagate - Poke around a while and you can find the SeaTools version for your supported drive. It contains a basic drive-sanitation tool.

These additional tools are “standalone” of sorts. They may or may not work within a WinPE boot environment. However, they all should work if you choose to attach your target HDD to be wiped to your main system via a USB-HDD adapter.

Roadkil's Disk Wipe Program - standalone tool to point, set, and wipe a drive. Works for USB/Flash drives as well.

DeviceEraser - standalone tool. Wipes both PATA/SATA drives as well as USB storage media.

DP Shredder 1.5 - Dirk Paehl tool to pick a drive, pick your passes, pick your pattern and wipe away.

WipeDisk - at Gaijin. This tool also will wipe physical and logical disks using any of 14 different wipe patterns.

HDDGURU: HDD Wipe Tool - Supports SATA,IDE, SCSI, USB, and Firewire interfaces. can also erase most Flash drive media.

Miray Software - HDShredder - The free version is very limited but can do the job. The free version contains both an ISO, IMG file to make a self-booting version or you can run directly in a Windows environment. The zip file contains a great PDF manual well worth reading if you decide to use this tool.

USB Flash Tools by Sarah Dean has the features to secure-wipe flash memory cards as well as USB flash drives.

Disk Wipe is a newer tool under GNU-GPL free for all. It has a great GUI, built-in sector viewer, and supports several different wipe patterns for addressing USB sticks, SD cards and other portable memory devices.  This was a new discovery I found while working on this post so I’ve not field-tested it yet. Check out both the Disk Wipe User Guide and Screenshots here.

Finally, TinyApps.org bloggist left a tip to a related post there on his blog: ATA Secure Erase (SE) and hdparm that bears some checking out.

For the pros, I’ve clearly left out all those leet Linux “live” CD/DVD distros that can off-line boot a system and then secure wipe the drive using any of many tools available under the *nix OS.  I figure if you already know about them, then you probably won’t be needing a recap of them here in this more “Windows-centric” tool post. However, if you have made it this far and have a specific distro/tool that you would like to share with us for secure wiping, please drop a line in the comments. For example, this Disk Wiping with dcfldd at the Anti-Forensics blog post uses a Debian build.

Cheers.

Claus V.

Posted by Claus at 0 comments
Labels: , ,
Subscribe to: Posts (Atom)