Relocation Bonus: Attacking the Windows Loader Makes Analysts Switch Careers

Video thumbnail (Frame 0) Video thumbnail (Frame 2112) Video thumbnail (Frame 4041) Video thumbnail (Frame 7668) Video thumbnail (Frame 10600) Video thumbnail (Frame 11338) Video thumbnail (Frame 17805) Video thumbnail (Frame 20120) Video thumbnail (Frame 21324) Video thumbnail (Frame 22364) Video thumbnail (Frame 23129) Video thumbnail (Frame 24132) Video thumbnail (Frame 26426) Video thumbnail (Frame 27137) Video thumbnail (Frame 27872) Video thumbnail (Frame 29442) Video thumbnail (Frame 31766) Video thumbnail (Frame 35623) Video thumbnail (Frame 37343) Video thumbnail (Frame 39967) Video thumbnail (Frame 41643) Video thumbnail (Frame 47023)
Video in TIB AV-Portal: Relocation Bonus: Attacking the Windows Loader Makes Analysts Switch Careers

Formal Metadata

Title
Relocation Bonus: Attacking the Windows Loader Makes Analysts Switch Careers
Title of Series
Author
License
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
2018
Language
English

Content Metadata

Subject Area
Abstract
The arbiters of defense wield many static analysis tools; disassemblers, PE viewers, and anti-viruses are among them. When you peer into their minds, these tools reveal their perilous implementations of PE file parsing. They assume PE files come as-is, but the Windows Loader actually applies many mutations (some at the command of the PE itself) before execution ever begins. This talk is about bending that loader to one's whim with the Relocations Table as a command spell. It will demonstrate how the loader can be instrumented into a mutation engine capable of transforming an utterly mangled PE file into a valid executable. This method starts with multiple ASLR Preselection attacks that force binary mapping at a predictable address. It then mangles the PE file, garbling any byte not required prior to relocation. Finally, it embeds a new Relocations Table which, when paired with a preselected base address, causes the loader to reconstruct the PE and execute it with ease. This isn't a packer or a POC, it is a PE rebuilder which generates completely valid, stable, and vastly tool-breaking executables. This talk will show you how this attack twists the protocols of a machine against the controls meant to protect it. It flexes on tools with various look-what-I-can-break demonstrations and, if you write similar tools, it'll make you rethink how you do it.
Email Parsing Software developer Code Robot Code 32-bit Fluid statics Operator (mathematics) Authorization Information security Game theory Hydraulic jump Parsing Email Binary code Mathematical analysis Bit Hecke operator Portable communications device System call Data mining MiniDisc Codec Game theory Window Disassembler
Code Multiplication sign Binary code Code Compiler Pointer (computer programming) Different (Kate Ryan album) Semiconductor memory MiniDisc Statement (computer science) Position operator Window Address space Booting
Email Dynamical system Code Texture mapping Real number Multiplication sign Characteristic polynomial Mereology Mach's principle Medical imaging Read-only memory Different (Kate Ryan album) Semiconductor memory Flag Diagram Gamma function Information security Address space Descriptive statistics Mathematical optimization Email Wechselseitige Information Mapping Block (periodic table) Structural load Point (geometry) Binary code Bit Virtualization Funktionalanalysis Directory service Subject indexing Type theory Arithmetic mean Pointer (computer programming) Sample (statistics) Personal digital assistant Right angle Block (periodic table) Table (information) Window Speicheradresse Session Initiation Protocol Booting Flag
Email Structural load Code Multiplication sign Sheaf (mathematics) Set (mathematics) Different (Kate Ryan album) Military operation Core dump Arrow of time Resource allocation Area Email Structural load Bit Funktionalanalysis Entire function Type theory Arithmetic mean Process (computing) MiniDisc Quicksort Block (periodic table) Speicherschutz Writing Booting Point (geometry) Table (information) Real number Computer-generated imagery Hand fan Read-only memory Operator (mathematics) Flowchart Address space Mobile app Content (media) Code Line (geometry) Euler angles Density of states Uniform resource locator Loop (music) Error message Personal digital assistant Read-only memory Statement (computer science) Table (information) Window Booting Library (computing) Address space
Email Texture mapping Computer file Demo (music) Structural load Computer file Sheaf (mathematics) Control flow Bit Funktionalanalysis Mereology Word Loop (music) MiniDisc Integer MiniDisc Table (information) Resource allocation Loop (music) Address space Window Position operator Booting
Revision control Assembly language String (computer science) Binary file Error message
Metropolitan area network Crash (computing) User interface Software Demo (music) Source code Port scanner Right angle Unruh effect
Validity (statistics) Hacker (term) String (computer science) Multiplication sign Sheaf (mathematics) Hill differential equation Table (information) Error message
Uniform resource locator View (database) Code Error message Hydraulic jump
Computer file Code Demo (music) Binary code Sheaf (mathematics) Cartesian coordinate system Medical imaging Process (computing) String (computer science) Videoconferencing Office suite Musical ensemble Error message
Sampling (statistics) 1 (number) Source code American Vacuum Society Window
Cross-platform Discrete element method Window Booting
Multiplication Randomization Demo (music) Real number Bit Embedded system Mathematics Embedded system Process (computing) Core dump Configuration space Right angle Speicheradresse Window Address space Speicheradresse
Windows Registry Point (geometry) Context awareness Freeware Computer file Ferry Corsten Code Texture mapping Multiplication sign Demo (music) Sheaf (mathematics) Mereology Wechselseitiger Ausschluss Latent heat Virtual memory Uniformer Raum Root Velocity Different (Kate Ryan album) File system Flowchart Process (computing) Drum memory Computer-assisted translation Speicheradresse Address space Email Mapping Block (periodic table) Structural load Closed set Forcing (mathematics) Computer file Binary code Code Instance (computer science) Embedded system Root Process (computing) Loop (music) Digital image correlation Sheaf (mathematics) Right angle Hydraulic jump Routing Speicheradresse Window Reading (process)
Code Image resolution Multiplication sign Computer-generated imagery Mathematical analysis Disk read-and-write head 2 (number) Preprocessor Semiconductor memory String (computer science) Lie group Macro (computer science) Error message Address space Form (programming) Block (periodic table) Binary code Mathematical analysis Sound effect Bit Funktionalanalysis System call Symbol table Parsing Iteration Right angle Window Booting
Metropolitan area network Process (computing) Computer file Multiplication sign Right angle Address space
Email Slide rule Run time (program lifecycle phase) Parsing Computer file Link (knot theory) Code Mountain pass Multiplication sign Source code Sheaf (mathematics) IP address Fluid statics Mathematics Semiconductor memory String (computer science) QR code Energy level Flag Selectivity (electronic) Address space Physical system Source code Inheritance (object-oriented programming) Information Structural load Binary code Mathematical analysis Sampling (statistics) Bit Maxima and minima Control flow Parsing Word Message passing Visualization (computer graphics) Software repository System programming MiniDisc Table (information) Window Booting
okay cool so I'm a bit nervous now following the monkey Comedy Hour it's gonna be hard to follow that up but this is relocation bonus attacking the windows loader makes analysts switch careers so quick introduction I am Nick
Cano I'm 25 and I'm a senior security architect at silence I have written a book on hacking games sorry I didn't know a clap was coming so I've written a book on hacking games I'm also a plural sight author just had a course publish like a month ago on C++ secure coding practices and what does this talk about well this a talk in essence is about the Windows portable executable header and how it can be weaponized to destroy parsers and other static analysis tools things like disassemblers and such and that all culminates into like a PE rebuilder for 32-bit windows binaries so you might ask why are you attacking relocations so this is a disassembly of a game a game that i make a bot for disassembly to get rid of a jump call just put some knops in there and then I save my new binary to disk I ran it and it crashed I was like what the heck is going on here and I looked at the code and mine ops were now changed the code was different from what I had patched and I know what you guys are thinking why do hack what's going on here so as it turns out there are these
things called relocations so at first I was like oh man this is broken for no reason then I was like ok relocations
corrupted the patched code then I was like maybe I shouldn't patch code that is relocated but then I thought I can
use relocations to hide my arsenal in the bowels of the machine so before we dive into the nitty-gritty technical details let's let's restate what we're doing here the Windows loader has this piece in it that applies relocations relocations exist because binaries will have pointers in there that's our that are sensitive to the position of the binary and where it is loaded so if the binary is loaded at a different base address then the compiler expected those things need to be relocated so if we can weaponize that if we can instrument that and make it modify things for a different purpose we can use that for obfuscation and we can get an obfuscator such that there's no D obfuscation code the Windows loader does it all for us and then it's kind of a mystery if it's the first time seeing that you're like this thing is a mess on disk and then in memory it's fine before anything executes so that's what we're going to talk about so first we need to
say well what are relocations they exist to enable a SLR and dynamic mapping that's not exactly true it's a bit more nuanced than that but for the sake of executables they exist to enable a SLR and let's look at an example so this is the same binary loaded at two different base addresses and I'm specifically looking at a function table and as you can see the function tables in the two different loads one on the left and one on the right the addresses are different at least that upper part of them and on the left we have what is that Oh 1 3 3 and on the right we have Oh 1 1 7 that is because they're at a different base address we can see that actually here outlined in blue is kind of reflected by the address of where this function table is in the binaries memory and we can see that the values are actually changed here in the bytes of the function table so let's take a sidebar really quick to talk about the PE header by the way this is not my diagram I got it from cork ami if you don't know that what that is check it out a really good resource so there are three things we're worried about and the first thing is image base image base is a part in the PE header well so the PE header is kind of the description of a binary in Windows what needs to be loaded what what parts of memory need to have what access rights what functions are important stuff like that but we're specifically interested in image base which is a value you can use to say what base address you want your binary loaded at and if a SLR is not on that will be followed throughout the talk I might refer to this as desired base there's also DLL characteristics now this is just a two byte value and it's flags value we're specifically interested in the bit o x40 which if it's set means ASL ours on and if it's not set SL ours off an SLR is just the part of the loader that says okay I'm going to put this binary at a different address for security purposes and finally there's the data directories and specifically there's an offset from the data directory is called image base entry real oak so the data directory is basically just an array of pointers and sizes to different pieces of data that the loader needs and we're only worried right now about the real oak index which points to the relocations table and the
relocations table looks something like this at the top here you have the data directories and then we have this little gray block and then we have what the real oak blocks actually look like in the data directory there's a pointer to these blocks to the first block and then all the blocks should be continuous after that and there's also a size which refers to the size of all of the blocks and bytes each block ends in an O X zero zero zero zero just two by zero to say this is the end of the block there's another block coming so that the loader knows that needs to look for a new relocation Center so each block looks something like this first there's a virtual address that virtual address is sort of like a base so instead of encoding every single address that needs to be relocated you encode a virtual address and then offsets relative to that virtual address that are less than four bytes long and that just saves space so this virtual address is the base which we will offset from in each entry there's also size of block and that is the size of the entire block that is including the size of size of block and the size of virtual address so those are both four bytes so four plus four and then in this case we have four entries which are each two bytes so then plus two four times and you get the size of the block so each entry is 16 bits four of those bits or half of a byte are the relocations type which we'll talk about in a second and then the twelve remaining bits are used for the offset so you get up to four oh nine six from the virtual address so you can have virtual address and then you can have as many entries as you want within four oh nine six bytes of that to be relocated and this optimisation it might not seem like much but when you have a function table where you have like 30 things to be relocated back to back it makes sense why it's done this way so this code kind of describes how
the wrote loader does relocations this is just pseudocode obviously it's not written in modern C++ but this gives you the gist and we're going to talk about this specifically what we care about is the first line where we say Delta is equal to base that's the base that were actually mapped at minus desired base that's a base that we asked for in the PD header and then the first if statement inside the loop is the type of relocation we're going to use so if we were to look at
that first steps if statement we would see that a plus equal operation is used during relocations and the right-hand side of that is Delta so essentially everything that is relocated is the value that's there plus equals Delta which is derived from the base address we're given minus the base address we wanted and that's how everything gets fixed up to point to the right place so the conclusion that we can come to is that if we want to abuse relocations or if we want to be able to control what their writing base must be pre-selected or we must have some way to take base and make it be something we know that isn't the base that we asked for there needs to be a difference there and desired base is the only means of controlling a SLR so that's a bit tricky and Delta's also dependent on desired base so we know we need to use a desired base somehow to pre-select the base but it's not clear how and I thought maybe you will just try invalid stuff so I tried negative one or maxint or whatever you want to call it and it didn't work pe fails to load well what I know is those final four FS actually have to mask and be 0 because of alignment so I tried all zeros pe fails to load invalid header so then I combine the two and he loads at base o X one with four zeros after it consistently every time so we're getting a base address every time that is different than the one we asked for and always the same as I later learned core commie already had all of this documented so this has been known for a few years as well so let's talk about the loading process it's pretty complex and this is not all of it but this is sort of what the windows loader does so you don't really have to read this whole thing what we really care about is that the things in blue are things that happen before relocations are applied by the loader and the things in orange are things that happen after relocations are applied so if we want to obfuscate things we might want to obfuscate things that happen after relocations are applied or we might break something so if we just take out everything that isn't relevant this is when we do our attack this is what it will look like this is a flowchart we'll go through now you might notice there's a red arrow coming from a SLR enabled which means we're actually gonna have a SLR set to OFF and the attack happens here so it turns out we're not tricking a SLR but when the allocator is being asked to locate something at ffff zero zero zero zero it's saying yeah I can do that but it's spitting back Oh hex one zero zero zero zero for whatever reason so our targets for relocation obfuscation well we know import table is loaded post relocations so we can obfuscate the entire import table that is all of the libraries and functions that are imported from DLLs can be obfuscated so on disk they look like trash but the loader fixes them up at load time additionally even though sections are mapped pre pre real oak they're not used until execution which is post real oak additionally their memory protections aren't set properly until after relocations in case read-only stuff has to be relocated also entry point isn't used until post reluck so we could obfuscate the entry point making it that much harder the problem is that is right protected before relocations are done so you can only do this if the target machine doesn't have data execution prevention turned on so and the conclusion is pretty much what I just said we could hit imports code and resource sections and optionally the entry point with this attack and that is this little green area you can see highlighted now you might look at this and say okay that's only like half of the binary but what you have to realize is this is a minified PE and that is actually most of the important stuff and in like a real binary it's going to be somewhere like above 90% or 95% of what's actually there and what's actually important content so the final attack looks
something like this will load the target PE file the PE file that we want to obfuscate then we'll apply the original relocations because remember relocations are there for a reason oh x1 0 0 0 0 it's probably not where that binary wanted to be mapped so it's gonna break unless we apply the original relocations and say ok fix everything up for that address once we do that we flip a SLR off because remember even though we planned to trick a SLR we're actually tricking the allocation function then we set desired base to that tricky ffff 0 0 0 0 and then we loop over all of the data that we want to obfuscate that is sections import table stuff like that in D word or you int32 size chunks and we decrement them by what we expect Delta to be that decrement is because the relocations part of the windows loader does an increment so we just do the opposite of that and that is kind of our obfuscation so every integer in the stuff we're obfuscating is going to be messed up a bit which is good enough then we discard the original relocation stable because we've already applied them on disk we generate a new relocation stable reflecting the positions of every single decrement that we've done so that the loader can fix them up we save the new PE file to disk and profit we're done we now have a PE that is completely mangled on disk it has a huge relocation table and then when it runs it maps perfectly fine so let's jump into some
demos so here I'm trying to load it in
Ida you can see the messed up DLL named Ida thinks is an import ok Ida throw some weird errors on older versions of Ida it was crashing sometimes I can't get newer versions of Ida to crash you can see Ida lights up red it doesn't know what it's looking at it only sees one subroutine and even the assembly code there's a bunch of invalid instructions and if you look at the strings and they look like trash everything looks like trash binge is gonna be mostly the same it's gonna see two subs but it's got like question
marks there it doesn't know what it's looking at so next is cff explorer this
one actually crashes somewhat
consistently I think it's this one that would like it reaches out on the network
and does a bunch of like out-of-band scans that come back like a few minutes
later and those do cause crashes more than any other tool there's no crashes in these demos because one you have to get lucky they're not even consistent across the same binary and also you have to get a binary that happens to cause them I haven't looked more into it I'm really worried about as you can see here the import names are all messed up some of them look kind of right because remember we're doing it in four byte
chunks so for Strings we're only messing up like one byte at a time depends just completely chokes it has no clue what it's looking at and then resource hacker just throws an error it says you don't have a valid resource table because a resource section is encrypted or obfuscated and even PE bear
you can see it just lights up red imports look like trash if we tab over
to the disassembly we'll see it says okay these are invalid instructions you will also see a bunch of jumps into
locations that can't possibly be jumped too
and finally pe view it's gonna be the same thing it's just gonna maybe pop
some errors and then imports are gonna be messed up codes gonna be messed up okay and that is that one okay so we've
shown that this attack is viable and then it works and we can do something with it oh wait what am i doing I have another video to show I'm pretty dumb we
like we've seen it break stuff but we haven't see it work what am I talking about so let's do that okay so here you
can see me clicking on the binary and it runs this is an encrypted obfuscated binary with this method it's running and it's just process Explorer that are that I've obfuscated it's going on over there it's just process Explorer that I've office gated so that's why you saw a process Explorer launch I did this because this is a relatively complex application it's got a lot of stuff in its resource section and it's got a lot of non-trivial code so I figure if it works on this it'll work what you see right now is be searching for invalid strings in the image to show you that this is actually obfuscated some of the strings are not obfuscated because they're in the dock our data section which I didn't obfuscate for this demo but if you look here you'll see a bunch of file paths and a bunch of like error strings that almost look right but are actually gibberish when you try to read them [Applause] [Music] and it also kind of messes up like a ton
of AVS so here's a malicious sample
we're gonna go ahead and pack that and now you see it's generated a new famil
or a new sample sorry and we're gonna drop them both on virustotal and see what happens the first one's gonna light up all red and now the second one even
though it's effectively the same binary that's just obfuscated by the Windows
loader I guess we only get two Reds okay
so we know the proof-of-concept works we should probably test it on multiple platforms Windows seven it works that's what I originally developed it on Windows 8 but no one uses Windows 8 come on Windows 10 oh it doesn't work yeah I get it okay I'm done sorry okay
no but really we have to find a new attack for Windows 10 what ends up happening is asking for four FS four zeros does not yield that one with four zeros after it it actually lets a SLR go through the process even if the SLR bit is off and then we get a random base address so no good so I thought maybe I can embed multiple PE copies for all possible base addresses and then use some kind of real oak tricks to point to the right one which is something core commie has actually shown as possible but that would be way too big it would inflate the binary even more than using relocations already does which is actually pretty significant so then I thought maybe I can tweak a SLR configuration because I know there was a major change on Windows 10 in how all of that works and that actually does work so if you notice the demos we're on Windows 10 and this is what I used to demo on Windows 10 we set mandatory SLR to on and bottom-up ASLR to off and if
we do that with this dot read file for specific executables that works but I don't really like it as soon as you start touching these registry Keys everything's gonna light up a V's are gonna light up EDR is gonna light up monitoring is just gonna say hey this is bad if it doesn't just block this entirely so I wanted something else and then I did a lot of playing with it I was trying to see what I can do to control base addresses and I noticed this so this is just a file I have multiple instances running and I'm basically just looking at the base address of this file and even though I have multiple processes running of the same file I noticed that they all have the same base address there are something in Windows that is caching that base address or reusing it on loads maybe it has something to do with copy-on-write not exactly sure and then I noticed ok if I take this file I copy it to another file I delete the original and then cat the copy into the name of the original it sounds crazy but it's a way of copying a file to its self without the file system being able to track that it's the same file and then I launch it again I invalidate that base address so they all have the same base address again but it's different from what it was before so this tells me there's something in the file system that invalidates that base address that's being reused so I can at least a brute force and get a base address that I want by just invalidating it every time so
we're gonna go over a pretty complex flowchart so really quick here's a flowchart on how to read flowcharts ok I'm actually put in the deep-fryer so let's just talk for a sec so what I figured out is that if you take a file and you memory map it then you close the mapping and you launch that file it will with a different base address then last time you launched it so if you do this in a loop you launch a file check the base address if it's not what you want memory map the file close the mapping launch it again you can keep getting a new base address and you can brute force and pre select whatever base you want and that attack looks like this so you'll have a route process and a drone process effectively where the drone process is just launching and throwing back a specific return code based on whether or not it has the base address that it wants and then you have your route process which in a loop is doing that mapping stuff with which is highlighted in yellow so here in orange is really the main part of the attack within the route process we're highlighting the loop that's going in and and saying okay I'm going to keep looping until I see the right base address which is signaled from the drone process by an exit code of Oh X what did I use bad beef yeah so if oxv f-- is the exit code of the drone process it knows that it didn't get the right base address and it will keep doing this loop now these are actually the same file so effectively we want to put the embed this attack in the binary we want to obfuscate it we'll make a copy of itself to be the drone process so that it can map that copied file to invalidate its base address and launch it over and over and over again but effectively there's the same code which is why you see at the top we create a mutex and check-check it if it exists and that's how we know if we're the root process or the drone process so to weaponize this the tool must create a new section with enough room for this brute-forcing code embed the code inside of this new section and make that code aware of the original entry point then it needs to point entry point within the PE header to the embedded code so effectively it's a typical parasitic infection and for this to work this SLR pre-selection code this brute-force attack must be position agnostic because we're just throwing in a binary or wherever you can it must be generically embeddable in any PE and yeah that's basically it so to do
that I made a bunch of preprocessor macros so I could do everything in lie and this you don't need to read these this is just showing a bunch of very attic macros and once I had all of these in place it looks something like this so like some of the weird stuff I had to do like some of these macros take a string in and then they emit that string as like SM bytes and then jump over those bytes and then use like a call and then our ret to get the address and like move it into a variable really weird stuff but this is how I made all that work now you might be looking at this big block at the top which is doing a bunch of function resolution and you might say Nick why didn't you resolve get module handle and get proc address and then do the rest normally and so my answer to that is this is like more obfuscated it's really indirect this code actually looks like a mess so it's harder to reverse that answers a lie I got really carried away of writing the macros and then I had resolved all of my functions by the time I realized I could have done that so yeah and it worked so this actually
worked so there are some caveats because this attack is actually running code we are sorry I had my bullets wrong in my head come on Nicky or together so it can be slow it takes about 200 iterations to land on the base address that we want so depending on what machine you're running it on it can happen in five seconds or a minute because you're launching this executable hundreds of times and you're mapping it to memory in between so also the size of the executable matters size matters and imports can't be obfuscated right because what ends up happening is the binary has to get mapped into memory properly for this attack to start running and if imports are obfuscated on the times where we don't hit the right base address the Windows loader is just going to nope out and it's gonna say okay this is wrong I can't resolve any of this and it's just gonna error so that's a bit of a problem but there are some advantages because first we don't really need to use that one with four zeros after it before if you saw the request of ffff zero zero zero zero and you're like a parser you know it's gonna map at this address but with this attack we can pre-select any address within the realm of possibility and the side effect of this is some form of symbolic execution or manual analysis is now needed determine what base address is going to be obtained so it's harder to just take this and do the relocations like inside of a parser to fix up the binary so yeah we can't do imports which was actually really cool to see but at the same time it's harder for automated analysis and
let's see what this looks like
so you see process monitor on the right and you're gonna see that just showing a bunch of process launches this is a brute-force going you can see on the left it copied itself to just its name to dot exe it launched itself a bunch of times looking for the base address showing that in process monitor and eventually it created that binary and then eventually it launched which we see down here we see that it actually loaded and launched process Explorer which is what we had obfuscated if we go and we look we see okay we had our first thing it copied the second thing it launched it that got mapped properly and then that our process Explorer actually then drops a 64-bit file and launches that which is why you see an extra process but that's just showing that we've actually obfuscated resources and they got D obfuscated so that process Explorer could dump another binary out of them perfectly without messing it up
yep and so what can we really do with this we've seen it work we know it's an interesting attack we've got the windows loader D obfuscating stuff for us but what can we do with it so you can annoy analysts with this it's gonna be annoying like maybe the first time or first few times you see this but if you see this a lot it's actually not that annoying once you know what's going on we can break a lot of automated static analysis systems as we saw before a lot of PE parsers just show up on it we can break a lot of tools those two are kind of one in the same but we can break maybe some AV parsers I haven't looked too much into it but I imagine there's at least one out there that's choking on this but there are a lot of improvements we can make as well such as more obfuscation now this might mean new targets so instead of just doing like a few sections and imports we might be able to find and identify other things that can be obfuscated or we might be able to do multiple passes so we do right now each D word in the file consecutively in any of our targets but what if we do that and then we start over offsetting by one and then we start over offsetting by two and then offsetting by three instead of getting like one or like one and a half bytes that are messed up for every four bytes everything is obfuscated the thing is your relocations table is gonna blow up if you do this but I mean if you really want to make it hard to analyze it's possible we might also be able to do header scrambling so we might be able to embed things in the relocations table that say these things need to be relocated that aren't things that we've done anything to things that are needed by the loader but not needed during execution so then the loader will go and I'll relocate things that were already correct then corrupting them in memory so not only would you have something that looks corrupt on disk and fine in memory you could selectively corrupt things to make dynamic analysis hard because right now this doesn't really do anything against dynamic analysis and we might even be able to combine this with runtime Packers and that would just be an extra level of annoyance now support from 64-bit binaries is definitely possible the pre selection attack it seems like there would be a much larger search space but as far as I can tell Windows does kind of prefer to load it around a base address that is like the maximum possible user space address that's available minus the size of the binary it tries to load it around there at first so if you do that you might be able to narrow down the search space though I haven't exactly tried it and the ffff 0 0 0 0 trick works similarly in 64-bit but not exactly the same might also be able to support dll's I actually have no evidence for that I just think it's probably possible with the right modifications and then you could also do selective obfuscation so rather than obfuscating the entire binary which just throws up red flags right away you might like have an eye P address embedded in a section and you only use this to change one bite in that IP address so now the analyst is like okay this is the CNC because this is a string this is a hostname or an IP address so then they try to connect to that and they're like okay the CNC is dead but they were looking at it in Ida which isn't doing relocations at load time you relocate just one byte in that address and now you're good to go like and it's it's kind of confusing it will trick a lot of people for too long but it will add a annoying bit there and that's the end
[Applause] so we have a bunch of links here this QR code I believe goes to the slides so here's what's gonna happen with the code release we've decided to do it like this because while we're not dropping any O'Dea or anything that's like super bad we are breaking some stuff so we want to give people time to catch up with that so in two weeks we're gonna drop some samples so if you're working on fixing this if you write a parser or you work for an AV company you read a PE tool you can go ahead and start thinking about this the slides already up so all the informations there and two weeks you'll have samples to test on and exactly one week after that full source code release everything will be dropped and anyone can play with this make changes commit the source code is in C++ Visual Studio 2017 so I think if you hit the relocation bonus github repo I've posted a timeline on there for now that will eventually point to the code full timelines on there but I think it's September 3rd for the full code release thank you [Applause]
Feedback