What is a fablab? It’s a workshop where a collection of computer-controlled machines enable people to build “almost anything” automatically. Fablab Aachen is such a place, and is part of RWTH Aachen (one of the biggest universities in Germany), from which it gets most of its funding. Indeed, the tools in this place really are expensive toys.

The place itself is only a small room in the “Informatik-Zentrum” of the RWTH, but it’s packed with tools. Among the most prominent ones are a laser cutter, a professional 3D printing machine and a CNC milling machine.

The 3D printer produces object of outstanding quality. It uses regular plastic wire (the same as in Reprap), however, the manufacturer is trying to make sure that only their wire (that they sell with a large profit margin) is being used in the machine. The wire cartridges come with a chip that prevents them from being refilled with inexpensive plastic wire. Unfortunately, the fablab people did not even try to hack the system for fear of breaking the machine. Come on!

The milling machine is mostly used to manufacture printed circuit boards. The only advantage over the traditional chemistry-based method seems to be that it’s fully automatic, which, for me at least, does not really justify the much increased cost and the relatively poorly cut copper (though this particular one produces a pretty good result). But it probably fits better in the “full automation” spirit of the fablab.

Anyone can use the fablab, including for commercial projects. The only two conditions are to cover the cost of the materials and to release the design files of your project under a free license such as Creative Commons.

Toile-Libre a besoin de toutes et de tous.

Pour participer au fonctionnement de l'association. Si la
compétence informatique est vitale à la fonction d'hébergeur elle
ne doit pas en être la seule composante. Participer à cela ne
demande pas uniquement d'avoir des connaissances techniques. En
apportant votre savoir-faire en matière de graphisme, d'ecriture,
de traduction, de gestion, ou toute autre chose, vous pourrez
continuer à faire de Toile-Libre autre chose qu'un repère de
geeks.

Toile-Libre, ne vend pas vos données personnelles, ne vend
pas non plus d'espaces publicitaires, et de manière plus générale
ne vend rien d'autre qu'un espace ouvert. Celui-ci est disponible pour
tou-te-s et a besoin d'une aide financière pour défendre une idée, une
idée de liberté. La liberté de communiquer sur une toile en étant
le plus autonome possible; mais cet engagement a un coût (achat
de serveurs, bande passante internet, électricité, ...). Cette aide peut
se faire sous forme de dons, mais mieux encore, en venant
partager un verre avec nous.

Défendre ces principes est difficile. Depuis quelques temps,
Toile-Libre rencontre des difficultés :
Des problèmes de trésorerie, une réquisition judiciaire qui
inquiète et génère des interrogations sur les obligations que
gènerent la fonction d'hébergeur, l'envie de modifier la
structure de l'association pour aller vers une organisation plus
partagée en mettant sur pied une structure construite autour
d'une responsabilité commune.

Dans cette optique nous organisons le 21-22-23 mai un Week-end Festif
auquel nous espérons sincèrement que vous participerez. Celui ci se
tiendra au 14-16 quai de charente, 75019 Paris.
Si vous avez besoin d'être logé pendant le week-end, contactez nous à
l'adresse contact@toile-libre.org

Au delà des festivités, une Assemblée Générale Extraordinaire aura lieu
le samedi 22 mai 2010 à partir de 14 heures.

Ce mail tient lieu de convocation

L'ordre du jour en sera le suivant :

- Rapports divers et variés
- Nouveaux Statuts
- Questions diverses
- Quelle orientation pour la suite ?

Le reste du week end sera orné de bouffe, apéros, concerts, et peut-être
même pièce(s) de théâtre, fanfare(s), ...
Tout ceci sera en ligne sur notre site et sur les différents médias
indépendants habituels.

L'avenir de Toile-Libre se lira dans la bière que nous partagerons.

I hate when applications go online without prior permission. What I hate even more is when they say that they will happily ignore you trying to disallow them to do so, just like the new 12.1 version of Xilinx ISE.

For those not familiar with Xilinx software, Webpack is the free of charge license of their design tools, that supports a limited range of devices. The Webtalk “feature” phones home every time you generate a programming file for their devices, and previous versions of ISE asked you whether you wanted to send Xilinx information about your design. What is new in version 12 is that Webpack users are forced to enable Webtalk, and even users of the paid version will have information about their designs sent to Xilinx should they use a device included in the Webpack license!

Fortunately, there is a simple and expedient solution to this problem. As it turns out, the Xilinx software people prefer to spend time trying to invade their customers’ privacy instead of making their tools easy to install (i.e. by providing packages for Linux distributions). Thus, ISE comes with its own version of the cURL library, that is used for the Webpack “feature”. Therefore, cutting off ISE’s internet access and thereby solving the Webtalk problem as well as potential others is as simple as doing:
rm -f /usr/Xilinx/12.1/ISE_DS/ISE/lib/lin/libCurl_Curl.so
rm -f /usr/Xilinx/12.1/ISE_DS/common/lib/lin/libCurl_Curl.so

Even though no one managed to find the correct passwords of the HES2010 FPGA reverse engineering challenge (maybe time was too short), we still congratulate Eric Rannaud who came up with an expertly designed method and very interesting conclusions. He wrote:

At first, I only worked with the binary tarball, and only had a look
at public/ later. I’m not entirely sure why, as I did read about the
sources in the announcement, but I only got around to look at them a
while after that. This made the beginning of the challenge more
entertaining I suppose.

I ran strings on bios.bin, found the “Access granted!…” string,
looked in the disassembly bios.bin for a use of that string’s address,
and a few instructions before that, found the addresses for the
security module registers on the CPU bus.

For level2, I converted the NCD to XDL, which is a much nicer text
version of the NCD. It’s the netlist at a gate level (so it’s somewhat
big and you can get confused or lost, as I probably was — even though
I did use a script to extract the passwords… oh, well). XDL is still
a somewhat unwieldy format, relying on a lot of implicit details
regarding the hardware primitives on the FPGA, so it can be a bit hard
to interpret (all these details are essentially specified in the
Spartan 3 user guide, with a couple of errors and ambiguities).

I located the two 32 bit comparators for pwd1 and pwd2 (the XDL
contains names derived from design wire identifiers, something like
“security/pgood2_cmp_eq0000_wg_cy<1>“). They are built with a bunch of
LUT4 chained with a fast carry-chain. The LUT equations are such that
the output is 1 only when the 4 LUT inputs match 4 bits of pwd1 or
pwd2. There are several possibilities at this point:

1- You figure out pwd1 and pwd2 from the LUT equations, then pass them
to the software. That led to my previous email. Even though I got it
wrong, that should be pretty straightforward.
2- You follow the outputs of the comparators back to the CSR bus,
figuring out the secret by looking at the logic between pgood1 and
pgood2 and the bus port. Your “bus <= {32{pgood1 & pgood2}} & secret"
trick made the synthesized logic a bit tricky, with some folding and
maybe physical synthesis obscuring things a bit. I had a look at that,
but stopped after (I think) figuring the logic for half the bits of
the CSR bus port, i.e. half the secret bits.

Ideally, you would want an XDL simulator: you excise a subnetlist of
the XDL by extracting the graph between the bus input port and bus
output port (dropping all the other logic). You feed the stimuli
corresponding to two writes at the addresses found in bios.bin. Then,
you follow the activity in your simulator to find the location of the
comparators, then you either find the equations, or your simply
monitor pgood1 and pgood2 (separately): you only need to try up to 2 *
2^32 possibilities (instead of 2^64), which with a fast enough
simulator should be feasible (as you only simulate a small subset of
the design).

The advantage of such a (local) simulator is: (i) much easier to see
what's going on as a program does the work for you, (ii) had you used
a much trickier type of password matching device (hash({pwd1, pwd2})
== known; or say, pwd1 and pwd2 is a sequence of bits used to put a
large LFSR in an initial state, then run it for a while, then check
128 bits of the LFSR output for a given sequence), being able to feed
any stimuli you want to a black-box, with the ability to observe any
wire in it, lets you progressively replace know parts with
higher-level code that you can comprehend.

Anyway, with more time (or a faster brain), level2 is quite feasible,
even without any Verilog or C code.

For level5 my approach was going to be the following.

As I know about the two 32 bit comparators, and that they are
synthesized in a pretty obvious way (two long fast carry-chain with
LUT equations in a special form -- i.e. only one input out of 16 gives
an output of 1, or "popcount(eqn) == 1"), it should be relatively easy
to locate the comparators in the device.

As long as the device is not too full, ISE uses a carry-chain with a
constrain to adjacent slices. Locating the LUT configuration bits in
the bitstream, for each LUT in each slice, is a fairly straightforward
task. You can use XDL to force a given physical LUT to be set at
0x0000 and 0xFFFF, say -- only 16 bits and a couple of CRC change in
the bitstream. By looking for the LUT equations with "popcount(eqn) ==
1", you get a list of 4 bit values (such that "lut4(eqn, value) ==
1"). You then have several approaches:

a- If that list of 4 bit values is small-ish, assume that the
synthesizer kept the same grouping of bits per LUT as in level2 (i.e.
one LUT matches candidate_pwd1[3:0], another matches
candidate_pwd2[11:8], etc.), then there are only so many possible
combinations of fixed 4 bit values to form a 64 bit word, (64/4) out
of size_of_the_list. You try all these passwords through the software.
b- You rely on the fact that the comparison LUTs must be next to
each to others to get a smaller list (e.g. any isolated LUT with
popcount(eqn)==1 can be ignored).
c- Figure out the bits controlling the carry-chains (again using
XDL). Find enabled carry-chain in the device (there should not be that
many), correlate that with the ideas of a. and b.

If you didn't have the information from level2, or if XST made
different choices than in level2 regarding synthesis decisions, your
pretty much have to know something about routing configuration in the
bitstream (so far, we didn't need anything like that).

The software released by Jean-Baptiste Note a ulogic.org does not
support Spartan 3A. So you either need to add it (should not be too
hard), or you start from scratch. In any case, this work likely takes
more than 48 hours. But it is tractable.

From this you can:
1- Extract some kind of netlist. You don't need everything, enough to
get close to a partial XDL-like around the CPU bus. To find the CPU
bus, follow the outputs of the only 32 bit 1-cycle adder in the design
(look for the longest carry-chain)... you rarely have more than one of
these.
2- More fun, you alter the bitstream to reroute some of the values
coming from the comparator outputs either back to the bus or to
external pins. Then you need to test 2^33 values (the speedup comes
from the fact you can observe pgood1 and pgood2 independently, as
opposed to only "pgood1 & pgood2" -- you guess two independent 32 bit
values, not a single 64 bit value). Depending on the system clock and
the speed of the software, that should take a few hours.

In my view, most of the difficulty in this type of task comes from the
sheer size of the netlists, not really from the obscurity of the
bitstream. The work at ulogic.org pretty much deals with that.

Download here the files for the challenge:

• Binaries (what you have to crack!)
• Sources (with different passwords) + other info

and see the description of the levels below! Do not miss the presentation at 14:00…

LEVEL 0
When the bitstream is loaded, the FPGA expects a 16-bit password which is shifted bit per bit using two pins. If the password is good, you are rewarded with an Arduino-style LED show. The participants will have to discover this password. This level is solvable using common techniques and is intended to give a rough overview of how FPGAs work in practice and what hardware security is about. Participants who think it’s trivial are encouraged to skip it and proceed directly to level 1.
Participants are given the bitstream, the NeoCAD Circuit Description (NCD) that they can examine with FPGA Editor, and the Verilog source code (of course, with a different password).

LEVEL 1
Same as Level 0, but this time, the password is 64-bit. Participants are given the same files.

LEVEL 2
This time, the security device is embedded into a complex system-on-chip (based on Milkymist [6]) comprised of a microprocessor, memories and serial port – all implemented on the same FPGA. A software program run on the FPGA softcore processor will talk to the security device and send it a password to make it reveal a built-in secret information. Participants will have to find out that secret. This level is harder than the previous one because the security device will be buried among thousands of FPGA logic cells comprising the system-on-chip and connected to it through an on-chip bus.
Participants are still given the NCD file and the source code, making the task significantly easier.

LEVELS 3-5
They are the same as levels 0-2, but without the NCD! (and different passwords of course).
Those are obviously the most interesting levels, as when you are working with a real security system, they will never give you the NCD. Reverse engineering bitstreams involves good knowledge of the FPGA’s internal structure (the previous levels should have gotten you some of this), mastery of Boole algebra and logic functions manipulations, and expertise with file format reverse engineering. There is an existing effort [8].

REFERENCES
[1] http://www.cl.cam.ac.uk/~sd410/papers/fpga_security.pdf
[2] http://spectrum.ieee.org/semiconductors/design/the-hunt-for-the-kill-switch
[3] http://www.xilinx.com/products/devkits/aes_sp3a_eval400_avnet.htm
[4] http://lekernel.net/blog/?p=668
[5] http://lekernel.net/blog/?p=429
[6] http://www.milkymist.org
[7] http://www.milkymist.org/wiki/index.php?title=Installing_the_Spartan_3A_evaluation_kit_mini-port
[8] http://www.ulogic.org
[9] http://lekernel.net/blog

Hackito Ergo Sum – Paris, April 8-10 2010
http://www.hackitoergosum.org

SRAM-based FPGAs are often touted as being “secure”, in the sense that a design for which only the programming file (“bitstream”) is available cannot be analyzed [1]. Many security features are built on this assumption: anti-cloning protections for hardware, evaluation versions of FPGA designs (IP cores) that stop working after a few hours, …

This security relies on the fact that the bitstream format, despite being unencrypted, is largely undocumented and proprietary and even assuming perfect understanding of the format, recovering a design’s netlist from the information contained in the bitstream solely is a daunting task.

Many security researchers believe that security through obscurity does not work. Could FPGAs prove them wrong? Could obscurity be, for once, an effective means to achieve security? In this case, what would prevent an attacker with knowledge gained from the FPGA manufacturer from injecting malicious code into your sensitive bitstreams without fear of being discovered?

In a world where concerns about hardware security are growing (two years ago, the DARPA launched a challenge where people were supposed to discover malicious insertions made into chips [2]), we will challenge these questions at Hackito Ergo Sum.

You are given bitstreams implementing security features, and your role is to break them. Even though they are significantly simpler than the security systems commonly found in the industry, the basic technique should be essentially the same especially for the last levels of difficulty. The very last one is close to what a real system would look like!

In the first levels, you have more information than the bitstream only, in order to ease your job and give you an insight about what needs to be done in the next levels. Furthermore, there will be a workshop at the beginning of the conference to get you acquainted with some FPGA tools.

THE WORKSHOP
A hands-on workshop will be given at the beginning of HES and shortly after the challenge begins. It will revolve around three subjects:
1/ logic design crash course.
2/ how an FPGA works internally.
3/ how to build a FPGA system-on-chip and how to connect a new peripheral (such as the security device) to an on-chip bus.
This workshop is merely a digest of the previous workshops at /tmp/lab [4] [5].

LEVELS
There are 6 levels of increasing difficulty. They will be announced at the same time as the files for the challenge are posted.

RULES
* Complete files for the challenge will be posted to my blog [9] on April 8th, 10:00 local time.
* Mail the answer(s) to the level(s) you have solved to seb AT tmplab DOT org before April 10th, 18:00 local time.
* You can work alone or in teams.
* You have to explain how you found the answer(s).
* Breaking into my computer is cheating and gets you disqualified. Don’t do it.
* If you do not want to waste time fixing libraries, installing virtual machines, downloading multi-GB files, etc., install Xilinx ISE Webpack before coming and make sure that it works (it rarely does the first time), including the fpga_editor command.
* All bitstreams can be tested on the cheap Avnet Spartan 3A Evaluation Kit [3], making the challenge accessible to everybody. A comprehensive list of commands to perform various operations on this kit is given in [7].
* Some kits are available for lending during the conference, in exchange for a deposit of 70 euros which will be given back to you when you return the kit in good working condition.

REFERENCES
[1] http://www.cl.cam.ac.uk/~sd410/papers/fpga_security.pdf
[2] http://spectrum.ieee.org/semiconductors/design/the-hunt-for-the-kill-switch
[3] http://www.xilinx.com/products/devkits/aes_sp3a_eval400_avnet.htm
[4] http://lekernel.net/blog/?p=668
[5] http://lekernel.net/blog/?p=429
[6] http://www.milkymist.org
[7] http://www.milkymist.org/wiki/index.php?title=Installing_the_Spartan_3A_evaluation_kit_mini-port
[8] http://www.ulogic.org
[9] http://lekernel.net/blog