1

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 a program called Process Explorer, but I'd like to not do it every time...

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.

Improve this question

3 Answers 3

Reset to default
2

There are 2 methods to do do this:

  • Use an API hook to intercept the call to CreateMutex and change the mutex name (e.g. randomize it).
  • Make a copy of the executable or dll that calls CreateMutex and 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.
Improve this answer
3
  • 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, 2018 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, 2018 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, 2018 at 9:32
1

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.

Improve this answer
1
  • 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, 2018 at 20:24
0

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.

Improve this answer
4
  • 1
    When 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 stdcall which states that the callee clears the stack from the arguments. Insted of poping x number of times to get rid of the argument, a ret n is performed. It basically remove n "variables" from the stack before returning. Without it, the program will execute incorrectly
    – Frowner
    Jun 5, 2018 at 21:25
  • 1
    I 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 to L"Local\\MutexName123\0" in your binary (the \0 is a result of the length difference between Global and Local). See: MSDN documentation on Object Names
    – 0xC0000022L ♦
    Jun 5, 2018 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, 2018 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, 2018 at 8:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.