1

Recently I have come across a few parts in a binary that looked odd to me, and I wanted to ask if this is something common compilers do, and if there is a way to undo it.

(The binary is from a raw flash dump)

A few examples:

In Binary File:
4C 65 76 FF 65 6C 3D 30 28 4F 46 46 FF 29 2C 31 28 45 52 52 29 FF 2C 32 28 43 4D 44 29 2C FD 33 1C 41 50 52 4F 43 29
Levÿel=0(OFFÿ),1(ERR)ÿ,2(CMD),ý3.APROC)

What it actually should look like:
Level=0(OFF),1(ERR),2(CMD),3(....PROC)
Bin:
45 D2 60 67 65 6E 63 79 DA 50 FF 6F 70 20 54 65 73 74 20 33 4F 4E
EÒ`gencyÚPÿop Test 3ON

Actual:
Emergency Loop Test ON
Bin:
53 FF 65 72 76 69 63 65 20 55 FF 6E 61 76 61 69 6C 61 62 E3 6C 65
Sÿervice Uÿnavailabãle

Actual:
Service Unavailable

Thanks in advance.

EDIT:

How do you know what it should look like ?

Because when the board is running, it is showing the exact same string in the GUI.

Can you diff your dump and the binary found on disk ?

Since this image is extracted from a flash, I'd say it actually is stored like that on it.

Can you update your question with hex bytes in order to aid investigation ?

Sure.

Are you aware of the compiler used ?

No, I do not know what compiler was used. It has to be something for embedded systems tho, since it was running on an mcu.

Could you provide some environment information ? (OS, arch, compiler...)

Embedded System Board running some sort of RENESAS Processor (exact model unknown)

UPDATE:

Every 8 bytes there is some sort of indicator. In my case mostly FF (ÿ) which indicates that the next 8 bytes are not encoded/compressed. If the byte is something like FD (ý) which in Binary(MSB) is 10111111, means the 2nd byte is encoded.

Example:

Levÿel=0(OFFÿ),1(ERR)ÿ,2(CMD),ý3.APROC)
678 12345678 12345678 12345678 12.345678

Meaning (APROC) isn't actually (APROC) but rather something more like (....PROC)

2 Answers 2

3

Shot in the dark: Maybe this text (or the whole binary image) is compressed. Think something like LZSS.

The fact that there is a mystery byte containing eight 1 bits, followed by eight literal and correct bytes, indicates that maybe the mystery bytes are actually flags that use each bit position to differentiate uncompressed data bytes from pointers to earlier data. Cases where the mystery byte is not FF are followed by text that is more corrupted than the other instances, leading credence to the idea that 0 bits mean pointer data.

1
  • I just took a look again at the binary image. It seems you might be right. FF is always followed by 8 correct Bytes. If the next one isn't a FF then some arent right. I'll try to find out, what encoding it is using.
    – Lukas S.
    Aug 25, 2019 at 21:43
1

A quick Google search revelead that ÿ in UTF8 is U+00FF. My guess would be that you're either looking at UTF8 bytes that are not being interpreted correctly or your dump has differences from executable file on disk that cause such corrupted characters. I'll ask a couple more questions:

  • How do you know what it should look like ?
  • Can you diff your dump and the binary found on disk ?
  • Can you update your question with hex bytes in order to aid investigation ?
  • Are you aware of the compiler used ?
  • Could you provide some environment information ? (OS, arch, compiler...)

As for undoing the corruption, can't you do it yourself by hand ? In case it is not feasible / you don't want the questions above become more relevant

1
  • I just added the answer to my original question
    – Lukas S.
    Aug 25, 2019 at 19:37

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.