Extracting the contents of an unknown file format

Question

I need some help and advice here. I'm self-learning how to reverse engineer a file content of an unknown format.

Here's the content of two files:

E5 44 2A F9 1C 72 96 B9 CA B2 40 33 DA 19 B9 56 C4 5F E2 46 C4 A2 37 1C 6B A7 FF 6A 14 96 E6 53 5E 63 0D A3 01 65 65 BC C6 55 1B 90 C9 56 16 6A C9 B8 3D 05 0F E5 13 62 F0 22 6D C6

DD 9F 44 2E C7 3D D2 31 48 3D 40 18 A8 D6 79 59 AE 31 6A E7 6C E2 92 6A A9 83 5A DC 64 56 34 1A 85 E7 2E 77 A9 34 32 29 61 4C A4 54 E1 76 6B C7 94 C0 FF 66 7F BC 1B A0 43 5C 83 87 19 1F AD AC 24 56 EE E4 87 9F BB 02 BD C1 35 ED F5

These two files are supposed to have the same information because I saved them with the same "visible" data from the user perspective (with just some seconds of difference between each saves).

The readable data should have something like this string "1111111111111100".

Aditional one:

02 D6 AB D8 4B 18 19 C2 88 AF A7 4E 7D DD C1 27 E4 FC A4 32 83 44 32 32 E9 2C 26 00 F9 56 8F F7 57 DC C0 E4 BB B2 65 55 CF E3 14 21 9F 07 51 A6 C0 1D 1D 74 3C 92 76 5C BB BE BE A1 3D E0 C5 4D BD 21 DC 11 83 C8 2A FC 9F 46 56 A3 34 98 2B BE 53 05 55 EE

I have the software that reads both files. I tried to change some values and I was able to get some descriptive errors, like "wrong version", "wrong format", "CRC error".

Is it compressed? Encrypted? Both?

Any advice?

Answer 1

I'll post this as an answer to techniques to reverse engineer an unknown file. Reverse engineering is not about just looking at binary data. It is a detective mystery. You need to gather clues and try to solve the mystery. Sometimes the clues are outside the binary data.

1. Look at the program generating the data. Look for places where you know the inputs and can collect the outputs.

2. What are the types of the inputs to the program? If they are strings, then you know there must be strings encoded.

3. Is there a program which consumes the file? If so, change it by one bit. Does the changed file load? If it does not, that indicates you have an error detection code on in the file. If not, change the single bit in different locations and observe what happens when you load the file. This will help identify field boundaries in the file format.

4. Is the data produced always the same size, or does it vary? If it varies, that indicates there's some variable length or optional data in the format. Try to construct input which should produce the same sized output in the file. Test it.

It looks like this is some sort of application for sports betting. This is actually the most useful piece of information for reverse engineering this file format. I found some description of escrutador.exe here and an image of the user interface here I believe. Sorry, I only speak english and I'm not up on sports and I'm not running a PC. It looks like there's some non-ascii characters in the images, so maybe the string types are unicode.

Also in that forum I see someone has captured some XML. This doesn't mean that the file format is in any way related to the XML, but it gives us an idea of what we expect to be encoded in the file.

I suggest you create a file which only has a single game between two teams with names 'red' and 'blue' and then look for both ascii and unicode encoded versions of those names in the file.

Then create the same file with order of the two teams reversed. You should see the same byte patterns move positions in the binary file.

Next, create a file which is identical to the first file, 'red' vs 'blue', but change 'blue' to 'green' for the team name. We should be able to find the bytes which correspond to 'red' and when we look for 'green' at the position of 'blue' we should find it.

If we aren't seeing the bytes in the positions we expect, that would be a strong indicator of compression on the data.

Does the name of the file end in .QUI?

Maybe this is quickbasic? I see some discussion on reading related data here.