Strings weirdly split in binary

Question

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)

Answer 1

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.

Answer 2

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