visible “header”， either TE has some very weird custom compression or (more likely) the file is encrypted. (very likely compressed and then encrypted). The first 0x300 Bytes are almost entirely zero Byte values and look like some kind of mostly-empty header. There is nothing that looks like a CRC as they had in the old .op1 file which is another hint towards encryption/signing because why bother checking if the file was transferred correctly when it will only decrypt successfully if it did. At offset 0x4 there is an 0xFF value (or 0xFF000000 if it is a 32bit value). that might be an offset to where to write the file. That would be a possible hint why the file is so small - they have updates of parts of the system this time. (Also 0xFF000000 has a special meaning in BlackFin) At 0x70 there is a 20-Byte value that looks pretty random. This could be a SHA1 And then the last 64Bytes of the file again seem to drop in entropy. No idea yet what that could be. Maybe a signature (ECDSA?) Entropy: https://www.dropbox.com/s/0sg3ikeyf713t9g/z_firmware_1_1_9.png?dl=0 This is gonna be interesting ;o) PS: ca someone with an op-z be brave enough and change a few Bits of the file and try a download? I would hope the device then yields some kind of error like “decryption failed” or something? Does it keep showing something on a connected display while doing an FW upload? ， 2018， TabascoEye October 22， 3:31pm 9 Well you guys know me by now. So I took a look into the FW file and it seems like TE doesn’t want to let us in on the fun quite as much this time around. binwalk doesn’t find any magic file signatures in the .zfw The file is really small compared to the .op1 files (800kB to 11MB!) The entropy of almost the entire file is quite high (see the picture attached) That much entropy is usually a) compression or b) encryption. Since binwalk can’t find any magic headers of known compression algorithms and the entropy just begins without any ordered，。