Note: I'm aware of the technical and legal implications of reverse-enginneering binaries.

I have the firmware for a Netgear WGR614v7 router, in the form of a .chk file, coming from Netgear themselves, and I wish to unpack the file. My understanding is that a firmware .chk file is a header before a TRX image, and I've tried to untrx the ile I had sans header, or with header as well. Neither that nor binwalk succeeded. Two useful strings are seen very close to the beginning of the file:

  • AH00I8
  • U12H064T00_NETGEAR

Inspecting the file in a hex editor, I'm unable to find the TRX file signature (I was looking for ASCII HDR0). I also cannot find any sort of compression magic values, except fairly far into the file where they're not likely to signify the beginning of the actual content I'm looking for.

Am I looking for the wrong filetypes? Is anything about this structure known that I haven't found yet?

Edit: The firmware has been downloaded from Netgear's site. I tried chopping off various lengths but cannot find a reasonably-located compression or TRX header. The characteristic ff ff ff ff of IMG images used as a method of preventing a repetitive boot firmware is also not existent.

Edit 2: I did some searching of my own, and found a decompression utility. When I chopped the file such that sqz had been the first characters, that utility seemed to find valid Huffman structures but incur a size mismatch. A result of the decompression yielded 11 bytes, while the program warned me:

Warning: Unpacked file should be 7537274 bytes but is 396409921 bytes! at ./unpack.pl line 61, <STDIN> line 3.

Of course, it could be that many kinds of data that is corrupt might be partially readable as huffman giving me strange results as seen here.

  • Might be a newer or older version of the file format. Could you post a sample?
    – nneonneo
    Jun 9 '14 at 1:30
  • @nneonneo I edited the post with that info,
    – nanofarad
    Jun 9 '14 at 10:23
  • The SQZ utility you found does not appear to be for the same sort of SQZ file. The file format seems totally different.
    – nneonneo
    Jun 10 '14 at 4:28

The file begins:

0000000: 4148 3030 4938 e66c 000e aa28 9835 0589  AH00I8.l...(.5..
0000010: 3004 125a 1b39 65ff 47e4 b95c 0001 0014  0..Z.9e.G..\....
0000020: 5531 3248 3036 3454 3030 5f4e 4554 4745  U12H064T00_NETGE
0000030: 4152 0000                                AR..

The reason for picking this size will soon become clear.

The first four bytes (AH00) are probably file magic. Googling just that string brings up this page, which has a detailed breakdown of a different firmware file with a similar structure.

The next four bytes are not described by the linked page. Reading them as a 32-bit big-endian value (BE32), though, you get 0x4938e66c = 1228465772, which is plausibly a recent UNIX timestamp (usually values from around 800,000,000 to 1,500,000,000). Indeed, it decodes to Fri Dec 5 08:29:32 2008 GMT, which is plausibly the build date of the hardware (and I note that the linked article has 0x481ac265 = Fri May 2 07:27:33 2008 GMT, which also seems plausible).

The next four bytes read as a BE32 value give 961064. The total filesize is 961116 bytes, so this is likely the payload size, leaving 52 bytes for the header (and thus explaining why I chose to show the first 52 bytes here).

The next 32 bytes are the MD5 sum of the payload as indicated by the linked page. I deleted the first 52 bytes and MD5 summed the result:

983505893004125a1b3965ff47e4b95c  /tmp/fw.sqz

which is exactly what the header contains.

The next two bytes are unknown.

The next two bytes are 0x0014, which is the length of the string that follows (including two padding NULs). While I'm not familiar with Netgear routers, I'm guessing this is a model/revision number for the hardware target.

And there you go: that's the .chk file header.

char magic[4];
uint32_t timestamp; // UNIX timestamp
uint32_t payload_size;
char md5sum[32];
uint16_t unknown; // = 1 on all files seen so far
uint16_t model_size;
char model[model_size];

In the original linked page, the payload was a plain ELF file. Unfortunately, in your firmware, the payload is some other kind of file, with the magic sqz ("squeeze"?). It's clearly compressed, but I can't tell what it's compressed with. For now, this will have to be an incomplete answer until someone figures out what the compression format is.

  • I did some poking into the sqz format, could you please see edits?\
    – nanofarad
    Jun 9 '14 at 22:25

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.