I'd like to patch an app to avoid it to use/create a specific mutex, because this one prevents the app from running in multiple instances. I'm already able to close the mutex's handle with the app process explorer, but I'd like to not do it everytime... Have you any idea to help me? I'm really new to mutex, semaphores, and stuff like this, and I have no idea how I can erase it from the app.
There are 2 methods to do do this:
- Use an API hook to intercept the call to
CreateMutexand change the mutex name (e.g. randomize it). - Make a copy of the executable or dll that calls
CreateMutexand search the Mutex name with a Hex editor (search for both ANSI and Unicode strings and modify the string. Make sure that you don't change the length of the string.
-
I tried your second method but the mutex is still there, it just have a brand new name :o. Anyway, I'm just gonna nop some stuff near the mutex call ans see how it goes. Thanks for your answer! :) – sebastien finor Jun 5 '18 at 17:52
-
Did you start the original process and the modified one? For the same reason as the original mutex name, you cannot launch multiple instances with the original name nor multiple instances with the new name. You should however be able to open the original exe and the modified one at the same time... – Remko Jun 7 '18 at 22:35
-
Oh ok I see what you mean now. I just tried to launch twice the modified process. I thought changing the name of the mutex would corrupt it. – sebastien finor Jun 8 '18 at 9:32
You need to find the code which creates the mutex. I.e. the call to CreateMutex/OpenMutex API function. And then patch it by overwriting the opcodes. So you'll need to learn how to disassemble and how to patch the code of the executable. If it's new for you, you should try from some crackme tutorial, which will teach you to do this.
-
Thanks. no problem with that, i know quite good how it works. I just didn't know at all of mutex before and wasn't sure of what to shearch for :). – sebastien finor Apr 5 '18 at 20:24
I did it. First I replaced the first instructions of the subroutine calling Windows API's CreateMutex by the "ret" of this function (it wasn't only "ret", but "ret xxxh", i don't know why). Then, I avoided the error call when handle is 0 (null) with a simple "jz" to "jmp" change.
Edit: I could also have nopped the call and the 3 arguments before it, instead of replacing the first instruction of the call by ret.
-
1When calling a function, some arguments are pushed fo the stack and someone need to pop them for the program to keep it's execution correctly. That some is "decided" by the calling convention, it can be the caller, it can be fhe callee. Winapi uses the
stdcallwhich states that the callee clears the stack from the arguments. Insted of poping x number of times to get rid of the argument, aret nis performed. It basically remove n "variables" from the stack before returning. Without it, the program will execute incorrectly – Amirag Jun 5 '18 at 21:25 -
1I would like to offer another potential alternative, depending on what exactly the namespace of the mutex is. A mutex, just like drive letters can be global or local. So if you are trying to run multiple instances of said application in different sessions and the application uses a name of the form
L"Global\\MutexName123"you could patch the name toL"Local\\MutexName123\0"in your binary (the\0is a result of the length difference betweenGlobalandLocal). See: MSDN documentation on Object Names – 0xC0000022L♦ Jun 5 '18 at 22:09 -
Thanks amirag :). And your idea is cool 0xC0000022L. Do you think I could change the mutex name to "Local\[Restofmutexname]" even if it is not Global\\ before? – sebastien finor Jun 6 '18 at 23:04
-
@sebastienfinor: I don't think so. I'm fairly certain that it defaults to local already. However, keep in mind that this suggests that you aren't trying to run your program in different sessions, so my suggestion isn't applicable to your case. – 0xC0000022L♦ Jun 7 '18 at 8:18
