Cheat Engine

[Tilosag]

Hello,

how to write a condition in olly that:

if anything(any call, procedure, function, etc..) writes a constant string (e.g. ABCD) to memory (or specific range of memory) then Olly stops?

or when something writes a pointer to string(eg. ABCD)?


Problem is bigger than the least one because there are many functions which can use such string (in this example it's password) and encrypt it.
Thus, I want to find a place in code where the string is being encrypted and modify it.


Regards
Tilo

[Slugsnack]

if you know where the string is stored and want to find out when something accesses it, that can be done with hardware breakpoints.

in your case if you are trying to identify and analyse the password encryption routine, your best bet is to find the call that is fetching the password after you enter it and break directly afterwards. for example, in a lot of crackmes, you would breakpoint on all calls to getdlgitemtext to find when the application attempts to read input.

[Tilosag]

That's not so simple (for me).

First of all, the place where the string is stored is flexible.


Do you know a routine in Java corresponding to getdlgitemtext in C?

I did a lot of investigation but I can't find the module responsible for reading passwordbox after pressing enter key..
I tried to put a BP on some suspicious modules and when it break, look for entered password (ctrl+b in memory map), when Olly find it I edit bytes and when the password is incorrect (I entered correct in passwordbox before) it means that I found the right module.

On "nio","net","lwjgl","CRYPTBAS","rsaenh" it breaks too late. Password has been already passed to some module and encrypted.
On "advapi32" it breaks too early. I don't think that tracing code from here has sense.

I can put here a list of modules. Do you recognize some suspicious ones which could be right?

Here is a link to Executable Modules:

silkroad*ovh*org/ExecutableModulesPP*txt

and here to All Modules:

silkroad*ovh*org/AllModulesPP*txt

Have any idea?


Regards
Tilo

[Slugsnack]

olly has a feature called 'execute till return' ctrl-f9 which you might find useful for tracing in the 'too early' cases.

as for what java uses to fetch the string, that really depends on what control ( component/widget ) is being used. the fact that the location of the string is dynamic is irrelevant though. as long as you can suspend the executable either by breakpointing or some other method to set your hardware breakpoints that is ideal.

actually hardware breakpoints are really quite perfect for finding encryption routines. sometimes a password may be obtained and a load of crap performed before it is actually operated on. setting a hwbp would allow you to just run past all the stuff and break as soon as the first read is done, often indicating preparing the string for the encryption.

sometimes if you are having trouble finding the procedure that does the fetching of input, it can be helpful to find the routine which outputs (in)correct display info. from there you could 'trace back' statically. this technique is often used in reverse engineering as well.

the thing is, you probably do not want to break on a module's entry. there are probably heaps of calls to advapi32 before a correct one is made for example. the trick is to try to locate suspicious calls and just breakpoint them all. not sure if the functions are name exported in java but if they are, try using olly to find 'all intermodular calls' in the main game's module. just have a quick scroll through there and see if you find anything enlightening. you might even try looking at 'referenced text strings' to help find the (in)correct display routine.

so here's an example of something once did for a game. i knew that a particular function was called after successful login. i figured the game designers had it so it would check if your login was correct first, then if yes call this function. so i breakpointed this function and entered correct login info. from there i traced 'out' ( decreasing stack size as more return addresses are hit ). eventually one of the return addresses was to an instruction in a function which did some sort of conditional which was the check for correct/incorrect login. from there it was trivial to find the password encryption routine.

so in your case, since you have been messing with packets so much lately, you could consider that for a login to be authenticated, the game must communicate with the server. therefore what you could do is break on packet sending and possibly locate what you're looking for that way. there's a lot of different ways