I have an exe previously prot'd with tElock 0.8 and after unpacking I noticed a special section called .fuckMut which contains the entry point.
It issues a call to CreateMutexA function with 3rd parameter as constant 'OLESCMLOCKMUTEX' defined in ole32.dll.
Does anyone have any ideas about what this can be (if it is generic either) and more stressed on that constant?
I did not find anything in W32 API help files nor on MSDN.

Any help would be greatly appreciated.

Hi

What is your app running that uses OLE? I can see this mutex-object name OLESCMLOCKMUTEX being used as part of a normal Object Linking process, many apps may call it and the system usage of that particular object name increments. It may use it with one of the Wait functions.

There seems to be a number of this class of CreateMutex object names, a quick search sees reference to them being used with several processes including Explore.exe, IExplorer.exe, winvnc.exe, outpost.exe and others of that ilk (Winsock2Protocol). You'd have to get into Ole programming references to see how they are used in normal programming though,
OLESCMLOCKMUTEX
OLESCMSRVREGLISTMUTEX
OLESCMGETHANDLEMUTEX
OLESCMROTMUTEX

The question is, is the app using it as part of its normal function or is it really trying to .fuckMut?

A common use of CreateMutex is to find if another instance of your application is running, GetLastError returns ERROR_ALREADY_EXISTS, but you'd use a unique object-name and not a system defined one. Your app may be messing with Ole (calling home?), but where does the .fuckMut come from, tElock or the apps protection?

Kayaker

tsss.. Kay..

This guy unpacked tElocked EXE with WKT's unpacker;
Just for kiddi, WKT replaces tElock's section with this one (OEP is hidden).

This guy needs to find only OEP & then strip this section.

Mutex object is created in telock's loader code, and then its checked in application code, if its already created, that means application is protected (just read telock doc's), and WKT unpacker add emulation of telock's loader. I wouldnt remove it from the unpacked application

Hi

yeah Bart gave me the right answer thanks
I knew nothing about tElock in general and tried to manually unpack it with no success. then I used WKT's tElock dumper, whereas I also tried to strip section with must-be-correct OEP but it locked up
thanks for notes on tE!'s protector and WKT's unprotector, now I think I should see some sources and docs
thanks

Ahaahhh...., Interesting ;-) That's a clever strategy, create a mutex object in the loader code and check if it's still there in the application, if it's not then presumably the app has been messed with and unpacked...

But, why use what appears to be a system defined mutex name OLESCMLOCKMUTEX that may already exist in the system and has a usage count? (other than trying to hide what is going on) Where is the discrimination between the kernel object created by the loader and the one with the same name created by for example Explorer.exe? In other words, how does the application 'know' it's been unpacked (if that is the purpose) simply by calling CreateMutex with this non-unique object-name?

Actually you're right, from the tElock docs this is indeed what is going on, a use of the old ERROR_ALREADY_EXISTS trick for detecting multiple instances, and it seems the programmer him/herself chooses the Mutex name to use. Still, it seems this might be a bad choice of names unless I'm missing the point here. If you use Handle.exe by Mark Russinovich (Sysinternals) and run it on your system you'll probably find at least one existing reference to that particular mutex object name OLESCMLOCKMUTEX

i.e.
EXPLORER.EXE pid: FFFF9DCB
4: Process EXPLORER.EXE(FFFF9DCB)
8: Mutex OLESCMLOCKMUTEX
...

Bingo, so unless the app can discriminate between the mutex created by tELock and the one created by Explorer it seems this tactic is going to fail, again because the name is NON-unique and apparently that's the whole point of how tELock implements it.

??

I did not know about that possibilities of
telock!!
Sorry!

I also not see such like prog, uses this kind of check. NoSorry here

Point me..

Several apps protected with telock uses this trick, eg. polish double telocked SafeLock

http://www.safelock.prv.pl/

MultiSys

http://www.vojtas.fr.pl/

it appears to be that mutexes belong to processes - that is, for me at least (under w98) many processes seem to have their own OLESCMLOCKMUTEX...
I should install an XP first (needed anyway because of CreateRemoteThread...) and check this then.
better - my app has TWO mutexes by the same name really funny