Um, thank you guys all for coming here. Uh, bright and early first talk of the day, track
three, rockin' it. Um, this is our first speaker, Jonathan. Uh, he is going to be, uh,
presenting an introduction to the Witchcraft compiler collection. Um, I hope you guys really
enjoy it. And uh, I'll let him take it away. Thank you very much.
Good morning, DevCon. It's a tremendous pleasure to be here with you. We're gonna talk
about, uh, some badass reverse engineering, hopefully. Um, as you saw, we got some
technical problems, but uh, hopefully, with a bit of imagination, we managed to see
everything. Uh, so my name is Jonathan Brossard. I have a, a whole lot of, uh, content to
share with you today. So I'm gonna start with the boring things a little bit. And uh,
hopefully we switch very, very quickly to, uh, full demo stuff. Um, I cannot give, like,
you know, the full feedback, uh, I mean, the full prerequisites and, and go through, um, why
everything works. So I'm gonna stick to the demos and try to outline, like, why the, um, you
know, the things which are a little bit, little bit touchy work. Uh, but I can assume that you
already know about the ELF format. Uh, you're familiar with POSIX. And basically, the more, uh,
reverse engineering you doubt previously, the more I think you'll be appreciate to, um, uh,
you'll be able to appreciate this talk. Okay, let's get started. So thank you very much, uh, for
coming this morning. I know it's, uh, 10 a.m. The afternoon is starting, so you should, uh, all
be exhausted by now. The real motivation of this talk is to, uh, share, uh, uh, some of the, uh,
features of POSIX. Uh, I'm gonna share with you, um, a new toolkit to do reverse engineering,
which really facilitates a whole bunch of things that I thought were impossible before even
trying to do it. Um, so it's published under MIT license. I mean, a dual MIT and BSD license,
cause I'm re-using components which were, um, already licensed this way. Uh, and I would very
much like if you, um, contributed to this witchcraft compiler collection. You don't have to be, uh,
assembly to do this. As a matter of fact you can write all the code you need on top of this
framework using Lua or web programming language that stems from Lua and that we created
specially for this tool which I call Punk C. Okay so quickly who am I? Uh so to to introduce
me uh I thought it would be good to tell you about my love relationship with DEF CON. Uh my
first talk ever was at DEF CON 8 years ago. It was on um um BIOS vulnerabilities. Basically
we found a new class of vulnerabilities on the BIOS which allowed us to uh pop using a single
exploit, TrueCrypt, BitLocker, McAfee endpoint and a fair bit of um um um BIOS Firmwares. Uh
then I've been rejected pretty consistently at DEF CON until 4 years ago where I gave this
talk on uh hardware back drawing. This is a um a
talk I really liked cause I did it with the people who engineered um um an open source BIOS
called Corboot. And the real pretext of this talk was to work with them uh we did this for our
conference in Paris called No Such Conference. And um basically uh they they dropped the
project and I pursued it a bit and uh yeah it ended up pretty pretty cool. The MIT uh
technology review gave me um you know gave a review on it and said like that's a computer
infection that can uh you know cause it can uh you know cause it can uh you know cause it can
never be cured even if you reflash the hard drive even if you change the hard drive or erase your
BIOS and things like this. Incidentally that's where my ex-teachers in engineering school
stopped talking to me. Uh the thing also got uh featured in you know more mainstream press. Uh it
got featured in Forbes which is interesting. Uh they had pretty much the same feedback. I'd like
you to pause for a second and imaging like you know the kind of online presence this gives me.
Imaging uh you know I mean I get I get you know I get you know I get you know I get you know I get
to meet a girl on Tinder or whatever and she Googles me she's like oh Osome, it's been on
Forbes. Yeah for writing malware baby. So I'm telling you I've been pretty
consistently rejected. That's a message to you if you submit to conferences, being rejected is
part of it. It's normal. It's completely expected. Uh so stuff that didn't make it to uh DEF CON
but I presented at BlackHat uh that was a uh a pretty cool debugger I thought. Uh its called PMCMA, you can find the 데� resistor. That's it. And they have yeah I took manager мои 내�
ember ges 재� цел하고 나
sciences and mana했어
the code base online if you're interested. Basically, the normal way it works is um you
have one debugger who's debugging a debuggy and you get a one shot. If you crash the
debuggy, like you have to restart everything again. So instead of doing this, my debugger
was attaching to the debuggy, forcing it to fork to replicate itself in memory and then
we'd work at on one fork at a time. That's the routine you can see over there. Um finally
last year we did a presentation with uh my team from Salesforce. Um we pretty much
redirected SMB relays and our contribution was to show that it doesn't work just on LANs, it
actually works from the internet. Uh I saw on the schedule um this year that there were more
talks on SMB at Black Hat, so uh yeah I hope we uh redirected something. If you run uh Windows
Networks, you want to watch this talk uh cause this is still unpatched and this is affecting
every version of Windows. Okay this uh slide is brought to you by the Security Vacation Club.
What do you do once you've done all the work to um you know create a badass presentation and
that you have massive content you'd like to share? Well do it more than once. There's all
this list of very cool conferences. Uh so I came to Argos from in Paris. I'm a bit biased cause
I created it. I came to Box in Malaysia which is really awesome. H2HC in Brazil is insanely good.
Uh things like ShakaCon in Hawaii. Uh I'm also part of the program committee of that one.
Infiltrate in Miami. Recon in Canada. Only reverse engineering. Very very cool. KiwiCon in New
Zealand. EcoParty in Buenos Aires. Zero nights in Russia. So basically if you do all the work to
create one presentation, I suggest you you know enjoy your Security Vacation Club tour and give
it to all these conferences. There's one left I didn't put in the slides because it's a trap. It's
called Raxcon in Australia. I will show it to you in a minute. So I'm going to show you the
Raxcon in Australia. I was supposed to go there for one week to speak and I stayed 4 years. So
it's a trap. Okay a bit of disclaimer and then let's go let's go to the meat. Uh so my employer
does not wish to be named even though I just did. Um they're not associated with this talk and
this is my personal research. On the upside it means I'm free to uh share it with you. There's
no intellectual property problem. But on the downside it means you want to do reverse
engineering and you're on your own. What do you do in this case? You go EFF to the rescue. And
before anything I'm going to ask you to give a big warm um um you know a big clap to the people
of the EFF because they've been amazing. Thank you very much. I know some of them are uh uh
talking today so they're definitely around. Uh if you manage to catch them like you know pay
them a beer because they they're really helping us when uh we're in situations like this where we
cannot afford like you know legal advising. And um if you do reverse engineering they have a
nice FAQ uh that I suggest you check. Um the URL is on the slides. Okay uh so my employer
doesn't want to be named but he's recruiting. It's a badass security team. Uh if you saw the attacks
on like breach and things like this, denonymizing SSL, uh Ravage which was um uh a very cool tool
to provide Java. Or the research we presented last year at uh at Black Hat. Uh yeah feel free to
decrypt those slides. I think we're cool. Uh the legal department and the PR department are
very unlikely to decipher this slide. In terms of agenda I'm gonna talk to you quickly
about why I started this project. And why I started this project. And why I started this
project. And why you know it's relevant hopefully. And then we're gonna do like some really
serious black magic uh with the witchcraft compiler collection. I'll show you um you know
what are the main tools in it. I'll show you how to transform the shared library like a like
uh sorry I'm gonna show you how to transform an executable into a shared library. Okay that's
not supposed to fly. But that's super helpful when you do reverse engineering or exploit writing.
Um then we go further and we'll completely unlink um an ELF to a re-locatable file. Um and
then we'll extend that and go a bit crazy. Okay. I don't get to see my slides so it's a bit
touchy for me too. Uh quickly let's imagine we're working on an an application and we don't
necessarily have the source code. Honestly even if you have it, it takes time like you know to
recompile things. Uh possibly to adjust your tool chain. Um you know you have missing
dependencies and things like that. You often don't have the right headers and things. So
working with source code isn't easy. I'd really like to work with binaries directly. As an
example um I took a very old version of uh SMB. It's called SMB server 1532. It's basically a
predecessor of Samba. So um if you do static analysis, that's a pet project I run on the side
uh with a number of people. Uh I'm not sure if you know what I'm talking about. Uh I'm not sure.
It's another company I work with full time. So I have two full time jobs right. The one with the
company who doesn't want to be named. One with a startup in France. And I have so much free time
that you know it allows me to uh uh do more research and share it with you. So basically that's
a thing we run with our startup in France. Uh you can you can register for free. It's only for
security researchers for the time being. It does full featured static analysis. So you upload your
binary and you get back a bunch of metrics. Um and then you can register for free. Um and then you
can register for free. And then you can register for free. So that's a really cool thing.
Uh on this slide like the more word you get, the better it is. You can see that it's checking you
know five different aggregated metrics. Without going into the details, the bit we're gonna care
about today is like okay. You can see that the binary for instance is compiled without ASLR,
uh without Fortify uh hardening and things like this. But what we're really gonna look at is
like finding uh proper vulnerabilities from this binary without using source code. One which looks
pretty cool is um uh the one with the uh the uh the uh the uh the uh the uh the uh the uh the one with
fopen right here which is opening um I mean it seems like it's opening um a file with a
predictable name in write mode in slash tmp. Uh so this thing is running as root. There might be
you know um possibility for a symlink attack and basically a local privilege escalation. The
thing which is interesting here is that we don't have a full back trace. So the way the tool
works internally is like it does like you know decompilation. I mean this is like a
forthpatch based on structure so you can do this assembly, decompilation, full static analysis on
the binary. Um, by using uh symbolic execution you hold the engine itself so it does it unm teary and
a problem you commonly face when you use advanced techniques like this is that you don't
have a full stack trace. So you only a partial stack trace here and I like to verify these
vulnerabilities does exist. Okay another way to do this is uh to keep this problem is
when you do fuzzing. Like often like in this case this imagine is sufficient in general always
this is taken from the, uh, the bugzilla of, uh, Red Hat. It's also SMB which is, which
seems to be crashing. And we have only a partial stack trace. And this thing is actually
bizarre, right? Cause it, it's not called from main. So we don't really know what's
happening. What I know is that I don't want to call the whole thing from remote by sending
packets. I'd like to verify the vulnerability exists by calling directly an arbitrary
function inside the binary or inside the shared library. So that's our problem
statement today. I want to be able to call any function inside any binary without having to
craft an input to reach it. And without necessarily going through main and whatever
layer of function and then reach it. I want to be able to call those functions directly.
Okay, so here are the components of the witchcraft compiler. Um, it has a, um, a linker,
uh, which is a, a badass tool which patches one byte in binaries. But its power is
incredible.
You're gonna see this. We got the, uh, WCC which is the core compiler, which is the tool which
takes a binary as an input and gives you relocatable files that you can later on relink to
generate new shared libraries or, or relink against your own code and like, uh, get new
executables. And finally we have, uh, the witchcraft shell which is by far the most complex.
It's a full dynamic interpreter and scripting engine, uh, built on top of Lua. And, uh, we
gonna see that this is pretty cool. Um, with this shell, you can write your own scripts. So an
example of scripts we're gonna see today are WCCH and WLDD. Let's go to the meat. Libification.
So if you did one class of computer science and C programming, the first thing people tell you
is that what we're gonna do today is impossible. Let's start with a demo.
I don't see anything.
Yeah, yeah, I know you're not seeing this. Okay. Here we go. Okay, so for instance,
um, to give you an idea of where, where is the state of the art of decompilation and why we're
not gonna take this route. So this is a elo.c file. Okay. And I'm gonna show you the equivalent
code generated by, uh, possibly the best decompiler you can get for free. It's called
snowman. It works in two modes, either on top of IDAR or it has a mode where it can run by
itself, uh, autonomously, which is free.
So to give you an idea, like when you, um, decompile these two lines of code program with,
uh, snow, uh, snowman, you get something like this. Okay, so that's the source code which is
supposedly equivalent. So if you take that path to decompile a real binary, let's take
proftpd for instance. It's 200,000 lines of code. Okay, you're gonna get about 200,000 times this.
So decompiling this and recompiling this is not reasonable. Uh, if we, if we give it a try, just
for fun, let's try to recompile the one from snowman. I'm just gonna, uh, grab the errors.
Maybe. I don't see shit. Okay, let, let's, let's drop this. I think you got the idea. Okay, so
what's libification? Uh, basically we're gonna take an ele file, this is the main place where we're
header um the elef header we're gonna patch one byte we're gonna tell it you're not a you're
not a binary you're not an executable binary anymore uh you're a shared library so patch it
from et exec to et din. So let's do it with proftpd for instance. Let me get this full
size. Can you get see any of this? That flies? Yeah? Okay. Okay. So let's do it with
proftpd. Okay so uh as an example let's take proftpd. And let's assume we don't have the
source code. Let's copy to slash tmp. If we check the the type of the file um okay it's
obviously an elef executable as seen right here. I'm gonna use uh wld so the first tool from
the witchcraft compiler collection. It takes only one
option which is libify and then the name of the binary. So I'm gonna run this and let let's
now check the type of this file. Okay and surprisingly it's a shared object. Okay. But
what's crazy now is that it really is a non-relocatable shared library that can care that I
can relink against my own applications. So let's check how to do this. So let's check how to do
this. Okay so that's a sample program which is gonna load uh slash tmp proftpd.so into memory.
So let's start with renaming uh proftpd we just patched into proftpd.so. It's gonna DL open
it. So load it in memory. Which returns a handle which allows you to call dm sim and find the
address in memory of any of the symbols in there. Okay. So let's check how to do this. So let's
see. What I'd really like to call is this function called pr underscore version underscore get
underscore string. Which returns inside proftpd the version of proftpd. So what's very crazy. Let
me show you the the make file quickly. There's nothing very crazy. Okay. We're just using a
linker script to avoid gcc giving by default the same address to the linker. Okay. So I'm gonna
go back to this program and to proftpd.so so they do not collide in memory. So what I do is
basically my demo is mapped much lower in much higher in memory to make space for this uh
non-relocatable shell library. And what's very crazy is that this thing actually works. Okay.
So if you look up there it it really returned like 1.3.3d which incidentally is the version for the
proftpd which we got from the shared library. Isn't this insane? Okay. so that's
exactly what we just did. You can see that we really just batched one one byte in memory. So
without going into the you know crazy details uh there's a couple reasons where this works. The
very crazy is that the the library we just patched is still a valid executable. That is
completely unexpected right? So the reason this works, the reason it's still a valid
executable is that basically the way we we uh pushed full ASLR in the Linux kernel is by
allowing you to compile your binaries as a shared library and execute at any execute them
at any address in memory. Um so yeah you can have you can have a binary with technically a
shared library. We're gonna see that a bit more on this later. Um the other thing which is a bit
crazy is that this newly recrafted like shared library cannot be remapped in memory right?
Cause it was never meant to be relocated that way. So we have a shared library but that can
only be mapped at a single address in memory. Um this actually does exist in the normal world
uh it's called pre-linking. It's the fact of giving a base address to speed up booting
essentially um to shared libraries. And uh yeah so that's exactly what's happening in here.
Okay let's do a demo with uh Apache. I'm gonna show you that um you can actually re-link
against Apache which is not a shared library but pretend it's a shared library. So
let's do this. Okay so uh let's look quickly at uh the source code. Okay so it does nothing
crazy. It tries to call AP get server banner which is a function which is defined inside
Apache. And to do this we're gonna link straight away against Apache as if it was a shared
library. So let's type make quickly. Okay it's complaining. Boom. And then we're gonna
run this application. And if now I run this application it's very crazy but that also works.
So Apache is not really a shared library right? It's an executable but it's compiled as ETDN
to have like full uh ASLR. And uh if you link directly against it you can actually call
functions directly inside it. This is so amazing that I'm tempted to end my talk here.
Okay if you look at like the way um you know if if if you try to print like which shared
libraries uh this recursively this application is linked with you see that the first one is very
much Apache and that looks very crazy but it works. Okay let's go one step further. Uh so
this uh this technique we just used is by far my favorite because it's cross platform. It works
across architecture. And it's super stable. There's no such thing as like a uh like a
complicated analysis that might fail and stuff like that. Like all we did was patching one
byte. Which you know incidentally is pretty reliable. If you wanted to go one step further
and instead of transforming an executable into a shared library go back to the uh output of a
compiler before the the the application is linked. So we call this uh unlinking. Um well
we're gonna use this tool called WCC. Which is a lot more complex and less
portable. And you know basically what it tries to do is recreate the relocations um uh that
we're missing from the final executable. And add them to the um the binary so that you can
relink it. So the normal way to um to do reverse engineering and to solve this problem would
have been this. Um when you have uh compiled source code you would use a decompiler. Which is
totally not what we're gonna do. We're just gonna go to back to the reco- relocatable files.
And once I have the relocatable files I'll be able to relink them again. So the command line is
made so that there is zero learning curve. If you know how to use GCC it takes essentially the
same parameters as GCC. Only it doesn't take source code as an input. It takes a binary.
Okay uh I'm gonna give you a demo on this. Okay so uh I'm gonna give you a demo on this.
Okay. So I have a- a small file here. Which is a small C file. And it has a whole bunch of
relocations. Okay it has a number of imports. Um it has strings which are in the re- read only
data section. It has strings which are you know passed on to the user. And it has a number of
uh as arguments. Um so yeah it has- it has pretty much all the type of relocations that do
exist. I'll- I'll you know I'll share- I'll share the source code so you guys um can verify
this. But essentially what we're gonna do is first compile it. Then uh so the- the normal
compilation will give us a binary called small. Then we'll use the witchcraft compi- uh compiler
to go back to a relocatable file from this final binary. And then uh we'll uh we'll uh uh we'll
use the bitmap. We'll use the bitmap. And we'll link it as another binary using GCC called
small two. And the question is like does small two actually runs? Cause that would be very
crazy. So let's compile it quickly. So if I run small. Which is the original binary. It tells
me something like hello from devcon. You can see that WCC. So let's redo this manually
actually. Let me re- re- re- re- re- delete this. And this. Okay so I start. I have only a
the small binary. I'm gonna use WCC, the tool I just told you about. If I, if I played stupid
and I, I assume I want, uh, you know, if I wanted to use GCC, so I would like to do
something like this essentially. Uh, until it give me, um, you know, small WCC dot O and
I'd like it to be a relocatable file. If you run this, like, GCC is gonna be like, I don't
understand what you're trying to do. The input is not a source, is not a, um, source code. But
if you do it with WCC, it's gonna be like, yeah, okay, let's do this. And it gives you this
relocatable file that then you can absolutely relink into small two. And what's amazing is
that small two does the same thing as the original binary.
This sounds very crazy, doesn't it? So if you like it, uh, I'd really like you to contribute
back to this tool and extend it. For the time being, it works mostly, uh, on, uh, AMD 64. I'm
trying to put it on ARM and the drawback as opposed to the first tool which, you know, worked
everywhere because we were just patching one binary. Here it's, uh, it's a bit of work because
we have to deal with all the type of relocations for all the type of CPUs. So I need your help
with this.
Okay, uh, I'd like to explain you one thing. Um, I choose, so to architecture this, uh, the
front end is basically libbfd. So it's like objdump and tools like this or objcopy. Uh, which
has a nice, I mean, the drawback is that it's not very precise. Uh, but the advantage is that it
works with many type of binaries, not just ELF files. So technically at this stage, we can try to do
very crazy things like let's do rich graph vb. Let's try to transform a PE file into an ELF file.
I'm running late so, uh, I'll let you play with this at home but that basically works. We have
one problem here. It's like I don't know what to, what to re-link this with, right? Um, so an idea
would be to use like the libraries, um, shipped with wine which already give us, uh, you know, the
the Windows API compiled as an ELF file. This is left as an exercise to the reader. We're
going to do something way more crazy right now. Can you run open BSD binaries like
naturally on Linux? I mean if you've been to you know if you've done a bit of engineering
like that's not supposed to be possible. Like technically you're supposed to have a virtual
machine. Let's do it without a virtual machine. Proper witchcraft.
Okay so we could do this uh manually. I'm I'm going to do it with a make file. Um so the
original binary. Yeah so here the the original binary we're going to be using the
play with. Uh you can see that it's very much an open BSD binary. Okay. The source code is
trivial. It's basically this. So it's it's doing a bunch of printf in a row. Okay. Here comes
the main file. Uh fuck the display today. Okay. So we're going to copy uh the
binary blah blah blah. Okay basically there's a couple problems. The the dynamic linker is
expecting to find does not exist. So to show you manually if I do like uh s trace on this
particular binary. Uh that was not supposed to work actually. Uh cause I already patched it.
Okay. Um.
Okay. Okay let's just run it. I'll explain to you how it works later.
So basically the dynamic linker is not the right one. This is out coded inside the binary.
Inside the interpreter section. I could patch the binary to put my own dynamic linker. Instead
what I'm going to do is copy my real dynamic linker to the location it's expecting. The
dynamic linker to be encountered. Okay. Right. Uh so then it has a little bit of a problem.
It's looking for a lipsy which is called lipsy dot s o dot 62 dot something. And my
lipsy is not called like this. So I could patch the binary there again to link to tell him like no
look at like the lipsy I've got. But instead of this I could also copy the lipsy to the
my own lipsy to the lipsy he's expecting. And if you do all that I share all the the the
material so you can reproduce yourself. But essentially. Oh amazing. Okay if you uh there's
an uh last problem it's like it has a missing dependency on um right if I try to run it now. Uh
it has a missing dependency on at exit. So what we are going to do is use uh ld preload to uh give him a
um um you know a shared library with all the dependencies is missing like at exit we don't
really care right at exit is a function which is called basically when you exit um uh to
called um you know deconstructed and things like this so I don't really care. Long story
short if you look at the last line you do the LG preload you run this open BSD binary which
has been slightly adapted inside um um a Linux machine and it does print what it was
supposed to print which is also very crazy cause there's no virtual machine and this was
never supposed to work. Okay now let's go to proper witchcraft uh and I'm gonna introduce you
to a programming language that comes from basically um allowing I mean uh implementing a
sort of reflection in C inside a Lua interpreter. So let's go to a Lua interpreter. So
what I'd like to do is basically to get um reflection-like features but on binaries.
Reflection is typically something which only exists on a virtual machine right? It allows you
to load um classes of binaries in memory and instrument them like um get um get a bunch of
information on them like what are you know um um what type of argument they're expecting and
things like this and then to invoke them directly in the boot space. And they can then use this to
memory. So I'd like to do that but without a virtual machine straight from binary. Um so
it's based on DL open uh which is the function we used earlier uh to link with POSTPD. You
can you can uh compile it with LuaJIT which gives you uh just in time compilation in
memory. There's no ptrace and it typically doesn't work like any um you know debugger you
might have used before. I don't see the slides so I'm gonna I'm gonna go quickly on this uh
and we're gonna stick to the demos. Ten minutes? Okay. So it's time to activate. Okay. Since
I don't see the slides I'm just gonna run it for you um uh okay. Okay so I'm gonna run it for
you um. Okay that DSMB server I I showed you earlier with the static analyze it thing. So
let's let's talk let's copy the SMB is already there fuck that shit okay nothing works so I'm
gonna load like the POSTPD binary we've uh patched before and I'm gonna um you know showcase
you the capabilities of WSH. So we just loaded the uh data um we're uh fingerssuper at the
it in memory. Um it has a bunch of built in functions. When you don't know one of the
functions you can use um you know the app which is uh the only documentation you'll get in
this respect. Okay so um let's call this function for instance. Hey everybody is Jonathan
doing a good job?
Thank you folks. Okay I really want to show you this cause it's it's it's it's beautiful. So
we can do crazy things like uh print the section headers that the output you would get from uh
NM typically only this is dynamic and this is recursive over all the shared libraries inside
your memory. This is a feature I always wanted cause it's not built in GDB and it's always a
problem when you're trying to do this. Uh you can have the program headers, you can look at
like what are all the functions which are loaded right now in memory. Uh let me show you this
first. You can you can ask him to print what are all the the libraries that you have loaded in
memory. I just loaded pre FTP but that also loaded all it's dependencies. So if we look at
like all the functions that this has actually loaded in memory. There's a fair bit of them in a
bunch of you know libraries and we can now invoke them straight away. So ready we got like 6,000
functions to play with in memory. I don't even know the prototype. I know nothing about them.
So let's look for instance if there is a function uh which print the version or something like
this inside pro FTPD. Uh okay so uh like before we find this version called PR underscore
version underscore get underscore version. Uh so uh let's look for instance if there is a
number. I'm going to print this inside um a variable. And if I print the variable like
before. Uh that's not what I expected. Uh cause that's not the right one. Let's try with the
string one. Yeah so like before that's printing me internally the version number.
. Now now now I'm going to show you the
thing. The real good thing. The real good thing is um uh so the real badass thing and way to clue
out is I'm going to try to activate. Is that you can have more than one return value. So I'm
gonna I'm gonna tell him okay I want A the result of this function but also give me a context. And
now if I looked at the context. It tells me a whole bunch of things is down um I mean uh
of the context of this execution. So that there's L number you know was zero there's no segfault and
stuff like that. I had not planned to do this but let's do something crazy. Um I mean this allows
you basically to build static analysis uh on top of uh WSH very simply. I won't have the time to
explain everything today. Uh let's just say we wanna test all the functions inside pro FTPD.
I'd like you to fold them and call them a hundred times each. So he's gonna list all the functions
in memory and what he's doing right now is like calling them. Okay. Okay let's stop this for a
sec. Dear god I've been too ambitious. Okay. A hundred times is too much. Let's run it like once.
And what happens is that he's recording all this stuff in memory and you can see them uh right
after. Okay I don't have the time to see you all this. I don't want to sabotage this talk but uh
that's too bad. We're looking to it. Invite me to your local conference. Uh yeah I won't talk
about this. I won't talk about this. Future work. What I'd like you to help me with. Yeah I
know we're super late. Uh so I think this is a very cool base to do reverse engineering. There's a
whole bunch of stuff I don't have the time to do. So uh if you would like to participate uh get
in touch. Do you have any questions? Or do you want me to stick to demos? Oh there is one thing I
need to show you because it's amazing. Uh what if I wanted to analyze an ARM binary on my
Linux machine? So typically to do this uh there again you would need like uh uh you know a full
hypervisor and things like this. What I did is just uh cross compile my WSH shell to WSH ARM.
Okay. I've registered QEMU in a weird mode uh to do me when I execute natively an ARM binary on
my machine. Um in memory binary translation. So this is really an ARM binary. I'm running on my
own machine right now. And what we're gonna do with this is load this Libesse Linux thing which
comes from ARM.
So it's complaining because some dependencies are missing. Typically you would do this inside a
ch root to have all the dependencies. But you can see that like before we have a bunch of functions
and we can't call them directly. Now let me show you something which is really insane. Uh for
instance. Okay. Let's print. Let me get my PID. So that's my PID. And it didn't work. That's
amazing.
Okay. Uh let's get it another way. I cannot get a shell. That's beautiful. Fuck. Okay. Uh I can
have it another way. Um let's just look at like the libraries mapped inside memory. So my
process is really an ARM process. It's loading an ARM binary and it's running relatively on Linux.
The binary translation is also inside the same process thanks to QEMU and uh the weird mode it's
using. And it's all it all of this is just one program in memory. You don't need a virtual
machine. You don't need all that garbage. And that facilitates a lot like you know the fact of
sharing this tool or or even like a ARM binary and calling functions inside it uh from other
application without any reverse engineering. Last but not least. I'm almost done.
Uh I told you SMB server. I wanted to write an exploit for it. So let's do that quickly. We saw
before that uh we wanted basically to call this particular function called reply close inside uh
SMB server. Do we have the binary here? Okay. So let's do WSH of SMB server. If I want to call
reply close directly I can. This exports by the way this is amazing. Um uh we get to know that it
writes. But we didn't decompile. We didn't ptrace. We get that basically by writing a custom
signal handler. And passing like you know the output we can get out of it. Let's give it a
couple arguments and let's see why it's crashing. Okay. So let's see how it works. So let's see how
it works. So right here it's crashing because basically the second argument as you can see is
trying to write. So let's map something here. Okay in Lua strings are supposed to be immutable but
in PXI which is you know what's happening in this script you can break all the Lua rules. In
particular yeah you can absolutely write to to strings. So I'm gonna try to this string. It did
reply close. Okay. And if you remember like the static analysis we saw uh this is supposedly creating a file
in slash tmp with a predictable name which is g something. And you can see here that yeah this
file was actually created. And what's amazing here is that we can verify results of static
analysis without any reverse engineering basically. And we can call any function we like in the
stack trace even if we have we don't have the full stack trace and even if we don't know an
input to take it there. With this my friends I think I'm done. Thank you very much for your
attention today.
Subtitles by the Amara.org community