What is this question asking?

Herkum has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: What is this question asking? by ikegami (Patriarch) on Sep 28, 2007 at 02:26 UTC
They wanted you to write a program that reads a file and displays the content in the shown format. The general format quite common and useful for inspecting non-text files. Each row represents 16 bytes of the file. The 1st column is the offset within the file, in hex. The 2nd, 3rd, 4th and 5th column each represent 4 bytes of the file, in hex. The last column is the ASCII representation of the same 16 bytes. Nonprintable characters are shown as `.`. Update: A solution: 00000000: 75736520 73747269 63743B0D 0A757365 use strict;..use 00000010: 20776172 6E696E67 733B0D0A 0D0A6C6F warnings;....lo 00000020: 63616C20 242F203D 205C3136 3B0D0A62 cal $/ = \16;..b 00000030: 696E6D6F 64652853 5444494E 293B0D0A inmode(STDIN);.. 00000040: 0D0A6D79 20246F66 66736574 203D2030 ..my $offset = 0 00000050: 3B0D0A0D 0A776869 6C652028 3C535444 ;....while (<STD 00000060: 494E3E29 207B0D0A 2020206D 79202462 IN>) {.. my $b 00000070: 79746573 203D2024 5F3B0D0A 20202024 ytes = $_;.. $ 00000080: 62797465 73203D7E 20732F28 2E292F73 bytes =~ s/(.)/s 00000090: 7072696E 74662827 25303258 272C206F printf('%02X', o 000000A0: 72642824 3129292F 7365673B 0D0A2020 rd($1))/seg;.. 000000B0: 20246279 74657320 3D206A6F 696E2027 $bytes = join ' 000000C0: 20272C20 6D617020 2F2E7B31 2C387D2F ', map /.{1,8}/ 000000D0: 672C2024 62797465 733B0D0A 0D0A2020 g, $bytes;.... 000000E0: 206D7920 24636861 7273203D 20245F3B my $chars = $_; 000000F0: 0D0A2020 20246368 61727320 3D7E2073 .. $chars =~ s 00000100: 2F5B5E5B 3A707269 6E743A5D 5D2F2E2F /[^[:print:]]/./ 00000110: 673B0D0A 0D0A2020 20707269 6E746628 g;.... printf( 00000120: 22253038 583A2025 2D333573 2025735C "%08X: %-35s %s\ 00000130: 6E222C20 246F6666 7365742C 20246279 n", $offset, $by 00000140: 7465732C 20246368 61727329 3B0D0A0D tes, $chars);... 00000150: 0A202020 246F6666 73657420 2B3D2031 . $offset += 1 00000160: 363B0D0A 7D0D0A 6;..}.. [download]	[reply] [d/l] [select]
Re^2: What is this question asking? by Herkum (Parson) on Sep 28, 2007 at 13:58 UTC
Someone is too clever for their own good! :)	[reply]
Re: What is this question asking? by bruceb3 (Pilgrim) on Sep 28, 2007 at 03:07 UTC
What is entertaining about this interview question is that in the Perl 4 book, in the section titled "Real Perl Programs" on page 272, Larry gives some code that produces the required output. Larry calls it 'xdump - A mainframe-ish Hex Dump'. We've all read the Perl 4 book, right?	[reply]
Re: What is this question asking? by graff (Chancellor) on Sep 28, 2007 at 02:53 UTC
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...	[reply]
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]
Re: What is this question asking? by derby (Abbot) on Sep 28, 2007 at 02:31 UTC
That's the typical output of a *nix hexdump command. The first section is the offset, the second section is the characters converted to hex, the third section is the ascii representation of those characters if they're printable, a . if not. So 7F -> not printable, 45 -> E, 4C -> L, 46 -> F, etc. -derby	[reply]