[Cryptech Tech] cryptech_upload

[Michael]

Pavel,

You are correct.

Performed a readback of the flashed EEPROM from both upload methods. The 
resulting .mcs files were converted to binaries to remove the Intel hex 
file formatting.


The cryptech_upload method writes header information that the xilinx 
file ignores. Offsetting a compare for this shows the files match up to 
0x4FFF26.

The xilinx file has additional 0xFF padding from 0x4FFF26 – 0x4FFF9E. 
 From 0x500001 on the files are once again identical.


On 05/10/2018 05:02 AM, Pavel Shatov wrote:
> 06.05.2018 3:37, Michael пишет:
>>
>> So I updated ARM firmware. Now either method , Impact using .mcs PROM 
>> file or cryptech_upload using the .bit file load the bitstream memory 
>> with a file that operates the cores correctly. However I am still 
>> unable to prove that both methods create the exact same image. To 
>> double check against the checksum difference , I performed a readback 
>> with both loading methods and there are significant differences. Is 
>> the cryptech method performing some obfuscation method to prevent 
>> reverse engineering?
>>
>> I'm really stumped on how to prove the cryptech method for 
>> programming the PROM matches the original .bit file.....
>
> Hi, Michael,
>
> the bitstream itself (partially documented in table 5-19 on page 104 
> in [1]) has the following structure:
>
> 1. FFFFFFFF repeated 8 times
> 2. 000000BB
> 3. 11220044
> 4. FFFFFFFF repeated 2 times
> 5. AA995566
> 6. ...
>
> The .bit file has some additional information in the beginning 
> (filename, timestamp, etc), I've a attached a screenshot. When iMPACT 
> programs the configuration memory, it skips that garbage, the first 
> thing it writes is those 32 0xFF bytes. If you generate an .mcs file 
> out of a .bit file, you'll see that it starts with 0xFF bytes and that 
> additional data is not included, I've attached a screenshot too. MCS 
> format by the way is in fact Intel HEX, just named differently for 
> some reason.
>
> Our script should do exactly what iMPACT does, i.e. strip that header 
> from the .bit file and start writing when it sees 32 0xFF bytes. Maybe 
> there's something like an off-by-one error in the script and it strips 
> more or less bytes than necessary. This will not prevent the FPGA from 
> successfully configuring itself, because when it starts reading the 
> PROM, it discards all the bytes until it sees the bus width autodetect 
> pattern (000000BB, 11220044). If that is actually the case, the 
> checksum will be different when programming with our script and with 
> iMPACT tool, but both methods should work.
>
> Another thing to check is how we deal with the last chunk of the 
> bitstream. Configuration memory can only be programmed one page (256 
> bytes) at a time. It's unlikely that the bitstream length will be a 
> multiple of 256 bytes, so some padding must be done. As far as I know, 
> iMPACT pads the very last page with 0xFF bytes ("unprogrammed" memory 
> contains all 1's), I don't remember exactly how our script does the 
> padding, maybe it pads with 0x00. This will also lead to a different 
> checksum, but successful configuration, because the bitstream has a 
> special "desync" pattern in the end, that tells FPGA to stop reading, 
> so those padding bytes are in fact ignored.
>
> I don't have my programmer at hand right now, so I can't reproduce the 
> issue. Should be able to do this on Monday.
>
> One thing I can suggest is do a configuration memory readback from 
> iMPACT, this lets you save the actual contents of the PROM into an 
> .mcs file. Then you can compare that to an .mcs file you generated 
> using iMPACT to find the difference. Note that the readback operation 
> reads entire memory and produces a larger file with a lot of 0xFF 
> bytes in the end from the unprogrammed pages, they should be ignored.
>
> I think it's good that you noticed the issue. I believe that's more of 
> a cosmetic off-by-one or padding thing, but I mean if it's 
> straightforward to fix, why not fix it?
>
> [1] 
> https://www.xilinx.com/support/documentation/user_guides/ug470_7Series_Config.pdf
>
>
>
> _______________________________________________
> Tech mailing list
> Tech at cryptech.is
> https://lists.cryptech.is/listinfo/tech

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cryptech.is/archives/tech/attachments/20180512/87f108bf/attachment.html>