1

I have a little endian 32-bit ARM binary, compiled for a CPU that's running embedded Linux. I want to figure out what a specific byte in the binary means. An example hex view of the first few bytes of my binary is:

 03 00 00 00 82 2C 00 00  50 01 00 00 C0 01 00 00
 1A 00 00 00 2B 00 00 00  80 00 00 00 00 00 00 00
 24 26 00 00 08 00 00 00  04 10 00 00 30 29 00 00
 FC FF 07 00 00 00 00 00  F7 27 13 00 FF 03 00 00
 01 00 00 00 74 2C 00 00  00 00 00 00 00 00 00 00

I am interested in finding the purpose of the byte with value 0x13 in line 4. The particular number seems to increase as the size of the binary increases, but I can't seem to find the exact correlation between file size and this number. I have tried the usual suspects (number of blocks, file size in e.g. KB etc.) but nothing gives an exact match with the number I observe in that byte offset.

Disassembling the binary in IDA renders the following assembly code for that portion:

ROM:00000000                 AREA ROM, CODE, READWRITE, ALIGN=0
ROM:00000000                 CODE32
ROM:00000000                 DCD 3, 0x2C82, 0x150, 0x1C0, 0x1A, 0x2B, 0x80, 0
ROM:00000020                 DCD off_2624
ROM:00000024                 DCD 8, 0x1004, 0x2930, 0x7FFFC, 0
ROM:00000038                 DCD 0x1327F7, 0x3FF, 1, 0x2C74, 0, 0

where the number of interest appears in the last line as DCD 0x1327F7. That number doesn't appear anywhere else in the code, neither that address is referenced anywhere in the rest of the code. The neighboring bytes (here 0x27F7) change in a seemingly "random" way (it is likely possible that I just haven't figured out their purpose yet). Regardless I am only interested in the 0x13 field.

Is there a convention for the contents of the first bytes of an ARM binary? Any ideas as to the purpose of that byte or if there actually exists a correlation to the file's size?

P.S. For differential analysis purposes I'm adding another file's initial bytes. Here the number I am interested in is 0x03 in line 4. The offset of interest is always the same. The first file was 11928 bytes whereas this one is 2850 bytes.

0300 0000 9608 0000 5001 0000 0701 0000
0a00 0000 1300 0000 8000 0000 0000 0000
6404 0000 0800 0000 0410 0000 9006 0000
fcff 0700 0000 0000 087d 0300 ff03 0000
0100 0000 8808 0000 0000 0000 0000 0000
Improve this question
3
  • "A binary" (or in this context, "an ARM binary") typically refers to an executable file. However, it seems as though you're in fact asking about a binary file (a non-text-based file that is not necessarily executable). Assuming that's the case, what program is consuming/modifying this binary file?
    – Jason Geffner
    Commented Aug 3, 2015 at 16:39
  • The program is compiled ladder logic that runs on an embedded ARM. I am not 100% sure whether this "binary" runs on the CPU as is or if it's first "unpacked" by another process on that CPU. I lean towards the option that the code is executable, as the rest of the assembly code from IDA contains the compiled binary for my source code.
    – koukouviou
    Commented Aug 3, 2015 at 16:44
  • 1
    If this was an executable running unter linux, it should be in ELF file format, or maybe in COFF, but both formats don't match your hex dump. So i'm almost sure this is either a binary for some other OS, or a file that's getting interpreted by something. Maybe the name of other files in your file system, or the name of the program used to open your file, could give a hint.
    – Guntram Blohm
    Commented Aug 3, 2015 at 17:12

1 Answer 1

Reset to default
1

As per the comments above, you would need to reverse engineer your ladder logic program to determine how it's parsing and updating this binary file.

Improve this answer
1
  • I already gave that a go but it's extremely tedious, I was hoping I would get away with a simpler solution as I already figured out the byte's correlation with the file's size. Thanks anw!
    – koukouviou
    Commented Aug 3, 2015 at 17:00

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.