1

I have a set of datafiles that I want to reverse engineer which are used by a software that controls my heating system. I want to extract the commands to then use these commands in my home automation system.

The files are not encrypted and using a hex editor, I can discover some of the information relatively easily. The problem is that some pieces of information belonging together are actually spread across the file. It seems to me that there is some kind of nesting (like with XML or something like that, but in binary) taking place, and if I could understand this nesting technique, it would probably be easy to access all the relevant information in one go.

The file starts out as this:

00000000: ffff 1600 1200 4344 6576 6963 6544 6573  ......CDeviceDes
00000010: 6372 6970 7469 6f6e 0100 0100 0100 0402  cription........
00000020: 0100 0409 0101 0200 0000 ffff 0100 1800  ................
00000030: 4344 6576 6963 6544 6573 6372 5374 6174  CDeviceDescrStat
00000040: 654d 616e 6167 6572 0100 0000 0200 0000  eManager........
00000050: 0700 0000 0100 0062 01ff ff01 000c 0043  .......b.......C
00000060: 436f 6d6d 4f62 6a56 616c 4d69 0005 0000  CommObjValMi....
00000070: 0000 0000 0301 0000 0000 0000 0200 0000  ................
00000080: ffff 0100 0700 4356 616c 4d45 3800 0012  ......CValME8...
00000090: 0000 0000 0000 0300 0010 0000 0000 00ff  ................
000000a0: feff 0120 0000 0030 0000 0000 0000 0000  ... ...0........
000000b0: 0000 0000 ff00 0000 0000 0000 6d00 0000  ............m...

Here's what I figured out: Each block begins with a ff ff signature. The third and fourth byte after ff ff are a 16-bit length field that indicates the length of the subsequent string. The strings here at the beginning of the file seem to be the, on the one hand, names of the table headers, but on the other hand could also be value types used in the software (such as CValME8; later occurrences are called "CComObjAnyString" or "CLString").

The actual data that I'm looking for comes later in the file:

000083b0: 0000 00a9 4090 0419 800d 092d 0001 0000  ....@......-....
000083c0: 0000 0401 0000 0000 0000 0100 0000 bc01  ................
000083d0: 0019 800d 092e 0001 0000 0000 0401 0000  ................
000083e0: 0000 0000 0100 0000 1b80 0000 0a09 0000  ................
000083f0: 0000 f40f 0000 8200 0000 0000 fffe ff03  ................
00008400: 3200 3200 3600 0000 8000 0000 007e 0000  2.2.6........~..
00008410: 0000 002d 800e 0905 0001 0000 0000 0202  ...-............
00008420: 0000 0100 0000 0100 0000 bd01 0000 0000  ................
00008430: 0000 0000 0000 0000 1980 0f09 2d00 0100  ............-...

The record begins at 0x83b9 (could be 83b8 as well, depending on whether 0x80 is a start or end flag). 0x0d092d is the command code for parameter 226 whose ASCII representation can be found at 0x8400. The text representation of the parameter is always preceded by 0xff 0xfe 0xff and the length of the parameter text (here: 3 times an ASCII value stored in a 16 bit value). The record ends in 0x8438 (or 0x8439) with the flag 0x80. Inside this record, there are again sub-records with the 0x80 as delimiter containing references to an external SQLite database where the clear text name of the parameter as well as the drop-down options are stored.

My problem now is that I can't figure out a system how this data is structured. Some fields have their length stored, others don't. The blocks delimited by 0xff 0xff seem to end arbitrarily and I haven't figured out how a 0xff 0xff would be treated as data and not as a marker, if applicable. The same goes for the records which have varying sizes, and sometimes all information on a parameter is stored in one record, but sometimes part of the information on one parameter is spread across several records.

Does anyone have an idea on how to move forward from here? Or does the file format look somewhat familiar? The original software is running on Windows and requires .NET 4.8 if that is of any help.

Any hints or suggestions are highly appreciated!

3
  • Assuming you haven't tried using a disassembler (you haven't mentioned that in the post), surely that would be the best way to move forward. Are you able to share the full binary? Mar 14 at 11:15
  • 1
    Sharing the binary would probably violate copyrights. It's a Windows executable and a rather large one, my assembly knowledge is limited to 6502 assembly, so that would be a non-starter for me ;)...
    – fredlcore
    Mar 15 at 12:05
  • Fair enough. Even if your assembly knowledge is limited, I'd still recommend giving it a go. I recently had success in figuring out a compression format with IDA by searching for the compressed file's extension/signature within the binary and going from there. I have zero knowledge in assembly, so if you're familiar with it at all then you're already at an advantage. Best of luck. Mar 15 at 12:46

0

Your Answer

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

Browse other questions tagged or ask your own question.