I'm trying to view directly a partition with a damaged filesystem on it (NTFS) and so far the hex editors I tried do not do that. I tried GHex for example and it complained that /dev/sda is not a file. The partition is unmountable as NTFS however since it is damaged so I couldn't mount it first. Are there any hex editors out there that would allow me to view the contents directly and copy and paste stuff in there?

Don't know about 'good', to subjective a term, but top of my search engine list was this: http://lde.sourceforge.net/.

1 members found this post helpful.

well yes /dev/sda is not a file it is a mounted partition


so this is a damaged hard drive that you need to copy data off of ? right ?

and you want a everyday hex editor to be able to do that

what data recovery tools have you tried ?

Thanks barriehie. Lde seems very good for the task at hand. It doesn't support NTFS and it falls back on an nofs mode in unrecognisable file systems which is exactly what I wanted. My filesystem is unrecognisable as NTFS anyway so it fits it perfectly. It seems kinda basic though and its man page is 14 years old. It's probably unmaintained as well. It will probably do the thing I want but I would like some more suggestions.

Yeah 'good' is probably a bit vague. How about a hex/bit editor that can read drives without mounting them, and it has some sort of following/user base/maintainer that could help if help was needed? I hope lde will do the thing I intend to do but I'd like to have some more options.

Maybe have a look at wxhexeditor. You won't be able to claim staleness for this one ...

Haven't tried it, but might go find a broken disk to play on now I found it (I have a pile of them).

1 members found this post helpful.

It is a damaged NTFS file system more specifically. The partition boot sector was damaged so the $MFT metadata file cannot be located. As the $MFT file contains the list of the locations of all the files on the file system, without it or the partition boot sector that points to it I essentially have a puzzle box filled with blank pieces. The plan is to access the first few sectors of the NTFS filesystem that contain the partition boot sector (lets call it BPS) and see what kind of damage there is. Then, I will either make a new BPS by hand after I locate the $MFT with the hex editor, awk and some magic or I will just have to write some sort of half baked program to gather together every fragment of the $MFT I can find on the disk. The hex editor is crucial in all these operations. Sorry if I'm being tedious but I wouldn't want to assume that people on a linux forum have extensive knowledge of the NTFS filesystem by default.

I'm currently working on a clone of the original disk to make sure that I won't destroy some precious fragment by mistake. I tried alot of recovery programs, mostly crapware for Win that weren't much help. The ones that stood out were TestDisk and PhotoRec but they both have their limits. PhotoRec for example found a lot of photos but as you can imagine a great deal of them were cut in half due to fragmentation. Unfortunately, without the $MFT I can only hope for one piece files and they are a bit rare.

Maybe hex editor is the wrong term for what I'm asking for? Bit editor seems more proper but I could be wrong on this. I'm no expert on data recovery, I'm still learning.

Nope no staleness there. Can it be true that linux doesn't have a good hex editor as the author says? Unbelievable. Well it certainly seems nice. I will have a proper look at it tomorrow, thanks.

I had a look at LDE years ago.
Seems people tend to write what they need at the time, then lose interest in maintaining it. No fun in that for a hacker mentality.

I think the term you want is "sector editor" rather than "hex editor".
Linux has perfectly good hex editors e.g. okular in a GUI, bpe at the command line

The issue that the writer of wxhexeditor highlights is the lack of large file size support. What is not understood is that within Linux it is easy to extract the region of interest into a small file and work on that, then put that segment back.
The dd command is your friend.

There is no need to work directly with large files.

Hmmm - dd is ok for meandering around a disk, but doesn't lend itself to use as an editor.

I tried running wxHexEditor on an Ubuntu 10.4 live cd but it gave me errors. I then tried to compile it from source but I couldn't find a configure file. I tried the same thing on a netbook running a distro based on ubuntu 9.04 and I had the same results. Did anybody else try to run it?

It's a shame really. At least it's open source so maybe someone someday will take over.

Yes maybe sector editor is the correct term. Also disk editor but search results point mainly to DOS/win progs which aren't really what I'm looking for anymore. There were a couple of linux ones too though. By the way, how do you use okular as a hex editor? Do you mean putting some binary output through okular for viewing? That would work as a hex "viewer" I guess but calling it an editor would be a bit of a stretch.

The writer also wants beautiful GUI's (can't argue with personal preference) and doesn't really care about CLI editors. If he went to the trouble of writing a new one altogether you can safely say that linux didn't have any good editors to use or even fork and then use. I worship dd and I don't mind a bare bones approach like what you suggest in principle but in this case it would just introduce unneeded steps in the process that in turn could lead to errors. Plus I'm busy as it is and I need the 'luxury' of a full-feature editor just to save time. You know how it is.

Sorry, I meant okteta, not okular.

The point I was trying to make is that it is more efficient just to work on the small portion of the disk that needs to fixed. This portion can be isolated using dd, edited with okteta, and then written back using dd.
It is a technique that I have used with success handling virtual disk images.

I don't doubt that with some experience this method is a breeze. But it's going to be more time for me at this point. It's all relative to how much time one can spend or has already spent on a particular way of doing something. I have been struggling with this recovery thing for a week now and I'm hoping it's not going to eat away time from the holidays. To illustrate what I mean better, lets imagine that I make a mistake when writing the segment back using dd. I will then have to fill the drive with zeros which will take some hours at least and then I will have to clone the original disk on top of it which takes approximately 14 hours. I can live with it but I hate waiting for dd to finish the cloning process.

I tried okteta and it seems really nice as well. It kept crashing when I ran it on the live cd for some reason. I will put some real testing to it tomorrow.

Katto, I'll keep digging.

Okay, after looking here I found this. It's in the debian repo's and I installed it and ran it on an unmounted USB flash drive and it looks like it might be *closer* to what you require.

HTH,