I know Xilinx keeps its bit file header format secret. But, does anyone know how to detect if a bit file is encrypted or not? As part of our manufacturing builds, we need to make sure the bit file we are choosing, is the encrypted file and not the regular bit file.
Maybe someone knows how to read and de-cypher the XIlinx bit file header. Or has a command-line tool to detect that.
Please let me know,
-- Amal
Amal,
An unencrypted bit file is 3 to 7% 1's (97 to 93% 0's) typically.
An encrypted bit file is roughly 50% 1's and 0's.
Real easy to tell them apart.
Austin
Hi Austin, What if the FPGA design had all the BRAMs initialised to 1's? ;-) Cheers, Syms.
Symon,
Even with all BRAM's to 1's, the files will still look really very different in terms of one's density!
One of the side-effects on a good encryption method is that it makes the data look like "noise."
So, what they need is a way to tell the difference between "noise" and a unencrypted bit file.
You could play it through a sound card, and you could immediately tell the difference, for example.
(I can see the assembly line taking 'dance to the bit stream breaks')
Or, you could display the bit file on a monitor with 24 bit color, in .bmp format (or .tiff, or whatever) and the encrypted files will look like grey splotches of many colored pixels, and the unencrypted bit files will look like structures of some sorts (not "noise" at all!).
By the way, I use this last method to evaluate true random number generators, as your brain can view a big (1760 X 1024 X 24 bit) picture and almost instantly "see" non-random behavior ... must have something to do with us all coming from hunters on the veld two million years ago ...
If you display them fast enough, you can even make a "movie" or if you play them fast enough, a symphony.
Austin
Hi Austin, That reminds me of the technician guys who can listen to PRBS patterns sent over PCM channels and tell you which of several PRBS's it is. You're right, the pattern matching of the brain is remarkable. Cheers, Symon.
Symon,
The 'sush-sush' of 2E20-1 is very easy to hear, as it repeats every ~.75 or ~.5 seconds (T1 or E1) so that was not such a remarkable feat!
And anything shorter (2E7-1) had audible tones that the tech could hear!
After all, a LFSR (linear feedback shift register) is a PRBS (pseudo-random bit source) is only a PRNS (pseudo-random noise source), and not really random at all.
Like any amazing feat, there is likely to be something simple behind it, so that any idiot can do it.
Reminds me of what I saw on the news this morning, a fish market vendor was asked about the ban on crab fishing in the SF bay area, and were SF bay crabs really different?: her answer? "Grandpa Alioto swore that they tasted better from the SF bay, but we snuck some from Washington onto Mom's plate, and when told of what we had done, she said - never could tell the difference really ... dad couldn't either."
Austin
To follow what said Austin, a side-effect caused by the contents of the encrypted bit-file locking like noise is that the compression ratio of the encrypted bit file will be near 1:1.
Therefore a practical solution regarding the problem of the OP would consist in compressing all his BIT files in a single archive and then sort the contents of the archive by compression ratio (or compressed size).
This however may not work if bitgen is called with the "Compress" parameter...
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.