Find a quick way back to more documents with this link.
Return to Main Index,
Dongles.
http://www.erdas.com - Webpage.
Files available on request or from your favourite site.
It seems to me now that more application developers than ever are turning to hardware protections to protect their software (when in reality a few knowledgable ASM routines would cause most crackers far more hassle). In fact if I did possess the dongles for all the programs I've reversed the back of my PC would have an extension of 3ft. If you are going to use a dongle then remember that merely using them isn't enough, just note as well that in my opinion a basic HASP protection is probably better than a Sentinel.
ERDAS IMAGINE is quite an expensive piece of software, launching the program gives a messagebeep error, you can bpx for that, turns out its inside a dll (elib.dll), a single F12 back to the caller gets you back inside eml.exe (just below the CALL which gave us this error), a simple scroll with Ctrl+Up will show you some interesting code. Lets disassemble eml.exe (12.5k), the developer was obviously versed in dll writing because the main program is really loading code for all the dll imports. Although development wise this is recommended practise, a skilled cracker isn't going to have too many problems finding your protection in a 12.5k exe.
This is the code above the P-RETurned messagebeep.
:004013BB CALL EMLLIB.eeml_Init <-- Is there a dongle connected.
:004013C0 ADD ESP,14 <-- Correct stack.
:004013C3 MOV EBX,EAX <-- Store function returned value.
:004013C5 CMP DWORD PTR [ESP+10], 00000000 <-- Compare.
:004013CA JZ 004013F3 <-- Good_jump.
So we've got the protection dll name (which we can now patch), a DWORD value
which we know came from the dongle and a convenient entry point to continue
our probes. We'll trace using our theories using a deadlisting. The code
resumes here.
:004013F8 PUSH 004051BC <-- "Checking Licenses..."
:00401410 CALL Elib.esec_CheckSecurity <-- Another dll used.
:00401415 ADD ESP,10 <-- Stack.
:00401418 TEST EAX,EAX <-- EAX >= zero please.
:0040141A JGE 00401455 <-- Obviously_good.
I seem to recall reading in a Sentinel implementation guide that you should
never tell a cracker what you are doing..., albeit the developer seems
to be using another dll to perform this check. Now that we've got our theories lets grab
the Loader and bpx for 004013BA, we'll then trace the 2 protection dlls exports
to see where the offending instructions are, obviously the ideal result is too
patch inside these dll's just in case these calls are exported somewhere else (although
I doubt it).
Here is the first location we'll examine (disassembly from emllib.dll).
:6202A3CC CALL Elib.esec_CheckSecurity <-- So it is this dll after all.
:6202A3D4 MOV DWORD PTR [EBP-18],EAX <-- Use EAX's value.
:6202A3D7 CMP DWORD PTR [EBP-18],00000000 <-- >= 0.
:6202A3DB JNL/JGE 6202A408 <-- Good_jump.
So CheckSecurity is also called inside elib.dll and must return EAX <= 0 for a
license to exist, sadly elib.dll is 5.69Mb's to disassemble and those of you
who can feel your way through SoftICE will see what to patch there. Here's the
log file of the code I snatched using the Symbol Loader.
0137:61499C45 CALL 61499CDE <-- Call wonderful protection.
0137:61499C4A ADD ESP,04
0137:61499C4D MOV EAX,[EBP-20] <-- Move dongle data to EAX.
0137:61499C50 MOV [EBP-24],EAX <-- Store @ [EBP-24].
0137:61499C53 CMP DWORD PTR [EBP-24],00 <-- Was it 0.
0137:61499C57 JZ 61499CA3 <-- This is a good_jump_but.
.....
0137:61499C99 MOV EAX,FFFFFFFF <-- Bad_EAX_return.
0137:61499C9E JMP 61499CD9 <-- Return function.
The JZ 61499CA3 is evidently a good jump, the DWORD dongle data at [EBP-20]
needing to be 0, however subsequent instructions affect EAX's value which
will then return FFFFFFFF (-1) in error. Evidently a sensible option is too
patch the bad MOV EAX,FFFFFFFF to say MOV EAX,00000000 (B8 00 00 00 00), this
ensures that EAX is returned as 0 (good guy) regardless, the only potential issue is
in how many places 61499CDE is called, many occurences would need investigating.
As it turns out 61499CDE is called from 2 locations. The one above which we know about and 6149C2DD. If you check the 2nd reference you'll see that it uses the value of EAX as well (storing it at [EBP-14]), 0 is the desired result. This means very simply that at least for single user use, patching the MOV EAX,bad_guy_val I described earlier is enough. As the network option also calls CheckSecurity the patch remains effective.
Return to Main Index,
Dongles.