00:00:00.667-->00:00:05.172 >> Um, thank you guys all for coming here, uh, bright and early first talk of the day. 00:00:05.172-->00:00:10.177 Track 3. Rockin' it. Um, this is our first speaker Jonathan. Uh, he is going to be, uh, 00:00:12.679-->00:00:16.683 presenting an introduction to the Witchcraft Compiler Collection. Um, I hope you guys 00:00:16.683-->00:00:21.688 really enjoy it. And, uh, I'll let him take it away. [applause] >> Good morning DefCon. It's a 00:00:29.229-->00:00:34.801 tremendous to be here with you, we gonna talk, uh, some bad ass reverse engineering hopefully. 00:00:34.801-->00:00:40.774 Um, as you saw we got some technical problems, but, uh hopefully with a bit of 00:00:40.774-->00:00:46.747 imagination we'll manage to see everything. Uh, so my name is Jonathan Brossard. I have a 00:00:46.747-->00:00:52.719 whole lot of a content to share with you today. So I'm going to start with the boring things a 00:00:52.719-->00:00:57.724 little bit. And, uh, hopefully we switch very very quickly to full demo stuff. Um, I cannot 00:01:02.629-->00:01:08.201 give like, you know the full feedback, I mean the full prerequisites and go through um, 00:01:08.201-->00:01:13.974 why everything works. So I'm gonna stick to the demos and try to outline like why the, ya 00:01:13.974-->00:01:18.478 know, the things which are little bit, little bit touchy work. Um, but I kinda assume 00:01:18.478-->00:01:24.584 that you already know about the ELF format, uh you familiar with POSIX and basically the more, 00:01:24.584-->00:01:29.323 uh, reverse engineering you've done previously the more I think you'll be appreciative to, um, 00:01:29.323-->00:01:34.328 uh, you'll be able to appreciate this talk. Ok, let's get started. So thank you very much, 00:01:41.935-->00:01:46.940 uh, for coming this morning. I know it's, uh, 10am. DefCon is starting so you should all be 00:01:49.409-->00:01:54.514 exhausted by now. The real motivation of this talk is to share with you, uh, a tool kit 00:01:54.514-->00:01:59.519 to do reverse engineering which really facilitates a whole bunch of things that I thought were 00:02:01.822-->00:02:08.562 impossible before even trying to do it. Um, so it's published under MIT license. I mean a 00:02:08.562-->00:02:14.401 Julia MIT MBA is the license 'cause I'm reusing components which were, um, already licensed 00:02:14.401-->00:02:19.406 this way. Uh and I would very much like if you um, contributed to this Witchcraft Compiler 00:02:21.742-->00:02:27.647 Collection. You don't have to be, you know very familiar with CO assembly to do this. As a 00:02:27.647-->00:02:33.186 matter of fact, you can write all the code you need on top of this framework using Lua. Or web 00:02:33.186-->00:02:38.725 programming language that stems from Lua that we created especially for this tool. Which 00:02:38.725-->00:02:43.730 I call Punk-C. Ok, so quickly who am I? Uh, so, to introduce me, uh, I thought it would be 00:02:48.568-->00:02:54.741 good to tell you about my love relationship with DefCon. My first talk ever was at DefCon 8 00:02:54.741-->00:03:00.380 years ago. It was on, um, um, BIOS vulnerability, physically we found a new class of 00:03:00.380-->00:03:05.786 vulnerabilities on the BIOS which allowed us to uh, POP using a single exploit to Crypt, 00:03:05.786-->00:03:10.791 BitLocker, McAfee Endpoint and a fair bit of, um, um, um, BIOS firmwares. Uh, then I've been 00:03:13.660-->00:03:20.400 rejected pretty consistently at DefCon until 4 years ago where I give this talk on Hardware 00:03:20.400-->00:03:25.238 Backdooring. This is a talk i really liked because I did it with the people who who 00:03:25.238-->00:03:31.711 engineered, um, um, an open source BIOS called Cobalt. And the reprotects of this talk was 00:03:31.711-->00:03:36.716 to work them uh we did this for our conference in Paris called "NoSuchCon Conference" and um, 00:03:39.119-->00:03:44.524 basically, they, they dropped the project and I bolstered it a bit and it ended up pretty 00:03:44.524-->00:03:50.630 pretty cool. The MIT technology review give me um, you know, give review on it and said, like 00:03:50.630-->00:03:55.368 that's a computer infection that can never be cured, even if you re-flash the hardrive, even if 00:03:55.368-->00:03:59.973 you change the hardrive or you erase your BIOS and things like this. Incidentally that's where 00:03:59.973-->00:04:06.246 my ex-teachers in engineering school stopped talking to me. Um, the thing also got, uh, 00:04:06.246-->00:04:10.984 featured in ya know, more mainstream press, uh, it got featured in Forbes, which is 00:04:10.984-->00:04:15.956 interesting. Uh, uh, they're pretty much the same feedback. I'd like you to post for a 00:04:15.956-->00:04:21.128 second imagine, like you know the kind of online present this gives me. Imagine, uh, you know, 00:04:21.128-->00:04:25.599 I meet, I get to meet a girl on Tinder or whatever and she Googles me and she's like, oh 00:04:25.599-->00:04:30.437 awesome, he's been on Forbes. Yeah, for writing malware, baby. [laughter] So I'm telling you 00:04:30.437-->00:04:36.877 I've been, yeah, pretty consistently rejected. That's a message to you if you submit to 00:04:36.877-->00:04:42.816 conferences. Being rejected is part of it. It's normal. It's completely expected. Uh, so 00:04:42.816-->00:04:48.555 stuff that didn't make it to, uh, DefCon, but that I presented at BlackHat, there was a pretty 00:04:48.555-->00:04:54.528 cool debugger I though. Uh, it's called PMCMA. You can find the code base online if interested. 00:04:54.528-->00:05:00.767 Basically the normal way works is um, you have one debugger who's debugging the debugee and 00:05:00.767-->00:05:06.506 you get a once shot. If you crash the debugee, like you have to restart everything again. So 00:05:06.506-->00:05:12.012 instead of doing this, my debugger was attaching to the debugee forcing it to fork, to 00:05:12.012-->00:05:17.417 replicate itself in memory, and then we'd work at on one fork at a time. That the routine you can 00:05:17.417-->00:05:22.422 see over there. Um, finally last year, we did a presentation with um, my team from Salesforce, um, 00:05:26.693-->00:05:31.298 we pretty much resurrected assembly relays and our contribution was to show that it 00:05:31.298-->00:05:37.304 doesn't work just on lands. It actually works from the Internet. Uh, I saw the schedule 00:05:37.304-->00:05:42.342 this year that were more talks on SMB at BlackHat, so uh, yeah, I hope we, uh, resurrected 00:05:42.342-->00:05:48.081 something. If you run, uh, Windows networks, you won't to watch this talk, uh, 'cause this 00:05:48.081-->00:05:53.086 is still unpatched and this is a 15 year version of Windows. Ok, this, uh slide is brought to you 00:05:55.622-->00:06:01.261 by the Security Vacation Club. What do you do once you've done all the work to um you know 00:06:01.261-->00:06:05.632 create a bad ass presentation and that you have massive content you'd like to share. 00:06:05.632-->00:06:10.971 Well, do it more than once. There's all this list of very cool conferences, uh, so Hackito 00:06:10.971-->00:06:15.475 Ergo Sum in Paris. I may be biased 'cause I created it. Hack In the Box in Malaysia which is 00:06:15.475-->00:06:21.915 really awesome, H2HC in Brazil, it's insanely good. SyScan in Asia, things like Shakacon in 00:06:21.915-->00:06:27.887 Hawaii, uh, I'm also part of the program committee of that one. Infiltrate in Miami. REcon in 00:06:27.887-->00:06:33.126 Canada. Only reverse engineering. Very Very cool. Kiwicon in New Zealand. Ekoparty 00:06:33.126-->00:06:37.998 in Buenos Aires, ZeroNights in Russia. So basically if you do all the work to create one 00:06:37.998-->00:06:42.869 presentation, I suggest you, you know enjoy your Security Vacation Club tour and give it 00:06:42.869-->00:06:47.307 to all those conferences. There's one left, I didn't put in the slides because it's a 00:06:47.307-->00:06:53.413 trap, it's called RuxCon in Australia. I was supposed to go there for one week to speak and 00:06:53.413-->00:06:58.418 I stayed 4 years, so it's a strap. Ha ha ha. Ok, a bit of disclaimer and then let's, let's 00:07:01.187-->00:07:06.192 go to the meat. Um, so my employer does not wish to be named even though I just did, 00:07:08.628-->00:07:15.268 um, they're not associated with this talk and this is my personal research. On the upside 00:07:15.268-->00:07:20.507 it means I'm free to, uh, share it with you. There's no intellectual property problem, 00:07:20.507-->00:07:23.977 but on the down side it means you wanted to reverse engineering and you're on your 00:07:23.977-->00:07:29.182 own. What do you do in this case? You call EFF to the rescue and before anything I'm going to 00:07:29.182-->00:07:35.322 ask you to give a big warm, um, um, you know, big clap to the people of the EFF, because 00:07:35.322-->00:07:40.327 they've been amazing. [applause] Thank you very much, I know some of them uh, uh, are talking 00:07:47.133-->00:07:51.705 today, so they're definitely around. Uh, if you manage to catch them like, you know, pay 00:07:51.705-->00:07:56.509 them a beer. 'Cause they're they're really helping us, uh we in situations like this where we 00:07:56.509-->00:08:01.781 cannot afford like you know legal advising and, um, if you do reverse engineering, the 00:08:01.781-->00:08:06.786 other nice fact that I suggest you check, um, the URL is on the slide. Ok, uh, so my employer 00:08:09.622-->00:08:16.029 doesn't want to be named, but he's recruiting. It's a bad ass security team. Uh, if you saw 00:08:16.029-->00:08:20.867 the attacks on like breach and things like this, data anonymizing, SSL, uh, Ravage, 00:08:20.867-->00:08:27.374 which was um, uh a very cool tool to provide Java. Well, the research we presented last year 00:08:27.374-->00:08:33.446 at uh, at BlackHat, uh yeah, feel free to decrypt those slides. I think we call, uh, the 00:08:33.446-->00:08:38.451 legal department and the PR department, are very unlikely to decipher this slide. [chatter] 00:08:41.187-->00:08:46.493 In terms of agenda, I'm gonna talk to you quickly about why I started this project. And why 00:08:46.493-->00:08:51.264 you know, it's relevant, hopefully. And then we're gonna do like some really serious 00:08:51.264-->00:08:57.370 black magic with the Witchcraft Compiler Collection. I show you, you know, what other main tools 00:08:57.370-->00:09:02.142 in it. I show you how to transform the shared library, like uh, like uh sorry, I'm 00:09:02.142-->00:09:08.448 gonna show you to transform an executable into a shared library. Ok. That that's not 00:09:08.448-->00:09:12.652 super supposed to fly, but that's super helpful when you do reverse engineering or exploit 00:09:12.652-->00:09:17.657 writing. Um, then we go further and we'll completely unlink, uh an ELF to recall, relocatable 00:09:20.193-->00:09:25.198 file. Um, and then we'll extend that and go be crazy. Ok. I don't get to see my slides. So 00:09:30.804-->00:09:37.110 it's a bit touchy for me too. Um, quickly. Let's imagine we're working on an application we 00:09:37.110-->00:09:41.614 don't necessarily have the source code. Honestly, even if you have it, takes time, like 00:09:41.614-->00:09:47.654 you know, to recompile things, um, possibly to adjust your tool chain. Um, you know, you have 00:09:47.654-->00:09:52.225 missing dependencies in things like that. You often don't have the right heaters and things. So 00:09:52.225-->00:09:56.796 working with source code is easy. I really like to work with binaries directly. As an 00:09:56.796-->00:10:01.801 example, um, I took a very old version of, uh, SMB, it's called smbserver-1.5.32. It's basically 00:10:04.270-->00:10:10.910 a predecessor of samba. So, um, if you do static analysis, that's a pet project I run on 00:10:10.910-->00:10:15.682 the side, um, with another company I work with full time. So I have two full time jobs, 00:10:15.682-->00:10:20.487 right. One with the company who doesn't want to be named, one with startup in France and I 00:10:20.487-->00:10:26.226 have so much free time, that you know, it allows me to, uh, uh, do more research and share it 00:10:26.226-->00:10:31.297 with you. So basically, that's a thing we run with our startup in France. Uh, you can, you can 00:10:31.297-->00:10:36.636 register for free. It's only for security researchers for the time being. It has four features 00:10:36.636-->00:10:42.175 that you can analysis, so you input your binary and you get back a bunch of tricks, um, on 00:10:42.175-->00:10:46.679 this slide like the more red you get, the better it is. You can see that it's picky, you know, 5 00:10:46.679-->00:10:52.018 different aggregated metrics. Without going into the details a bit, we're gonna care about 00:10:52.018-->00:10:58.091 today is like, ok, you can see that the binary for instance is compiled without ASLR. Uh, 00:10:58.091-->00:11:03.363 without Fortify hardening and things like this. But what we're really gonna look at is like 00:11:03.363-->00:11:08.668 finding proper vulnerabilities from this binary without choosing source code. One which 00:11:08.668-->00:11:13.673 looks pretty cool is, um, uh, the one with fopen right here, which is opening, um, I mean, it 00:11:16.643-->00:11:21.648 seems like it's opening, um, a file with a predictable name in write mode in slash tmp. Uh, see 00:11:25.585-->00:11:30.223 and the thing is running as root, it might be, you know, um, possibility for assembling 00:11:30.223-->00:11:34.794 attack and basically your local privilege escalation. The thing which is interesting here, is 00:11:34.794-->00:11:39.899 that we don't have a full back trace. So the way the tool works internally is like it does like 00:11:39.899-->00:11:44.370 you know, the compilation, I mean disassembly, decompilation, force the the static analysis on 00:11:44.370-->00:11:51.044 the binary. Um, uh, by using uh symbolic execution, rob the engine of cells. So it does it 00:11:51.044-->00:11:55.582 straight on binary. And a problem you come and you face when you, use advance techniques 00:11:55.582-->00:11:59.986 like this is that you don't have a full stack trace. So I have only a partial stack trace here. 00:11:59.986-->00:12:06.859 I'd like to verify this vulnerability to exist. Ok. Another way to do this, is, uh, 00:12:06.859-->00:12:12.966 to hear this problem is when you do fuzzing, like often, like in this case, the systic end from 00:12:12.966-->00:12:19.405 the BugZilla of, uh, RedHat, it's smb, which is, which seems to be crashing. Uh, we have only 00:12:19.405-->00:12:24.143 a partial stack trace. And the thing is actually bizarre, right? 'Cause it's not called 00:12:24.143-->00:12:28.748 from main, so we don't really know what's happening. What I know is that I don't want to 00:12:28.748-->00:12:33.920 call the whole thing by remote by sending packets. I'd like to verify the vulnerability exists 00:12:33.920-->00:12:38.925 by calling directly an arbitrary function inside the binary or inside a shared library. So 00:12:40.927-->00:12:45.765 that's all problems I've met today. I want to be able to call any function inside any binary 00:12:45.765-->00:12:50.737 without having to craft any patch which hits. And without necessarily going through main 00:12:50.737-->00:12:55.808 and what overlay your function and then reach it. I wanna be able to pull those functions 00:12:55.808-->00:13:00.747 directly. Ok, so here are the components of the Witchcraft Compiler. Um, it has, uh um, a 00:13:03.916-->00:13:10.890 linker. Uh which is a a bad ass tool. Which patches 1 one byte in binaries. But it's power is 00:13:10.890-->00:13:16.896 incredible, you're gonna see this. We got the, uh, WCC which is the core compiler, which is 00:13:16.896-->00:13:21.167 the tool which takes the binaries a part and gives you relocatable files that you can 00:13:21.167-->00:13:28.041 later on relink to generic new shared libraries or or relink against your own code and like, 00:13:28.041-->00:13:33.846 get new executables. And finally we have, the Witchcraft Shell, which is by far the most 00:13:33.846-->00:13:38.851 complex. It's a dy- a full dynamic interpreter inscripting engine. Uh built out of Lua. And 00:13:41.254-->00:13:47.193 uh, yeah, we gonna see that this is pretty cool. Um, this this shell you can write your own 00:13:47.193-->00:13:52.198 script. So an example of script, we gonna see today are WCC and WLDD. Let's go to the meat. 00:13:55.735-->00:14:00.373 Libification. So if you did one class of computer science and C programming, the first thing 00:14:00.373-->00:14:06.145 people tell you is that what we're going to do today is impossible. Let's start with the 00:14:06.145-->00:14:11.150 demo. I don't see anything. Yah, yah, I know you're not seeing this. Ok, Here we go. Ok, so for 00:14:40.780-->00:14:45.785 instance, um, to give you an idea of where where the state of the art of the compilation and 00:14:47.854-->00:14:52.859 why we're not gonna take this route. So, this is ilo dot c file, ok. And I'm going to show 00:14:56.529-->00:15:02.402 you the equivalent code generated by um, possibly the best decompiler you can get for 00:15:02.402-->00:15:07.507 free. It's called Snowman. It works in two mode, either on top of Vidar or it tells the mode we 00:15:07.507-->00:15:12.512 can run by itself autonomously, which is free. So, to give you an idea, like one, um, decompile 00:15:18.651-->00:15:23.656 this two lines of code program with uh, Snow, uh Snowman, you get something like this. Ok, so 00:15:28.027-->00:15:33.065 that the source code, which is supposedly equivalent. So if you take that path to decompile a 00:15:33.065-->00:15:39.372 real binary, let's take POFTPD for instance. It's 200-->000 line of code, ok. You gonna get about 00:15:39.372-->00:15:45.778 200-->000 times this. So decompiling this and recompiling this is not reasonable. Uh, if 00:15:45.778-->00:15:50.783 we, if we get it a try, just for fun, let's try to recompile the one from Snowman. I'm just 00:15:52.785-->00:15:57.790 gonna, um, grab the errors. Maybe. I don't see shit, ok, let let's drop this. I think you got 00:16:02.161-->00:16:07.166 the idea. Ok, so what's libification. Uh, basically we gonna take a another file, this 00:16:11.003-->00:16:16.876 is the main eater of the EF eater we gonna patch one byte. We gonna tell it, you not a, you 00:16:16.876-->00:16:22.081 not a binary, you not an executable binary anymore. Um, you're a shared library. So 00:16:22.081-->00:16:27.086 patch it from etexec to etgen. So let's do it with PrOFTPD for instance. Let me get this full 00:16:31.624-->00:16:36.629 sized. Can you guys see any of this? That flies. [applause] Yeah. Ok, so uh, as an example 00:16:43.369-->00:16:48.374 let's talk PROFTPD. And let's assume we don't have the source code. Let's copy to slash cmp. 00:16:54.580-->00:16:59.585 If we check the the type of the file. Um, ok it's using any LF executable, as in right here. 00:17:03.689-->00:17:08.694 I'm gonna use, uh wld, so the first tool from the Witchcraft Compiler Collection. It takes 00:17:10.963-->00:17:17.737 only one option, which is libify and then the name of the binary. So I'm gonna run this. And le- 00:17:17.737-->00:17:22.742 let's now check the type of this file. Ok, and surprisingly it's a shared object. Ok. But what's 00:17:27.213-->00:17:32.752 crazy now is that it really is a normal relocatable shared library that can carry, uh, that 00:17:32.752-->00:17:37.757 I can relink against my own applications. So let's check how to do this. Ok, so that was 00:17:46.265-->00:17:52.838 sample program which is gonna load, uh, slash tmp PROFTPD dot SO into memory so let's start 00:17:52.838-->00:17:57.843 with renaming uh PROFTPD we just patched into PROFTPD dot SO. It's gonna DL open it, so load 00:18:00.046-->00:18:05.051 it in memory which returns an and all which allows you to call dmcm and find the address in 00:18:08.854-->00:18:14.293 memory of any of the symbols in there. What I'd really like to call is this function called PR 00:18:14.293-->00:18:20.666 and this call version and this call get and this call string. Which returns inside PROFTPD the 00:18:20.666-->00:18:25.671 version of PROFTPD. So what's very crazy, let me show you the make file quickly. There's 00:18:33.245-->00:18:38.250 nothing very crazy ok. We just using a linker script to avoid gcc giving by default the same 00:18:40.586-->00:18:45.591 address to this program and to PROFTPD do SO so they do not collide in memory. So what I do 00:18:47.727-->00:18:54.433 is basically my demo is mapped much lower in, much higher, in memory to make space for this, 00:18:54.433-->00:19:00.039 uh, non-relocatable shared library. And what's very crazy is that thing actually works. 00:19:00.039-->00:19:05.044 Ok. So if you look up there it it truly returned like 1 dot 3 dot 3, which incidentally the 00:19:10.716-->00:19:15.721 version from PROFTPD, which we got from the shared library. Isn't this insane? Ok, um, so 00:19:21.494-->00:19:26.499 that's exactly what we just did. You can see that we really just patch one one byte in memory. So 00:19:30.202-->00:19:35.307 without going into ya know, the crazy details, uh, there's a couple reasons why this works. 00:19:35.307-->00:19:40.312 The first reason is that um, oh, I need to show you something else, which is very crazy. Is 00:19:43.649-->00:19:50.556 that, the the library we just patched is still a valued executable. That that is 00:19:50.556-->00:19:56.762 completely unexpected, right? So the reason it works the reason it's still a valued executable 00:19:56.762-->00:20:03.769 is that basically, the way we we uh, pushed full SLR in the Linux kernel is by allowing you to 00:20:03.769-->00:20:09.608 compile your binaries as a shared library and execute that any, execute them at any address 00:20:09.608-->00:20:14.613 in memory. Um, so yeah, you can have, you can have a binary, which technically a shared 00:20:16.649-->00:20:22.788 library. We gonna see that a bit more on this later. Um, the other thing, which is a bit 00:20:22.788-->00:20:28.094 crazy is that this newly recrafted like shared library cannot be remapped in memory, 00:20:28.094-->00:20:32.865 right? 'Cause it was never meant to be relocated that way. So we have a shared library, but that 00:20:32.865-->00:20:37.937 can only be mapped at a single address in memory. Um, this actually does exist in the 00:20:37.937-->00:20:42.975 normal world, um, it's called pre-linking. It's the fact of giving the base address to speed 00:20:42.975-->00:20:49.281 up booting essentially. Um, to shared libraries. And uh yes, so that's exactly what's happening 00:20:49.281-->00:20:56.188 in here. Ok, let's do a demo with, uh, Apache. I'm going to show you that, um, you can 00:20:56.188-->00:21:01.227 actually re-link against Apache, which is not a shared library, but pretend it's a shared 00:21:01.227-->00:21:06.232 library. Ok, so uh let's look quickly, uh at the source code. Ok, it does nothing crazy, it 00:21:18.144-->00:21:23.182 tries to call ap getserver banner. Which is a function, which is defining inside Apache. 00:21:23.182-->00:21:28.621 And to do this, we gonna link straight away against the Apache as if it was a shared library. 00:21:28.621-->00:21:30.623 So let's stop start play quickly. Ok, it's complaining. Boom. And if now I run this 00:21:30.623-->00:21:32.625 application, it's very crazy, that what it works. So Apache is not really a shared library, 00:21:32.625-->00:21:34.627 right? It's an executable, but it's compiled as ETDN. To have like full uh ASLR and if uh you 00:21:34.627-->00:21:39.632 re-link directly against it, you can actually call functions directly inside it. This is so 00:22:01.153-->00:22:06.158 amazing that I am attempting to end my talk here. [laughter] Ok, if you look at like the way um, 00:22:10.896-->00:22:17.203 you know, if if if you try to print like which shared library is uh this recursively, this 00:22:17.203-->00:22:23.509 application is linked with, you see that the first one is very much Apache and that looks very 00:22:23.509-->00:22:30.516 crazy but it works. Ok, let's go one step further, um, so this, this technique we just used is 00:22:30.516-->00:22:36.422 by far my favorite, because it's cross platform. It works across architecture and it's super 00:22:36.422-->00:22:41.827 stable. There's no such thing as like complicated analysis that might fail and stuff like that. 00:22:41.827-->00:22:48.667 Like all we did is patching one byte which you know, haha, incidentally is pretty reliable. 00:22:48.667-->00:22:53.372 If you wanted to go one step further and instead of transforming an executable into 00:22:53.372-->00:22:59.945 a shared library, go back to the uh operate of compiler before the the the application is 00:22:59.945-->00:23:04.884 linked, so we'll call this, um, unlinking. Um, well, we gonna use this tool called WCC. Which 00:23:06.885-->00:23:12.024 is a lot more complex and less portable and basically what it tries to do is recreate the 00:23:12.024-->00:23:18.564 relocations. Um, uh, that were missing from the final executable and add them to the 00:23:18.564-->00:23:23.569 them the binary so that you can relink it. So the normal way to um, to do reverse engineering 00:23:26.538-->00:23:31.176 and to solve this problem would have been this. Um, when you have uh compiled source code. 00:23:31.176-->00:23:35.347 You would use a decompiler, which is totally not what we gonna do. We just gonna go to 00:23:35.347-->00:23:40.753 back to the recolate- relocatable files and once I once I have the relocatable 00:23:40.753-->00:23:46.625 files, I be able to relink them again. So the common line is made so that there is zero 00:23:46.625-->00:23:52.831 learning curve. If you know to use GCC, it takes essentially the same parameters as GTC only 00:23:52.831-->00:23:57.836 it doesn't need source code as an input. It takes a binary. Ok. Uh, I'm gonna give you a demo on 00:24:02.808-->00:24:07.813 this. Ok. So I have, uh, a small file here, which is a small C file. And it has a whole bunch 00:24:25.631-->00:24:30.636 of relocations. Ok, it has a number of imports, um, it has strings, which hand the read 00:24:33.872-->00:24:40.245 read only data section. It has strings which are you know, passed as arguments, um, so 00:24:40.245-->00:24:45.250 yeah, it has it has pretty much all the type of application that do exist. I I you know, I, I 00:24:48.554-->00:24:53.559 share the source code so you guys um, can verify that, but essentially what we gonna do is 00:24:55.661-->00:25:01.200 first compile it. Then uh, so the the normal completion will give us a binary code small. 00:25:01.200-->00:25:07.639 Then we'll use the Witchcraft Compiler to go back to a relocatable file from this final 00:25:07.639-->00:25:13.612 binary and we'll relink it as another binary using GCC code small 2. And the question is 00:25:13.612-->00:25:20.119 like does small 2 actually runs, 'cause that would be very crazy. So let's compile it quickly. So 00:25:20.119-->00:25:25.124 if I run small, which is the original binary, it tells me something like "Hello from 00:25:27.893-->00:25:33.599 DefCon". You can see that WCC, so let's redo this manually actually. Let me re- redelete 00:25:33.599-->00:25:35.601 this. And this. Ok, so I start, I have only this small binary. I'm gonna use WCC the tool I 00:25:35.601-->00:25:37.603 just told you about. If I if I played stupid and I, I assume I want, uh, you know, if I wanted 00:25:37.603-->00:25:39.605 to use GCC, so I would like to do something like this essentially. Uh, until they give 00:25:39.605-->00:25:43.909 me um, you know small WCC dot O and I like it to be a relocatable file. If you run 00:25:43.909-->00:25:48.914 this like GCC gonna be like, I don't understand what you're trying to do. The input is not 00:25:51.884-->00:25:56.889 a, is not uh uh source code. But if you do with with WCC, it's gonna be like, yeah, ok. Let's 00:26:00.626-->00:26:05.631 do this. And it gives you this relocatable file, that then you can absolutely relink into small 00:26:21.780-->00:26:26.785 2. And what's amazing is that small 2, does the same thing as the original binary. [applause] 00:26:29.354-->00:26:34.359 This sounds very crazy doesn't it? So if you like it, I, uh, really like you to contribute 00:26:41.900-->00:26:48.440 back to this tool and extend it. For the time being it works mostly, uh on, uh AND64, I'm 00:26:48.440-->00:26:52.978 trying to put it on ARM. And the drawback as opposed to the first tool, which you know, worked 00:26:52.978-->00:26:57.583 everywhere because we were just patching one binary, here it's uh, it's a bit of work because 00:26:57.583-->00:27:02.454 we have to deal with all the type of relocations for all the type of CPUS. So I need your 00:27:02.454-->00:27:07.459 help with this. Ok, uh, I like to explain you one thing. Um, I choose so to architecture this, 00:27:13.532-->00:27:18.871 uh, the front end is basically libbfd. So it's like Arch Dump and tools like this or Arch 00:27:18.871-->00:27:24.877 Copy. Uh, which has a nice, I mean, the drawback is that it's not very precise. Uh, but the 00:27:24.877-->00:27:26.879 advantage is it works with many types of binaries, not just ELF files. So technically at this 00:27:26.879-->00:27:28.881 state, we can try to do very crazy things, like let's do Witchcraft baby. Let's try to 00:27:28.881-->00:27:30.883 transfer a p file into an ELF file. I'm running late, so um, I'll let you play with this at 00:27:30.883-->00:27:32.885 home, but that basically works. We have one problem here, it's like, I don't know what, what 00:27:32.885-->00:27:37.890 you're reading this with. Right? Um, so an idea would be to use, like the libraries um, shaped 00:27:56.508-->00:28:01.446 with wine which already give us uh, you know the Windows API compiled as an ELF file. This is 00:28:03.749-->00:28:08.954 left as an exercise to the reader. We gonna do something way more crazier right now. Can 00:28:08.954-->00:28:13.959 you run openBSD binaries like natively on Linux? I mean if you been to you know, if you've done 00:28:17.095-->00:28:20.966 a bit of engineering, like, that's not supposed to be possible. Like technically 00:28:20.966-->00:28:25.070 you're supposed to have a virtual machine. Let's do it without a virtual machine. 00:28:25.070-->00:28:30.075 Proper witchcraft. Ok, so we could do this um, manually and I'm gonna do it with a make 00:28:42.387-->00:28:47.392 file. Um, so the original binary, yeah. So here the original binary we gonna play 00:28:52.097-->00:28:57.102 with, um, uh, you can see that is very much an openbsd binary. Ok? The source code is trivial. 00:29:08.981-->00:29:13.986 It's basically this. So it's it's doing a bunch of print f in a row. Ok? Here comes the main 00:29:17.122-->00:29:22.127 file. Uh, fuck the display today. Ok. So we gonna copy the binary blah, blah, blah. Ok, 00:29:31.870-->00:29:37.275 basically there's a couple problems. The the dynamic linker is expecting to find, does not 00:29:37.275-->00:29:42.280 exist. So to show you manually, if I do, like, um, S trace on this particular binary, uh, that 00:29:47.653-->00:29:52.658 was not supposed to work actually, 'cause I already patched it. Ok. Um. Fuck. Ok, 00:30:04.736-->00:30:09.741 let's just run it, I'll explain how it works later. So basically the dynamic linker is not the 00:30:12.044-->00:30:17.049 right one. This is hard coded inside the binary. Inside the Intel printer section. I could 00:30:19.284-->00:30:24.289 patch the binary to put my own dynamic linker, instead what I'm gonna do is copy my real dynamic 00:30:26.625-->00:30:31.630 linker to the location is expecting the dynamic linker to be encountered. Ok. Right. Uh, 00:30:38.937-->00:30:43.942 so then it has a little bit of a problem. It's looking for libc which is called libc dot so dot 00:30:46.445-->00:30:53.018 62 dot something and my libc's not called like this. So I could patch the binary there again to 00:30:53.018-->00:30:58.690 link, to tell him like, no look at like libc I've got. But instead of this I could also 00:30:58.690-->00:31:05.397 copy the libc, my own libc, to the libc's expecting. And if you do all that, I share all the, 00:31:05.397-->00:31:10.802 the material also you can reproduce yourself. But essentially, fuck. Amazing. 00:31:10.802-->00:31:15.807 Haha. Ok, if you, uh, there's an a last problem, it's like, it has a missing dependency on, um, 00:31:20.679-->00:31:26.118 right if I try to run it now, uh, it has a missing dependency on atexit. So what we are gonna 00:31:26.118-->00:31:31.123 do is use uh, LD preload to uh, give him a uh, you know, a shared library with all the 00:31:33.191-->00:31:37.295 dependencies it's missing. Like atexit. We don't really care right? atexit is a function, 00:31:37.295-->00:31:42.100 which is called basically when you exit uh uh to call, um you know the constructor and things 00:31:42.100-->00:31:48.006 like this. So I don't really care. Long story short, if you look at the last line, you do a 00:31:48.006-->00:31:53.011 LD preload, you run this open bsd binary which has been slightly adapted inside, um, um 00:31:55.614-->00:32:00.252 a Linux machine. And it does print what it was supposed to print, which is also very crazy 00:32:00.252-->00:32:05.257 'cause there's no virtual machine. Uh, this was never supposed to work. Ok, now let's 00:32:07.425-->00:32:12.531 go to proper witchcraft, uh and I'm going to introduce you to a programming language that comes 00:32:12.531-->00:32:17.536 from basically uh, eli- um, I mean, uh, implementing a sort of reflection in C. Inside the Lua 00:32:20.572-->00:32:25.577 Interpreter. So what I'd like to do is basically to get um, reflection like features, but on 00:32:36.254-->00:32:41.293 binaries. Reflection is typically which only exists on the virtual machine, right? It 00:32:41.293-->00:32:45.497 allows you to load um, classes of binaries in memory and instrument them, like get um, 00:32:45.497-->00:32:47.499 get a bunch of information on them. Like what are you know, um, um, what type of argument 00:32:47.499-->00:32:50.435 they expecting and things like this and then to invoke them directly in memory. So I'd like 00:32:50.435-->00:32:52.437 to do that, but without a virtual machine, straight from binary. Um, so it's based on DL 00:32:52.437-->00:32:54.439 open, uh which is the function we used earlier to uh link with PROFTPD. You can, you can you 00:32:54.439-->00:32:59.444 can, ru- compile Lua jit, which gives you a just in time compilation memory. There's no 00:33:19.364-->00:33:24.436 big trace and it typically doesn't work like any, um, you know debugger you might have 00:33:24.436-->00:33:29.441 used before. I don't see the slides, so I'm gonna, I'm gonna go quickly on this. Uh and we 00:33:32.377-->00:33:37.382 gonna stick to the demos. 10 minutes. Ok. So it's time to activate. Ok, since I don't see 00:33:40.085-->00:33:45.090 the slides, I'm go- I'm just gonna run it for you, um, uh, ok. Ah. Ok, the dsmb server I 00:33:58.436-->00:34:05.010 get, I showed you earlier with the static analysis thing. So let's let's talk let's compare 00:34:05.010-->00:34:10.015 the smb, is it really there? Fuck that shit. Ok, nothing works, so. I'm gonna load like 00:34:14.586-->00:34:21.059 the PROFTPD binary with uh, patched before and I'm gonna um, ya know showcase you the 00:34:21.059-->00:34:26.064 capabilities of the WSH. So we just loaded it in memory. Um, it has a bunch of built in 00:34:29.601-->00:34:34.172 functions, when you don't know one of the functions, you can use um, you know, the app. Which 00:34:34.172-->00:34:39.177 is, uh, the only documentation you'll get in this respect. Ok, so um, let's call this function 00:34:44.182-->00:34:50.188 for instance... >> Hey everybody, is Jonathan doing good job? [applause] >> Thank 00:34:50.188-->00:34:55.193 you my brother. Thank you folks. Ok, I really wanna show you this because it's it's it's it's 00:34:59.531-->00:35:06.104 beautiful. So we can do crazy things like, uh, printing the section eaters. The [inaudible] 00:35:06.104-->00:35:12.410 would get from uh NN typically only this is dynamic and this is recursive over or the shared 00:35:12.410-->00:35:16.414 libraries inside your memory. This is a feature I always wanted, 'cause it's not built 00:35:16.414-->00:35:21.419 into GBD and it's always a problem when you're trying to do this. Uh, you can have the 00:35:21.419-->00:35:26.658 program eaters, you can look at like what are all the functions which are loaded right now in 00:35:26.658-->00:35:32.297 memory. Um, let me show you this first. You can, you can ask him to print what are all the 00:35:32.297-->00:35:37.335 libraries that you uploaded in memory. I just loaded PROFTPD, but that also loaded all it's 00:35:37.335-->00:35:43.441 dependencies. So if we look at like all the functions, that this has actually loaded in 00:35:43.441-->00:35:49.814 memory, there's a fair bit of them in a bunch of, ya know, libraries and we can now invoke 00:35:49.814-->00:35:55.587 them straight away. So ready, we got like 6000 functions to clear within memory. I don't even know 00:35:55.587-->00:36:00.458 the prototype, I know nothing about them. So let's look for instance, if there is a 00:36:00.458-->00:36:05.463 function, uh, which print the version or something like this inside PROFTPD. Ok, so uh, like 00:36:13.238-->00:36:18.243 before, we find this version call PR and this call version and this call get and this call 00:36:22.981-->00:36:27.986 number. I'm gonna print this inside, um, the variable. And if I print the variable, like 00:36:33.224-->00:36:39.864 before, uh, that's not what I expected. Uh, 'cause that's not the right one. Let's try with a 00:36:39.864-->00:36:44.869 string one. So like before, that's printing me internally the version [applause] Now, now, 00:36:52.944-->00:36:58.216 now, now, you've seen nothing, the real good thing, the real good thing is, um, uh, so the 00:36:58.216-->00:37:04.089 real better thing and why I took it out, I'm gonna try to activate. That you can have more 00:37:04.089-->00:37:10.028 than one return value. So I'm gonna, I'm gonna tell him, ok, I want a) the result of this 00:37:10.028-->00:37:15.033 function, but also give me a context. And now if I look at the context, it tells me a whole 00:37:19.704-->00:37:26.578 bunch of things is done. Um, I mean of the context of this execution. So that there's L 00:37:26.578-->00:37:32.250 number you know was 0. There's no segfault and stuff like that. I had not planned to do this, 00:37:32.250-->00:37:38.790 but let's do something crazy. Um. I mean, this allows you basically to build static 00:37:38.790-->00:37:44.295 analysis on top of uh, WASAGE very simply, I won't have to time to explain everything 00:37:44.295-->00:37:50.735 today. Uh, let's just say, we wanna test all the functions inside PROFTPD. I'd like you to 00:37:50.735-->00:37:57.675 fuzz them. And call them 100 times each. So it's gonna list all the functions in memory and 00:37:57.675-->00:38:02.614 what it's doing right now is like calling them. K? Ok, let's talk this for a sec. Dear God, 00:38:08.086-->00:38:13.091 I've been too ambitious. Ok. 100 times is too much. Let's run it like once. [laughter] And what 00:38:20.532-->00:38:25.203 happens is that it's recording all this stuff in memory and you can see them, uh, write FL. Ok, 00:38:25.203-->00:38:30.074 I don't have the time to see you all this, I don't wanna sabotage this talk, but uh, that's too 00:38:30.074-->00:38:37.015 bad. We're making time. Invite me to your local conference. Uh, yeah, I won't talk about this, I 00:38:37.015-->00:38:42.420 won't talk about this. Future work. What I'd like you to help me with, ya I know we are super 00:38:42.420-->00:38:48.059 late. Uh, so I think this is, uh a very cool base to do reverse engineering. There's a whole 00:38:48.059-->00:38:54.399 bunch of stuff I don't have the time to do, so uh, if you would like to participate, uh, get in 00:38:54.399-->00:38:58.670 touch. Do you have any questions? Or do you want me to stick to demos. Oh there is one 00:38:58.670-->00:39:05.109 thing I need to show you, because it's amazing. Uh, what if I wanted to analyze an 00:39:05.109-->00:39:11.115 un-binary on my Linux machine? So typically to do this, uh, there again you would need like, 00:39:11.115-->00:39:16.254 um, uh you know a full improviser and things like this. What I did is just cross combine 00:39:16.254-->00:39:21.259 my WSH shell to WSH Arm, ok? I've registered QMU in a web mode, um, to do me when I 00:39:27.966-->00:39:32.971 execute natively an unbinary on my machine, um, in memory binary translation so this is really an 00:39:37.175-->00:39:42.180 unbinary. I'm running on my own machine right now, and all we gonna do with this is load this 00:39:45.750-->00:39:50.755 lib Libec lx thing which comes from ARM. So it's complaining because some dependencies are 00:39:52.757-->00:39:57.562 missing. Typically you would do this inside a ch root, you have all the dependencies. But you 00:39:57.562-->00:40:02.400 can see that like before we have a bunch of functions and we can call them directly. Now let me 00:40:02.400-->00:40:07.405 show you something which is really insane. Uh, for instance, ok. Let's print, let me get my 00:40:09.974-->00:40:14.979 period. So that's my period and it didn't work. That's amazing. Hahaha. Uh, let's get it another 00:40:23.087-->00:40:28.092 way. I cannot get a shell, that's beautiful. Fuck. Ok, uh, I cannot wait another way, um, 00:40:35.266-->00:40:42.040 let's just look at like the libraries mapped inside memory. So my process is really a ARM 00:40:42.040-->00:40:48.513 process. It's loading an unbinary and it's running natively on Linux. The binary 00:40:48.513-->00:40:54.852 translation is also inside the same process. Thanks to QMU and the web mode it's using and it's 00:40:54.852-->00:40:59.157 all, all of this is just one program in memory. You don't need a virtual machine and you 00:40:59.157-->00:41:04.996 don't need all that garbage. And that facilitates a lot, like, you know the fact of sharing 00:41:04.996-->00:41:11.269 this tool or or even like unbinary and calling functions inside it, uh, from other 00:41:11.269-->00:41:16.274 application without any reverse engineering. Last but not least, I'm almost done. Uh, I told you 00:41:21.579-->00:41:26.584 smb server, I wanted to write an exploit for it. So let's do that quickly. We saw before that, um, 00:41:28.720-->00:41:34.092 uh, we wanted basically to call this particular function call reply close inside uh smb 00:41:34.092-->00:41:39.097 server. So we have the binary here, ok. So, let's do WSH of smb server. If I wanna call 00:41:45.036-->00:41:50.041 reply close, directly, I can. This segfault, by the way, this is amazing, um, uh, we get to 00:41:53.077-->00:41:59.884 that it writes, but we didn't decompile, we didn't p trace, we get that basically by writing a 00:41:59.884-->00:42:04.389 custom signal [inaudible] and passing [inaudible] like, you know, [inaudible] we can get out 00:42:04.389-->00:42:09.394 of it. Let's give it a couple arguments and let's see where it's crashing. Ok. So, right 00:42:15.800-->00:42:20.738 here it's crashing because right here the second argument as you can see is trying to write. So 00:42:20.738-->00:42:26.110 let's map something here. Ok, Lua strings are supposed to be immutable, but in proxy, which 00:42:26.110-->00:42:31.082 is, you know, what's happening in this script, you can break all the Lua rules. In 00:42:31.082-->00:42:36.721 particular, yeah, you can absolutely write two strings. So I'm gonna write to this string. 00:42:36.721-->00:42:43.060 It did reply close, ok. And it should remember like the static analysis we saw. Uh, this is 00:42:43.060-->00:42:49.867 supposedly creating a file in slash tmp with a predictable name which is G something. And 00:42:49.867-->00:42:56.174 you can see here that yeah, this file was actually created. And what's amazing here, is that we 00:42:56.174-->00:43:01.646 can verify results of static analysis with doing reverse engineering basically. And we 00:43:01.646-->00:43:06.284 can call any function we like in the stack trace, even we have, we don't have the full stack 00:43:06.284-->00:43:12.290 trace and even if we don't know an input to take up there. With this my friends, I think I'm 00:43:12.290-->00:43:15.126 done. Thank you very much for your attention today. [applause]