ok so good luck guy
i'm curious to read your article. i just have some ideas on how it could be working but nothin sure.
what i initially wanted is a full bypass for any memory protection. but if i dont find anything new, than it wont be possible...
but maybe your specific research and workaround can be applied against some more protections
Hooking CreateRemoteThreadEx (75A4BB2F) for Windows 7 support.
Found the CSRO security thread!
Information:
BaseAddress: 1DB26000
AllocationBase: 1DB20000
AllocationProtect: 40 (PAGE_EXECUTE_READWRITE )
RegionSize: 950272
State: 1000 (MEM_COMMIT )
Protect: 40 (PAGE_EXECUTE_READWRITE )
Type: 20000 (MEM_PRIVATE )
The scanning function address is at 1DB8439A.
The scanning function should be hooked at 1DB84D53.
The second scanning function should be hooked at 1DC04C89.
[edxSecurity::ScanLogic] Patching B9 to 8B in the code section at 00491D1E.
[edxSecurity::ScanLogic] Patching 33 to 4C in the code section at 00491D1F.
[edxSecurity::ScanLogic] Patching 00 to 24 in the code section at 00491D20.
[edxSecurity::ScanLogic] Patching 00 to 04 in the code section at 00491D21.
[edxSecurity::ScanLogic] Patching 00 to 81 in the code section at 00491D22.
[edxSecurity::ScanLogic] Patching 90 to E1 in the code section at 00491D23.
[edxSecurity::ScanLogic] Patching 90 to FF in the code section at 00491D24.
[edxSecurity::ScanLogic] Patching 90 to FF in the code section at 00491D25.
[edxSecurity::ScanLogic] Patching 90 to FF in the code section at 00491D26.
[edxSecurity::ScanLogic] Patching 90 to 7F in the code section at 00491D27.
[edxSecurity::ScanLogic] Patching A8 to 08 in the code section at 0049E6F4.
[edxSecurity::ScanLogic] Patching 36 to 94 in the code section at 0049E6F5.
[edxSecurity::ScanLogic] Patching 5E to FD in the code section at 0049E6F6.
[edxSecurity::ScanLogic] Patching 70 to FF in the code section at 0049E6F7.
Just another little status update. I've figured out how the client loads their anti-cheat logic into the process and have been able to successfully load it into my own program. That means I can easily study the software in memory and work out how their logic is setup a lot more easily now than trying to work with it through Silkroad, which takes forever to startup and login. Being able to load it myself will save a lot of time.
There is still a lot more work to do, since the client calls functions of the security module and passes it data and whatnot, so my current task is working out all of those interactions to figure out how I can emulate the client interactions. I have done the basic steps to get it initialized though, and I know it is working because my packet sending function I pass to the security module gets called. Here's an example of the output:
Code:
MySend
1D EB 25 BD 64 45 9B 73 B6 0B BF 89 82 57 26 FF
35 FB EB 64 C9 E6 3D 11 84 B8 6F E2 26 82 41 04
72 D3 20 C9 4D 2F 4C A3 AC D9 DA 0C 1E 16 88 70
BB B4 EE 41 2C 8B EC 56 5B 0C 9E AB C3 FD D2 92
0E 5B 35 79 60 3F C3 A2
MySend
80 8B 20 B2 BB 29 55 52 9B 55 E2 88 C4 09 A1 27
2D 7C 81 2E 42 86 F1 84 FB 00 3E 2A D0 AE B3 B6
98 3F 04 F1 80 16 1F 73 39 AB CF 1D 07 DC 21 40
74 0D 5C 76 31 F8 8C F1 FE 69 D2 93 97 84 3F C7
E7 DB 1A B6
MySend
20 26 DB 41 AF 29 1D B0 4A 5A D5 1F F3 BF 95 92
C9 07 AA A9 91 6D C4 11 BA 42 38 C3 C2 FB 3E F1
75 9E FE 01 F6 2D 1E D0 25 29 08 C0 25 15 5F 72
5F 45 18 51 08 18 1B 10 89 E4 8E 05
I still have to work out what the data is and how it is generated, but it is a lot easier since I can quickly and easily trace back into the memory from my own program and Olly. I have a feeling those packets are encrypted by this logic:
Since I am running the code in my own program, I can just calculate the offsets of this particular function and modify the logic myself before the security module runs to be able to break into the execution flow and reverse their algorithms. Without the knowledge of getting the security module loaded, this would not be easily doable. I'll just add an int 3 to the function entry point to be able to break on entry in the debugger.
So, progress is still going good and strong, but as I mentioned before, there is a lot of code to work through and it does take a bit of time figuring out all this stuff. I do hope to be able to reverse it all though, because as of right now, there are no real obstacles that make reversing harder than usual.
I'll post again later after some more significant progress has been made.
nice one
i also did some researches. not much and what i found confuses me:
it creates a full CRC of the client data in memory from start +0x1000 until nearly the end of the clients memory.
dont know, why they dont fully scan it. there are just a few bytes left.
what i also found is that it is running in an extra thread and it uses a table with offset and size like: (0x401000|0x1000;0x402000|0x1000;0x403000|0x1000.. .)
this table is dynamicly generated (as expected) but the initial offset of the table seems to be static. only problem: i cant find where it gets its memory
on startup the memory is not set.
later it extracts some pk2 files there and free the memory after that
and than suddenly (without a virtualalloc call or virtualprotect) there is the table...
strange...but it seems i had to BP zwvirtualalloc instead of just virtualalloc (due to globalalloc, getheap...)
but the strangest thing is: the crc checksum seems to be never used. t is just checked for zero and than deleted restarting the continous calculation...
could you (if you have time) document what you found (functions, reversed code) and maybe how you got it?
because as mentioned i just got that strange CRC calculation
could you (if you have time) document what you found (functions, reversed code) and maybe how you got it?
because as mentioned i just got that strange CRC calculation
Sure, after my previous versions of this project were detected time after time, I decided I needed to understand the whole system if I wanted to get around it. So, I started looking for the answer to the first important question, how does the csro security get loaded into the process?
If you watched the last update, you'll notice the rdmex files were updated as well as data/ahclient.dat. After looking for new processes being started and tracing where the cltax.cc file is used (inside the security code, which is after it is already loaded) the only thing left to look at was how ahclient.dat was used.
Since the ahclient.dat file is inside the PK2, that means they have to access it through the GFXFileManager DLL interface. I tried searching the client for referenced text strings for ahclient, but none were found. So, I just set a breakpoint inside the PK2 lookup function. Just find a known pk2 file access, like type.txt in the client and you can set a breakpoint inside the DLL to know the exact address.
From there, the breakpoint was triggered with a file name of ahclient.dat. I back traced the call into the client logic that accessed the file. The file name is 'encrypted' so to speak and is unencrypted at runtime, which explains why no string references were found. Once the file was loaded, it is copied again to a new buffer while the old one was destroyed, so the next thing to do was trace the access to the contents.
I noticed it had some weird access logic to it. In doing so, I skipped over the logic that built this new logic (which is created, used, then destroyed), but I only focused on the AHClient buffer. The same logic that is used to unpack and rebuild the logic used for the AHClient buffer is also used in the client to unpack and rebuild the AHClient itself.
This function is what rebuilds the AHClient in the process:
Basically what it does is update the runetime IAT with the values of the current process and loads the image into memory, like the Windows loader would. At this stage, the AHClient buffer has already been uncompressed in memory from the previous logic (so it's uncompressed, then loaded into memory). In addition, a few other addresses are updated as needed for proper execution.
Once that function completes, the AHClient is loaded into memory and is ready to be used by the client. There is a set of logic that is returned to from that function that makes calls into the AHClient. That code looks like this:
The lines with arrows show the function calls into the memory. Since the address changes, global variables are used to store the addresses of the client functions. The logic for storing the function pointers can be found earlier and looks like this:
Those function addresses are actually calculated and stored into an array in the AHClient rebuilding function previously pasted. Once all that is setup, then the client continues to work normally as needed. At this stage, you'd just have to trace all of the calls into and out of the module to work on how to emulate it and figure out what triggers the memory scans and the other functionality. That's the point I'm at right now.
So just to wrap up: sro_client loads ahclient.dat from data.pk2. sro_client unpacks an embedded executable into memory and passes the compressed ahclient.dat buffer to it. The new executable in memory uncompresses it and then is unloaded from memory. sro_client loads the uncompressed AHClient into memory for execution. Finally, sro_client interacts with AHClient through a series of function calls. Likewise, AHClient interacts with sro_client through registered function calls.
It's a lot of tracing and going through the logic over and over until it all comes together. I actually skipped the first process sro_client loads into memory,so I'll go back to that later. It was fairly obvious which compression method was used because it was so common I'd seen it dozens of time, so I didn't really get into the specifics of what the first process does, besides the obvious uncompress data.
As for the client calling the AHClient functions and the AHClient calling the sro_client functions, I'm still working on tracing those and looking at what the individual calls do mentioned above. There's still a lot of code to go through and logic to be worked out since the AHClient runs its own threads and will send packets through sro_client to the server. On the bright side, that makes a clientless more easy since the security uses a user callback function to send data.
That's about what I have for now. I'll be looking at how the first packet is generated as well as some more details of the AHClient functions called tomorrow. It is very draining work, but it's a nice, fun challenge!
if your not that busy can you give instructions on to manually changing the pk2 files with hex editor or what not so that instead of using a loader i can always have zoom hack, nude patch n stuff? Thanks.
if your not that busy can you give instructions on to manually changing the pk2 files with hex editor or what not so that instead of using a loader i can always have zoom hack, nude patch n stuff? Thanks.
it is not made by pk2. its made by client modification (sro_client.exe).
[ALL SRO] edxSilkroadLoader Beta 09/09/2009 - SRO Hacks, Bots, Cheats & Exploits - 149 Replies Please note this thread is long and some of the posts are outdated. I'll be making a new thread that is more cleaned up and organized on the next release, so please be patient in the mean time. If you need any help, just send me a PM!
edxSilkroadLoader_Lite (w/ source) -- Open the 'bin' folder for the executable!
The rest of this post is OLD now, please read the post linked above.
About
It's finally done and ready for some beta testing! edxSilkroadLoader is a generic loader for all...
![[cSRO] edxSilkroadLoader Beta 3c Testing](https://www.elitepvpers.com/forum/iconimages/sro-hacks-bots-cheats-exploits/csro-edxsilkroadloader-beta-3c-testing_ltr.gif){kind=small}
