i have see sources of your gretools and suggested that exist such methods
but don't have time for found them.
Hello,
The method I used made it simpler to transcode firmware as all I had to do was calculate the xor difference between the two tables rather than completely decoding and encoding. Although I would have noticed the pattern repeating after 512 bytes.
The two bytes after the size (the first two obfuscated bytes) are a CRC-16 of the rest of the unobfuscated file. The bytes after the CRC are a straight binary image loaded at the base of the CPU flash memory. The bootloader jumps to the base of flash memory to run the app, and this location has another 2 byte jump instruction into the code. The byte following the jump instruction is the firmware version encoded as two nibbles in the byte. This is followed by a version text string.
The CRC-16 value is calculated using the ITU-T V.41 polynomial (x^16 + x^12 + x^15 + 1). HxD has a neat Custom CRC feature that allows specifying the polynomial that I used to check. The table generated to implement a table-based calculation of this CRC-16 is also used as part of the code obfuscation. Since a 512 byte repeat pattern is a little short, this is lengthen out to the longer pattern.
I noticed a couple of early GRE models used the same obfuscation, and that seemed to change when a Canadian version of firmware was released for the PSR-500/600. I suspect this was done to prevent the unblocked Canadian firmware from being loaded into the US model. It also prevents users from loading the wrong firmware. The CRC will not match if the wrong deobfuscation is used by the bootloader.
73 Eric