I'm on Windows 7 myself atm. Start Silkroad.exe and choose your Division so the Start button appears. Exit the launcher after that. Now start edxSilkroadLoader and try to launch your clients.
The cSRO client is not packed, so you do not need to do anything with that either. Sometimes there is a wait for the client to launch, if you see the console and the patches listed, then the DLL was injected, but the client isn't connecting to the Login server yet.
Try selecting a different login server and use TaskMgr to kill the processes that get stuck. I've had that happen a few times I think before this version of the launcher.
The security thread does not always start. However, if it starts, it will be after you login at the character select screen. If you get in game and it is not running and you restart, chances are it will start the next time. You can see this in the two screenshots. The first time I logged in both accounts, no security thread ran but after I restarted, it ran.
I tried selecting different Loginservers, the result was the same. By the way im using WinXP SP3. When i start the edxloader i get the same Informations on the Debug Console like you on your first screen (left side).
I tried selecting different Loginservers, the result was the same. By the way im using WinXP SP3. When i start the edxloader i get the same Informations on the Debug Console like you on your first screen (left side).
Ok, sorry about that, it's actually a bug in my code. I've updated the project again, thanks for reporting the errors! I am uploading the new version right now.
Ok, the new version, 3c4 has been uploaded. Windows 7 has made some changes to how CreateThread/CreateRemoteThread work, so I have to hook a different set of functions for Windows 7 than non-Windows 7 versions.
Ok, sorry about that, it's actually a bug in my code. I've updated the project again, thanks for reporting the errors! I am uploading the new version right now.
Ok, the new version, 3c4 has been uploaded. Windows 7 has made some changes to how CreateThread/CreateRemoteThread work, so I have to hook a different set of functions for Windows 7 than non-Windows 7 versions.
Everything should be working now.
I tried it today, and it works now, thank you for fast answering and taking care of this issue..keep up the good work
I've updated the version to 3c5 today. I noticed the security logic can scan the DLL memory, so I faked those results to prevent the DLL from being easily identified.
The "freezes" that you might encounter are not related to this loader (pretty sure) but rather just a problem with CSRO. I'm not sure why it's happening, but I notice it from time to time on a second character only. It's like the server just stops sending packets but does not disconnect your client. It's not an easily reproducible problem, so I can't really look into it more to see why CSRO does this.
If anyone else runs into any issues, please let me know!
I've updated the version to 3c5 today. I noticed the security logic can scan the DLL memory, so I faked those results to prevent the DLL from being easily identified.
The "freezes" that you might encounter are not related to this loader (pretty sure) but rather just a problem with CSRO. I'm not sure why it's happening, but I notice it from time to time on a second character only. It's like the server just stops sending packets but does not disconnect your client. It's not an easily reproducible problem, so I can't really look into it more to see why CSRO does this.
If anyone else runs into any issues, please let me know!
That's exactly what im going through! Just freezes and i get "sro_client" stopped responding etc.
The new detection started yesterday evening and I am currently looking for a new solution. The current method of patching the security scans is not going to work out because they can just add more code to scan or change them around to break my existing code. That is why the DCs started again, there is more code that was being executed that checked the memory. I managed to get the new code accounted for, but I still got DCs which means there are a couple more now to find.
I have to play with some memory access logic to see if I can find an easy way around this issue. The tricky part is that they are not using any API calls to read the memory, so I can't simply detour a function and call it a day. Hopefully I'll find something, but if not I'll have the thread closed in the mean time while I try to work out a solution.
@pushedx:
can you maybe post some information related on the scans. this means how, what and where they scan and what they compare it with to check, if it's the right code?
because i tried to bypass xtrap (vsro) with a very advanced method (writing a driver and using it like a rootkit)
although it does not work yet (xtrap was changed too) it's a good method
and maybe it's possible to change it according to the current protection
because i tried to bypass xtrap (vsro) with a very advanced method (writing a driver and using it like a rootkit)
although it does not work yet (xtrap was changed too) it's a good method
and maybe it's possible to change it according to the current protection
Yea, I started learning driver development to be able to work with XTrap and GG on that level, but they are pretty advanced now and were able to defeat the simply stuff I learned. Being on the Kernel level gives you the same access they have, but you still have to work around their logic, so it helps, but it's still really complicated. I figured I need to learn some more stuff in Ring 3 first before I dive into Ring 0 as a result.
The biggest problem with drivers though is that you will have to have a different version for x86 and x64 platforms and then you will have some interoperability issues with XP and Vista/Win7. Usually though, the driver should have an API that the DLL injected into the process or the external process communicates via. For example, this is a good thread on how works.
Quote:
Originally Posted by hack0r89
@pushedx:
can you maybe post some information related on the scans. this means how, what and where they scan and what they compare it with to check, if it's the right code?
The scanning function calculates hashes of memory and send it to the server, so the server would know if it is correct or not. The logic is dynamically loaded into the process and then executed as a thread. There are many threads that are created for the scans. In addition, there is scanning logic for the main client scanning logic as well.
The code at address 246F4D53 - 246F4D6D is the hash calculation logic. ECX has the address to get the byte of and then the hash is calculated for the region of memory. If you codecave this logic and fake the results, you can essentially fake the results, but there is a problem.
There is another scanning function that runs in another thread that will scan this logic to make sure it has not changed. If you only change that logic, the second thread will detect changes in the code as the hashes sent to the server will not match.
Here is a snippet from the second byte scanning function:
In this case, EDI will have the address to get the value of. I had missed the second EDI - 1 access earlier but I fixed that in version 5.
Now, there are a few other places that I managed to get triggered accessing memory, but who knows how many possible locations there are. As you can see by the code, it's not really straightforward at all.
The only ways to easily identify the logic is to set hardware breakpoint on memory access on the memory of the client and then the security memory. I think it's possible to get them all, but it'd be nice to find an alternative method of tracking each access without a driver.
So for anything you patch, you have to find all the security logic that eventually checks that memory. I noticed the security memory scans start about 15-30s after you get in game, so it's possible that you might not get a DC for a few minutes but eventually get one, and then you have to go back to hardware breakpoints to see what code you missed.
I noticed there was a memcpy like function that I need to patch since it reads important memory, but then I need to find the code that scans the integrity of that function. It's a lot of cat and mouse work or needles in haystacks.
To figure out which thread was the main security thread, I first found the main client scanning logic from the first paste and took note of which thread ID it had. I then found the entry point of that thread and came up with a byte signature to uniquely identify that thread. In my loader I hook the CreateRemoteThread/Ex family of functions and then check the entry point of the threads with the byte signature, which does have to use some wildcards.
Then you can call VirtualQuery on the thread entry point to get the entire page of memory and then do signature searching to make your patches. That's pretty much what I do. However as I previously mentioned, it's not that great of a long term solution since the logic can change and you have to re-find the new logic. In addition, some threads can be given a long Sleep and only execute at longer time intervals, which makes catching all the memory accesses impractical, since the security logic that is executed will vary based on when you login.
The security logic also makes a patch in the client to start execution of their code, so you can catch that if you detour VirtualProtectEx and look for an address inside the client's code section. If you then set a HWBP on write on the address, you can catch the logic that does it.
It is quite a challenge to work with. I was hoping to find a solution that I could just control all memory accesses and fake the results, but that gets tricky. I'm working with VirtualQuery, VirtualProtect, and Vectored Exception Handlers trying to come up with something that would work.
what do i have to study to know (and also understand) all that... kind of amazing... what did u do to get all this knowledge? is it just the years of expierience or more?
thanks for telling.
this is indeed quite tricky. i messed a bit more with memory protection systems.
there is one main advantage of a driver: you can patch kernel memory
i made a driver with a quite good interface and a little demo app that is loaded and where you are able to register changed memory
the driver will intercept all ReadProcessMemory (or better: ZwReadVirtualMemory) and patch their return values.
so its impossible for an external program to find any changes
i also unhooked any kernel hooks from xtrap. so i was able to write to sro_client via WriteProcessmemory
the problem: i said "external" programm.
the process can read its own memory without using RPM
and unhooking kernel hooks ith also possible from a ring3 programm (yes, you can enter ring0 with a usermode app without a driver...i could terminate my AV without being detected...just for testing)
i could imagine 3 ways for fully getting around it:
first: get these scanning function calls and get their address they are trying to scan. if its a region, where you made a patch: change this region to a clean copy of the region. could be possible...but very hard
2nd: maybe its possible to get accesses to the adresses. than you can check its origin and temporary undo the patch or again fake the results...
this is what i wanted to do with my driver...
3rd: dont let any thread execute: if you prevent any thread from being executed there is no check...you'd only have to make a "whitelist" for the main thread and some others.
Problem: if in the main thread a scanning takes places it's not affected
also if the server requests a scan and there is no answer, it will be bad
Do you have some information on the packets?
in vsro the server sends a request and xtrap answers it almost instantly
but stupid themida prevents me from attaching my debugger even i use a kernelmode hiding driver...
how are they send and what is in them?
also: how is the adress to be scanned calculated and stored?
Edit: i just looked at the Hackshield bypass...the last quote is the best. ssdt hooks can be undone even by usermode apps. but these memchecks are almost the same as we have here. but there it is only one check...
however: i think my method of registering changed memory could be used...
the "only" thing to do is, intercepting all read attempts...
You 2 ppl need to share msn/skype/qq so that u can help each other
All i understood from both posts is this: "freaking AWESOME codes involved, and days at tracking and re-coding and **** like that over and over and over again."
You 2 ppl need to share msn/skype/qq so that u can help each other
All i understood from both posts is this: "freaking AWESOME codes involved, and days at tracking and re-coding and **** like that over and over and over again."
dont make them angry ... quite best thread on epvpers since ages...
Just a little status update, since I've not replied for a few days. I'm currently working on reversing the entire cSRO security system, so it will be a short while longer as I work out how the entire thing is setup. I'll have a little article that explains it all when it's all said and done and hopefully have a new method to get around the detection, as my latest patches are still getting detected somehow.
I'll get around to more specific replies made in this thread later on after I'm done. So far though, everything is going 'good', it just takes a lot of time to reverse this stuff and to work through what is going on! It's pretty tedious since it's all loaded at run-time dynamically.
[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}
works.
what did u do to get all this knowledge? is it just the years of expierience or more?
