N00b : help ?

If its not by window name/process then its Mutex or Semaphores.

Mutex: stands for mutual exclusion object. Is a program object that allows multiple program threads to share the same resources such as file access, but not simultaneously. When a program is started, a mutex is created with a unique name. After this stage, any thread that needs the resource must lock the mutex from other threads while it is using the resource. The mutex is set to unlock when the data is no longer needed or the routine is finished. That way, you can find an external way to release the Mutex or change the mutex name on each instance and as a result have multiple instances running.

Semaphore: It a software flag. In multitasking systems, a semaphore is a variable with a value that indicates the status of a common resource. It's used to lock the resource that is being used. A process needing the resource checks the semaphore to determine the resource's status and then decides how to proceed. Things are more complicated.

If it works in one of the above ways then its not so easy to clear the check. Is not like a FindWindow() and if yes, it shows - if no, deny. There are several functions and checks, such as CreateMutex to create a mutex handle, OpenMutex to obtain an existing handle and when threads needs to run in Mutex it uses wait functions such as WaitForSingleObject. Then its done by calling the ReleaseMutex.

Conclusion, is it better to fool the instance system rathen than cracking the exe itself. You dont know if the developer "locked" only the executable instances using a single check or it has many internal restrictions/checks.

Thanks alot

Im 99% certain i got the mutex name at home from previous tracings .. or i can step it up again !!! You're saying it may be simply enough to *change* the name ?
You know, it DID puzzle me that there was what seemed to be a 'var name' on the stack oll of a sudden...

I hope this works out ... thanks again.

btw. i've been told that i can have 4 sessions going by simply, in XP, swithcing to another user and run 2 more from that account!!!! if thats telling something about what strategy it may use!!

Originally Posted by abitofboth

btw. i've been told that i can have 4 sessions going by simply, in XP, swithcing to another user and run 2 more from that account!!!! if thats telling something about what strategy it may use!!

Switching between users is a nice (but timewasting) trick to fool it. None of the above ways (process/class check, mutex or semaphores) can prevent an application from running in another user session (like switching with WinKey+L).

As retroer said there are plenty utilities out, or you can handle to make it by your own, to kill or change the mutexes. That will also work for all future versions of the program.

A timeconsuming affair, especially since olly wont *keep* the breakpoints I set outside of the debugged app, that is user32, kernel, ntdll etc. So thats manual work for each iteration!

you are not letting olly to keep it rather than olly not keeping it

all information regarding breakpoints comments labels patches etc are written to .udd files and they happen only if you analyze the module you are debugging
if you look at options --> debugging options --> analysis 1
you will see auto start analysis of main module checked by default
so olly remembers the break point in your main module
if you uncheck it olly wont remember the break points you set in main module too
now you may still not read the help file
so here is a small how to

when the module loaded use
1) view --> executable modules --> right click ---> analyze all modules for analyzing all modules that have been loaded so far
2)view --->executable module --> select a specific module -->right click -->follow entry ---> then press ctrl+a will analyze only that module

now also keep in mind these are universal break points
so if you load another exe these break points will pop up in that exe too with out you having to set them implicitly

have fun