I am working on a project that requires me to load a firmware file (.aff) to an embedded device using a proprietary protocol. Google shows that aff stands for augmented file format but I am not sure what that means in this context.
-
I don't see a 6-character hex string in the "example" (i.e. the `{0:X6}` part). Also, how do you get "xx" from your input file, if that's the "part of the protocol"? Also, `BitConverter.ToString` inserts dashes between hex numbers. Are you sure you are supposed to send bytes as 2-character hex ascii, instead of simply bytes? – vgru Feb 17 '17 at 01:20
-
What I am trying to do is create the same hex output (with my code) that I captured using my serial port sniffer while uploading the firmware using some legacy software that actually works. The output I captured is the firmware block with 'xx' in it, and no 'xx' is not part of the protocol I just edited the output so it didn't contain the actual data (for security reasons). The .aff is what contains the firmware. I tried using the code examples above to convert that file into an array of bytes and compare it against the output (the firmware block with xx in it). – Joseph Mawer Feb 17 '17 at 12:26
-
As you can see in the firmware block above, the data starts with hex values: 0x41, 0x49, 0x43, 0x30, 0x31, 0x00, 0x00, etc... however, when I get the bytes from the .aff file using my code and convert it to hex... I don't get these values. – Joseph Mawer Feb 17 '17 at 12:32
-
In the code sample above, Console.Write("{0:X6} ", ix); is just converting the line number to hex not the actual data within the .aff file. You can try using the code snippet above on some file to view the output format. – Joseph Mawer Feb 17 '17 at 12:41
-
The first "attempt" *will* dump actual bytes from the file, so I am presuming that the protocol contains additional data (perhaps header with cookie/length and similar information). Simply open the input file using a binary editor like [HxD](https://mh-nexus.de/en/hxd/) and you will see that you are either 1) dumping correct data, or 2) opening the wrong file. Also, to read the entire file, you can simply use `var buffer = File.ReadAllBytes(filename);` and remove the `FileStream` stuff. – vgru Feb 18 '17 at 09:34
2 Answers
Presuming the format is "augmented firmware file", if you google for is, you wil get this page. This file seems to be loading an aff file and uploading it to a controller.
You can see that the file starts with a css_header
struct (128 bytes if I am not mistaken), then contains stuff like modulus
, signature
and other, meaning the actual firmware data starts somewhere at a rather distant offset (908 bytes from the file start):
struct css_header {
u32 module_type;
u32 header_len;
u32 header_version;
u32 module_id;
u32 module_vendor;
u32 date; /* BCD yyyymmdd */
u32 size; /* in DWORDs */
u32 key_size; /* in DWORDs */
u32 modulus_size; /* in DWORDs */
u32 exponent_size; /* in DWORDs */
u32 reserved[22];
};
#define KEY_SIZE 256
#define MU_SIZE 8
#define EXPONENT_SIZE 4
/* the file itself */
struct augmented_firmware_file {
struct css_header css_header;
u8 modulus[KEY_SIZE];
u8 exponent[EXPONENT_SIZE];
u8 signature[KEY_SIZE];
u8 r2[KEY_SIZE];
u8 mu[MU_SIZE];
u8 firmware[]; // <--- 908 B from struct start
};
I would recommend opening the aff file using a hex editor (like HxD mentioned in the comment above) and then search for the bytes that you captured using the serial sniffer to see where they are in this file. If the data above is correct, you should find the actual firmware data offseted inside the file.

- 49,838
- 16
- 120
- 201
-
Thanks Groo, however, the hex editor produced the same results that my code did... so I don't see any hex that resembles the hex I captured using the serial sniffer. I am now thinking that a mask is being applied to all the hex values (through the legacy software application) before loading the firmware, and I saw the altered hex values. I now have the source code for the legacy application... so I think my best bet is to just work through that... unfortunately it's all written in C/C++, which is not a language I am very familiar with. Thanks for you help! – Joseph Mawer Feb 18 '17 at 13:38
The key information that I was missing was that the file I was working with was in fact an SRecord. Once I understood the format of an SRecord I was able to parse out the correct data from the record and successfully load the firmware image.

- 288
- 6
- 16