HDHacker Portable 1.4 Rev 2 has been released. HDHacker is a stand-alone micro-utility that saves, visualizes, and restores the MBR (from a physical drive), the BootSector (from a logical drive) or any specified sector from any disk (even removable disks). [PLEASE NOTE: This is an advanced hard drive tool for system administrators. Improper use can result in inaccessible hard drives.] This release updates the app to the current packaging format. It's packaged in PortableApps.com Format so it can easily integrate with the PortableApps.com Platform. HDHacker is freeware for personal and business use.
HDHacker is packaged for portable use with permission from Dimio.
Update automatically or install from the portable app store in the PortableApps.com Platform.
Features
HDHacker can be used, for example, to save and restore a particular boot manager (such as LILO, for example) before a new Windows setup (which, obviously, overwrites it). An MBR and BootSector backup can also be useful for simple precautionary purposes too, since sometimes viruses or other OS setup (like Linux) could overwrite and/or alter the MBR/Boot Sectors, making it impossible to start up previous OS and/or access datas stored on the disk. HDHacker can provide "insurance" against all these types of loss.
PortableApps.com Installer / PortableApps.com Format
HDHacker Portable is packaged in a PortableApps.com Installer so it will automatically detect an existing PortableApps.com installation when your drive is plugged in. It supports upgrades by installing right over an existing copy, preserving all settings. And it's in PortableApps.com Format, so it automatically works with the PortableApps.com Platform including the Menu and Backup Utility.
Download
HDHacker Portable is available for immediate download from the HDHacker Portable homepage. Get it today!
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
Comments
Sure, lets write files to the actual drive before testing it
Honestly, do you all get the concept of these standalone utilities needing to NOT write data to the hard drive before testing it?
Every single PortableApps package writes a few files to the %temp% directory on launch, which defeats the purpose of all your file system recovery software utilities.
This is just absurd. Noone should touch PortableApps recovery utilities and should always opt for the natively portable clients, which actually know better than to write to a potential problem area.
Boot Sectors
If you read, you'll note that this is an MBR and boot sector utility. It deals with areas of your drive completely independent of your TEMP directory. So, your rant is, at the very least, completely misplaced here.
You can easily self-contain your TEMP directory on your portable device by setting the environment variable and pointing it to your device before launching the PortableApps.com Platform. Then all apps you launch from the menu, whether PA.c Format or not, start using your portable TEMP directory. The platform will even have an option to do this automatically in the future.
One last point... If your drive is having issues to the point that writing to TEMP may cause issues, you should not be using ANY portable software to restore it. You should be using a live CD.
There are no guarantees
Any data on a drive is never guaranteed to be completely independent of other data, especially in this day and age of SSD's.. there's just no telling where a write to a hard drive will wind up.
Also, while I understand where you are coming from, there are no guarantees what the TEMP directory maps to. It could be a completely different drive (some people map it to HDD's to 'preserve' SSD life), a network share, or even a RAM drive. And of course it could be mapped to any given drive that is having issues.
To recommend that someone modify Environment Variables just to overcome one of the PortableApps platforms shortcomings is a bit silly - your typical average Joe user will have no clue what that's about or how to do it. In fact, I doubt many people know all the stuff that's written to the system drive to make these hacky NSIS packaged apps work, nor how much junk is left over when the portable launchers misbehave, don't clean up properly, or fail to take into account certain behaviors (like apps that relaunch themselves, etc). I routinely find leftovers there myself.
But anyway, the point I'm trying to make still stands - any drive recovery or manipulation software should really avoid ever putting data on the drive its working on in the first place. And I don't just mean HDHacker, I mean all those disk scanning, defragmentation and data recovery programs available on this site.
And honestly, this is widely accepted knowledge. I'm not spouting anything new here. You don't ever muddy the water you are testing just because it seems easier to stand with one dirty boot in the stream.
Misunderstanding HDHacker
HDHacker deals with the master boot record and boot sector. Those are independent of the data on a drive regardless of the underlying medium just by the way hard drive records are structured. HDHacker doesn't deal with the actual contents of the drive. So, no, writing to TEMP can't interfere with the way HDHacker functions. It seems like you just latched onto this news story to post a rant.
As I said above, if you're trying to recover a badly damaged computer, like a partition or drive that's dying, you probably should be using a live CD. It's the best way - really the only way - to ensure Windows or some other app on the host PC isn't messing with anything. If you don't want to muddy the waters, you should not be running the host OS.
As I also said above, we're incorporating TEMP redirects into the platform proper which handles TEMP portablization across all kinds of apps, whether or not they use a launcher (ours or anyone else's), and whatever they're written in. This will be handy for folks with troubleshooting kits working on PCs with issues less dependent on fixing with a live CD or in scenarios where it isn't possible.
NSIS works very well for our needs, far better than some experiments with other languages that are either closed source or have false positive issues or both. Plus it's easy to learn. And, with the PA.c Launcher, you don't even need to know it.
Linear is no longer linear
Any write to a physical device, including those done with HDHacker - which allows you to read or write to ANY sector on disk (yes, not just the MBR and Boot Secton), is a huge risk. Even if it WERE just limited to the MBR or Boot Sector (its not - read the text file!), there's still a risk at a device level.
I think this bears mentioning as people like to imagine everything on a drive to be neat and tidy in its different places. On mechanical drives, it was more or less the case that given sectors were written at given positions of the drive (ignoring alignment and certain tricks hard drive manufactures have used in the past). However, with SSD's data is written more or less like little bits of data thrown from a spritzer bottle - data is purposefully spread all over the drive (to increase lifespan).
So with SSD's, there is no real notion of linear data, or sectors occupying specific physical locations on a drive; a first sector may very well be broken up into 20 pieces spread across the entirety of the drive. Even partitions don't actually physically separate data at a given position on the drive. Its all about logical concepts that are translated into physical representations in hardware. But I only say this to illustrate that this concept of separation of TEMP folder from MBR data is just an illusion - the data could literally be right next to each other. A faulty write could disrupt one or the other..
But I digress.. certainly if there's faulty writes happening, the drive is borked and its not something any piece of software could change..
HDHacker would be okay if it didn't actually allow you to write to specified sectors of the disk, but I'll concede that if someone's working at that level then they had better know what the hell is going on in the background and what sector maps to what. And they also should probably not use PortableApps to wrap something available already in a portable zip file. There's just too many variables as it is.
Also, on your point of Live CD's - yes, if there's major problems with a drive or O/S, this would be the way to go. But most of the software I mention should work fine. Data 'recovery' software is more often about accidentally-deleted-files than some O/S mishap. And in fact its most important in that scenario to never EVER write data to the drive when attempting to recover files as each new file created is a potential deleted file overwritten.
Anyway.. this has gone on pretty long. I need coffee