Welcome back.
In the previous video, we have managed to track the grade process internal from the first parent Shbg,
and we found that it has spawned a new process called Ramnit manager from the parent process and we
attached to it using the second shbg.
So now we are in a second and the first shbg is still running.
So we have to you can see from the top here the title will tell you this is the parent and this is the
child Ramnit manager.
So now we can analyze this process as well as this process simultaneously.
So for now, we have to put breakpoints on the child process and the breakpoints have be set almost
the same as the ones we set for the parent, as you can see here.
So we come to the child now and we go down and set the breakpoints.
The first one is virtual lock, hit enter.
Just follow the list here.
And the second one is virtual product.
Protect Enter.
And then the next one is, is is debugger present?
So breakpoint on is debugger present.
After that create process internal w so.
Create process.
Internal w hit enter and next one is write process memory.
So type in write
process memory.
Okay.
And we can leave out the last one until resume thread.
So because it is not necessary.
So now to confirm we have got all the breakpoints.
Click on the breakpoints tab and you find there is nothing.
So this happens because this second process is.
Let me see.
Probably suspended state.
So what we need to do is we need to use the first.
Process here to activate the second process.
Child process.
So to do that over here, we can click on run to user code.
So we can click this one run to user code.
Take note.
We are in the first process.
He should be running.
All right.
So now we can repeat this.
Setting the breakpoints virtual.
Hello?
Okay, hit enter.
And this time it works.
So just repeat all the breakpoints from the first list here, from the first process
breakpoint on which will protect breakpoint on.
Is debugger present?
Breakpoint on Createprocess internal
w.
And breakpoint on write process memory.
So just double check to make sure you've got it all.
Once you confirm that it's all there, you can click on CPU here and go back to the first process.
Click on CPU as well.
So this is the first process.
So now we are going to click on Run to see whether it hits animal breakpoints.
No, this is debugger presence is being hit so we can execute your return so that it will execute that
code.
And the result of the API is 001, which means that it's debugger presence is positive.
So we can change it to zero to negate it.
So click.
Okay, run again.
Same same thing here.
Once you see this run to execute your return.
And the result of that API call is again one.
So one means the debugger is detected.
So we have to bypass that by setting this to zero again, click okay and then run again.
Okay.
This time it is freely running, as you can see here, and it is not hitting any more, any more breakpoints.
So now we can go back to the child process remnant manager and continue analyzing here.
And probably we are going to dump the unpack code from this child child process.
So let's go ahead and do that.
Now we can expand on this one.
So let's try to run it now and see if it hits any breakpoints and it hits virtualprotect this Virtualprotect
We can continue to analyze this by stepping over it and see what it is trying to do Jump, jump and
let it push the parameters.
So now it's going to call this watcher protect.
We looked at the second parameter.
It is changing the protection for this region of memory.
4000.
And we can follow this in the dark, number one, if we wanted to.
So from here we can right click on this, follow the in dump.
Kingdom through D-word in current dam.
So here you have something and then look at the memory map for this.
Right click on this and follow in memory map.
Okay, so here you can see this is the main executable at the moment is readable only.
The reason why we follow this in memory dump and then go back to memory map is because we cannot go
to memory map from here directly.
That's why we follow this in dump.
And from dump we follow in memory map.
So now it is only ah, let's see what happens when we execute this API.
Now we go back and it has added the right permission.
That means it's going to do something to this region of memory starting from 004.
Probably it's going to unpack something.
So let's run.
And here's what you protect against.
So let's continue to step over.
Virtual Protect.
Jump.
Jump to virtual protect and come to this call.
Now, it has pushed the all the parameters to the stack.
We look at the second one, same thing.
It is going to change the permissions for this region of memory, which is here.
So we go back and take a look.
It is now readable, writable.
So let's step over this call.
See what happens to that region of memory.
So we have stepped over.
Now we go back and inspect it.
It has removed the writable.
That means it has already unpacked something somewhere in this region of memory.
Could we then dump this?
If you're not sure, you can go ahead and dump and analyze it with the other tools and so on.
We are not sure whether this is the correct place to dump.
So we just continue.
First.
So let's continue now.
We click run and it hits virtualalloc this time.
Okay, so now let's go and we are going to step over this jump log.
Jump to come to this call.
And after we call this, the allocated memory will be shown in X register.
So let's step over and inspect this.
So there you go.
So we follow this in tandem to now select number two.
And here, right click on this following thumb.
So now number two is over here in memory.
And that shows that properly done, number one is not the main X because it is trying to unpack something
else probably done.
Number one is just an intermediate program that is going to use to do something to the final unpack
code or to use the first dump, the portable executable file to unpack dump number two.
So we're not sure this is just a hypothesis.
But anyway, let's continue to explore.
So now we are going to run again.
Which are allowed in at a time.
So we continue to step over this one.
I lock.
And then when we step over this, we should get the new allocated region in, step over and see is two
three followed by four zeros.
That means it's continuing to to unpack code with starting from this region of memory.
If we wanted to, we can follow in dump three.
So we do that right click following dump.
Make sure you select dump three first before you do this.
And now dump three is here.
Let's run.
In his motion along again.
We start over again.
Jump to watch along, come to this call, step away.
And now it is allocating another region memory 2D so we can follow this in dump file select dump four
and right click and follow in dump.
So now down two has got unpack code, dump three and four is blank.
So let's run.
And you see now downfall.
We have got some unpack code in dump four.
Okay.
This time it has hit virtualprotect and you can see now dump four has already been populated with Z.
So it is now going to call Virtualprotect.
Okay.
So at this point in time we can probably dump dump four, but if you're not sure, you can continue
to proceed with the exploration.
But I think at this point, since we have done this before, I've done this before, I can tell you
that this is the correct place to dump.
So what are we going to dump?
Is using process Hacker to dump it.
So we'll do that in the next lesson.
Next video.
Thank you for watching.