Brussels 2017.

All right. So let's start. OK. So the main constraints about this talk and this project in general was that there was a need to have no vendor tool, part, device, documentation, stuff like that specific

so that people could just work without having to work around an NDA or having to, you know, being able to share their findings. And of course, to have that in a more

infosec friendly environment and not having to have a PhD degree in electrical engineer to figure out what an FPGA and what the tools do. So FPGAs right now are really a hot topic.

I mean, with the recently Amazon going clouding the FPGAs, we've had recently the Project Ice Storm that made a huge buzz in the hacking community and FPGAs

all together. But it's very poorly explored territory. I mean, most of the stuff as it is right now depends on the tools provided by the vendors, except for, well, Ice Storm.

So their security mostly relies on security through obscurity. And there's a very big, it's all about the paradigm of it's protected because it's forbidden.

So yeah, all right. All right. So it all started out as a proof of concept. Some ideas I've had back in, I think it was 2012 or 2013.

And I was talking with Hugo and Sam at some recon, and we were drinking beer. And it's like, hey, you know what? I've had this friend who had reversed some bit streams.

I was like, well, I doubt it. I never seen this paper. I mean, I've been reading about it all the time and never came out in my search. I was like, well, you should see it. So I go, test a bunch of stuff, finally get around to read the paper.

I was like, OK, that sounds interesting. I'm going to try it out, implement the proof of concept. But this was not vendor neutral. This was very relying on a specific vendor tool. And there was very few alternative to build on. So there was either going with VTR or Project IStorm.

But the thing is, when I went and looked at it, Project IStorm, it's middle stuff before going into an actual bit file. It's a partial bit file. So if you want to analyze that, you're

starting off way too deep into the process. So I decided, OK, well, I'm going to go with VTR and re-implement a bit gen. So VTR, it's called Verilog to Routing.

It's very legacy major project by academics, for academics. It's mostly used as a comparative unit within the software development people. So they usually go, oh, so we tested our algorithm.

And so it's, let's say, 70 times faster than the best time you can get with VTR. So since it's not vendor specific, everyone in the community can use that to benchmark.

Its main selling point is it's open source. So, but at the end of that, I still need to reverse a configuration file. But there's not that. It's missing. Like, you have to do it.

And the thing is, you can't even parse the routing configuration it gives you at the end. So I'm like, OK, well, this is a bit of work. So here came Putin. So Putin was to provide this final step in VTR to use all this configuration data, all the thing it made,

the architecture definition and everything, and just do the Putin, you know? So it was coded within the last month. And it set back the project, the reverse engineering of the bit files quite a bit, because I

didn't expect to have to write so, so much code and to have to reverse engineer all the VTR project itself, because, well, it's so well documented. And here's a code from one of my co-workers.

It's like, you know, when everything is hopeless, decisions are really easy to make. So here it is. It's not done yet. So as I was going for the past few days, like, just trying to add more code and everything just keeps breaking up.

So yeah, I'm sorry about that. There. This was well delivered. So the forget the norm, because yeah, OK,

I talked about making these configuration files. But hey, this is recon. There has to be some reverse engineering here. So the thing is, all this stuff is based on the PhD thesis of Edson, the thesis called

Jitson Thesis on Signings of PGAs. But the guy is computer science. So nobody really cares about computer science and electrical engineering. Well, very little. So the main goal of the project was to do some scheme acceleration on the FPGAs.

So you would use the power PC provided inside the FPGA to run the scheme, and then just in time compile the hardware and run the thing on the hardware. But the thing is, partial reconfiguration depends on the tools of the vendors.

So there's no documentation. There's actually very little documentation on what all these bits mean, and how do you configure, and what did you do. So it's like, well, no problem. I'm going to do some computer science with artery

and just solve the problem. Because I have a paper to present. And if I can get work around the NDA, because the NDA sort of blocks me from just putting all the libraries into IDA

and just look at it, because there's probably little obfuscation there. Well, you can't do that. So it's like, okay, I'm going to find another way. So this is the interesting part of it, is it came out with a logarithmic time

way to map the configuration, let's say human readable configuration to the actual bits, their meanings. So let's start off with a simplified version

of log mapping. And of course, I've forgotten to add the result there. Cool. So, okay.

So here, X and Y represents some configuration, some, it's how the programmable point can be configured.

So it has two values, X and Y's. And so we change these values to try to match them outside. So yeah, the next one is with face correction. So it's the same thing, but now you have the values.

And now I can show you what this is really about. So when you go from X to Y, okay, you see the bits, the results there happening. So this is what you would see in a bitstream or a bit file.

So the zero, the one, so they're all column. So the column are the configuration vectors and the columns to the right are the configuration results, the encoded version of it. So as we're toggling, sometimes you have,

like the bits can be active high, active low, hard ones, hard zeros. So this is a way to find, like if you toggle from all X's to all Y's, you can see the face of your bits

and then move on to do the actual mapping. So this is where you go, the X, X, Y, X, X, Y, Y, Y. This is actually just from the top. You could see it as zero, zero, one.

Well, zero, one, two, and three. So, and then each sort of configuration point gets its own number and gets mapped at the end. So this is really crappy. I thought I would have a mouse or something.

Okay, it's going bad. Thanks, do we see the mouse? Yeah, thanks, cool. So here, okay, you see that the face is very aligned with our X, Y thing.

And so one and zero would map to this green one here. And zero, zero being here, it's also face aligned. So zero, zero maps to this one. And here we have a face inversion happening.

And so zero, one does not map to the zero, one here, but to one, zero, if you can understand that. And so also there's multi-values. So when you go into FPGAs, things are not just lookup tables where you have binary values.

There are so some routings that are mocks, actually, to set which wires drives another wire. So these are mocks, and you have to, like, find a way to match these multi-values

to an actual point in address set. So from here, okay, you see this point here has three values so it needs at least two bits to be able to encode all these states.

So this is the interesting part here. So the vectors here being encoded goes to, okay, so three full transition from X, Y, and Z.

Since all the others are just, just have two states, while this one has three, I just decided to, like, Y all the others. So from here you can get the face alignment

that we were looking for in the previous slide. And while, so here this X, Y thing is phase aligned and also sort of phase align X to Z.

So then I thought, okay, let's stop that with Project Slouch,

which is sort of an homage to Ice Storm. Slouch is in Montreal talk for either the slush or the semi-melted snow mixed with mud thing on the side of the road. So this is what is supposed to be my,

the thing that does the reverse thing. So first off it was a proof of concept, made targeting vendor tools as I said, but the thing happened that I got employed by a major FPGA company.

So it just got way too risky for me to just leave it out on GitHub. So I needed a more generic non-vendor tool and I didn't want to go through the problem of just re-implementing the tool for each different architecture they come up with each,

well, year. So the motivation behind this was to actually provide some tool for verification because as it is right now, there is no tool to see if there is a difference between what you wanted and how it was encoded.

So let's say someone was to cheat and change out the bitstream and the configuration file was generated. Well, no one could, you'd have to trust the tools that no one just went there and changed all the libraries

or whatever does the encoding. So there's no way to verify back is what you wanted really in there. And it was needed to give a space and the tools to do talk about the VLSC reverse engineering.

So are there any question? I know, I think it was scheduled to be a one hour but yeah, any question?

Yeah, no. Okay, well, I think that's a wrap. So the main motivation behind this was really to get people started and get tools

to actually make a competition. That's my goal to get something by the end of the year. But I mean, with the project in the state it is right now, well, we'll have to see. So thank you for listening and I hope you actually learned something.

And well, check me out on GitHub and everything, so thanks.