[Cryptech Tech] cryptech_upload

[Pavel Shatov]

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

-- 
With best regards,
Pavel Shatov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bit.png
Type: image/png
Size: 47694 bytes
Desc: not available
URL: <https://lists.cryptech.is/archives/tech/attachments/20180510/1e7af084/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mcs.png
Type: image/png
Size: 38479 bytes
Desc: not available
URL: <https://lists.cryptech.is/archives/tech/attachments/20180510/1e7af084/attachment-0003.png>