How to identify the address where the test is done?
 

Hello guys
I need help please
When you change a string the process ends.
How to identify the address where the test is done?
The string is "uLme" in the address 007B3AD8 in ulme.exe file

FILE: http://www113.zippyshare.com/v/oenVyf9Q/file.html

Thank you for your help.

PS: sorry, I could not post the REQUESTS

You can set a read/write hardware breakpoint to obtain the location that reads/writes the string.

Another possibility is a pure static approach: searching for xrefs in the code. Doing that, you will see that 0x7B31B6 loads the data location into eax and then calls 0x40A748.

And how do I stop this test and change the string?

assuming the program is otherwise unprotected and will not try to prevent or detect it, write a loader which injects a dll into the target process's memory and patches bytes in the appropriate place to call a function in your dll that changes the string however you wish. there are lots of tutorials on code injection, here are some good ones:

Three Ways to Inject Your Code into Another Process
A More Complete DLL Injection Solution Using CreateRemoteThread
Code Injection - A Generic Approach for 32bit and 64bit Versions
InjLib - A library that implements remote code injection for all Windows versions

But in practice how do I stop this test and change the string? :confused::confused:

i didn't have a chance to look at your exe, but say a target calls strcmp and then does something based its result. your loader (which injects a dll with your code) can use WriteProcessMemory to patch the call to strcmp (in your target) to instead call the function in your dll. your function can then modify the string and return strcmp(s1, s2). the tutorials show you how can calculate the address of the dll function so that you can patch the call with the right address.

For those who know it is easy, but for a layman is complicated.:(:confused::o

here is sample loader and dll code for you, i tried to put it in the thread but exetools forum kept giving errors.

https://gist.github.com/anonymous/0f8bdbcc6e0bc2bb835ebe55713b41de

What to do with it?:confused::confused::confused:

HW breakpoints won't help you if the program performs self-checksums in memory. What you really want to do is diff runtime traces:
1) Record a trace of running the unmodified binary
2) Record a trace of running the modified binary
3) See where they differ. This yields one (possibly many) program location which does "the check(s)".

As for collecting traces, use your favourite debugger (x64dbg, ollydbg, IDA) or dynamic binary instrumentation tool (DynamoRIO, PIN).

@bongos_man
Thank you my friend,
I will replace the value FF bytes by 88 bytes. It worked, but not 100%
0xE88875C5FF to 0xE88875C588
it is?:confused::confused:

sorry, i was very, very drunk. ignore everything i said.

try this: https://gist.github.com/anonymous/9068570079dd3550015caeb19026d5f8

Sorry, I do not know what to do with it!:confused:

compile main.c as an exe and loader.c as a dll/shared library, then run:
if you don't know very much c or assembly, you will need to learn them better in order to become a good reverse engineer.