08-07-2014 10:10 PM
I have an application in which I would like to use a tool similar to data2mem for hacking block ram contents in an FPGA bitstream prior to download into an FPGA.
The FPGA could be Virtex 6 or Artix 7 or Kintex 7.
The bitstream is not encrypted and not compressed.
The problem is that I want this to run on an embedded system. The CPU is not x86, so there's no chance of getting data2mem to run on it. Even if data2mem was recompiled by Xilinx for my system, I would not be able to run a "binary blob" on it for reasons I don't want to go into here.
The actual creation of the software is trivial - just change some bits in a file, and adjust some CRCs. The hard part is getting the specification for the bitstream format.
I understand that the bitstream format is not public.
- licensing source for data2mem from Xilinx.
- obtaining (under NDA) the bitstream format from Xilinx.
- reverse engineering the bitstream format.
I'm currently favouring the reverse engineering approach since the block rams should be easy to identify.
Any pointers or other ideas?
08-12-2014 03:27 PM
None of these is likely to happen...
(I don't work for or speak for Xilinx, but...) I doubt Xilinx will release any source code to anyone - the maintenance issue is a nightmare. Similarly, I doubt you will get a lot of support for modifying the bitstream, and reverse engineering it might be quite difficult than you think - particularly since there are CRC checks in the bitstream.
Your best bet is to "find another way". Create some communication path between your CPU and your FPGA and modify the BRAM data after the FPGA has been configured. You could probably do this with as little as 2 or 3 pins and a serial protocol.
You might also be able to do this through the JTAG port; if your FPGA is already being programmed via JTAG, the connections are already there. In most families of FPGAs you can configure the JTAG chaint to have a user register implemented in the fabric of the FPGA - you can then do reads and writes through this JTAG register.
08-12-2014 09:04 PM
My local FAE is currently looking for scripts that could be used in place of data2mem. If he comes up with something, I'll use it. I'm not too hopeful though.
Why is reverse engineering the bitstream hard? I know it has been done before. Neocad, who were later bought by Xilinx, reverse engineered the entire bitstream (of earlier generation parts) and made their own tools. I only want to alter block ram initialisation, which should be easy in comparison.
The block rams should be simple to locate in the bitstream. Data2mem allows a chosen plaintext attack. I can automate a process which uses data2mem to change each bit in each block ram, and compares the before and after bitstreams.
A CRC provides no security against an attacker who has a basic understanding of algebra, and should also be easy to locate in the bitstream.
I actually think it's about an order of magnitude less work to hack the bitstream than to modify the FPGA source code to mux in an extra port that can write into the block rams. Some of these work at over 200MHz and already use both ports.
I had also considered the use of JTAG (or ICAP), but rejected it on the basis of being more work than bitstream hacking.
There are other considerations (that I won't discuss in a public forum) that make me not want to change the existing FPGA source code. I really do think that bitstream hacking is a good solution for this problem.
08-14-2014 09:48 AM
From reading your posts, I cannot tell what your actual problem is. Just your solution is hacking the bitstream? I completely understand that finding the BRAM in is pretty straight forward in a design as DATA2MEM uses this to modify the bistream. I published some TCL scripts to do just that for a NON-Embedded design when you have access to the implemented design. I also know Xilinx provides some bitstream dumping tools to give you visibility to the contents of the design including the BRAM contents. They don't provide a way to go the other direction that is publically available; I could see the factory having access to such tools.
My first though is you don't have access to the design; you indicated that hacking the bitstream to add the mux for the memory write port is the same level of effort of hacking the bitstream to put in new BRAM data. The key here is "hacking" which tells me you don't have any source for what you are doing? 200MHz is not a problem to add a write port to the BRAM, BTW.
Yes NeoCAD did some reverse engineering on what I would consider significantly less complex designs (I have worked in Boulder for 30+ years so I know some of those involved). I wish you luck, a determined engineer can do a lot of amazing focused work.
08-14-2014 08:46 PM
I knew someone would get the wrong idea if I used the word "hacking".
I have access to all the source code. I wrote a significant fraction of this project (at least a few hundred kLOC), so I have a good understanding of what it does and what it takes to modify it.
In a typical pipelined > 200MHz design, adding a mux to create an extra write port would be simple. But this design can't be pipelined, for reasons I don't want to go into in a public forum. The block ram address setup to clock is on the critical path.
Can you please provide pointers to your published TCL scripts?