Coding UndeRealM

Everybody faced problems with array initialization, error handling for dinamics and so on. Today, first time in my life (and that’s almost 20 year worth of coding) I found a bug out of the blue. Or what I think to be so. Typical example incoming:

On Local Error Resume Next
  Dim sArray() As String, C As Long, D As Long
  D = [102 or 99]
  For C = 100 To D
     ReDim sArray(UBound(sArray) + 1)
     If Err.Number > 0 Then ReDim sArray(0): Err.Clear
     sArray(UBound(sArray)) = CStr(C)
  Next
  Debug.Print UBound(sArray)
On Local Error GoTo 0

' D = 102  -  Ubound(sArray) = 2
' D =  99  -  UBound(sArray) = Error

This example is stupid on purpose, but gets us to the point. If D is set to 99, then sArray is gonna be uninitialized. Which means that we have to set another error handling to check wether or not the array contains something. And this generally brings us pain, it’s always very, very, very ugly to do, but until now it was the only way, aside setting up a base 0 array with data starting from 1, like this:

ReDim sArray(0) As String
ReDim sArray(UBound(sArray) + 1)
sArray(UBound(sArray)) = 1
For C = 1 To UBound(sArray)
   Debug.Print sArray(C)
Next

Another ugly way to do the job, but as I said a little above, there weren’t many ways to do it. Until I found something so stupid to be genial. Let’s see a slightly modified version of the same code.

Dim sArray() As String, C As Long, D As Long
sArray = Split(""," ")
D = [102 or 99]
For C = 100 To D
   ReDim sArray(UBound(sArray) + 1)
   sArray(UBound(sArray)) = CStr(C)
Next
Debug.Print UBound(sArray)

' D = 102  -  Ubound(sArray) = 2
' D =  99  -  UBound(sArray) = -1

You probably won’t understand that, so I’ll explain: the Split() of a 0 length string with a non-0 length string, brings us an amazing Array(0 To -1). You heard it right, 0 to -1. What does this mean?

1. Empty arrays can checked with a (UBound(Array) = -1).
2. Incremental arrays available from scratch, from index 0.
3. Possibility to return safely arrays without the need to define a count variable to set the array lenght.
4. …
5. Profit!

This is one of the most stupid amazing things I ever seen, and it caught me so off-guard I totally didn’t expect it. Could even make it to The Daily WTF?!?

#define CURRENT_YEAR 2008

UINT TimeSpan(const UINT *thisYear)
{
    UINT span = 0;
    for (UINT C = 1981; C < thisYear; C++)
       span++;
    return span;
}

int main()
{
    printf("%ui: I'm screwed!!", TimeSpan(CURRENT_YEAR));
}

This is cryptic, isn’t it?

No wait, probably it’s not ;)

I know what most of the people will think viewing future content or taglines around here: “pfft, vb kiddie”. So, just to preemptively shut them up, here’s some quite advanced asm trick.

A little intro before the code. It is possible, working the way through a SEH, to jump to another location instead of using a standard JMP. The advantage of this is the (eventual) obfuscation of the jump (if done properly), and although I’ve seen plenty of references around the web, I just couldn’t find anything on this matter, especially in the way I wanted it.

What you are going to find about SEH around the web (including dirty tricks) are most likely:

1. Standard way (no tricks at all, just standard behaviour)
2. Jump & Clean (jump to the SEH, never get back)
3. Clean jump based on SEH hack (only here, searched a lot, and never found)

About #1, I will let you seek through the vast ASM/C++ references, no need to talk about it here.

About #2, code snippet:

.code
assume fs:nothing

start:
   push @@SEH_Handler           ; Address of SEH Handler
   push FS:[0]                  ; Original SEH Handler
   mov  FS:[0],   ESP           ; Install SEH Handler
   xor  eax,      eax
   idiv eax                     ; Generate exception
   int  3                       ; Will never reach this
   jmp  @@Exit

@@SEH_Handler:
   mov  esp,  [esp+8]           ; Restore pre-jump stack
   pop  FS:[0]                  ; Reset Original Handler
   add  esp,      4             ; Remove handler address from stack
   [...]                        ; Code goes on from here as normal

This code works perfectly. But there’s a pretty grievous problem with it. That is, it assumes and requires that you are both the author of both codes (pre and post jump) and that you can modify both. Which wasn’t my case.

Example, while writing a packer, or a loader, or whatever you may want to, you just can’t clean SEH handler and the stack after the jump. Because, since the code isn’t yours and can’t be recoded, it won’t do it. And that’s bad. Immagine it doesn’t have an exception handler, and at every unhandled exception it “returns” to your OEP. Nasty, huh? And that’s the least of the problems actually.

Nastier problem is having a “dirty” stack, and god only knows what else could happen. But there is a workaround, which is cleaning and resetting everything inside the SEH handler, with a bit of hacking and eventually some heuristic approach. At least mine had to be, I knew nothing about it.

.code
assume fs:nothing

start:
   push @@SEH_Handler           ; Address of SEH Handler
   push FS:[0]                  ; Original SEH Handler
   mov  FS:[0],   ESP           ; Install SEH Handler
   xor  eax,      eax
   idiv eax                     ; Generate exception
   int  3                       ; Will never reach this
   jmp  @@Exit

@@SEH_Handler:
   mov  eax,      [esp+C]       ; Pointer to SEH Data
   add  [eax+C4], 8             ; [1]
   mov  [eax+B8], @@JustGoOn    ; [2]
   mov  eax,      [esp+8]
   mov  eax,      [eax]         ; Pointer to original Stack
   mov  FS:[0],   eax           ; Reset Original Handler
   xor  eax,      eax           ; Set to 0 to "return"
   ret

Pointer to SEH data ([ESP+C]) points to a zone in the stack with lot of infos, including hardware breakpoints and (between the other things) the exact stack address returned to you after the jump. And, of course, the address it will return to.

[0] – [ESP+C]: SEH data
[1] – [[ESP+C]+C4]: Original Stack Address (pre-jump)
[2] – [[ESP+C]+B8]: Return Point

Adding 8 in point [1], makes the kernel return to the address with the stack pointer set to the original one (pre-jump) minus the two push instructions (first two instructions after the start:). Which also basically means, it will return from the SEH handler with the original stack pointer, just as if the code started from the return point.

The point [2] should be fairly readable and intuitive, hacks the stack to “hack” the return point. Another approach, in case you wanted to continue right from the next instruction, would have been to add the size of the operand to the address (in this case the size of IDIV EAX). Just to remind you, the default SEH way is to return to the very same instruction that caused the exception.

With this piece of code you achieve two things: the first and most important, you perfectly and seemlessly jump from one context to another, just as there were two programs in the same executable; secondly you have the ability to easily obfuscate the jump, which in this case is pretty obvious, but that’s up to you, not me.

This is it. Guess this article makes quite a good start, doesn’t it?

We’ll be seeing again.

Coding UndeRealM has just been launched.

There is a lot to come in the next few days, stay tuned!