CreateMutexA - ReleaseMutexA

Ask for Help on Using the Language With Memory Hacking Software

Moderators: g3nuin3, SpeedWing, WhiteHat, mezzo

CreateMutexA - ReleaseMutexA

Postby mezzo » Thu Jan 31, 2008 9:39 pm

Several games use a mutex to prevent a second instance from opening.
I used to simply search for the (mutex) handle with process explorer and then close it, so that I'm able to start a second instance.

I would very much like to do it with LSS. I'm guessing that a breakpoint script on CreateMutexA is the way to go. But since I'm not a realy a windows fan, I was wondering if CreateMutexA, ReleaseMutexA and OpenMutexA are realy the only API calls that deal with this kind of objects ? If so, would anybody know the 'usual' way to verify if a mutex already exists ? Would it be to execute CreateMutexA again and check for the return value or more likely that it is OpenMutexA and check that return value ?

From what I found in the win32.hlp file, I only get the following returned:

------------------------------------------------------------------------------
The ReleaseMutex function releases ownership of the specified mutex object.
BOOL ReleaseMutex(

HANDLE hMutex // handle of mutex object
);

------------------------------------------------------------------------------
The OpenMutex function returns a handle of an existing named mutex object.
HANDLE OpenMutex(

DWORD dwDesiredAccess, // access flag
BOOL bInheritHandle, // inherit flag
LPCTSTR lpName // pointer to mutex-object name
);
-----------------------------------------------------------------------------
HANDLE CreateMutex(
LPSECURITY_ATTRIBUTES lpMutexAttributes, // pointer to security attributes
BOOL bInitialOwner, // flag for initial ownership
LPCTSTR lpName // pointer to mutex-object name
);
------------------------------------------------------------------------------


As you can see, only the ReleaseMutexA function returns a BOOL and the others return a HANDLE... This doesn't realy give me much insight in what I should be using to test is a mutex exists...

I was thinking of attaching the breakpoint script to CreateMutexA, see if the Mutex name = 'gameIwantothack', if the mutex doesn't exist then do nothin, if the mutex DOES exist, then ReleaseMutexA of the old Mutex, so that the new one can be created by the game/tool...

Anybody know how I can have LSS check if a Mutex exists?

UPDATE: I just noticed that there is also a CloseHandle api call... which API calls should I be using to accomplish my goal? Any and all hints are welcome.

UPDATE2: It appears that I jumped the gun a bit and that those API calls aren't available in LSS.
L.Spiro, would you mind looking into including them into the next update, please ? That would be great :-)
- No thanks, I already have a penguin -
User avatar
mezzo
El Mariachi
 
Posts: 739
Joined: Mon Apr 30, 2007 10:27 pm
Location: Antwerp

Postby L. Spiro » Thu Jan 31, 2008 10:33 pm

OpenMutexW() is the one you need to use to check that a mutex exists.

To accomplish your goal: hook OpenMutexW() and/or CreateMutexW() in the target process. When it attempts to check for the existance of a mutex or create one, you call the OpenMutexW() yourself to see if it exists. If the HANDLE is not NULL you call CloseHandle() on it twice, then return to let the target process see that the mutex no longer exists.

I can add these functions for the next release.


L. Spiro
User avatar
L. Spiro
L. Spiro
 
Posts: 3129
Joined: Mon Jul 17, 2006 10:14 pm
Location: Tokyo, Japan

Postby mezzo » Thu Jan 31, 2008 10:54 pm

Cool ! Thanks a bunch (both for explaining it and adding it in the next version!) :-)
- No thanks, I already have a penguin -
User avatar
mezzo
El Mariachi
 
Posts: 739
Joined: Mon Apr 30, 2007 10:27 pm
Location: Antwerp

Postby kth_prkns » Fri Feb 01, 2008 2:35 am

normally in games, theres a jnz (i think thats what it is) that you can simply change to a jmp and it will bypass the mutex all together... only game this hasnt worked on is WC3
kth_prkns
NULL
 
Posts: 101
Joined: Sun Jan 14, 2007 5:29 am

Postby mezzo » Fri Feb 01, 2008 2:44 am

kth_prkns wrote:normally in games, theres a jnz (i think thats what it is) that you can simply change to a jmp and it will bypass the mutex all together... only game this hasnt worked on is WC3


Yup, could be, but since I'm making a bot *framework*, it needs to be as generic as possible. Doing it the way described above will allow it to be used in loads of different games/tools by only changing the string of the mutex object name. As I said, I already have a fairly easy way to close handles to mutex' (through process explorer), but I want one that is 'generic' and automated, LSS is ideal for this.

And a breakpoint script to simply be attached to a WIN32 api call is about as generic as I can think of. (expect some code snippets when I'm further then 75% with my project)
- No thanks, I already have a penguin -
User avatar
mezzo
El Mariachi
 
Posts: 739
Joined: Mon Apr 30, 2007 10:27 pm
Location: Antwerp

Postby L. Spiro » Fri Feb 01, 2008 10:08 am

I don’t know what I was thinking for a while (but it was 1 AM so…).

You can close the HANDLE to your own mutex objects but if you tried to close the same HANDLE again it has already been closed so it won’t work.

You need to get the HANDLE that the target process is using and create a thread in the target process to close that.

But that leads to the same loophole; you can’t close the one in the target process until it has already been returned from the function, and then you can ony close it once, so the mutex is still alive in some other process.

Your best bet, aside from scanning every process and trying to find its HANDLE to that mutex, is to hook the end of the OpenMutexW function with a breakpoint, use your script to get the value in EAX, create a remote thread to close that value in the target process, set EAX to NULL, and let it continue.


L. Spiro
User avatar
L. Spiro
L. Spiro
 
Posts: 3129
Joined: Mon Jul 17, 2006 10:14 pm
Location: Tokyo, Japan

Postby mezzo » Fri Feb 01, 2008 5:25 pm

hmmm, you have a good point there.. haven't had the time yesterday to play around with it some more..

What if (big assumption here); Am I correct in thinking that the only way to use the mutex is through the handle that was returned during the Create call ?

If so, could I trap the CreateMutex call, use the pointer that defines its name and change its name before it has been created ? For instance change the first character of the mutex name to a digit and just increase the digit for every subsequent create ? The handle saved in the process would still point to the mutex, the mutex would simply have a different name. Or would a process be able to 'verify' it's mutex name ?
- No thanks, I already have a penguin -
User avatar
mezzo
El Mariachi
 
Posts: 739
Joined: Mon Apr 30, 2007 10:27 pm
Location: Antwerp

Postby L. Spiro » Fri Feb 01, 2008 6:58 pm

You may be able to do that or you could just close the handle from the return of CreateMutexW each time.
This way none of the processes keeps an open HANDLE on it while they are alive.
You have to keep the value of EAX the same or else the process will think it failed to create the mutex and close.

So just hook the end of the function, CloseHandle( EAX ) (in the target process) and return. The process things EAX is a valid HANDLE and runs normally. Next process tries OpenMutexW() which fails since the HANDLE was already closed in the previous process.


L. Spiro
User avatar
L. Spiro
L. Spiro
 
Posts: 3129
Joined: Mon Jul 17, 2006 10:14 pm
Location: Tokyo, Japan

Postby mezzo » Sun Feb 03, 2008 5:36 am

just need a little confirmation here..

MHS_ADDRESS GetRemoteFuncAddress(
const CHAR * pcModule,
const CHAR * pcFunction)


MHS_ADDRESS is supposed to be type int, right ?
- No thanks, I already have a penguin -
User avatar
mezzo
El Mariachi
 
Posts: 739
Joined: Mon Apr 30, 2007 10:27 pm
Location: Antwerp

Postby L. Spiro » Sun Feb 03, 2008 11:30 am

unsigned __int64


L. Spiro
User avatar
L. Spiro
L. Spiro
 
Posts: 3129
Joined: Mon Jul 17, 2006 10:14 pm
Location: Tokyo, Japan

Postby Shynd » Wed Feb 06, 2008 6:35 am

The way MANY (maybe most, I'm not sure) games work is they call CreateMutexW/A and then check the last error by calling GetLastError. They then compare the last error to ERROR_ALREADY_EXISTS (0xB7) and if so, exit. You could simply hook GetLastError right before it returns and compare EAX to 0xB7 and, if true, set EAX to 0 or whatever else.
User avatar
Shynd
Acker
 
Posts: 68
Joined: Fri Jan 05, 2007 2:11 am

Postby mezzo » Wed Feb 06, 2008 7:02 am

thanks, will surely check it out !!

How are you Shynd ? Haven't seen you around lately..
What have you been up to ? We could do with more nice tutorials !! :-)
(still using your other ones for reference often)
- No thanks, I already have a penguin -
User avatar
mezzo
El Mariachi
 
Posts: 739
Joined: Mon Apr 30, 2007 10:27 pm
Location: Antwerp

Postby Shynd » Wed Feb 06, 2008 8:14 am

Haven't been too bad. I've been lurking around, just not posting much. More tutorials, huh? Did I already write one on how to send packets programmatically as if they were sent from the game client (ala WPE)?
User avatar
Shynd
Acker
 
Posts: 68
Joined: Fri Jan 05, 2007 2:11 am

Postby L. Spiro » Wed Feb 06, 2008 10:11 am

You wrote one for intercepting outgoing packets but not manually creating and sending them.


But you may find a more graceful way to do that in the next release so you might want to hold off.
The next release allows to call any function in the target process via scripts, regardless of calling type and convention.

This will surely make it easier to write something that can send packets from the target process.


L. Spiro
User avatar
L. Spiro
L. Spiro
 
Posts: 3129
Joined: Mon Jul 17, 2006 10:14 pm
Location: Tokyo, Japan


Next

Return to Help

Who is online

Users browsing this forum: No registered users and 0 guests

cron