Hollywood FX v3.08 - Tutorial

http://www.hollywoodfx.com - Webpage.
Files available on request (5.42Mb's).

Over the last few months I've been focusing a lot of my efforts on the HASP range of dongles, but I'm back once again highlighting the fundamental weakness of any dongle, its API. Most Sentinel's I've seen aren't as strong as equivalent HASP's, although implementation is the real question, Sentinel's don't seem to lend themselves to strong schemes, there isn't so far as I know a facility to check anything other than internal return codes, a skilled HASP protectionist can implement some really sneaky tricks. For HFX (a good program which you should buy btw), we'll spend the majority of our time in IDA/SoftICE.

The main protection I located (as I didn't have PhotoShop/Premiere installed at the time) was inside hollywoodfx30.dll, but before you even get this far there is the small matter of the installation serial #, sadly I've lost mine and tracing the installer wouldn't be a lot of fun. Instead fire up Wisdec and decompile the setup.ins, its an easy couple of patches which you should of course make yourself.

We'll find the main protection routine easily enough with IDA and SoftICE, address 1000932D is a really easy entry point (bpx InitCommonControls). Sure enough a few lines away our protection kicks in.

:10009364 PUSH off_100229F4
:1000936A CALL sub_1000FA10 <-- Is Dongle Connected.
:1000936F TEST AX,AX <-- AX has the return code.
:10009372 JNZ short 100093A7 <-- Bad_jump.

Trace over 1000FA10 and note what I term the "Sentinel lag", the short delay in SoftICE :). The return AX=3 is bad (check your API guides, it means "Sentinel Not Connected"), the desired result is AX=0. We can trace this function down and easily identify where we want to patch.

:1000FA99 MOV AX,0003 <-- Move_bad_flag.

A lot of crackers might criticise what I'm about to suggest, as we'll never have the dongle connected it is perfectly acceptable to patch this MOV to something more appropriate (say MOV AX,0000). Of course we can also see by examining the disassembly that forcing the 2 conditional jumps to take the intended code path will give us no benefits. More protectionism approaches.

:1000938E CALL sub_100100E0 <-- Access Dongle Again.
:10009393 TEST AX,AX <-- Once again AX stores return code.
:10009396 JNZ short 100093A7 <-- Bad_jump.
:10009398 MOV AL, BYTE PTR 10026A7C
:1000939D CMP AL, BYTE PTR 100229F0 <-- Needless to say these bytes should be equal.
:100093A3 JNZ short 100093A7 <-- Bad_jump.

:100101F9 AND AX,00FF <-- Polish AX finally. (Change too XOR AX,AX perhaps :) ).

Once again you can trace down this CALL and identify where to patch, although this isn't strictly necessary because the CALL is referenced only at this code, we can also change the byte which is checked elegantly by merely editing the move_bad_flag to MOV AL, BYTE PTR [100229F0]. The final check approaches after some innocent CALL's designed merely to bore reversers, providing you watch AX for a return code of 3 or 9 its easy to locate the dongle checks.

:10009420 CALL sub_1000FC30 <-- Check Dongle (yet) Again.
:10009425 TEST AX,AX <-- Use AX (yet) Again.
:10009428 JNZ short 10009434 <-- Bad_jump.
:1000942A CMP WORD PTR [EBP+0C], 5E6A <-- Dongle return code.
:10009430 JNZ short 10009434 <-- Bad_jump.
:10009432 XOR ESI,ESI <-- Clear ESI nice dongle owner.

I won't insult your intelligence explaining this. Trace 1000FC30 and patch address 1000FCF5 with XOR AX,AX. You also have the address space to change the CMP to a MOV (66 C7 45 0C 6A 5E). Now it appears as if we have a working Hollywood FX. Obviously now that you've seen how the API is structured in the main program any protection inside the plug-ins will be eminently similar (incidentally I've looked at the Premiere plug-ins and they seem to be protection free). As an aside you can now delete the /Sentinel directory.

Additional Notes

Its obviously important to have someone who uses a program check your work :), in this instance you have my apologies.