what I'm looking for

I have a binary that, for various reasons, I'm pretty sure is executable machine code (although possibly for a VM language, although I doubt it's Java). I'm looking for a table of byte frequencies for byte values v. architecture.

I recognize that those values will vary by compiler, operating system ABI / API, application, and binary format, but for my purposes I'm assuming they vary most markedly by architecture, and:

  • I just need frequencies for the actual executable code- the .text section- not the entire binary.
  • the binary's targeting one of the most common end-user operating systems from 1985 - 2005 (so, old-style unices, Linux, VMS, DOS, Windows NT, MacOS, or OSX).
  • it was compiled with default flags on the most common compilers for those systems

If all that fails, I'd at least want a list of nop opcodes for all the most common architectures, since I think it's probably fair to assume most compilers use nops for padding, and runs of nops will help me figure out where a good entry point for a disassembler would be. Wait, there's this list on wikipedia. Thank you, wikipedia.

my use case

I have a snippet of a binary, which I'm pretty sure is executable object code (sans headers / section information. I think it's the .text section (or whatever you'd call that) in its original format).

I'm not sure that it's even from a binary, but when converted to a grayscale bitmap it has some clear patterns (stripes at regular intervals), and I've noticed that the bytes FF FF appear often enough, and beside other bytes in the form Fx, that I get the feeling I'm looking at high memory addresses. The shannon entropy is low enough I'm pretty sure it's not compressed or encrypted (around 7.76), but all 256 possible byte values are represented.

I can't actually give the hexdump itself for personal reasons.

  • Wait, after looking through other questions on here, I've realized that I should probably just use binwalk, which in fairness I hadn't found in previous searches on the larger internet. I feel kind of silly now, but I'll leave this question and answer it myself in a bit. Assuming binwalk actually helps. If it doesn't help, I guess I'll just... wait around... Commented Mar 3, 2016 at 20:39
  • Hm. binwalk -A isn't getting me anything, nor is binwalk -I. Literally- they're giving me no hits. Just as a sanity check, running binwalk -A against /bin/bash also got me no hits and no error codes, so I'm not sure what to think. Commented Mar 3, 2016 at 23:13
  • binwalk does give me entropy values consistently around 0.94 for all four kilobytes, while /bin/bash (for the code section) consistently fluctuates around 0.75. Not sure what to make of that. Commented Mar 3, 2016 at 23:32
  • What I do know is that binwalk -H reports that both /bin/bash and the binary I'm looking at appear to have a "high entropy" section that extends for nearly the same number of KB (~5 for bash and ~6 for the binary I'm using). According to readelf, that starts at the tail end of .gnu.hash and the rest (most of it) is in .dynsym. Commented Mar 3, 2016 at 23:34
  • A symbol table would make sense, given the stripes at regular intervals... Commented Mar 3, 2016 at 23:35

1 Answer 1


Assuming that this is indeed executable code with no data at all (please note that the .text section used to include things that nowadays go to .rodata), bytes FF and other Fx could also be parts of relative addresses for backward branches (loops). If you see obvious striping, it suggests that the min. instruction size is likely greater than 1 byte, so Intel is probably out. Can you tell if striping is regular or has subpatterns? If the former, it is probably a RISC architecture (all instructions are 4 bytes long) like SPARC or MIPS, otherwise it is some kind of instruction set similar to PDP-11 (all instructions are of even length, but it varies). After you've narrowed the field, you'll have to do a word-based analysis, because in most architectures with word-based instruction format the opcodes aren't byte-aligned.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.