These are graphic dumps from the source data. I use this extensively, with a hex reader I wrote myself -- it's a great way to quickly locate "data" (see the difference between
.data) and larger structures (which often contain repeating or similar data on the same offsets).
The top images show raw data dumped as grayscale information: each byte is treated as a pixel. Presumably, the author chose grayscale for convenience. I prefer a full range of contrasting colors, so long swathes of "same" and "similar" data can be discerned easier.
The blocks of solid color near the bottom (
.rsrc) are icons and other graphics. They appear horizontally stretched out because they are displayed as one-pixel-per-byte, and are actually 16-, 24-, or 32-bpp images.
(I don't believe the entire top is
.text! Executable code appears as random pixels, but the top 1/3rd in that image is less dense. It's probably the MZ and PE Executable Header; these contain lots of zeros. The more denser part in the bottom 1/3rd is part of
.text and most likely the Virtual Call table, which happens to contain the byte
0xFF a lot.)
In the bottom images, each byte is displayed in a monochrome binary format: each byte is shown as 8 consecutive pixels. By convention, these are displayed with the most significant bit first. There is no need to check for 'endianness', as that only comes into play when dealing with single values larger than a single byte.
Writing something like this yourself is not hard; probably most important is to make the graphics routines as fast as possible, in particular the monochrome bitmaps. This is also addressed by Conti et al., Visual Reverse Engineering of Binary and Data Files (http://www.rumint.org/gregconti/publications/2008_VizSEC_FileVisualization_v53_final.pdf):
When testing performance we found that the display could be updated in 0.03 seconds, leaving open the possibility of creating byteview visualizations at greater resolutions while still providing a responsive interface. [...] We were able to achieve this level of performance by avoiding C#’s GetPixel and SetPixel methods and directly accessing image memory [...]
Screenshots of my own tool, very similar to what is shown above:
.text section of CALC.EXE. The repeating structure on the bottom is the Virtual Call table.
A file containing RLE-encoded images. The RLE compression can be recognized by the horizontal stripes of "coherent" data (better visible when changing the width interactively).
GZ compressed data, in monochrome. This is as close to random static as possible.
A tiny embedded bitmap font found in another executable. The random bits between characters are the width in pixels - see the synchronically scrolling hex dump.
Some data is better visualized in other ways. This is an old-style VGA palette (6x6x6 RGB).