2

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?

7
  • 1
    If you own the software that is able to decrypt it, why can't you just reverse it instead of guessing?
    – morsisko
    Dec 9 '20 at 19:35
  • Actually, I have lost a couple of days trying to explore it with Ghidra and x32dbg but without success. :(
    – hmiguel
    Dec 9 '20 at 19:40
  • 1
    Just two examples are not enough. Make samples and increase size each time by one character. If the output file only increases every e.g. 16 bytes for 16 bytes an block cipher encryption is likely. Signs few hundred samples you could to a statistical analysis if there are positions that have a higher chance for certain values.
    – Robert
    Dec 9 '20 at 20:01
  • Thats perfect reason to learn reverse engineering, as you see exploring is not enough. Unless you are very lucky you will have hard time to decode it only by guessing.
    – morsisko
    Dec 9 '20 at 20:13
  • There are numerous places where this data shows characteristics of checksums. 3 samples is too few to saw anything definitively. What is the software which reads the file formats?If you get CRC error, that tells us there's a checksum/CRC in there. For example Byte 6. The wrong version tells us there's a file version (type) byte in there. If the files are compressed / encrypted then having 10 samples or so would make that obvious. Dec 9 '20 at 20:50
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.

Image of UI

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.

xml of some related data

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.

1
  • Yes, it's a .qui file. The .qui file (not related to that qbasic program) has something like N combinations '1X2' (home-draw-away) of 14 games + 1 game (result 00, 01, 10, 11, ...). I think the file doesn't have any game or round information, that is not relevant. The software just compares the master key with combinations supplied in .qui file and sorts the 'closest' columns close to that master key. (sample: imgur.com/a/QoTYHL6) A file with all possible combinations will have something like 3^14 = 4,782,969 columns. (file: cutt.ly/LhY9zSO)
    – hmiguel
    Dec 10 '20 at 16:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.