Week-4

WinDBG

This week we jumped right into labs which was refreshing! I was able to load up my vsphere vm with the exploitme program running within half an hour of starting the hours and hours of lectures so this was a nice turn of events. I’m looking forward to acutally targetting some exploits this week as it’s always something that I’ve found fascinating. And now maybe I can reread the girl with the dragon tattoo series with a different lense.

Running lab 1

My first task was to find the correct files to run. Exploit me seemed pretty straight forward but I tried to follow the setup directions and ran into some oddities. The .pdb file was already located in my C:\Windows\Downloaded… programs file so I initially replaced it there but then was worried that I’d ruined the symlink that the next setup line instructed to create. I ended up reverting my vm back to the most recent snapshot and attempting to forge onward with the assumption that the .pdb file in my Windows directory was put there to make my life easier.

With that in mind, I was able to get the debugger to break at the entrypoint provided in lab 1!

Now I’ll attempt to answer some of the questions outlined in the lab

1) What address is FSExploitme.ocx loaded at?
My initial guess was that the instructions had asked us to but a break point at the entry to the ocx program, so my answer was 54431df0 but I after peaking at the answer, I realized that there is probably a ton of setup that must take place in a program before finding bytes to set break points at, so it would make sense that the program wouldnt start there. In fact it starts at 54430000

2) How large is the stack?

It’s been a while since my assembly class but I believe we can analyze stack size by taking a look at how much room is cleared off of the stack at the start.

14h converted to decimal would be 20 -> 20 bytes is my guess, let’s see how I did.
And I was way off. Running teb shows stack size to be 1900 bytes

I was having trouble running the answer code, as it looks like it can’t resolve the variables I’m interested in calculating “StackBase - StackLimit”

3) What is the starting address of the Process Heap?

This time instead of guessing I thought I’d take a look at the lecture slide cheat sheet. Here I found a command where I can take a look at process !peb

At first I was sad because nothign useful seemed to show up in the command results but it turned out my window was too small!


000e0000

4) What is the value of EIP

Well I know this ones a register so it should print out when the breakpoint hits.

54431df0

5) How much space is issued for local variables?

Maybe the answer to this one is what I initially thought #2 was. I’m going to go with 20, which is the amount subtracted from the esp (or ebp I can’t remember which one goes first)

(Correct! feels good!)

6) Execute 5 instructions with t 5, what is the string at the top of the stack?

I ran a bunch of combinations of dd, da and du on all sorts of locations in memory, but I wasn’t able to turn up anything but gibberish. Going to take a look at the answer and analyze.

Ah interesting I had run du 020e9c14 but I had not made it a pointer. Running du poi(esp) I get

7) Trigger the breakpoint and enter the loop 11 instructions later. How many interations do you think the loop will run?

My guess, the loop will run 10 times.
Here the address at ebp-4 is set to 0, moving it to eax, adding 1 to it, then checking it against the constant 10 and jumping out when its greater or equal.

Surprised I got this one correct!

8) What is the return value?

As stated in lecture, the return value of the function should be set in the eax register, so running pt then r shows that eax has the value 7a69h or 31337 decimal

9) Is the esi value within the Stack, Heap or Text Segment?

Took a gander at the lecture cheat sheet again, they have the !address helper there. Running that shows that esi is on the Stack.

Overall this was a pretty tough experience, although I was able to make it through more than half the questions. I’m running into my lack of general knowledge about how computers work. I’m Looking forward getting more clairity on how assembly plays into the whole picture.

I was happy to see that in the following letures, Brad went into a review about how the stack works within an execution frame, however for me I was still pretty lost. When it got to the last lectures and discussing heap sprays my mind was pretty blown. I hadn’t ever considered javascript exploits in such a way, and I felt like that one student in the videos who couldn’t seem to pinpoint exactly what was going on, so I’ll try and explain it as best I can.

There’s a hacker who finds an exploit some dll called program X. Program X can be run by internet explorer, even if the user has to click “okay” to turn on the dll program. The hacker has verified that by writing some simple javascript code, they are able to push their own code into the dll execution, thus giving them previously forbidden access.

In this situation, the hacker creates a website that innocently prompts the user if it’s okay to turn on program X while viewing the website. The user clicks okay and then interacts with the website. The hacker has already pinpointed the an overflow vulnerability in program X, so once the user turns it on, the hacker’s code overflows some bit of the stack, changes the return address of one of the layers of the program x program. The return address points to some other bit of code that the hacker has written into the stack, in this fake scenario it is the address of hte calculator program.

I was trying to follow along with how the hacker was able to find their shell code within the browser heap, but I still don’t quite understand the heap spray and I feel a bit stuck on the lab so I’ll try and explain my thoughts. The heap spray adds a series of similarly sized blocks of memory to the haep so that when the heap is dumped for inspection, we can quickly skim through the normalized blocks of memory to find the intersting parts that were looking for. My question is, how does this make the block of shellcode reproducably found? Why do we even need ha heapspray, as adding more code to the heap seems like it might just pollute it? It could be my misunderstanding about how heaps work. Perhaps by adding so much into the heap, since the heap must reorganize itself and most added chunks are of the same size, the tree of heap data will eventually even out as the tree grows?

Well, this week was especially hard for me. I’m hoping to rewatch the lectures again and try and rewalk through the different exercises to get a better grasp on the material. I regret taking assembly and this class so far appart as I think it would be really useful to have that type of knowledge fresh in my mind. Windbg and the page heap are super cool tools that I’d like to get more comfortable using! Windbg seems pretty complicated to me right now, it almost seems like it has its own programming language to learn, so hopefully over the course we’ll keep using it and it will become second nature!

Until next week !