Hello.

I was thinking is there any alternative way to patch process memory without using WriteProcessMemory API? Actually I know crackers can get my patched bytes by just putting a bp on WriteProcessMemory so I want to know is there any other way to handle this?

Hope for the Best  

You can use Nt or ZW apis

 

Quote

Actually I know crackers can get my patched bytes by just putting a bp on WriteProcessMemory so I want to know is there any other way to handle this?

You can use othe function but is not a protect for ripper to get your patched bytes.

raggy,

Depending on how far you are willing to go with things you could inject a DLL and do the memory edits directly.

Another thing you could do is make a loader that loads the process into memory, make the edits, and then launch it from memory. 

Injecting a DLL would still require some kind of WriteProcessMemory most of the time, depending on your injection method.

 

You could write a driver to patch your stuff, or even go for dma. You won't be able to archive 100% protection, but going into r0 could scare some more reversers away.

Any body have a vedeo or tutorial to get patches from patcher or loader plz .....

Hello again.

I found a way to protect my patching bytes. It can't accessed from WriteProcessMemory but patch bytes are modified so when someone dump it. He can access my patching bytes by comparing old and new files. So is there any way to prevent this ? 

You will never stop rippers, so just put some useless patches in as well as a tell tale

I obfuscated many part of code (my patching section and some useless too) then copy all bytes and make a loader with all bytes.

Maybe it work

7 hours ago, A200K said:

Injecting a DLL would still require some kind of WriteProcessMemory most of the time, depending on your injection method.

 

You could write a driver to patch your stuff, or even go for dma. You won't be able to archive 100% protection, but going into r0 could scare some more reversers away.

 

Most of the time? You would call WriteProcessMemory once to do the injection of the DLL, outside of that it would not be called again. And even then, you do not need to go that route to inject in the first place, which can cause WriteProcessMemory to never be called at all.

5 hours ago, ramjane said:

Hello again.

I found a way to protect my patching bytes. It can't accessed from WriteProcessMemory but patch bytes are modified so when someone dump it. He can access my patching bytes by comparing old and new files. So is there any way to prevent this ? 

 

Most you could do is try and implement anti-dump techniques but you are starting to get into a point of things that will become useless and do nothing but generate a ton of overhead. You'll protect your stuff from newbies, but people that understand anti-dumping / anti-debugging will be able to bypass you protections with ease.

While not a sure fire protection, something you could do is implement hooks on the locations you need to edit and have the jumps go back into an injected DLL that is protected with some packer. That would help prevent easier debugging, will remove the dumping aspect since the jumps will go into your DLL which could be obfuscated / virtual machined, etc. to prevent easy dumping and so on. Just keep in mind every public protector is cracked, so either way you are only creating a deterrance, not creating anything that will be 100% protected.

We are really talking on how to protect a patcher/loader that crack an application? That is purely illogical!

Edited July 22, 20169 yr by crystalboy

2 hours ago, atom0s said:

Most of the time? You would call WriteProcessMemory once to do the injection of the DLL, outside of that it would not be called again. And even then, you do not need to go that route to inject in the first place, which can cause WriteProcessMemory to never be called at all.

I meant most injection methods require WriteProcessMemory calls, not all do. It is obvious you dont need many wpm calls for a single injection, just wanted t point out when an attacker bps WriteProcessMemory, he will easily find the dll path / pe contents too.

 

Going for direct syscalls would be better here, you'd need a driver to catch this.

hmm try using VirtualProtect as memory efitor 
or if you want to do it internaly (via injecting dynamic library c++) you caon do just *(DWORD*)0xAddres =  0x123123 (you can also int, byte, etc)