Comments on: Countslide alphanumeric GetPC

By: moonpants

moonpants — Mon, 11 Jan 2010 04:46:47 +0000

ah yes, what you say makes sense. i was thinking about it a different way (aka the wrong way . that is indeed a clever approach, nice work!

By: SkyLined

SkyLined — Sun, 10 Jan 2010 22:25:14 +0000

We are working under the assumption that you cannot know EXACTLY where your shellcode will start. If you would, you would not need a nopsled at all. Since we do not know where the shellcode starts, we do not know where in the shellcode to put the patcher to have at an exact location. We can only make sure it is in a certain region.

By: moonpants

moonpants — Sun, 10 Jan 2010 20:50:32 +0000

i guess what i’m saying is if you can predict that code execution will start somewhere within [A_min, A_max], then you can assume the address of EIP is A_max and then append the “patcher” stub starting at A_max + 1. This is because A_min and A_max are fixed addresses per your description above.

in other words, you fill [A_min, A_max] with your NOP sled, followed by the “patcher” piece which is really just a fixed geteip that stores the address of A_max + lengthof(patcher) in the desired register, followed by the decoder stub.

what is the downside of doing it this way over what was described above?

By: SkyLined

SkyLined — Sun, 03 Jan 2010 12:54:55 +0000

I need to do all these elaborate tricks to calculate the exact value of A_nop not A_avg; the later is the predictable average address where the shellcode will likely be but doesn't say much about the exact location of the shellcode when it gets executed. The former is what you need to know; it is the exact location where the shellcode starts for each try and it changes with each try. This is a value predicted to be in the range [A_min, A_max]. The countslide trick is the only way that I know to calculate it.

By: moonpants

moonpants — Sun, 03 Jan 2010 02:11:48 +0000

I suspect that i'm being overly dense here... You assume that your nop sled will reside in a predictable sub-region of [A_min, A_max] and based on this you can calculate the fixed address of the countslide (A_avg + D_max * 3 + P). this effectively means you are able to pre-compute the location of your actual shellcode to begin with, since the address of the patcher and the following countslide is a constant. if this is true, why not just replace the patcher with a bit of code that directly initializes ECX to the effective address of the shellcode, since in essence this seems to be what you're doing. I can understand that this value may need to be encoded somehow to be alpha compatible, although it seems like the patcher already has to account for this in your example considering that it pushes this value to the stack. what is the benefit of the added complexity that you describe above?