reverse engineering ?

is it easy to reverse engineer ASIC/FPGA ?
do u have any reference for this ?

binaryboy wrote:
> is it easy to reverse engineer ASIC/FPGA ?
> do u have any reference for this ?

binaryboy wrote:
> is it easy to reverse engineer ASIC/FPGA ?
> do u have any reference for this ?

Easy is VERY relative to ones experience and resources. The straight
forward answer is that it's probably very very hard for you since you
are asking. For most mortals ASICs are also very very hard as well, and
relatively easy for those that do it every day for a living (requires
some signficant investments in equipment and training).  FPGAs with
built in crypto are a little tougher nut to crack, but far easier than
ASICs .... still takes some special equipment but far less work.
Standard FPGA bitstreams for most FPGAs requires a two step process,
first finding the map for the device (which may require reverse
engineering some vendor tools first) then writing a netlist generator
using the map from the bitstream. This requires the least skill, and
can be done by most mortals that understand programming at an
undergraduate level and basic FPGA architecture in somewhere between a
few weeks to a few months for someone fairly bright and skilled, a bit
longer if they have a difficult time playing deductive reasoning games
or lack programming experience. Turning the extracted netlist into a
usable readable design for modification or clean room specification is
fairly linear in time by it size ... which can be significantly reduced
if your reverse engineering tools can "reverse compile" the netlist
into a higher level form, such as good high level VHDL/Verilog or C.

There are professionals that do reverse engineering for a living ... we
find that the experience from each project greatly helps develop the
skills/experience for the next.

You might find boomerang on sf.net interesting ... binary ISA streams
are about the same difficulty as unencrypted bitstreams, with the minor
twist that most FPGA bit streams are undocumented, forcing a two step
learning curve.

All,

That said, we are not aware of anyone who has ever reverse engineered a 
Virtex device bitstream (unencrypted).

There have been inquiries to vendors 'who do this for a living' and they 
have refused to quote on anything larger than a Virtex 1000 class 
(V1000, 2V1000, 2S1000, 2vp7, 3S1000, 3S1200e).

It seems that they feel it isn't worth the headaches.  Not that it isn't 
"possible."  But then, it is "possible" I could visit the moon.

As for once the bit stream has been encrypted (since Virtex II, 6 years 
and counting), no one has broken it (3DES).  And they have been trying.

More than one outfit.

It is even more unlikely that a direct attack on the newer 256 bit AES 
encryption with battery backed up keys will also be able to succeed.

Austin

fpga_toys@yahoo.com wrote:

> binaryboy wrote:
> 
>>is it easy to reverse engineer ASIC/FPGA ?
>>do u have any reference for this ?
> 
> 
> Easy is VERY relative to ones experience and resources. The straight
> forward answer is that it's probably very very hard for you since you
> are asking. For most mortals ASICs are also very very hard as well, and
> relatively easy for those that do it every day for a living (requires
> some signficant investments in equipment and training).  FPGAs with
> built in crypto are a little tougher nut to crack, but far easier than
> ASICs .... still takes some special equipment but far less work.
> Standard FPGA bitstreams for most FPGAs requires a two step process,
> first finding the map for the device (which may require reverse
> engineering some vendor tools first) then writing a netlist generator
> using the map from the bitstream. This requires the least skill, and
> can be done by most mortals that understand programming at an
> undergraduate level and basic FPGA architecture in somewhere between a
> few weeks to a few months for someone fairly bright and skilled, a bit
> longer if they have a difficult time playing deductive reasoning games
> or lack programming experience. Turning the extracted netlist into a
> usable readable design for modification or clean room specification is
> fairly linear in time by it size ... which can be significantly reduced
> if your reverse engineering tools can "reverse compile" the netlist
> into a higher level form, such as good high level VHDL/Verilog or C.
> 
> There are professionals that do reverse engineering for a living ... we
> find that the experience from each project greatly helps develop the
> skills/experience for the next.
> 
> You might find boomerang on sf.net interesting ... binary ISA streams
> are about the same difficulty as unencrypted bitstreams, with the minor
> twist that most FPGA bit streams are undocumented, forcing a two step
> learning curve.
> 

binaryboy wrote:
> is it easy to reverse engineer ASIC/FPGA ?
> do u have any reference for this ?

It was only ever "easy" maybe 25 years ago or more for full custom VLSI
and has gotten progressively harder by Moores law and more so ever
since for ASICs. There were (are?) quite a few firms that used do it
but the business model has changed.

Most DRAMs from different vendors were largely similar because they
could all buy "reports" from Mosaid of the design of leading parts.
Design engineers liked to know they were at least doing the same sort
of thing as the leader, but memories are a special case. It probably
helped the consumer to mix different vendor parts without too much
fuss.

FPGAs another story.

This has been discussed many times here if you care to google groups
for reverse engineering.

John

Austin Lesea wrote:
> There have been inquiries to vendors 'who do this for a living' and they
> have refused to quote on anything larger than a Virtex 1000 class
> (V1000, 2V1000, 2S1000, 2vp7, 3S1000, 3S1200e).

I've done code recovery and clean room reverse engineering on and off
for software projects, and pld's since the late 1960's. Tools really
make the difference. For a large project we did in 1973 it required
writing a pretty state of the art high level disassembler for the
CDC3100 series to do code recovery for an operating system and major
utilities. The whole project including the disassembler was about 9 man
months. Another project required taking some dozen large eproms of 386
firmware converting to asm and back to forth. Again it took about two
weeks to write the tools, and several weeks to reconstruct the forth
code and provide the client with a clean room specification for the
system design.

If someone came to me wanting code recovery for any sized Virtex series
fpga, I don't think that is a problem, would require a modest effort in
tools that do not exist today. A clean room specification would take
longer, and is linear to application size, as you actually have to
understand the design to write it's specification. In general, clean
room projects typically run about 15-35% of the original design labor
for software projects ... and I suspect a similar range for hardware
designs reverse engineered back to verilog or C using a decompiler
approach. A Virtext front end for boomerang to FpgaC is probably less
than months work, and would require some hand tweeking to handle odd
cases of clock edge usage into a verilog module.

> It seems that they feel it isn't worth the headaches.  Not that it isn't
> "possible."  But then, it is "possible" I could visit the moon.

When the engineering time for a hardware/software project is measured
in a few man years, with a burdened cost of $500K and up, then $75-200K
for code recovery or a clean room specification of the design can be a
cost effective engineering expense to replace an old lost design or
jump start a competitive redesign.

>
> As for once the bit stream has been encrypted (since Virtex II, 6 years
> and counting), no one has broken it (3DES).  And they have been trying.
>
> More than one outfit.
>
> It is even more unlikely that a direct attack on the newer 256 bit AES
> encryption with battery backed up keys will also be able to succeed.

Crypto attacks don't make sense .... other physical attacks would, if
required. Nice big vaults with a shinny armor door are seldom the
easiest way into a vault of the locks fail. The cinder block or
concrete back wall, ceiling, or floor are probably much easier entry
points, and cheaper to repair afterward.

Austin Lesea wrote:
> There have been inquiries to vendors 'who do this for a living' and they
> have refused to quote on anything larger than a Virtex 1000 class
> (V1000, 2V1000, 2S1000, 2vp7, 3S1000, 3S1200e).

You can always "prove" how difficult it is ... follow the RSA example
and offer a $20K challenge for reverse engineering an XC4VLX200 design
to an HLL that can be modified and recompiled. And maybe $100K for a
similar design that is DES locked.

Maybe Ron and I would have a lot more fun on those projects :)

Austin Lesea wrote:
> There have been inquiries to vendors 'who do this for a living' and they
> have refused to quote on anything larger than a Virtex 1000 class
> (V1000, 2V1000, 2S1000, 2vp7, 3S1000, 3S1200e).

Please send your customers that need code recovery for larger devices
to me :)

John,

Sure.

No problem.  If anyone asks, I'll let them know you will consider it.

I had gone to get some quotes last year from some houses, and they had 
'no bid' after looking at it.

Some of these houses advertised that they would do exactly that, and had 
done so in the past (with a XC4005!).  People were asking how difficult 
it was to do this, and we felt we should find out.

Just be careful with your quote.

One more word of caution; I have access to the schematics, the bitstream 
map, and anything else.  When we have to reverse engineer a design for a 
customer (such as "why did the part fail the way it did" in some 
critical military application) it is still very tough to find which line 
of HDL was affected by the fault (presuming we even found a fault!).

And, I agree that if the front door is solid steel then most attackers 
look for a less secure means of entry, like an open window.

Austin

Austin Lesea wrote:
> Just be careful with your quote.

Certainly. Source reconstruction is a pretty high risk contract even in
the best cases.

The absolute WORST contract I took was to reconstruct the CURRENT
sources for 20 cabinets of two year old IBM Cobol that had been
maintained online and lost (contract operations center refused to hand
sources over when client decided to change vendors, luckily they
managed to snarf binaries). Project was a year of painfully finding and
fixing every bug and change to those sources during the previous two
years by running in parallel with the production binaries for a year
till I got it to match line for line. Most of it came up with strainght
forward debugging in 3 months ... the last 5% took the rest of the year
-- all of 1974. The entire financial and inventory system for a Los
Angeles company.