Okay, hello everyone. My name is Paramount Kid and I welcome you to Reversing with Dynamic
Data Resolver. If you are not already in the Discord chat, please go to blueteamvillage.org,
click on the Discord channel link, and I would like you to give a warm welcome to Mr. Holger
and let's start with the talk. Hi and welcome to my presentation,
Reversing with Dynamic Data Resolver Best Practices. My name is Holger Unterwink. I'm
a security researcher at Cisco Talos and I'm mainly focused on malware research,
threat hunting, and tool development. If you want to follow me on Twitter,
you can find me at hunterbr72. I'm the author of DDR and I will guide you through the different
features of DDR today, the installation process, and I will show you some of the best practices,
how to use the tool, and some of the special cases and caveats which you can
see later on in the demos where you might can run into.
So what is Dynamic Data Resolver? First of all, Dynamic Data Resolver is an instrumentation tool.
It is instrumenting the binary so that you can trace all the instructions the binary is executing
and it is collecting all kinds of data from strings to register values, memory locations,
etc. etc. It comes with an IDA plugin which is controlling the backend so you can easily
handle everything from this IDA plugin and you don't need to use the command line tools. You can
and I will talk about that later on. DDR comes with an client-server architecture.
So you have the DDR server which is running on the malware PC side, so the PC where you are
executing malware, and you have the IDA plugin which is running inside of IDA on the analyst PC.
It is highly recommended to separate these two machines. In theory, you can run all of that
on one machine, but keep in mind that you are executing the malware at the end.
So the malware really runs on that machine and you might not want to infect your machine
where you have your IDA installation on. It'll be infected with malware.
So what can I do with DDR? DDR was mainly built to resolve dynamic values and this is why I've
called it a dynamic data resolver. But it comes with all kinds of other features. But for now,
let's keep with the data resolving option you have in DDR. You have the option to resolve
certain register values, for example. So if you want to know the absolute value of EDI or EBX or
EAX, you can just do that with one click. You can also get the pointer to the memory this value is
pointing to, or even the pointer pointer. And DDR also tries to detect if the address which is
stored in a certain register, if that one points to a certain API call like virtual protect.
And if that is the case, it will also resolve the API call so you can see the human readable name
of the function call. After you have run a trace and DDR has all the instruction traced,
you can highlight the instructions with a color. You can just highlight them depending on how many
times they were executed. So you get a pretty quick overview about which basic blocks were
executed by the program and how often these basic blocks were executed by the program.
As you can see here on the slide, if you see a color which is a more warmer color,
like red or purple, you know that this basic block or these instructions were
executed many times. So it is likely that it is maybe a decoding routine or something like that.
So that already gives you a good clue about what the sample is doing
and what parts of the sample are executed and what other parts are maybe not executed.
You can also get a table of all the API calls the sample has executed. So you can search
through this list. You can search for certain API calls like a virtual alloc or something like that.
And then you can do a double click on the line and you are jumping to the disassembly code
where this API call was called. The same applies for strings. As I mentioned earlier,
DDR tries to collect all the strings at runtime. And it is filling this table with these strings.
And the table is again searchable. So you can look for certain interesting strings like PE,
for example, if you're looking for a PE header, and then double click on this line
and check out in the disassembly what's going on where this was used.
And we will see all of that later on in the live demo.
Another neat feature of DDR is that there's a smart way to dump buffers at runtime.
So all you have to hand over to DDR is the size of the buffer, the address of the buffer,
and when or where you want to dump the buffer. And we will also see that later on. For example,
you just have to mark the operands in the disassembly which are storing these
informations. The size, the address, and at the end where you want to dump the buffer.
Unfortunately, often malware comes with anti-analyzing features.
And it is not executed like it would be executed on a normal PC.
If you're running it in a VMware, for example. So DDR comes with an option to patch the sample
at runtime. So for example, you can knock out certain instructions. Or you can toggle the
E-flag and manipulate the execution flow. So if there's a conditional branch, you can just
toggle the E-flag and the conditional branch will do the exact opposite.
But again, we will see that later on also in the demo.
And last but not least, you also have the option to completely skip certain functions.
You can just mark a function, skip it, and return a fake return value.
So if you have, for example, a certain function in your malware sample which is
checking for virtual machines or for anti-debugging stuff, you can just skip the function
and return the value which is telling the sample that it is not getting debugged or that it's not
running on a virtual machine. But again, we will see that later on in the demo.
If IDA and DDR is not enough for you to analyze the sample, you can also create an x64 debug
script which is automatically executing the sample. So it automatically loads the sample
into x64 debug and it is automatically breaking at that address which you have
highlighted in IDA when you have picked this menu point.
If you don't like x64 debug, you also have the option to create a new executable of the
binary with an endless loop at the marked address. So you can mark a certain location or certain
address inside of IDA, pick this menu option, and then a new binary is generated which has an
endless loop patched at that location. So you can start the binary, it starts to loop endlessly,
and you can attach your favorite debugger to it, restore the bytes, and proceed debugging it.
Okay, that should be enough for a quick overview about what you can do with DDR.
In the upcoming demo, we will see all these features in detail again. So let's start with
the installation. Of course, first of all, you have to download DDR. You can get it from
its repository on GitHub. And once you have downloaded it, it comes with an installation
script. And pretty much all you have to do is to execute this installation script, and it will
guide you through the installation process. Again, we will see that later on in the next demo.
If you want to stay up to date with the latest versions of DDR, you can follow me on Twitter.
And every time I'm changing, fixing, or fixing anything, or releasing new stuff for DDR,
I will announce that on my Twitter account. If this presentation is not enough for the
information you are looking for, you can also find a very detailed blog post about DDR,
which I've released end of May on our blog, which is also describing the different
steps, the different features, and the best practices,
and the caveats which you have to be aware of when you are working with DDR.
DDR has a client-server architecture. Keep in mind that DDR is instrumenting the binary. So the
binary is getting executed at the end. So it is highly recommended to split the analyzing part
and the execution part, so that you have an analyst PC where your IDA is running on, including the
plug-in, and a dedicated malware PC where you are executing the malware sample and analyzing
the malware sample. The DDR server is controlling the backend of DDR, which is implemented
using the DynamoRIO framework, and that one is at the end executing the sample,
instrumenting the sample, and collecting all the data, which is then transferred back to the
IDA plug-in. But we will also see that later on in a demo.
Okay, so enough theory. Let's have a look how that looks in the real world.
Installing DDR is pretty straightforward. All you have to do is to execute the
ddr-installer.py script, and it is solving all the dependencies for you.
After it has downloaded all the dependencies, it will ask you a couple of questions about the IDA
installation directory, the IP address it is supposed to listen on, etc. etc. And after you
have done that, you can start a local HTTP server, or in other words, the script is starting an HTTP
server for you. And then you can move over to the IDA machine and access this HTTP server and
download the DDR IDA plug-in site of the installation. Then you unzip the file and
copy over the content to the traditional IDA plug-in directory. That will change in the next
release, which is coming out very soon. And we will move over to the IDA user plug-in directory.
So that has the advantage that you will not need any administrative rights anymore.
Once you have done that, you need to figure out which Python version your IDA installation is
using. And then you need to install two dependencies for this Python version, the
requests library and the pfile library. And with this, you are ready to go. And you can move over
to the server side again and start the DDR server. Okay, so after we've seen how the installation
works, I can give you now a quick walkthrough of the different DDR features, which I've mentioned
earlier. Okay, for this end, we have a dedicated analyst PC where IDA is running on, including the
plug-in. And we have a dedicated machine where we are executing the malware on and where DDR
server is running on. So let's move to this malware machine. Once on the malware machine side,
we are starting the DDR server via the DDR server Python script. And when we are starting it,
there's a little hind that you have to be aware of, that there is a caveat with
Windows command prompt and Python scripts. If you're marking any text in the output window, you are
freezing the Python application. So that means that if the plug-in would try to talk to the
server now, you would run into a timeout. If that happens, you just need to
hit escape a couple of times or just do a ctrl z and restart the server if you like.
Okay, so let's move over to IDA.
The first thing you usually want to do is you want to run a trace. A trace is filling all the internal
data structures inside of DDR which are necessary for most of the other features. And you have two
options, either to run a light trace or a full trace. A full trace is a trace which is collecting
as much information as possible per instruction. So for example, it is saving all the
register values for every single instruction. A light trace is only collecting a subset for
these informations, but enough informations that you can have a look at the API calls, for example,
or at the strings which were traced, or to get a source operand. And a light trace is usually
something which I'm running when I start to analyze the sample. And if I just want to get an
overview, if I just want to highlight the traced instructions, for example, or if I just want to
see the API calls, then the light trace is good enough. Later on, when I'm analyzing a crypto
algorithm, for example, and I need more informations, for example, all the registers,
then I'm running a full trace. But I'm only running a full trace for a small address range or
for a few basic blocks, for example. Because this is really time consuming and it is also consuming
a lot of memory. So you usually want to limit the amount of instructions which you are instrumenting
within full trace.
Okay, enough about traces. Let's run the light trace and check how that looks like on the DDR
server side. So the sample is executed and the dialog box which you have just seen just belongs
to the sample code. It doesn't have anything to do with DDR. Don't be confused by that.
Once the analysis is done, you can see that the trace log file is written to the same directory
where the original sample is located. And you can also see that the temporary trace files
were deleted based on a server command and then transferred over to the IDA plugin. So now we can
switch back to IDA. And we also see this method can switch back to IDA. And we also see this
message inside of IDA that the light trace was done successfully. So this means that DDR now has
all the information it needs. And we can execute other features like highlighted traced instruction,
which is giving us an overview about which basic blocks were executed or which instructions
were executed. Okay, so let's move to the next feature. You can nop out instructions at runtime.
So if you have certain instructions which you want to get rid of, like the dialog box which
we have seen earlier, you can just mark these instructions and you go to the patch menu in DDR.
And then the next time you execute the sample, so for example you run a new trace,
then these instructions are nopped out, they're not getting executed anymore. And you can see here
that it is responding much faster because we didn't have the pop-up of the dialog box
and the sample immediately proceeded with execution. Okay, the next feature which I would
like to show you is how you can use the dynamic values which were collected by the trace.
Now first we are doing a trace again. This time we are just doing a trace over a couple of
instructions. Now you're picking full trace for marked address range. And once this is done,
we have all the values from these instructions inside of the database. So we can just go to
get value for source operand and we are getting the value for RAX in this case.
Or we can just get the values from memory pointers like you can see here,
or all kinds of other information DDR has collected.
The next nice feature is that you can collect all the strings and API calls at runtime.
You can show both of them via tables where the DDR menu. So if we are looking at the strings,
for example, this is a list of all the strings which we have collected at runtime. And of course
you can also search for something in there, like PE for example. And if you're double clicking
on the line, then you're jumping to the line in the assembly where it is used.
You can also have a look at the API calls which were executed at runtime.
And again, the same applies like for strings. You can search for something and double click on it.
And then you see where it is used inside of the code.
You have seen earlier that you can manipulate the code flow by nopping out instructions.
But there are also other options inside of DDR which are manipulating the code flow.
The next one which I would like to talk about is the option to toggle the E-flags. So for example,
if we have a code like this, where we have a conditional jump and a comparison before,
then we can toggle the E-flag at the jump. In this case, you have to know that EAX can
never be bigger than 5. So at least in theory, this jump should always be taken in this code.
And the program should print out main A is not greater than 5.
If we want to manipulate that, we can just mark the GLAE instruction, do a right click,
and go to the patch menu inside of DDR.
Inside of the patch menu, we pick a toggle E-flag. In this case, we have to toggle the SF-flag.
And once this is done, we can now just run the sample if we want.
So for example, again over the patch menu, if we pick that one, then the sample is just
getting executed. But we could also use any other feature of DDR, running a trace or doing a dump,
which we will see later on. All these patches which I have applied will work for all the DDR
features. Once we executed it, then we can move over to the DDR side and check the output of the
file. Sorry, of the executable. So here you can see that the patch worked, and the program printed
out A is greater than 5, and this should never happen. The last option you have is you can skip functions
at runtime. So for example, if we have my function 1 here in this case, maybe something which is doing
some anti-analyzing, anti-debugging stuff, you can just skip it and you can fake the return value.
You're just marking the first instruction in the function, and you are going again to the patch
menu, skip function at marked address at runtime, and you hand over the faked return value, and that's it.
Now you can execute the sample again.
And if we are moving over to the DDR server side, we see that the sample is getting executed,
and in the output of the sample, we see that the my function 1 output is gone,
because the my function 1 is not executed anymore.
And another main function of DDR is that you can dump buffers at runtime.
And you can do that in a smart way. Later on, this string will be copied into this buffer,
which we are going to dump. So remember that for later. So for example, if you have a function
like virtualalloc, all you have to do is you have to mark the operand, which is storing the size of
buffer. Get buffer size. And the next thing is you mark the operand, which is storing the address
of the buffer, which you are going to dump. Get buffer address. And last but not least,
the final step is you mark the instruction or the location where you want to dump the buffer.
So use marked address to dump buffer to file. That's it. Now you can go to the dump menu and
execute the sample and the buffer gets automatically dumped at runtime. Once it is dumped,
it is transferred over to IDA and you can store it somewhere on disk.
And here you can see that it is the buffer which I've mentioned earlier,
where the program has copied the PE string into.
If you want to debug the sample inside of x64 debug, you can also generate x64 debug scripts,
which are automatically setting a breakpoint at the location which you have. So once you
generated the script, you can load it into x64 debug. All you have to do is to run the script,
it will automatically stop the sample and break at the breakpoint which you have highlighted in IDA.
So here we have reached the breakpoint, the script has finished,
and now you can proceed debugging in x64 debug.
The last feature which I would like to show you is how to create endless loops in binaries.
So if you want to create an endless loop, you can just mark the line where you want to create the
loop and then you select create executable with loop at marked address. Now DDR is creating a
patched binary and you can move over to the DDR server side and you will find a patched binary
inside of the samples directory. So now you can start this binary, just double click on it and
at a certain point we are reaching this endless loop.
So now we can attach our debugger to it and proceed debugging the sample.
So after pausing the sample, of course first thing you have to do is you have to replace
the patched bytes. The patched bytes of the endless loop will help in the DDR server
output to see what kind of bytes you have to patch.
Now you're just copying the address into this command
and then finally you have the original commands back inside of the binary.
So when we are proceeding to debug, you see that this changed to the original
bytes and now you can just proceed debugging like usual.
And that's it.
Okay, so this was the installation and the feature walkthrough of DDR.
Let's move on and have a look at some of the special cases and of course the best practices.
The better you know DDR, the more efficient you can use DDR.
And as usual, the easiest is to watch a quick live demo about it.
When I start analyzing samples, I like to run a quick light trace.
Light trace is only executing 20,000 instructions by default.
You can change this default value. If you're running a light trace,
you can probably set that up to 200,000.
But this is in this case for this sample not necessary, so we can leave the default value.
Once the light trace is executed, we can highlight the traced instructions to see which
basic blocks were actually executed.
This was pretty quick in this case, so let's see what's going on.
Highlight traced instructions and we see that there are only four
basic blocks which were actually executed.
So it seems to be that there is some anti-analyzing checks going on.
So let's go into the last function which might be responsible for this check.
So when we are scrolling down a little bit, we see that it seems to be that this function is
dynamically resolving the getNativeSystemInfo API call.
It's using getProcessAddress. We see that pretty often in malware samples.
Then it is storing the address in this variable.
And a bit later on, it is subtracting 10 from this address.
And a little bit below, we see that this value is pushed as an argument to the next function.
So it seems to be that the first argument of this function
is this getNativeSystemInfo API call function address minus 10.
So when we are looking at the first argument here, we see that it is executing a couple
of mathematical instructions. And it seems to be that it is just
adding 10 to it. So it has restored the original address.
And it seems to be that it is just calling the getNativeSystemInfo API call here at that point.
Unfortunately, in real malware, this is often much more complicated.
So in real malware, we often see that these calculations are distributed
all over the place. And they are heavily obfuscated.
So it's often very difficult to figure out what is actually called at this point.
With DDR, that is much easier. You can just do a right click,
and you can get the value of this function pointer.
Just pick getValue for pointer and source operand.
And then you see the value which was used at runtime.
So it is confirming what we assumed getNativeSystemInfo is called.
With this information, we can now go one level up.
And we can change the name of this argument to function pointer getNativeSystemInfo minus 10.
And we have also seen earlier in this function that there was one parameter pushed.
And this is the second argument of this function.
So if we are looking at the getNativeSystemInfo,
we see that this is actually a pointer to the system infrastructure,
which is storing all the system information.
So again, we can go to the function above.
And we can find the second argument here.
And we can also rename it to something like systemInfo or whatever you like.
As far as this is a stack variable, which is pointing to a structure,
we can also do some housekeeping and quickly assign the right structure to it.
So that makes it a little bit easier when we are proceeding the analysis to see what's going on.
So here we can see that here is actually a comparison between the number of processors
and three. With a closer look, we see that if the number of processors
of the machine where the sample is running on is smaller than three, then
we are just printing out a likely virtual machine detected.
So if it has two or less processors, the sample assumes that it is running on a virtual machine.
If it is more than two processors, it is returning zero.
And again, if we go one level up, we can see here that it is comparing EAX.
And only if it is zero, then it is proceeding with the rest of the malware code.
If not, it is just exiting.
Let's rename the function quickly to something like VMCheck and let's proceed analyzing.
So of course, we are also interested in the rest of the code. And to make sure that we can
execute it on a virtual machine, we can just toggle the EFlex like you have seen before.
In this case, it's a jump zero, so the zero flags are fine.
So let's run the trace again and wait for the results.
Okay, so I've cheated now a little bit and fast forwarded the video. We run into a timeout.
So we are seeing this warning message here. And it is telling us that the response from
the DDR server took too long. By default, the plugin waits for 30 seconds to get the results
from the DDR server, the trace for example. And if you like, you can change this behavior here
under API timeout. You can increase the timeout, for example, to 60 seconds or to 100 seconds or
whatever you think works. And then the plugin waits for a longer time. So you've seen earlier
that you can also configure the number of instructions, for example, which are supposed
to be analyzed. And you can play with these two values a little bit. Of course, if you're
increasing the number of instructions, much more data will be collected. And the files which are
going to be exchanged are also much bigger. So sometimes it helps to increase the timeout to
do these kind of long traces. But nevertheless, make sure that you're not
increasing the number of instructions to a too high value. Keep always in mind that it is also
increasing the file size of the data which is collected. So coming back here to our issue
that it timed out. We can, for example, now look over to the server side and we can check if there
was some internal error. For example, there could be a bug inside of DDR which caused a crash, for
example. Or there could be some other reason. A super endless loop or whatever. And a sleeper,
whatever. And we see here that the analyzers run for 60 seconds. So it seems to be that it was
successfully executed. When we are now going back to IDA, we can proceed with the analyzers
of the malware to get an idea about what happened. And usually you would now check these
instructions what's happening. Of course, I'm not doing that in detail here in the demo.
And I know the result and the reason for the timeout in this case is a sleep timer.
So you have a sleep timer here which is actually waiting for 60 seconds. And of course that is more
than the 30 seconds. And we haven't reached the maximum number of instructions at that point
yet. So the DDR server side is still trying to analyze the sample. But there are no new
instructions before this sleep is not over. So this means that the analyzers are still
going on the server side. But the plugin runs into the 30 seconds timeout.
So we could now increase the timeout, for example, and just wait for a little bit longer. Or again,
we can just here knob out these instructions and run it again. I don't like to wait, so I prefer
using the knob out functionality. And now we are running the trace again.
And now it should be a little bit quicker. So light trace done. And now we can clear
the old highlighted instructions, clear highlighted instructions. And we can highlight it again. And
now we can see the new path with all our patches which we have applied. Now you see that we have
manipulated the VM check here, even if it has detected the VMware. Nevertheless, we toggle the
E-flag here and we are going this way. And now it is checking here if its name is evilmalware.exe.
And if that is not the case, then the sample is going this way. And a quick summary of what's
happening here is it is copying itself over to the temp folder. And then finally here, after the sleep,
it is creating the process and starting another instance of itself just from this other directory.
So this is the reason why we are seeing that we are reaching here this exit call. And the sample
seems to be... or the execution of the sample seems to be stopped at that point.
In reality, it has started the new instance. And the new instance is running under this name.
So it will now go this path and will proceed to execute the rest of the code.
This should be enough for this sample. So let's move on to the next one.
Actually, one which we found during a recent apt-temp campaign.
It is an executable which looks like an XML file. But as you know, if you run that on the command
line, it will execute it like any other normal executable. So to get an overview about what it
is doing, as usual, we are just running a quick light trace with DDR. And when we are moving over
to DDR, we suddenly see... oops, what that? The window disappeared. So it seems to be that
maybe the process was killed or something like that. Interesting. So we are moving back to IDA.
And we suddenly see that the light trace was nevertheless successfully executed.
So it seems to be that the DDR process is still running in the background.
So what's going on here? To get an idea, it's always a good idea to check the API calls which
were executed. And when we are looking at those, we see that there's a couple of initialization
going on. And stuff like rebuilding the IRT, for example. A lot of get process address calls.
And after that, we suddenly see, oh, there's a show window API call. That looks interesting,
because with show window, you can manipulate the window. And when we are looking into the
disassembly, we see that it is using get console window to get the handle of its own window. And
then it is executing show window. And show window is using ESI for the command show parameter.
And ESI is cleared right before. So we can be pretty sure that ESI is zero in this case.
But even if it would be a more complex function in a different sample, for example,
of course, we can always use DDR to get an idea about what this value is. Here in our case,
zeros, obviously. So it is handing over a zero to show window. And if we are having a closer look
to the show window function, we see that the command show parameter is offering a couple of
different options. And if it is zero, it is just hiding the window from the desktop. So we have
solved the issue why the command window suddenly disappeared. It was not killed. It was just moved
into the background. So this is one of the examples how you can pretty quickly analyze
what's actually happening with your sample.
And now you could either leave it like it is in this case, because it doesn't hurt. Or if you
still want to see the window, you just go ahead and you kill these instructions, because you
don't need them for anything else. You can just knock them out,
about mark instructions. And then we are restoring the snapshot on the
on the other side, on the DDR server side. And once it is restored, we can just run the sample again.
Just do a glide trace again.
And now we can see that it is running normally like before, but it is not
hiding the window anymore, because we have knocked out these instructions.
And we are done. And we can proceed with our analysis.
Back to the presentation. Another special case which I would like to talk about is if you
want to analyze the sample in an air-gapped environment. So for example, if the sample is
doing excessive anti-VMware checks, or if you have to disable the networking for any reason,
there are probably many cases why you want to analyze the sample on an air-gapped system.
You can do that because the engine of DDR is implemented in a way that it is a command line
tool. And it is heavily leveraging the DynamoRIO framework to do all the instrumentation.
So at the end, the DDR server script is just executing this command line tool to
inject the DDR DLL into the sample. The DDR DLL is the engine which is doing all the analysis,
which is saving all the traces and the registers and so on. And if you're running this command
tool via drun-cclient-dll and the sample-to-instrument, you will get a JSON file back.
Or actually, you're getting two JSON files back, one for the instruction trace and one
for the API trace. These JSON files are looking like this. So they have all the
information per instruction in it. So all the registers, all the values of the registers
at the point of the instruction, the E-flex, the disassembly, etc., plus the memory location,
which might be interesting, and so on. And this is a JSON file which is getting transferred over
to the IDA side, which is the IDA plugin reading to fill in its data structures.
And with this file, you can then use the plugin like you have seen before.
So you've seen earlier in the command that you have to hand over a configuration file.
You will find in the docs directory of the GitHub repository a sample configuration file,
which is heavily commented and gives you an idea about what kind of commands you can
write into this configuration file. We will see in the demo, you can also use the output of the
DDR server script to get an idea about what's going on and what kind of values you can use.
So for example, you can just generate a certain command via the plugin and then you can check the
generated configuration. But again, we will see that later on in the demo.
So talking about the demo, let's have a look at it and see how that looks on the command line.
So when you are running the command line tool the first time, you can cheat a little bit by
looking at the server output. The DDR server is printing out the command which it is actually
executing. And this is the command and the configuration which belongs to the command,
which was automatically generated by the IDA plugin. So you can start with using the GUI
and then you can have a look at the configuration file in the command line. And this gives you
probably a good idea how these things are actually working. And for the details,
again, you have the documentation in the docs directory of the GitHub repository.
So let's just run this again.
And once it is finished, we see that it has written all these trace files to the samples
directory. So let's move over to the samples directory.
And we see that we have all these generated traces here. But there are also further files
like the DDR process trace. And the DDR process trace is a file which is logging all the processes
which were started by the sample. And pretty much the same, but for threads, are these threads
files. They include the information about which threads the certain processes have started.
So if we are looking at the processes file, for example,
we see that the original sample has executed a second process, the evilmalware.exe.
And DDR is following all the threads and processes which the original sample is creating.
So we have seen earlier in IDA the trace which was imported for the main
thread and for the main process. We haven't seen the second process in IDA so far, but
the trace was generated. So we can go back to IDA and we can import this one and then we have
all the instructions which were executed by the process evilmalware.exe, the second instance
of the buffertest.exe file. And let me show you how that works.
Okay, so we are back in IDA and you hopefully remember the sample which we have looked at
earlier. The buffertest.1, the one which was checking if its name was evilmalware.exe.
And if that is not the case, it is copying itself to the temp folder and executing itself
under this name again. And you remember that we were only following the main process here and
we were able to highlight the instructions down to the point where the initial process exited.
But of course we are also interested in the second part and what happens with the second
instance and what kind of code is the second instance executing. One thing we could do,
of course, is we could just manipulate the code again like we've done before,
or now we are importing these files which we have just generated.
So we can clear the highlighted instructions and we are using the loadddr trace
button to go to the directory where we have imported these traces which we've seen earlier.
So now I'm interested in the one of evilmalware.exe. So I'm loading this one for the trace
commands and I'm loading this one for the API calls.
So API calls. So now we have successfully imported these traces, one for the API calls and
one for the instructions. And now we can use ddr like we've done it before and you see that
the second instance which is running under evilmalware.exe is of course going this path
and now we can proceed analyzing these parts and look what it is doing like we've done before.
GetSourceValue or whatever helps us to understand what this sample is doing.
The last thing which I would like to mention is that you should really keep in mind that
it is good practice not to run traces for too many instructions. Keep in mind that
stopping at every instruction and collecting all the registers and all the memory informations
of course it takes a lot of time and consumes a lot of memory. So it's usually good practice
to just mark the basic blocks you are interested in. So for example if we are just interested in
the values of these two basic blocks it is usually a good idea to just select them
at basic blocks to list and this one select at basic block to list and you can see that
it was successful here and then run the trace just for the basic block list.
And it is done. That is much faster, you don't have to wait for too long and you're not creating
gigabytes of files. Just keep in mind that if you are doing that
that you now only have these two basic blocks in the database. So all the others are not traced
or not in the database in the moment. Which means that if you try to get a value from here
of course you're running into an error. It's not in trace. It can be a little bit confusing
in the beginning if you don't think about it but usually you are getting pretty quickly used to
that. And now you can analyze the functions which you are actually interested in.
GetSourceValue or whatever you are looking for. Okidoki, that's it.
So you've seen that DDR is not replacing your brain but nevertheless it speeds up a lot of
reversing tasks and it is usually a pretty big help in analyzing malware samples.
With this I'm done for today and I'm giving back to the folks from the Blue Team Village.