Any idea why the Minipro detected it as the CS version? I'm using genuine hardware with the same device id and serial correct boot loader the whole time. What did the updater end up changing?
Because the device ID and serial code are not stored in clear text. Let me explain some insides because i see a lot of confusion here.
The central unit of this programmer is obviously a Microchip PIC18F87J50 processor. This processor has an internal flash of 128Kb which is divided like this:
- the first 6KB is reserved for the bootloader; this code region is identical in the two versions (A/CS).
-the next 121Kb is the actual firmware (i name it the normal firmware); This is the upgradable area. We have two firmware versions: the A version and the CS version. The CS version is a castrated A version with disabled ICSP functions. This area is updated by the bootloader; nothing special here.
Now we reach the last Kbyte of flash where some magical things exists! So we have 1Kbyte of flash between the address 0x1FC00-0x1FFFF.
The last 8 bytes (1FFF8-1FFFF) are reserved for configuration bytes.
This region is divided like this:
-1FC00-1FCFF = 256bytes; here is a random generated table. Just pure random numbers. This table is used internally by the bootloader as a "key" for the decryption process. There is a table for the A version and one for the CS version;
-1FD00-1FD4F = 80 bytes. Here in this data block the device ID and serial code are stored. This block is encrypted and is unique for each device. I will explain later about this block.
- 1FD50-1FF4F = 512 bytes; Here is a precomputed CRC16 lookup table used internally by some CRC16 routines; this table is identical in the two versions.
The rest of 1FF50 to 1FFF7 is a free region (FF) followed by the configuration bytes.
But let's go back to that encrypted 80bytes data block where the device ID and serial code are stored. This block is decrypted by the firmware (either bootloader or the normal firmware) using that Random generated table from 1FC00-1FCFF. The encryption/decription process uses some byte swaping/shifting and xoring each value of this block against that random table. Nothing special here but a weak encryption algorithm.
After decryption we have a clear text data block (80bytes). Something like this:
0-7 = 8 characters device ID (00000000 for example) only decimal digits.
8-31 = 24 characters serial number; only hex numbers (0-9; A-F); Four digits from this field are the computed CRC16 of the device ID.
See this post32-77 = 46 bytes; filled with random rubbish data.
78 and 79 = 2bytes; computed CRC16 of the first 78 bytes; if you screw this CRC the firmware will refuse any transaction.
But wait! At the offset 34 we have an 8bit checksum computed from all bytes from offset 5 to 33. Go figure! something like byte34 = SUM(5 to 33); This is where my first version of the firmware updater screwed. I was not aware of this checksum and also the embedded crc from the serial code.
Also in my first updater version there was no advanced window to tweak the serial and other things 'on the fly'. Only the firmware generator which generates a hex file and then with the help of an external programmer (like PICKIT) the new firmware was flashed.
The algorithm to generate that 80bytes data block was something like that:
-generate or copy the existing device ID and serial to offset 0-31;
-fill the rest of bytes from offset 32 to 78 with random numbers;
-compute a 16bit CRC of the above 78bytes and store it at the offset 78 and 79
-encrypt this block
Later this block is inserted at the offset 1FD00 in the generated firmware. So this block is unique.
In time my updater evolved and the firmware dumper was developed (a custom firmware to dump/manipulate the data in the last kilobyte) but the routine which generate that encrypted data block remained the same.
This was at year 2013/2014 if i remember correctly. A lot of people converted their programmers from CS to A for the ICSP capabilities. Also many sellers converted their CS stock and sold them like A (for extra money of course). Those programmers were genuine produced by Autolelectric.
After 4 years the Autoelectric suddenly didn't liked this anymore. And the evil Minipro V6.80 was pushed out. Flood of bricked and locked devices!
https://www.eevblog.com/forum/blog/eevblog-411-minipro-tl866-universal-programmer-review/msg1688264/#msg1688264 here is where the fun begins.
Also some counterfeit hardware appeared on the market. Those programmers were loaded with the same generated hex file by my earlier version of firmware updater. So the same device ID and same serial code!
The autoelectric discovered this and if someone with this kind of device tried to update the firmware and the firmware update routine found such device during the update process then the bootloader is wiped out thus bricking the device.
This check was introduced in the Minipro 6.50 and is still present in the last known version (6.85).
But the check routine has one big flaw.
For example, if you want to detect a particular device ID and serial code you just compare two strings, like this:
//Pseudo code
if(deviceID == "00000000" and serialcode == "blabla") then brick_this_device
but instead the developer used something like that:
//pseudo code
if(CRC32(deviceID) + CRC32(serialcode) == 0xC8C2F013) then brick_this_device
which is very evil. That 0xC8C2F013 CRC can be computed from many pairs of device ID and serial code. Is called CRC collision and this is why so many genuine devices were bricked. This is a Russian roulette.
So if your device ID and serial code collide and you try to update your device, then the bootloader will be wiped out.
Another detection introduced in the minipro 6.8x was the block checksum (that byte at the offset 34), serial code and code protect bit check.
If the CP0 is found unset then the bootloader will be locked. So a semi brick; you can't update your device anymore (you can force the bootloader mode with the resistor trick). This was the case of my generated hex files which had the CP0 bit unset.
If the checksum at the byte 34 is wrong, but the device ID and serial code is good, then you'll get that nag screen "converted from CS" and your device will work.
This was the case of many devices either converted by the seller or the final user. Rewriting the serial code in the advanced window corrected this checksum.
The last case is random generated serial code with my earlier firmware updater. Those devices are detected as "pirated/piracy" and my last firmware upadater will show "bad serial" in the info field"
For those device a new serial must be generated to work otherwise when you read something you will get gibberish data instead of real data.
Hope this cleared some confusions about this subject.
Heh, I have skills 
.
I have no doubt about this, but it's still funny.
Home
Help
Search
Login
Register
