Re: What is this question asking?

But looking at the output is confusing.

I guess you never worked with data files (whether text or binary) on a VAX or other DEC OS. Maybe this format was commonly used on other systems of the same era besides DEC, but that's where I learned it, and the first time I had to use a non-DEC OS, where I didn't have this sort of hex-dump output format (or I just couldn't find a tool to do it), I wrote my own (in C) -- which I'm still using almost daily, 20 years later.

It's a remarkably useful display technique, whether you're doing a quick visual diagnosis of an unfamiliar data file, or a fine-grained, detailed inspection of output from a program you're writing (or reverse-engineering).

I tend to prefer having the central hex columns be bytes by default, rather than quads (though an option to change the size of the hex "word" is vital, as well as switching to decimals or even floats on occasion). But just having that together with the ASCII content right along side it is so handy in so many ways...

Comment on Re: What is this question asking?

Replies are listed 'Best First'.
Re^2: What is this question asking? by Herkum (Parson) on Sep 28, 2007 at 13:56 UTC
Yeah, I have never really had the need to work with hexidecimal files so I am sitting there, scratching my head saying "WTF am I supposed to do!". I tend to prefer having the central hex columns be bytes by default, But just having that together with the ASCII content right along side it is so handy in so many ways... How does it help you to have both the hex columns AND the ASCII content? They are just different representations of the same information right? I got to be missing something.	[reply]
Re^3: What is this question asking? by TimToady (Parson) on Sep 28, 2007 at 14:57 UTC
Pragmatically, when you have a chunk of recognizable text in the right column, it strongly indicates that you should not attempt to interpret the corresponding hex bytes as binary data. And if you don't have text, then it very likely is binary data. In old COBOL programs much of the data is stored as strings (albeit in EBCDIC rather than ASCII), so what this usually tells you is whether you're looking at data or program, which is a very important distinction when you're trying to decipher a core dump. Even if your binary machine code happens to fall in the range of characters, it'll just be gibberish on the right, which tells you at a glance that it's probably not text.	[reply]
Re^2: What is this question asking? by mr_mischief (Monsignor) on Sep 28, 2007 at 20:19 UTC
We used them on the bitty boxes back in the days of PC-DOS and MS-DOS, too. Some were just viewers, but most had an edit mode and a few even handled inserts. I knew a few guys who could write small DOS executable programs using nothing more. In any case, they were very helpful for debugging, for fixing typos in the strings contained in compiled programs (which is scary using a text editor) and for reverse engineering data file formats or even code. A good hex editor is great even for hybrid code/data files in the few instances one runs across those. For example, lots of DOS system utilities had their own password schemes since the OS had no security. I had forgotten my password for Norton Utilities (version 6) a couple of times and had to reinstall the package. I got tired of that, so I did something about it. A hex editor was a big part of the toolkit I used to figure out how the package stored its password and how to change or disable said password. It was also my preferred tool to use when changing the password until I wrote a specialized program to do that. As for the specifics of the story, in case anyone's interested... It turned out the password was encrypted with a fairly basic cipher and stored inside all the individual executables it was meant to protect. I was too lazy to figure out the cipher itself as code, as I figured out there was a simple mapping of plaintext to ciphertext first. That and the offsets in the files to put the new data were all I needed to know. A friend had me try it on his NU v7, but the scheme used for that didn't seem to be quite so simple. I gave up before figuring it out, and stuck with v6 the rest of my DOS-using days since I always had this trick. I doubt my particular find and the change in tactic for the new version are related, as it's probably coincidence. Let this be a lesson, though, that security through obscurity does not work.	[reply]