What is the easy way? Read on.
 For there to be an easy way, surely there's a hard way? Yes, hooks. They're redundant in this case... why complicate the process!?!
 What's the easy way? Conditional log breakpoints. 
 
  Example.

 Let's say we're reversing a target that imports LoadLibrary and GetProcAddress. It's a fair
 assumption that because these two functions are present, the target dynamically loads a minimum a 1 function, it may load 50 functions, there's no real way to find out without peaking closely at GetProcAddress during run-time.

 Crack open OllyDbg and load your up your target.

 Right-click the CPU window > View > MODULE "kerne32.dll"

 The CPU window will bring up a list of imported/exported functions, type in GetProcAddress and it will automatically highlight the function for you.

 Right-click > Follow in Dissasembler

 You will land at;

  MOV EDI, EDI

 Right-click on this line > Breakpoint > Conditional log

 Leave the 'Condition' and 'Explanation' fields blank, we're only interested in the 'Expression' edit box. Type "STRING [[ESP+8]]" into the expression field and ensure the following options are set.

  Pause program   > Never
  Log value of expression > Always
  Log function arguments > Never

 Hit 'OK' and execute program as per normal, F9.

 Open the 'Log' (View > Log) window either by, and you will see the following logged strings;

 7C80AE40  COND: EnumDisplayDevicesA
 7C80AE40  COND: GetMonitorInfoA
 7C80AE40  COND: EnumDisplayDevicesA
 7C80AE40  COND: GetMonitorInfoA
 7C80AE40  COND: EnumDisplayDevicesA
 7C80AE40  COND: GetMonitorInfoA
 7C80AE40  COND: glAccum
 7C80AE40  COND: glAlphaFunc
 7C80AE40  COND: glAreTexturesResident
 7C80AE40  COND: glArrayElement
 7C80AE40  COND: glBegin
 7C80AE40  COND: glBindTexture
 7C80AE40  COND: glBitmap
 7C80AE40  COND: glBlendFunc
 7C80AE40  COND: glCallList
 7C80AE40  COND: glCallLists
 7C80AE40  COND: glClear
 7C80AE40  COND: glClearAccum
 7C80AE40  COND: glClearColor
 7C80AE40  COND: glClearDepth
 7C80AE40  COND: glClearIndex
 7C80AE40  COND: glClearStencil
 7C80AE40  COND: glClipPlane
 7C80AE40  COND: glColor3b
 7C80AE40  COND: glColor3bv
 [...]

 There we go, we've logged the functions loaded by the executable and it's modules without the need for any extravagent hooks.

  Untill next time...
  Cheers,
  Ksbunker

Hey guys, today I'll try to teach you how to do a really basic "auto update" type thing.

First off, this script does not automatically download the file, but checks its versioning and prompts the user.

First of all, this is a function that i use to open a file, and read its contents.

Public Function GetFileContents(ByVal FullPath As String, Optional ByRef ErrInfo As String = "") As String Dim strContents As String Dim objReader As StreamReader Try objReader = New StreamReader(FullPath) strContents = objReader.ReadToEnd() objReader.Close() Return strContents Catch Ex As Exception ErrInfo = Ex.Message End Try Return "" End Function

Fairly straightforward stuff. Just reads an entire file.

Dim WC As New System.Net.WebClient Dim ver() As String Dim RunUpdate As Boolean If File.Exists("newversion.txt") Then File.Delete("newversion.txt") End If wc.DownloadFile("http://kingsley.themeparktrips.co.uk/warhammerclient/newversion.txt", "newversion.txt") While Not File.Exists("newversion.txt") End While newVersion = GetFileContents("newversion.txt") ver = Split(newVersion, ".") newMajor = Int(ver(0)) newMinor = Int(ver(1)) newBuild = Int(ver(2)) newRev = Int(ver(3))

We dim wc as a new System.Net.WebClient, ver as an array, and runupdate as Boolean.

We check if the version file exists, if so, delete it.

Then we download the new file.

I just threw the while in there just incase it wasn't as instant as i'd hope.

Then we split the version information up.

Now, this is the part i like, where we detect the version of our client, and compare that to the server.

If newMajor > verMajor Then MsgBox("Your copy of Warhammer Army Calculator needs updating. I will update now") RunUpdate = True End If If newMinor > verMinor And verMajor = newMajor And RunUpdate = False Then If MsgBox("It is highly reccomended that you update the Warhammer Army Calculator" + vbNewLine + vbNewLine + "Would you like to update?", vbYesNo, "Update?") = 6 Then RunUpdate = True End If End If If newBuild > verBuild And verMinor = newMinor And verMajor = newMajor And RunUpdate = False Then If MsgBox("You should update your copy of Warhammer Army Calculator" + vbNewLine + vbNewLine + "Would you like to update?", vbYesNo, "Update?") = 6 Then RunUpdate = True End If End If If newRev > verRev And verMajor = newMajor And verMinor = newMinor And verBuild = newBuild And RunUpdate = False Then If MsgBox("It is reccomended that you update the arhammer Army Calculator" + vbNewLine + vbNewLine + "Would you like to update?", vbYesNo, "Update?") = 6 Then RunUpdate = True End If End If

Just rememeber to change the string when you decide to use this!!

Then, finally, we detect if RunUpdate has been set to true, if so, we update!

If RunUpdate Then wc.DownloadFile("http://kingsley.themeparktrips.co.uk/warhammerclient/newclient.exe", "newclient.exe") While Not File.Exists("newclient.exe") End While Process.Start("newclient.exe") Application.Exit() Else MsgBox("Your Warhammer Army Client is up to date!") End If

Now, in the form load section of your application, (Possibly) after all this code. We would have something to detect the client name and update accordingly.

Dim MyExeName, Path() As String Path = Split(Application.ExecutablePath, "\") MyExeName = Path(Path.Count - 1) If MyExeName.ToLower <> "warhammerarmycalc.exe" Then If File.Exists("warhammerarmycalc.exe") Then File.Delete("warhammerarmycalc.exe") End If File.Copy(MyExeName, "WarhammerArmyCalc.exe") Process.Start("warhammerarmycalc.exe") Application.Exit() ElseIf MyExeName.ToLower = "warhammerarmycalc.exe" Then If File.Exists("newclient.exe") Then For i = 1 To 5 Threading.Thread.Sleep(1000) Application.DoEvents() Next File.Delete("newclient.exe") End If Else If File.Exists("warhammerarmycalc.exe") Then Process.Start("warhammerarmycalc.exe") Application.Exit() Else 'donno wtf happened, copy me over it! File.Copy(MyExeName, "WarhammerArmyCalc.exe") Process.Start("warhammerarmycalc.exe") Application.Exit() End If End If

As you can see, if its the real client, we delete newclient.exe, else if its a differentname, such as 'newclient.exe', it will delete the orignal, and copy itself over it. Which in turn, will delete the newclient.exe

I hope somebody found this helpful!

Please leave a comment if you have any questions.

This information is nothing new, but I think it's very interesting none-the-less. Given the prevalence of hooks (detours, hotpatches, IAT hooks) in todays scene, it is becoming more important to understand how to circumvent these rudimentary attempts at slowing us down.

Hooks have been spoken about ad nauseum here at zonehacks so I won't explain what they are or how to use them... this is all assumed knowledge (and if you're still uncertain, just browse over Specific's articles). Besides this article is not about hooks per se, but rather how to call function without executing the modified (hooked) line(s) of code.

And so, I present some usermood tricks for invoking/calling WriteProcessMemory when WPM is hooked;

kernel32.WriteProcessMemory Trampoline

USAGE:
 push lpNumberOfBytesWritten ;out
 push nSize ;in
 push lpBuffer ;in
 push lpBaseAddress ;in
 push hProcess ;in
 CALL @WriteProcessMemoryTrampoline

@WriteProcessMemoryTrampoline: mov eax, WriteProcessMemory ; IAT mov eax, [eax+2] ; .idata mov eax, [eax] ; kernel32.WriteProcessMemory add eax, 5 ; kernel32.WriteProcessMemory+5 mov edi, edi ; emulate first instruction push ebp ; emulate second instruction mov ebp, esp ; emulate third instruction jmp eax ; JMP to kernel32.WriteProcessMemory+5

ntdll.ZwWriteVirtualMemory Trampoline ( LoadLibrary/GetProcAddress)

USAGE:
 push lpNumberOfBytesWritten ;out
 push nSize ;in
 push lpBuffer ;in
 push lpBaseAddress ;in
 push hProcess ;in
 CALL @ZwWriteVirtualMemoryTrampoline

@ZwWriteVirtualMemoryTrampoline: jmp @F pszModule db "ntdll.dll", 0 pszFunc db "ZwWriteVirtualMemory", 0 @@: push offset pszModule call LoadLibrary push offset pszFunc push eax call GetProcAddress mov ebx, eax add ebx, 05h ; ntdll.ZwWriteVirtualMemory+5 mov eax, 115h ; emulate first instruction jmp ebx ; JMP to ntdll.ZwWriteVirtualMemory+5

ZwWriteProcessMemory via Syscall

USAGE:
 push lpNumberOfBytesWritten ;out
 push nSize ;in
 push lpBuffer ;in
 push lpBaseAddress ;in
 push hProcess ;in
 CALL @ZwWPMSysCall

@ZwWPMSysCall: push ebp mov ebp, esp push [ebp+18h] push [ebp+14h] push [ebp+10h] push [ebp+0ch] push [ebp+8h] mov eax, 115h mov edx, 7FFE0300h call dword ptr [edx] leave retn 18h

ZwWriteProcessMemory via KiFastSystemCall

USAGE:
 push lpNumberOfBytesWritten ;out
 push nSize ;in
 push lpBuffer ;in
 push lpBaseAddress ;in
 push hProcess ;in
 CALL @WPM_KiFastSystemCall

@WPM_KiFastSystemCall: push ebp mov ebp, esp jmp @F pszModule db "ntdll.dll", 0 pszFunction db "KiFastSystemCall", 0 @@: push offset pszModule call LoadLibrary push offset pszFunction push eax call GetProcAddress mov ebx, eax push [ebp+18h] push [ebp+14h] push [ebp+10h] push [ebp+0ch] push [ebp+8h] mov eax, 115h call ebx leave retn 14h

ZwWriteVirtualMemory via SYSENTER / Int 2E

USAGE:
 push lpNumberOfBytesWritten ;out
 push nSize ;in
 push lpBuffer ;in
 push lpBaseAddress ;in
 push hProcess ;in
 CALL @WPM_sysenter

@WPM_sysenter: push ebp mov ebp, esp push [ebp+18h] push [ebp+14h] push [ebp+10h] push [ebp+0ch] push [ebp+8h] call @stub leave retn 014h @stub: mov eax, 0115h mov edx, esp int 02Eh ret

I breifly covered the subject of IGZ's encryption in a forum post earlier. Now I figure maybe I should explain how to apply it. I'm not going to post code for the most part, and to follow along you may need a pretty decent understanding of datatypes.

Average Packet Header
[dword header CRC] [dword payload length] [dword payload CRC] [dword command] [dword sequence]

* note: the header is used differently during the handshake phase

Each CRC is a simple (depending on how you look at it) CRC32 value. You should be able to find publicly available crc32 modules for whatever language you are coding in.

Secure Handshake
CLIENT:  00 01 00 00 00 00 00 00 01 00 00 00 00 00 00 00 9A 4E 25 69 00 00 00 00
SERVER: 00 01 00 00 DC D9 62 77 01 00 00 00 8A 59 B5 5B DC 40 26 A9 00 00 00 00
CLIENT:  66 67 66 67 66 67 66 67 00 00 00 00 00 00 00 00 ?? ?? ?? ?? 01 00 00 00
* underlined bytes are the client supplied key (supposed to be generated at random), ?? bytes are the CRC which we need to compute
SERVER: CF 1C 12 6E CC 6B 97 8C 3C 2B DF DD EA 67 FC 3B 78 AC 60 39 01 00 00 00
* underlined is the server supplied key. Our new ice key is now determined by a byte to byte xor of the client and server keys.

 More info to come as I feel like posting it ...

Out of bordom, I decided perhaps this may interest someone. I have no use for this knowlegde any longer as their is no Zone left, just a pathetic mess of a flash gaming site.

When the final update was applied a lot of things were changed. They added a protection scheme, which was identified as armadillo. Armadillo at the time was one of the most difficult schemes to defeat. Most information on the subject was closely gaurded, and there were no public "unpackers". For most of us, it was game over. But fuck that, I'm a stubborn basterd.

They also implemented a change in protocol in the previous update a few weeks (I think?) before. So, fortunately for us not much was changed internally and the files they provided us with earlier had much of what I needed. I may have been no longer able to debug the process easily, but that wasn't too much of an issue.

On to the good stuff!

In ZoneCli.dll there has always been a lot of debug strings. These pretty much highlight exactly what a function is for. Using this technique I was able to identify a number of new functions in the Recv and Send functions used for parsing.

( I'm guessing the scheme they use is some kind of widely used encyption scheme. I never looked into it too much, so I really have no idea. )

The old scheme was simple. (painfully simple psuedocode)

for each dword in packet dpacket = dpacket + (dword packet) XOR key next dword in packet

it''s just an XOR32 cryption scheme. (They actually only used an 8bit key)Anyway, the new scheme is something entirely more complex. It was a hash based encyption layer with a layer of psuedo random bytes using a base seed. I can't go into too much detail (unfortunately I don't remember a lot of it), but I can at least provide the meat and potatos of the implementation.

Psuedo random first layer (applied before the real encryption)
loop_start: imul eax, 343FDh add eax, 269EC3h mov ecx, eax shr ecx, 10h shr ecx, 2 xor [esi+ebx], cl inc esi cmp esi, 18h jb short loop_start

This roughly translates to .. //p is packet data, k is the key for(int i = 0; i < strlen(p); i++){ k = (k * 0x343FD) + 0x269EC3 >> 18; p[i] ^= (j & 0xff); }

At first, I figured this was *all* the new encyption. After decrypted packets looked just as obfuscated, I realized I was dealing with something more beastly. I then identified the following function being called in a loop.

Cryption Layer 2
mov ecx, [esp+8] mov eax, 0FFh mov dl, cl push ebx and edx, eax push esi shr ecx, 8 mov esi, edx mov dl, cl shr ecx, 8 mov ebx, ecx and edx, eax push edi mov edi, edx mov edx, [esp+10h] and ecx, eax shr ebx, 8 and ebx, eax mov eax, [edx+ebx*4+48h] add eax, [edx+ecx*4+448h] movzx ecx, di pop edi xor eax, [edx+ecx*4+848h] movzx ecx, si pop esi pop ebx add eax, [edx+ecx*4+0C48h] retn 8

This roughly translates to..
//k is the key table //p is the packet (dword) to be decrypted //d is the decrypted value d = k[(p >> 0x18) + (0x48 / 4)]; d += k[((p >> 0x10) & 0xff) + (0x448 / 4)]; d ^= k[((p >> 0x8) & 0xff) + (0x848 / 4)]; d += k[(p & 0xff) + (0xC48 / 4)];

As you can see above, a precomputed key/hash table is used for decrypting the packet data. Very annoying. Locating the function that builds the key table was fairly simple (key table location is passed to the client during every encryption and decryption call).

push ebp mov ebp, esp push ecx push ebx push esi push edi mov edi, [ebp+8] push 1000h ; Size push offset dwKeyTable ; Src lea eax, [edi+48h] push eax ; Dst call _memcpy mov esi, offset dwKeyTable2 add esp, 0Ch xor ecx, ecx mov eax, edi sub esi, edi mov dword ptr [ebp-4], 12h loc_1: xor edx, edx mov dword ptr [ebp+8], 4 loc_2: mov ebx, [ebp+0Ch] shl edx, 8 ovzx ebx, byte ptr [ecx+ebx] or edx, ebx inc ecx cmp ecx, [ebp+10h] jl shortloc_3 xor ecx, ecx loc_3: dec dword ptr [ebp+8] jnz shortloc_2 mov ebx, [esi+eax] xor ebx, edx mov [eax], ebx add eax, 4 dec dword ptr [ebp-4] jnz shortloc_1 and dword ptr [ebp+8], 0 and dword ptr [ebp-4], 0 push 9 mov esi, edi pop ebx loc_4: lea eax, [ebp-4] push eax lea eax, [ebp+8] push eax push edi call ZCryptLayer2 mov eax, [ebp+8] mov [esi], eax mov eax, [ebp-4] mov [esi+4], eax add esi, 8 dec ebx jnz shortloc_4 lea esi, [edi+76] mov dword ptr [ebp+0Ch], 4 loc_5: mov ebx, 80h loc_6: lea eax, [ebp-4] push eax lea eax, [ebp+8] push eax push edi call ZCryptLayer2 mov eax, [ebp+8] mov [esi-4], eax mov eax, [ebp-4] mov [esi], eax add esi, 8 dec ebx jnz shortloc_6 dec dword ptr [ebp+0Ch] jnz shortloc_5 pop edi pop esi pop ebx leave retn 0Ch

Andddd I'm not going to translate that one to something more readable for you. Sorry. Its not that hardest thing to break down and understand anyway. The only that that really merrits explaination are the calls to ZCryptLayer2. They are essentially calls to a function which calls the Cryption Layer 2 function against a char array.

Anyway, this was long and probably entirely unnecessary! I know a few EX- die hard zone coders were curious as hell about this, so hopefully you can finally let this one go and leave me alone!

Later.