7

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.

Parthian Shot
  • 281
  • 2
  • 8
  • 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... – Parthian Shot Mar 03 '16 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. – Parthian Shot Mar 03 '16 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. – Parthian Shot Mar 03 '16 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. – Parthian Shot Mar 03 '16 at 23:34
  • A symbol table would make sense, given the stripes at regular intervals... – Parthian Shot Mar 03 '16 at 23:35
  • So, not a symbol table, probably. But definitely formatted data, not code. It's 52-byte-aligned... sort of. It looks like there are "chunks" filled with a fixed integer number of 52-byte records, and each chunk has delimiters. – Parthian Shot Mar 04 '16 at 00:26
  • Okay, turns out it's not a fixed number of records, it just visually appeared that way. – Parthian Shot Mar 04 '16 at 00:48
  • So, I found the delimiters, and found a similar-looking set of records in the /bin/bash executable's .text section. Based on the fact that it doesn't seem to contain any actual meaningful opcodes in and of itself, and it's broken into nearly fixed-length records with delimiters, my money's on a trampoline. – Parthian Shot Mar 04 '16 at 01:30
  • Actually, scratch that. At this point I think it's either a jump table or a set of interrupt handlers. Either way, putting off the rest of the analysis until tomorrow... – Parthian Shot Mar 04 '16 at 03:21
  • Check out https://sites.google.com/site/xxcantorxdustxx/ there is also a talk that goes with it but I don't have the link handy... – mrexodia Dec 11 '16 at 09:37

1 Answers1

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.

Leo B.
  • 233
  • 1
  • 8