Oh btw, wanted to mention, the way I described (caching just an arbitrary size block) is fine, however if you want to do it the 'best' way, do it on a per-region basis. It should be more efficient that way and also less likely to run into overlap problems. Just loop over all regions with VQEx.
Leader: G1 go to Stab
Just a simple scanner, Based on Apocs example, but updated to it works more tidy and with current wow. Below is screenshot:
Also a example of a dump .txt file:
Code:================================ Address updated - xautomation WoW process name: wow Dump started at: 28/02/2010 00:46:48 ================================ Patches: Anti_jump: Waterwalk: Inputblock: M2Colission(Highlightable): Airwalk: Airwalk up/down: Animations: Others: FrameScript_Execute(Dostring):7F25C0 ================================ Dump finished at: 28/02/2010 00:46:51 ================================
Not bad 3 seconds
Also I remove the none-public addresses
Not exactly a screenshot, however an update to my WardenSrv: Private Paste - Pastie
After you had the idea to implement this how long did it take you to make it? @kynox
It's simple-looking, but I have to bet there's a lot of research and code behind the scenes.
No, not really. I'm rather sure that it'll be semi-impossible to give warden good replies (to be honest, didn't look at those packages yet, but I assume the warden data changes each time and that you cannot simply feed a 'default' one ^^)
Also, I got server > wow client injection working now (so I can fake stuff on the client :P)
Yes, I'm aware that if you emulate a mac, that warden doesn't do much, but as I read, it still has the 'framework' => the least it could do 'protection wise' is let the packet differ each time and verify @ server (aka if you fail this step : banhamer)
Could any mac user confirm that the warden client-reply is (semi-)static?
And I assume you were able to crack the encryption then? (If so : share pls kthx? )