Account Management
Users Online
Online Now: Guest1
Recent Active Topics
| Post Title | Post Info |
|---|---|
| DirectPlay | Posted
about 16 days ago Author: Specific |
| Hackshield Bypass | Posted
about 17 days ago Author: iPromise |
| memheader.h | Posted
about 17 days ago Author: boringwall |
| Scorp's Win32 API program | Posted
about 21 days ago Author: Specific |
| RAGE! | Posted
about 22 days ago Author: zhScorpion |
Sponsored Links
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.
Fairly straightforward stuff. Just reads an entire file.
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.
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!
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.
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
ntdll.ZwWriteVirtualMemory Trampoline ( LoadLibrary/GetProcAddress)
USAGE:
push lpNumberOfBytesWritten ;out
push nSize ;in
push lpBuffer ;in
push lpBaseAddress ;in
push hProcess ;in
CALL @ZwWriteVirtualMemoryTrampoline
ZwWriteProcessMemory via Syscall
USAGE:
push lpNumberOfBytesWritten ;out
push nSize ;in
push lpBuffer ;in
push lpBaseAddress ;in
push hProcess ;in
CALL @ZwWPMSysCall
ZwWriteProcessMemory via KiFastSystemCall
USAGE:
push lpNumberOfBytesWritten ;out
push nSize ;in
push lpBuffer ;in
push lpBaseAddress ;in
push hProcess ;in
CALL @WPM_KiFastSystemCall
ZwWriteVirtualMemory via SYSENTER / Int 2E
USAGE:
push lpNumberOfBytesWritten ;out
push nSize ;in
push lpBuffer ;in
push lpBaseAddress ;in
push hProcess ;in
CALL @WPM_sysenter
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)
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)
This roughly translates to ..
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
This roughly translates to..
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).
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.

