I lost track of the post with that decrypted file but it was definitely decrypted/correct.
It's in the 1st page.
Oh, yeah, duh!
Here's the hex dump of the decrypted file as shown in HxD:
First up: You can see a lot of zeros, that's a good sign of correct decryption.
Here's the analysis:
00000000 File CRC32: A2A69654 [00000008-000000D3] CRC OK
00000004 File Length: 204 Size OK
-----------------------------------------------------------
00000008 NameSize: 4
0000000C Name: E_CFG_MODEL_RAW
00000010 FieldSize: 56
00000014 CRC32: 0ADE0274 [0000001C-0000004B] CRC OK
00000018 DataSize: 44 Size OK
0000001C Data: DHO924
-----------------------------------------------------------
0000004C NameSize: 4
00000050 Name: E_CFG_SN_RAW
00000054 FieldSize: 56
00000058 CRC32: 6184E52C [00000060-0000008F] CRC OK
0000005C DataSize: 44 Size OK
00000060 Data: DHO9A252500008
-----------------------------------------------------------
00000090 NameSize: 4
00000094 Name: E_CFG_MAC
00000098 FieldSize: 56
0000009C CRC32: 8292C492 [000000A4-000000D3] CRC OK
000000A0 DataSize: 44 Size OK
000000A4 Data: 0019AFA00004
File processed OK
First up: The checksum is hexadecimal A2A69654
In the hexdump you can see the first four bytes are 54 96 A6 A2. That's the same four bytes as the checksum but reversed, that tells me the rest of the file will also have any 32-bit numbers reversed in it.
Next up in the hex dump we have CC 00 00 00. Reverse that and we get 0x000000CC - 204 in decimal. That's the file size.
After that is 04 00 00 00, that gives us "NameSize: 4". It looks like every packet of data in the file is preceded by its size so we read out 4 bytes. "05 00 00 00". 5 must be the code for E_CFG_MODEL_RAW (which I assume is "model number").
Then we get 38 00 00 00, ie 0x00000038, 56 in decimal. The remainder of the "E_CFG_MODEL_RAW" packet is 56 bytes long. It has a 4-byte CRC ("0ADE0274 ") and then this:
06 00 00 00 31 67 FA 5A AE C8 12 02 15 AA 70 96 0A CA 4E A0 EF 82 04 1B B2 36 40 C3 23 CF 2E EF 3A 03 58 80 76 02 1B CD BF 10 1A 36 45 2C 02 98
I'm not exactly sure how that works but the first 4 bytes are"6" (the length of the string "DHO924") plus what I assume is an encrypted version of the text (there's no zeros or recognizable characters in the data and some bytes are higher than 127).
The next packet is the serial number. It starts at offset 0x00004c and has the same structure.
The final packet is the MAC address and starts at 0x00000090. Same structure again.
Why would they encrypt the strings inside the file? No idea. It's suspicious that all three strings in the file have 40 bytes of data even though the strings are different lengths.