#1
|
|||
|
|||
N00b : help ?
I got this program.. it has a two session max... i wanna defeat that..
I've pinpointed the problem to be here (using olly and hidedebug 1.22) 004f9154 CALL DWORD PTR DS:[545E40] (olly : USER32.ShowWindow) From here the code will run into USER32, kernel etc. Now the 'problem' is when it returns, it doesnt return to the successive address (004f915a). Depending on whetether its successfull or not, it will return to either 004f914b (success) OR 004fd1bf (wich is the deathtrap) Now.... I dont get how a call to user32.showwindow can have an impact on the next instruction to be executed /return address... so to speak.. I think of it in terms of 1 do somethig 2. return 3. call 1. 4. do something else eip = 3 and we would go 3,1,2,4 ... right ? Obviosly not .. perhaps someone has the patience to explain it to the n00b ? |
#2
|
|||
|
|||
firstly test it under some VirtualPC & use regitry + file trackign.
|
#3
|
|||
|
|||
Can you define "2 sessions max"? If you mean it allows 2 instances of the software running, can you see how it checks for the instances? Is it checking the class/caption of the software? Is it mutex? Is it semaphore? Maybe its easier to trick it using "external" ways rathen than patching/debugging the exe itself.
|
#4
|
|||
|
|||
If you mean "Terminal Sessions", program can use CreateMailslot and GetMailslotInfo functions to check how many instances running under different Terminal Sessions (in addition to many uniqueness checks under same Terminal Session, with FindWindow, CreateMutex, CreateSemaphore, etc functions)
If you unsure in EIP value after ShowWindow check stack integrity right before ShowWindow and correctness of all function's parameters (check whether exceptions occurs inside ShowWindow) |
#5
|
|||
|
|||
evaluator -> ill do that again. however i've allready done that some time ago, and the thing is, iirc the damned thing queries 3k+ registry entries!!!!
baatazu -> yes, thats excatly what it means. Its not by window name/process name. However i am tracing into some weird stuff like openmutant etc right around where this happens. retroer -> no, not ts Basicly what i do(right now) is this; 1. open one session 2. start second session in olly 3. trace forward in olly, if note from step6 exists then step up close to that 4. start third session 5. if 4 succeeds, close it and goto 3 else continue 6. take note of current instruction address, place breakpoint 7. goto 1 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! Another thing that would be ubercool is some recording feature of the trace .. sorta like a code-traceroute, and a feature to compare these recordings. This way u'd quickly be able to see where two execution paths differs/branches for the first time... yea, i'd like THAT! |
#6
|
|||
|
|||
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. |
#7
|
|||
|
|||
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!! |
#8
|
|||
|
|||
Quote:
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 |
#9
|
|||
|
|||
Quote:
One of interesting examples of breaking multiple instances restriction is regedit.exe (there used FindWindow function) |
#10
|
|||
|
|||
OMFG ...
that was it ... a friggin mutex .. mutant, and yes, it was the exact var name i mentioned earlier seeing on the stack.... the application will do this create mutex varname_01 if that fails create mutex varname_02 if that fails, fail all! With process explorer, if i simply *close* the handle, im there !!!! Now ... onto the task of patching this up manually ... damn... took SUCH a long time... (and im not done yet lol) ... thanks to ALL who have helped me so far !!! learning alot new shit... my brain hurts lol... edit : got a message filtered, rightfully i suppose, so i'll edit this post ; JuneMouse -> sorry, cant help being a noob, but I can help being a stupid noob ... point taken, and TY so much for that pc of info .. totally made my day Last edited by abitofboth; 05-05-2005 at 17:34. |
#11
|
|||
|
|||
Well it's good to seem someone at least pretending to be older than I am. Will there be a big party next year when you reach "100"?
Regards,
__________________
JMI |
#12
|
|||
|
|||
Quote:
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. |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Likely N00b question - Bassmod.dll | Stingered | General Discussion | 6 | 01-16-2018 02:23 |
n00b Quest II(tm) | abitofboth | General Discussion | 5 | 01-19-2006 15:32 |