reverse engineering ?

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.

Aust> b>

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

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.

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.

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.

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 :)

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

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.

hmm ... someone asks just how would you attack an encrypted Virtex part?

There are two problems, first the key is on the chip being protected with a battery, and second getting to the unencrypted bit stream that passes through the chip at one or more parts.

The key to attacking the chip would be to take one or more of the same chip and peel it apart to locate it's basic design, looking for the section of the chip where the 3DES engine is, the bit stream data path, and the muxes which switch the bitstream. Then decide where the best place to probe the clear text point is, and take a couple practice runs on a practice chip. Probing is very likely to require a non-contact solution if you can not easily reach a metalized trace with the clear text bitstream on it.

Then the fun part, stripping down a live part on a board with the battery backup intact to preserve the key, and using the knowledge gained on practice parts to uncover the probe point on the target device, and getting it to reconfigure while you tap into the target clear text bit stream.

Hopefully you can get your hands on two or three such devices just in case the first attempt has something very bad happen to the target device.

John,

And I hope someone tries it.

We intentionally placed these points (note the use of plural) that are in the clear where they would be the most difficult to get at.

Not because obscurity is security, but because the obscurity helps make the attack more expensive (to be successful).

Also, it is a flip chip device (since V4), so you need to dig in from the back side, through the active layer, to get to the probe points (note plural again). Cutting through some working devices that might be required would break it.

Finding the probe points will be loads of fun, too. Especially without schematics, or a layout. And the internal bus is not necessarily one bit wide (anywhere). So that will really challenge the attacker!

In fact it is documented that a config frame is 1312 bits in V4. Yes, there are 1312 wires from a register in the config logic to every frame across the chip. I can see someone probing 1302, 1303, 1304 .... oops! Lost the key again!

Of course, you might not need every decrypted single bit to then go back and break the encrypted bitstream. Maybe someone can answer how many decrypted bits you need to shorten the cracking of the encryption to a reasonable length of time...

Of course the decryptor is all hard logic (just like an ASIC decryptor), so if one had a few 3DES, or 256AES ASIC layouts, and schematics, from other chips, they could probably make some educated guesses to identify where the core is, but where the signals are will take some ASIC reverse engineering.

And, what is to say that the chip you are trying to crack doesn't have a design in it that is able to dump the keys (0 them, or even scramble them) if it detects that someone is tampering with it?

Folks that are serious about security think about all these things all the time (because they do them, and have had them done to them by others).

About this time, I think the attacker will be considering other methods of attack....which is all we needed to force them to do.

Aust> fpga snipped-for-privacy@yahoo.com wrote:

Who needs Moore's Law for obscurity? The way most HDL is written would make any hacker turn pale.

Even vendors' "model" code can be so bad you wouldn't want your name on it. In one example project, the code is claimed to be "...built such that both the software and hardware portions would be easy to understand...". On examination, the HDL is full of unexplained "magic" numbers and the comments gaze at each other through long-distance binoculars.

As for unwinding the compiled versions of other people's creations, surely life is too short, unless that's the only job you can get.

Me? I'd rather sign up at MacDonalds.

It would probably be fun to try as well, unfortunately I don't have access to a VLSI lab and prober :(

But for a $100K bounty I might be temped to purchase the toys on eBay :)

or getting very creative and drilling thru the BGA carrier, attaching wires to the standby battery bumps, and removing the carrier to get access to the process side of the die.

While iteratively etching/slicing and scanning the die is a lot of work, over the last 25 years high resolution image/pattern recognition (with FPGA assist) has gotten better and faster. Attacking a 20M gate or larger device would have to be largely automated. FPGA's are at a disadvantage because they are highly regular, so one is mostly looking for the irregular blocks. If I had a contract to do it, it's probably map several die with an automated process first just to make sure the automated etching/slicing and scanning process yielded the proper mask design. Then work at automated reconstruction of your cell/transistor library, and then fold it back to a high level description to identify the odd logic blocks. Since the configuration and 3DES core are probably larger than any other support block, it's probably not that hard to issolate, unless somebody really tried hard to hide it in the middle of the FPGA array highly distributed in area.

I've done security stuff on and off over the years, but I'm not a hard core crypto guy. About 20 years ago one company wanted me to sign an NDA for the security projects, which was very draconian, so I refused. After the team was done, and the security project was shipping I broke it in about 3 hrs with a logic analyzer ... which I expected a much better challenge for a VERY expensive security consultants fee for providing the design. Since security is one of those things where people are much happier ignorant, I just let it ride rather than pissing a bunch of blisful exec's dreams away.

There are a ton of horrible mistakes with security implementations ... my favorite is 802.112b WEP ... the security boys committee camel that was just a wet dream.

That is always the hope .... but making sure the security fence is the same height and durability all around the product is sometimes harder that one might first think.

I was going to add a related point but didn't think the post was going to go on.

I could have said that a small amount of good or bad code produces alot of ASIC or FPGA final result with the myriad of synthesis and P/R settings, the same code could produce zillions of different chips to reverse engineer ie most of it is noise and very little is interesting anymore.

When it was easy, the intent of the designer was often crystal clear and it was almost a pleasure to reverse and quite educational on a small scale, the layout was an exact reflection of the schematics and floor plan. The junior engineer looking at the masters work, but that was decades ago. Ofcourse before chip layouts were protected, many lazy semiconductor companies would blindly duplicate the works of leaders. Once automation set in, one is really looking up that tools rear end if one can see anything at all.

It is, and I don't think anybody really does it anymore, it has to be far cheaper to just hire similarly skilled people and design to same spec.

I'd rather die than do that.

John Jakson

snipped-for-privacy@btinternet.com wrote:

Actually, doing traditional coding is far more boring ... after a few decades even what appears a very different projects is writing the same old algorithms over again.

reverse engineering is more like jigsaw puzzles on steroids ... lot's of little pieces all the same "twisty windy little passages all the same". Learning to recognize algorithms, FSM's, etc allows you to abstract thru the clutter and rearrange the puzzle back into a clear picture without getting lost in the forest. Being able to see the adders, multipliers, fsm's, synchronizers and data paths as higher level objects allows you to cut thru the design more quickly and work with it at an abstract level more effectively.

For example, when we bid the 386 controller project twenty years ago, it was one of those projects nobody else wanted, and I took it on a lark because it was interesting and I had a couple college kids working for me that had never done reverse engineering before. All the client needed was the communications protocol along with a clean room description of how to write a control server for the machine. I took it fixed price, for a month, with a "no delivery, no pay" clause (as I do a lot of high risk projects). The next week a $100K machine showed up at my door step, and we moved it into our office. I thought we were really going to have to dissassemble a dozen eproms of 386 asm and sort thru a hand coded assembly design. So I did that first, taking the proms off the board, and disassembling them. Then I connected the HP1650B to the processor bus, and started tracing control flow for major activities. By the second day I noticed a regularity in the code blocks which indicated a higher level structure, and sure enough it was forth pop code functions. It took another day to reconstruct the forth execution engine, and another day to reconstruct the forth sources that we needed. and a few more days to reconstruct the design and provide the clean room design documents. It took another week to track down all the constants and variables in the protocol and document them. They came and picked the machine back up, and we got paid for a couple weeks of very fun puzzle playing.

Some people are challenged by deductive reasoning puzzles ... and others are clueless how to even get started. And even when shown, can never connect the dots.

Anyone here that has taken a contract to convert a schematic design to VHDL/Verilog yet?

same problem

I was in a project that rescued from HP a late 70s nmos chip and had to bring into the mid 90s, all we got were the original mask tapes in a dead layout language (with notes) and the old test vector tapes. We had to write the layout decompiler to get the hierarchy and leaf cells and turn those into crude schematics. SInce those were nmos transistor level, it was only really possible to do so with a knowledge of nmos design with bootstrapping and mostly pass logic, something the new cmos kids wouldn't have known about.

It was alot of fun and we did give HP back a new cmos Verilog source passing the same vectors so it should stay in production portable fashion as long as folks want arb waveform instrument boxes. At the time I never would have thought that I'd be doing nmos work again in the mid 90s. They also had a sin table in nmos rom but the std cell cmos had no rom, so got to replace that with an engine.

The problem with all these projects is the contract fee, you never know whether your are going to lose your shirt on it or just survive another day.

John Jakson

You've hit on the two factors that separate failing teams from those that deliver. The vision to invest in automated tools, such as your layout decompiler, and specialized knowledge of the technology area.

Fixed price contracting actually has some feedback rewards that way, you bid conservately enough after a few bumps not to lose your shirt again :) I find T&M far more risky, as the client is much too often to hold you to your initial time estimate, after increasing the requirements over the life of the project. With T&M you can not say no to design/requirements changes, and have less control over schedule expectations that result.

One of the most stupid things is to take a high risk fixed price contract while you are hungy. Creates a lot of pressure that is counter productive in making reasonable decisions about the project. If you get into trouble, you are quickly very frustrated and HUNGRY.

I normally bid them low ball based on best case with a very short time leash, and walk away if the project gets in trouble -- which is why the "no deliver, no pay" clause is critical. Out of several dozen of these contracts I've only walked away from one, and that was renegotiated a year later after several other teams had failed as well. I also had a year to sort out what went wrong and formulate a better attack on the project. I generally start those projects with a few 70-100hr weeks to bring them into perspective quickly ... the intense focus is for me worth several months of regular days, and very much needed to internally visualize the architecture of the problem early.

After that, I've found these projects pay well, and generate follow on work well worth the initial risk.

Nah, that wouldn't work - Austin would just claim they were counterfeit/grey market chips and therefore unsupported/somehow easier to crack.... ;)

-jg