r0da's blog

Hi all. Last april, I looked to a commercial software to see how it was protected. It was using Themida 3.0, a very good virtualization with custom handles, optimized bitcode and stuff.. But after looking around it for one hour, I figured out that some very important parts of the code were not virtualized. In fact, the entier license system were clear x64 ! Today I will try to talk about it without revealing the software for obvious reasons. So how a good security like Themida could lead to this result ? How this security is applied during the release process ?  Well in general software that are a little bit serious protect things that should be protected. But, if you look closly, you may notice that there is a problem. Some important parts of the code are not protected at all by the virtualization !!! It's could be resumed by the thing that some software providers wants to apply a security to protect their software without understanding the point of it. They just check security

Hi, all. Last year, I thought it could be a great idea to combine all possible ways to modify code of an executable in a thread. And one year later this is it ! the post is out ! (thanks to caffeine) There is a lot of reason why modify / inject code in an assembled executable : Inject a shellcode in a legit program to make it a malware Modify a program to patch a vulnerability while the update is not available (cc 0patch) Crack a program to bypass a check Make a malware or a protection signature change to be "FUD" Code a cheat for a game (more about runtime modification) Just make a "strong" security (assembly level, more about runtime modification again) Here is what you can do in function of each perspective. In executable : Byte patching Code caving Code caving with new section Creating a new section and make the entrypoint point to it Create a new import to a DLL From external programme : Inject a DLL and create a t