Its all over for Aladdin & Safe-Net Inc. Released by EDGE are the following commercial emulators.
SoftKey.Solutions.SENTINEL.Emulator.2007.FIXED-EDGE - bug fix for certain Sentinel driver versions (197k).
I'll just use this space to explain exactly what dongles are. Often termed as hardware protection most dongles are small parallel port or USB plugs which consist of little more than factory burned EPROM and a custom ASIC of sorts (on chip) coated in epoxy to prevent tampering (several incorporate tamper trips too). Initial ASIC development costs are high so the dongle sellers compromise quite considerably on parts to drive down unit costs, most of the other components are readily available off-the-shelf.
The idea behind a dongle protection is the developer issuing checks against return values obtained from the dongle, either read directly from its memory or using some internal algorithm. Evidently these calling routines (the API) are the weakest link, although any decent hardware engineer could also peer inside and analyse what the dongle is doing. Virtually all dongle implementations can be broken without the need for the dongle, the software developers who use them usually aren't devious or motivated enough to really invest the time reading the dongle manufacturer's API, they assume that because they are using a dongle that will be deterrent enough, as you can see from reading my pages, this is false optimism of the worst kind perpetuated by the dongle industry.
On very rare occasions dongles can be unbeatable without access to the original dongle, either that or they are just impractical in computing time to break, some dongles literally drive the programs they protect (e.g. LightWave) or make so many checks on query returns (e.g. ArchiCAD) that patching all of the checks reliably just isn't an option (although emulation of the main protection routines is). Others use the return codes from the dongle as inputs to hash functions or as values that control execution flow, implementations of this kind of secure method are few and far between. I really can't stress this point enough, make your way to the dongle manufacturer's web sites and get their API guides, example code, everything you can lay your hands on, often you'll find full SDK's, else you'll be reversing jumps all day.
I should point out that removing dongles from software is legally a slightly different area to debugging standalone applications (even if you have purchased a legitimate dongle), read either here or here the legal directives regarding hardware locks (the second link there is a little German biased), note that if your dongle is stolen you are left up the creek basically, pay for a new one or else. Needless to say, your here only to learn about these protections just in case you need to fix something quickly while waiting for your replacement ;-).
Modt dongle manufacturers have now switching away from the traditional LPT dongle altogether, in favour of better performing USB devices or in some cases smart cards. This is almost certainly where the future of the market lies, well implemented smart card technology is likely to be far more immune from both software and hardware reverse engineering, however the reversing of such devices will still be within the budget of most corporations.
DESKey range (a variety of models all prefixed DK), API documentation
available here (938k).
Dallas iButton - 'button' style protection inside a can.
Dinkey Dongle - 4 flavours of very rudimentary dongle, download my edited guide here (15k).
http://www.globetrotter.com - FLEXlm licensing system (can interface with hardware locks), they have recently removed their SDK's from most parts of the web because of the insecurity, check out the dedicated FLEXlm page.
http://www.ealaddin.com/hardlock/default.asp?cf=tl - Hardlock by AKS, API guide available here (91k).
http://www.ealaddin.com/hasp/default.asp?cf=tl - HASP by Aladdin Knowledge Systems (AKS), also http://www.aks.com. Suggested reading haspman.pdf. All HASP 4 related material can now be downloaded freely from HASP's web page.
Keylok II - From Microcomputer Applications Inc. A very rudimentary dongle designed more for developer ease than any real attempt at protection, '21 years of protecting software' (badly I mighten add ;-) ).
Proteq 'COMPACT' range - Brazilian dongle, you'll need to register (with just an e-mail address) in order to download the SDK and samples.
Rainbow Technologies - Now acquired by SafeNet Inc. Sentinel range by Rainbow, most common model is the SuperPro, newest is the ULTRAPro (recommended reading pro223.pdf, spro_dev.pdf if you can find them, otherwise download the full SDK).
ROCKEY (Feitian Technologies) - Pretty much a copy of all things HASP, the password on the zips by the way wouldn't be hard to guess ;-).
WIBU-KEY - Full API Guide available here (158k), v2 & v4 dongles based around FEAL.
bpio -h 378 rw (I/O port access), CreateFileA (dongle driver file), DeviceIOControl, FreeEnvironmentStringsA (very effective against HASP's). Message Box API's, Prestochangoselector (16-bit HASP's), '7242' search string (Sentinel packet record validation).
Before you download these tools, please note that I am not the author of any of them. I have only tested about 1/2 of them with very mixed results, so do not send me e-mails asking why they don't work with your target.
|Fastread & FastUSBread||Utilities for reading algorithm data and memory from Hardlock LPT/USB devices (109k).|
|Hardlock Envelope Emulator||This dll by SaPu requires a small patch to a Hardlock envelope protected program in order to automatically log and then emulate (via playback) the protected program (20k).|
|Hardlock Monitor||Hardlock monitor (authored by toro). Produces a log of all Hardlock API's, ideal for known targets (1.16Mb's).|
|Hardlock Packet De/Encrypt C Source||C source code for de/encrypting the Hardlock packet structure, this is only applicable to very old Hardlock API versions (authored by HarmEr) (<1k).|
|Hardlock Reader||I forget who authored this. You need to know the Hardlock module address to read the memory, which imho doesn't make it much of an improvement over Hardlock's own Testapi.exe (23k), I recommend HL-DUMP from Sp0Raw's page, linked below.|
|Sp0Raw's latest version of HL-DUMP, the only Hardlock dumper you'll ever need (49k).|
|HL_Solver||Solver for recovering the Hardlock seeds from a dump, author unknown (1.17Mb). This tool works only with Luna Hardlocks (see instructions below).|
|SafeKey Hardlock Reader v4.1||Dumper for Hardlock (requires hlvdd.dll), does much the same as HL-DUMP except considerably slower (28k).|
|Dmp2rg & Dmp2rg v1.5||Conversion programs that convert .dmp files to EDStruct registry data for use with several HASP 4 emulators (9k / 202k).|
|DumbHASP||Dumps the internal contents of HASP dongles (written in Pascal), only works with 112 byte flavours i.e. MemoHASP-1 (47k), courtesy of stpark.|
|Eds2seed||Recovers the seed value used from an EDStruct (an example is included) (10k).|
|HASP 3 Reader||Interrogator for MemoHASP-1 dongles (254k).|
|HASP 4 Dumper||BrainStudio's HASP 4 dumper, you need to supply
the HASP passwords (60k).
*Note* Even though both HASP 4 dumpers are named H4dmp, their outputs are not the same.
|HASP 4 Dumper||UCL's HASP 4 dumper dongles, you need to know the HASP passwords (148k).|
|HASP 4 Schematic||PDF schematic of the HASP 4 hardware (22k).|
|HASP Emulator PE v2.33.A001||Unscrambled source code to v2.33.A001 of this HASP Emulator, requires FASM. I have to confess that it seemed unstable under my Windows 2000 (72k).|
|HASP Grabber v0.97.3 & v1.00.2||HASP memory dumper and rewriter which might work with all HASP key types, its a lot faster than DumbHASP too (18k). I've recently tested this dumper with a HASP 4 key under Windows 98 and it does not work (even if you manually insert the HASP passwords under SoftICE).|
|HASP/Hardlock API Monitor v0.07||HASP/Hardlock API monitoring tool (979k).|
|Safesoft HASP Emulator||A packaged version of a ready made Windows 95 HASP emulator. I have been informed that this particular emulator was obtained from a former Safesoft distributor 'Imagine That' who incorporated the Wise Install password (Hasp0184). This emulator is very similar to UCL's early source code which made me think that UCL had based their emulator on its code, Meteo has since confirmed that this emulator was written by a fellow UCL member involved in the original HASP 3 project. (123k).|
|Soft-Pro HASP Emulator v0.06||More HASP emulation via vxd/sys. These files aren't actually a variation on the commercial UCL Emulator hence my reason for including them. This replaces hasp95.vxd which is curious to say the least, since rewriting hasp95dl.vxd is by far the easier way to go imho. This package also includes the source code and translated documentation (now all that remains is for you to fix the bugs!). Note a little HASP history with some undocumented services (978k).|
|Tony Lee's HASP Emulator v1.3||An integrated HASP dumper and emulator for MemoHASP-1 dongles from this Taiwanese author, take note, you must have the original dongle (143k).|
|Toro's Aladdin Dongles Monitor v2.5||Great service logging tool for Hardlock & HASP dongles courtesy of toro (757k).|
|UCL's Commercial HASP Emulator||Released by Meteo & Fixit this is the full package of a HASP vxd/sys emulator that was being sold commercially. It takes registry keys to activate these files for use with specific programs. All services are emulated however the driver version needs updating (continually). You might ask yourself why these were released to the public?, well the advent of HASP 4 and widespread knowledge of HASP cracking techniques probably means these enterprising Russians aren't making any money out of selling HASP cracks (103k).|
|Tools||Description / Review|
|DESkey DesLock PE Prot. Remover v1.00B||Previously known as KILLDK3 (150k). Now supports (DK2 / DK38 / DK3 / DK12 / DK37 / DK9 / DK25 / DK47) and Deslock v2.25,2.27, courtesy of ExeLord (141k).|
|Dinkey Dongle Manual||Dinkey Dongle Developer's Guide (564k).|
|Dongle IDA Signatures||Hardlock, HASP, Keylok, Sentinel & Wibu signatures for IDA (155k), *updated March 2008* .|
|Dongle Readers||Freeware HASP/Hardlock & SSI (Activator) dongle readers (10k).|
|DongleSpy BETA 1||+spath's generic DOS dongle spy (includes source code), one for your low level probes (4k).|
|Eutron SmartKey Dumper||Unverified dumper for Eutron SmartKey (90k) (dump is ciphered so not directly usable).|
Internal disclosure of KEY-LOK II kfunc() (6k).
Small bug : sscanf(mystring,"%08x", &ValidateCode1); sscanf(mystring2,"%08x", &ValidateCode2); Edit klcalc in hex-editor: sscanf(mystring,"%04x", &ValidateCode1); sscanf(mystring2,"%04x", &ValidateCode2); and klcalc works OK.
|KeyPro Emulator||Dongle emulator for DOS hardware keys, includes source code, (useful for historical reference only) (74k).|
|MicroGuard IDA sigs||mgvc32c.sig (MicroGuard PC API (x86/C/MSVC)), mgcw32c.sig (MicroGuard PC API (x86/C/CodeWarrior)) (8k).|
|Proteq Emulator||Proteq dongle emulation VxD with source code (12k).|
|SenZap v1.2||Includes DosZap & WinZap (ageing software to remove unknown dongles) (8k).|
|Safesoft SSI Emulator||Generates reliable vxds for this very particular flavour of dongle (21k).|
|SKEYEM v1.0||Eutron SmartKey NET skeylink.dll emulator (3k). Also try this replacement SmartKey dump and emulation dll (103k).|
|USBDongleSearch v1.0b||Utility by souz for identifying manufacturers of connected USB dongle devices (186k).|
|Virtual DOG v1.04||Sent to me by the Chinese author, this dongle emulator relies on trapping low-level IO access (very similar to WKPE according to the author) (94k).|
|Wibu Logger||Toro's WibuKey logger for protected programs (31k).|
|Wkdump & Wkdmpusb||Wibu-Key LPT & USB key dumper, requires wkwin32.dll (unverified), (55k).|
(also includes versions 1.01/1.2/1.5/1.8)
|This one was kindly sent to me by the author and is freeware (Windows 95 only). Its approach is vxd based yet not specific to any specific dongle, seems to rely on trapping low-level IO access (of course you need the original dongle). The author claims 80% reliability or effectiveness, I recall reading elsewhere that this could be somewhat optimistic :-). I can only advise you try this (it didn't work on the HASP or Sentinel I have here). As its free I don't really think you ought to trouble the author too much for support (1.04Mb's).|
|Dongle Spy v1.0||A monitoring program for Super SentinelPro dongles, pretty much obsolete (25k).|
|DumpSentinel v0.2||Memory dumper for Sentinel SuperPro dongles by sPLiFF! '2000 (40k). Will brute force the Developer ID and dump just the dongles memory.|
|NetSentinel Emulation Library||Sentinel NSLMS emulation library with source code, courtesy of MeteO (8k).|
|PVA Sentinel SuperPro Dumper||PVA's Sentinel SuperPro dumper (54k).|
|Sentinel De-VM||An IDC script for use with IDA, comments the Sentinel shells VM (1k).|
|SentinelDumper v1.0||Sentinel dumper of Chinese origin, dumps only the cell attributes and memory contents (125k).|
|Sentinel SuperPro CrackMe||Test your Sentinel skills, courtesy of CyberHeg (my solution is available on request) (30k).|
|Sentinel SuperPro Readers||Obtained from SafeKey, Sspro.com and Sentread.exe (63k).|
|Sentinel SuperPro Tools||DOS/Windows & I/O capture tools for Sentinel dongles (477k).|
|Sentinel SuperPro (vxd) (v0.08 & v0.24)||A vxd for Sentinel dongles (this looks like a method to support only specific applications, hiho's Yonkie btw :-) ) (32k). Latest version usually available here.|
|SPRODUMP v0.2||A working Sentinel SuperPro memory dumper by +spath (I've included an example of a dump in the zip, tested in October 2000, now includes source code) (96k).|
|SPUICA||v1.05.1 of this Sentinel Shell Remover (courtesy of the I.C.A (hi! guys)), (202k).|
|SSUNSHL||Another Sentinel SuperPro Unsheller (138k).|
Attacks on and Countermeasures for USB Hardware Token Devices - An interesting paper discussing some hardware reverse engineering of USB protection devices. Of course dongle manufacturers don't normally make the elementary mistake of shipping their hardware without the protection bit set so you can read out the firmware.
Bitwixen - An individual offering his own reverse engineering services, mainly of dongles (HASP/Sentinel and other generic licensing systems), of interest since he seems to have his own custom Sentinel drivers (available in demo functionality), unfortunately query responses are handled via registry keys, i.e. complete emulation is not present.
Brain Studio (Glasha) - Offers his own HASP emulator. In 2003 these used to be free to download and use (if I remember rightly), at some point (probably the HASP 4 breaking) this changed to become time limited (30 minutes) and shortly after users were then expected to pay for the emulator. The HASP 4 project was closed in April 2004 after a Russian cracker managed to break the emulators registration function, this however will not allow you to easily recover the details of the new HASP 4 Decode/EncodeData functions. You can download release v2.33.a002 here (1.86Mb's) including the keygen, the drivers used by this emulator are heavily obfuscated (however I managed to remove a lot of the tricks with simple search / replace + wildcards in WinHex), in fact Glasha seems to have borrowed some of his techniques from the Aladdin developers. This emulator has the added disadvantage of not supporting Hardlock, although I understand a later version has been produced that does. Should you own a HASP 4 dongle you can download h4dmp.exe from Glasha to produce a dmp file and then use dmp2reg (10k) to create a working EDstruct (ED perhaps for encrypt/decrypt) registry key for complete emulation.
DongleLabs - Offers Matrix / DESKey / Sentinel SHK / Sentinel UltraPro / HASP SRM / HASP HL / KeyLok / Dallas emulators and licensing solutions for FlexLM / Sentinel LM / ElanLM / CrypKey. I believe these to be reputable.
FrogsPrint's 'Dongle Bashing paper, the end of an era' - Very good (and very long paper) destroying 15 dongle protected programs (57k).
IEEE Computer Society Strength Measurement for Dongle-Protected Software - Nov/Dec 2007 report, mirrored here as they explicitly mention this page (432k).
JCDONGLE - Jeffrey Corwin's Dongle Emulation Services. Offers legitimate dongle emulators for most of the common keys, (Hardlock / HASP / Sentinel / Wibu / KeyLok) as well as license solutions for most of the common license managers. Jeffrey was kind enough to send me several private examples of his work so I can vouch for his authenticity.
Larry's Home Page - Another dongle emulation service provider. Has a useful selection of utilities for dongles such as Guardant which I have yet to study in any detail.
mAxIm's Dongle Page - Predominantly HASP related files / information and a mirror of an early version of this page. Useful site for legacy HASP dumps which I've mirrored in a complete archive here (76k).
MD5 Hashing Articles - 2 descriptions of MD5 hashing which is used by the HASP envelope, the return codes from HaspCode() are the input, the message digest?, forget about ever reversing it.
MMGroup's Webpage - or Martin Mckeen (both of his sites have disappeared from the web for violation of TOS, want to take one guess on who reported him?). Offers hardware duplication of HASP's, of interest because he seems to have done analysis work on HASP 4 which implies his hardware must support the new decrypt / encrypt services. Here are some hardware pictures such as the HASP logic trace and wiring scheme. After combing DejaNews I also managed to find a quite interesting post regarding the new HASP 4 functions.
In May 2001 Martin was kind enough to e-mail me with the following update. "I wish to announce a death of newest HASP 4 functions Encode/Decode. After 8 months search I really found a way how encryption is done inside the ASIC. More - I designed a duplicate based on MCU which simulates HASP 4 - it really works perfect. If you hear somebody has problems with HASP 4 - you can pass them my mail... I will try to help." So there you have it, another instance where security by obscurity has once again been proven useless.
Quine's "Pushing the Envelope with HASP" essay - A simply superb essay which disappeared from the web a while back (I have some idea as to the reason why). Now that the envelope has moved on a little I see no harm in re-publishing this great document in its entirety (if Quine objects I'll remove it).
Rainbow I2C Analysis Project - Analysis of dongle hardware (invaluable for all serious dongle aficionados), this covers Sentinel keys (132k).
Safe-Key - (formerly SafeSoft of Canada), sell emulators to legitimate end users (you have to prove you own a dongle). I confess to hearing some rumours about the former 'SafeSofts'' integrity from disgruntled end-users, this may or may not be the case with the new company.
Semi-invasive attacks - a new approach to hardware security analysis - A very interesting paper from the University of Cambridge which describes techniques that can be used to analyse hardware security devices (11Mb PDF download).
Spectrum Software - Based in the USA (site needs a bit of updating though). Have been offering dongle replacement software since 1991 and also advertise their services in Computer Shopper. Joe Montoro who manages Spectrum has been very supportive towards this site and me personally and is constantly exploring legal avenues against the likes of the BSA/SPA with regards to dongles (even recently the DOJ have used his services). Joe assures me that he will only deal with legitimate dongle owners.
Joe also has something of a history in the 'hardware lock scene' and has fought developers (and proud members of the BSA) such as CNC Software in the past when he ran 'Imagine That' (products Icelock / Rivalock). As an aside might I suggest that anyone looking for a legitimate dongle replacement or solution contact Spectrum Software first and avoid like the plague any of the russian sites offering 'dongle emulations' (usually in badly written english); payment to be sent by Western Union or transfer (whereupon you'll never see it again ;-) ), consider yourself WARNED.
Sp0Raw's Webpage - An old (russian) friend of mine, hosts some interesting research and resources regarding dongles (Sentinel, Hardlock (dumper for the 8k of algorithm data required for full emulation (actually this just seems to be a better implementation of Safe-Key's fastread.com)), HASP 3/4, MicroGuard) and also FLEXlm (website information is generally in Russian though). A selection of decompilers for Visual Lisp and VB are also available. One of the few good sites and trustworthy vendors of dongle emulation solutions.
UCLabs (Reverse Engineering) - UCL were one of the foremost groups in the dongle reverse engineering scene back in the 90's. This new site has several current dongle dumping tools (for HASP/Sentinel/Hardlock dongles) and several of the old classic HASP essays, be advised that the majority of the pages are in Russian. Individual UCL members have considerable experience and knowledge of many dongles, this page however seems to be more focused on selling dongle emulators.
MYLOCK.FST Builder 0.1 - Simple utility by Larry to generate SafeKey Hardlock .FST files (13k).
UniDmp2Reg v1.1b0/1 & 2 - Universal HASP dump to reg converter by sataron! (if you have dumped out your Hardlock or HASP key and have any of the popular emulators) this tool will generate a working registry file for immediate importing (246k).
The Hardlock envelope performs its decryption using the undocumented 0xE API service (or E-Y-E algorithm), E-Y-E was acquired by Aladdin from FAST Germany in 1996, the envelope also uses the documented API's API_GET_TASK_ID, API_INIT, API_AVAIL & API_DEINIT. E-Y-E is a block cipher which transforms 8 bytes of encryption data into an 8 byte response, since speed is of the essence each 8 byte response is then usually used as a key to decrypt larger chunks of encrypted data, this means that a plaintext attack could theoretically recover a query / response pair (as it turns out this isn't required since the correct responses are stored in the envelope).
I believe E-Y-E was first recovered by SafeKey via hardware means (however the file hlse_inst.zip available from many Aladdin ftp repositories contains a significant portion of the algorithm), many reverse engineers have recovered the full algorithm directly from SafeKey's emulator which has been passed around several Russian messageboards in the form of individual emulators for specific programs. The details have largely remained a closely guarded secret since there is apparently considerable money to be made in selling dongle emulators.
E-Y-E's internal security depends upon the secrecy of 3 16-bit seeds (in Flora Hardlocks this consists of a 32-bit Basecode & a 16-bit Subcode, see below for more about this), this gives a theoretical strength of 48-bit which would certainly be beyond the brute force capabilities of most desktop users. The Hardlock dumpers that produce 8kb of 'algorithm data' provide information that enables a faster recovery of the seeds, the simplest rule to apply is to treat the algorithm data as an array of words (this gives a maximum of 16 possibilities), each of which is a candidate for seed 2, this rule reduces the bruteforce possibility to 0xFFFF x 0xFFFF x 0x10 and is faesible on most current desktop systems. There are at least 2 other rule reductions that can also be applied as well making a brute force of anytime between 10 seconds and 5 hours, without access to the original Hardlock or known encryption / decryption data (the envelope provides that unfortunately), Hardlock would be reasonably secure against unknown attacks.
SafeKey's emulator uses its own *.FST data files for emulation (most likely the .fst is to denote 'FAST' or something similar), *.FST files are 138 bytes in length and have the following format :
dw modAd ; module address of supported Hardlock
db 128 dup(0) ; Hardlock memory (if applicable)
dd seed3 ; e.g. seed3 = 12EFh represented as 01 02 0E 0F
During the Hardlock product cycle Aladdin provided developers with the ability to program their own 16-bit Subcodes into their Hardlocks via the crypto programming card, this has the effect of altering the cryptographic behaviour of the Hardlock, a Subcode is an integer value between 0-43679, Hardlocks encoded in this manner have been termed the 'Flora' hardlocks and can be identified by their modAd's (if modAd & 0x1F = 0x1F then Flora), the Luna Hardlock's do not have this property. Many thanks to a poster on the RCE Msgboards for clarifying this.
A solver for the Luna ASIC by an unknown author has been recently posted (a modified demo version of a private tool) and can be downloaded here (1.17Mb), users should create a directory named 'trial_solver_directory_demo_version_only' and place the .dat file created by HL-Dump into the directory, solving of the seeds should take a maximum of around 30 minutes. I can verify that this particular solver does produce accurate seed results for Luna dumps.
The HASP 3 range of dongles depend upon a single API (HaspCode() or service 2) for their security, analysis of this is provided by exefoliator here, he has graciously provided the following code samples included here (8k). The rest of the HASP API functions can be emulated or have returns patched for. A developer must call HaspCode() with their unique HASP passwords and a seed code used as a seed for random number generation, if the correct HASP is connected 4 return codes will be generated. If the dongle isn't present all 4 returns will be zero'd. Aladdin's HASP Envelope (a full blown PE encryptor) depends upon the return codes from the HaspCode() service for its decryption, without knowing the correct responses to a given seed the protected program cannot be run.
The original HaspCode() algorithm was first recovered in the early 1990's but its details didn't leak until 1997 courtesy of UCL. The story I've heard about how it was found is somewhat hard to verify, however, I think I can confidently state that it came from 1 of 2 sources. The first is a commercial emulator from SafeSoft, who used to ship the driver Hasp95.vxd to customers, the algorithm is clearly visible inside; the second is an old driver binary (haspgar.bin) which also contains at least the major part of the algorithm, this can still be found archived around the web.
Example (from a real TimeHASP - ALLDATA v2.5) :-
:0045F02B PUSH 00006B47 <-- 2nd HASP password.
:0045F030 PUSH 00003815 <-- 1st HASP password.
:0045F037 PUSH 00000135 <-- Hasp Seed Code.
:0045F03C PUSH 00000002 <-- Basic Service 2 (HaspCode).
:0045F03E CALL 0045F0A6 <-- HASP routine.
:0045F046 CMP DWORD PTR [EAX+18], 0000B940 <-- Good return code.
On this occasion you are given the value of the return code that is checked, (you can verify this with the generator). Of course if you are planning on reversing lots of HASP's you'll want to convert this code into ASM, perhaps emulating other services whilst your there, this should be achievable in under 120 bytes if using a static table or a little longer for the generic algorithm.
In the latest generation HASP 4 dongles the HaspCode() implementation appears initially to have been changed, the return codes are no longer compliant with the known generic algorithm which either derives the secret table from the HASP passwords or uses the universal secret table. In fact all that has really changed is the password -> secret table relationship (although from the HASP 4's I've looked at, I doubt now there is actually a relationship). I read on Sp0Raw's webpage that there might be a relationship for some HASP 4's, however since developers have their HASP's custom manufactured by Aladdin the only way this might be likely is if certain Aladdin manufacturing sites were using different secret table construction methods; either way this all remains pretty academic since there are definitely boolean patterns from which one can infer unknown bits. You can download this HASP 4 unlocker which will reveal the secret table for HASP 4's in your possession; or by utilising 2-3 known HaspCode() responses from a HASP 4 dongle you can manually derive the secret table (most dumpers use 8 HaspCode() response sets to be sure of getting all the bits, however some of the HASP 4 dumpers above use as few as 5 (seeds 0xFFFF/0xFFF/0xFF/0xF & 0x0).
Even with this information, in the latest generation envelope, HaspCode() features only for internal use (background HASP checks) and the code section is now decrypted using the new HASP 4 block encrypt / decrypt services (Feistel cipher in CBC mode), during the enveloping process the sections are encrypted using 0x8 or 0x10 byte queries to the HASP. By searching the newsgroups one may find an early initial analysis of the function using the HASP demo dongle, or one may conduct a software analysis of the HASP communication routines which have changed very little since HASP 3. I understand the HASP 4 algorithm was recovered as early HASP 4 dongles used Cypress chips without the protection bits set (this is pretty much the hardware equivalent of shooting yourself in the foot), it was simply read out.
Update October 2005 - There are now 2 methods to completely emulate the HASP 4 encoding/decoding function; early emulators construct a 2016-bit EDstruct table using 8 rounds of encrypt/decrypt responses (tools such as dmp2rg or dmp2rg v1.5 available above can automate this process). Fairly recent emulators however appear to have broken the HASP 4 internal logic which seems to be a LSFR based upon a seed value and the secret table (the seed value can be recovered from the EDStruct using the tool Eds2seed). This most recent break may have implications for the theoretical strength of the HASP 4 envelope.
If you are interested in say HASP 4 hardware unlocking ;-), then perhaps pass2seq.cpp might be interesting.
HASP-HL is Aladdins latest generation of hardware key and implements full on-chip AES encryption. With a symmetric encryption system such as AES all of the security rests in the secrecy of the actual key, AES has thus far proven itself very resistant indeed to any known attacks aimed at recovering the key, this implies that HASP-HL itself ought to be very secure as well. Although I can't verify this for definite it seems very likely to me that Aladdin custom assign AES keys to each customer during the manufacturing cycle, if a way was ever found to read these out of the hardware then that vendors protection would be completely compromised, but I'm really not hopeful Aladdin would have made this mistake twice. My guess is that Aladdin may well have some means of rewriting the on-board AES key just in case a very determined attacker was to significantly invest resources in recovering an individual key from the hardware, however even this would be a fairly limited impact break.
The current generation of commercial HASP-HL emulators work only in 'HASP 4' compatibility mode. The HASP-HL device itself only actually ever encrypts a maximum of 16 bytes of data, any larger buffer will simply be cycled using this response data as the initial key via the API, this is most likely a decision based on the fact that encrypting in hardware is slower than in software, it has no implication for the security of the AES key. In summary, HASP-HL currently appears secure from all but the most expensive of attacks.
Recently released by MeteO, but also recoverable from any of the commercial SafeKey Sentinel emulators is the complete emulation code for the Sentinel Pro query function.
Sentinel has remained one of the most resistant keys to hardware analysis and attack largely due to Rainbows use of their own custom hardware rather than cheaper components, its API and automatic shelling tools however leave much to be desired giving the shell a strength of only 2^32. Sentinel is largely a tale of 2 algorithms, often these are termed as the 'pro' and 'advanced' queries (after the API sproQuery() that implements them). The pro algorithm was broken in 1993 and can be found in SafeKey's SafeSSPR emulator.
The 'advanced' algorithm is an alteration on the pro, it is both enhanced algorithmically and also incorporates memory cells (DWORD algorithm descriptors) that are capable of altering the effect of the unit, many scene crackers believe that sproQuery() remains secure. However, this is not absolutely the case, full query emulators are required to recover the algorithm descriptor (depending on which cells are assigned so) and build an internal table (SafeKey uses files with the suffix .ssp); as little as 8 carefully constructed query values are required for this process. Having sufficient query data usually requires access to the original dongle so the impact of the break could be considered somewhat limited. (My thanks to several people and their source code for this information, you know who you are ;-)).
The Sentinel shell is implemented as a message loop of function definitions, this makes tracing somewhat tedious, here for your reference the complete 'message list' courtesy of ketan.
ControlStruc Struc val1 dw ? ; func id val2 dw ? ; element id val3 dd ? ; element ControlStruc Ends ; element id 0x068 *b 0x28e *w 0x234 *d 0x3d5 d 0x0d4 d (index) into cElement (* dword array) ; func definitions 0x1a44, n/a, *func ; cElement = func() 0xba51, n/a, *func ; cElement = func(cElement) 0x1109, n/a, *func ; cElement = func(cElement.04, cElement) 0xb323, n/a, *func ; cElement = func(cElement.08, cElement.04, cElement) 0xaa61, n/a, *func ; cElement = func(cElement.0C, cElement.08, cElement.04, cElement) 0x9b73, n/a, *func ; cElement = func(cElement.10, cElement.0C, cElement.08, cElement.04, cElement) 0x00e4, n/a, *func ; cElement = func(cElement.14, cElement.10, cElement.0C, cElement.08, cElement.04, cElement) 0xcd03, element id, element ; cElement = element 0x1092, element id, element ; cElement += element 0x22b7, element id, element ; cElement -= element 0x9104, element id, element ; cElement *= element 0xfb52, element id, element ; cElement /= element 0x3345, element id, element ; cElement &= element 0x654d, element id, element ; cElement |= element 0x74bb, element id, element ; cElement ^= element 0x698a, element id, element ; element = 0 0x1992, element id, element ; element = cElement 0x5211, element id, element ; element = cElement 0x0704, element id, element ; element++ 0x3dc8, element id, element ; element-- 0x5910, n/a, lpControlStruc ; clpControlStruc = lpControlStruc 0x7123, element id, lpControlStruc ; if (cElement == 0) then clpControlStruc = lpControlStruc 0x0611, element id, lpControlStruc ; if (cElement != 0) then clpControlStruc = lpControlStruc 0x2245, index, n/a ; clpControlStruc = cElement, cElement += index*4 0x0342, index, value ; cElement[index*4] = value 0xbed7, n/a, n/a ; cElement = clpControlStruc 0x8109, id, n/a ; if (cElement == id) then cElement = clpControlStruc 0x65ab, id, n/a ; if (cElement != id) then cElement = clpControlStruc 0x096f, exitcode, n/a ; if (exitcode == 0) then SUCCESS, else display error message & exit
DigiSHOW.vld v1.25 - Just
don't use DESKey's dk47wn32.dll for your protection (05/09/98).
Vero VISI Series v7.2 - Inside the DESKey DK2 dongle protection (includes DESlock), (21/08/00).
ALLDATA CAR v3.0/3.2/v4.25/v5.25/v6.0
- How to emulate completely the main HASP() routine (27/03/00).
Barudan Punchant v6.0G - TimeHASP-4 and function disabling reversing (28/12/99).
CASMate-Pro v6.52 - HASP envelope encryption reversing and complete emulation of a MemoHASP (22/10/99).
Cimagrafi v126.96.36.199 - MemoHASP-1 envelope cracking without unpacking (21/02/01).
Cimatron Series (v10 BETA, v10.6, v11.0, v11.1, v12.0) - HASP emulation, adding code to a dll, HASP's new encrypted object, redirecting HASP routines, HASP driver attacking, Cimatron's KeyCode algorithm (17/08/01).
FabriCAD Suite v3.0 - Recovering HASP return codes and patching a good HaspCode() implementation (04/09/99).
HASP Envelope Cracking - How to unpack the HASP Envelope, also an introduction to the HASP dll technique (24/04/00).
Inec Investor 7.3 - Fast HASP Envelope unpacking (courtesy of aSL!) (10/07/01).
Mastercam v8.1 Beta 2 - HASP and access code reversing (05/12/2000).
Matchmover - InstallShield decrypting and HASP cracking (courtesy of Kashmir) (09/06/00).
Hardlock Dongle Reversing
- Great paper by MaV3RiCk (with an addition by yours truly) (14/09/00).
Plastic Animation Paper - Hewlett Packard's ppppapi.dll or 'why you shouldn't use this protection' (25/01/00).
SSI Dongle Protection - Historical essay describing how to rebuild encrypted SSI dongle protections, useful for general information and if you have the dongle (22/01/98).
Vellum Solids 99 & WIBU-KEY - WIBU-KEY & yet more algorithm reversing (29/02/00).
Wibu Protection - Knuth20 implementation analysis (15/09/06 - 299k).
Zen & the Art of Dongle Cracking - A general document by zeezee describing how to approach dongle reversing.
3D Studio Max R2.5/R3.1
- Tracking Kinetix's changes to their Sentinel protection, discussion
of sproQuery() (03/06/00).
AutoCAD R14 (French Version) - Courtesy of ACiD BuRN (19/08/00).
Breaking the shell - Sentinel shell breaking courtesy of CyberHeg (March 2001).
CPSWin32 v1.3 / v188.8.131.52 & GeoPath Power CAD/CAM - Emulation of the Sentinel Cplus dll (31/10/00, updated 12/07/07).
FlexiSign PRO - Sentinel cracking courtesy of goatass (16/06/00).
StruCad Drawing Viewer v2.05 - Recovering of original dongle words (21/02/00).
Surfcam 2000 - sproQuery() emulating, general Sentinel (08/02/01).
Virtual Gibbs v5.05/v5.55rc1 - Re-writing sproRead() and identifying Sentinel trademark API weaknesses (26/09/99).
Please do not ask me for 'cracks' for any dongle protected programs, whether featured here or not, I won't help you.
Of course some of the developers are kind enough to supply wonderful little utilities such as the example above from Cimagrafi. Naturally ALL of my options are now enabled :-).
When reversing HASP & Sentinel (and other dongles too), there is usually a piece of information supplied to the developer which identifies that specific dongle. HASP's for example are characterised by their passwords and Sentinel by a developer ID & other passwords for specific API functions, Hardlock is identified by its MOD address. The following page linked here is my attempt to log those manufacturers details I am aware of (its by no means a complete list of even the programs I have reversed so I hope you will contribute).
If you insist on protecting your application with a dongle consider heeding my advice :
1. Firstly, when any good cracker attacks your software he or she (not to discriminate) will usually go looking for the tell-tale signs of your dongle manufacturers routines (read above how all dongles are vulnerable to simple API breakpoints / code signatures, as well as many other approaches), to be honest there isn't much you can do to disguise that you are using a dongle because communication ultimately takes place via the dongle vendors drivers. Assume therefore that a cracker isn't going to have much difficulty identifying each of the dongle API's, this reduces his task simply to working out what the dongle should return/contain.
Your first step therefore should be to make this task harder. If your dongle vendor provides any encryption e.g. the HASP envelope or Sentinel shell then USE it and check for file tampering, this is especially effective with dll's which are time consuming to unpack. At present all HASP 3 envelopes can be broken because the HaspCode() algorithm used is known, however it will still add time to a crackers progress, HASP 4 remains secure but can still be broken with known query data. All Sentinel shells are vulnerable to either a known plaintext attack or brute force. Caveat emptor : The HASP envelope & Sentinel shell won't stop anyone with a legitimate dongle, however multiple files requiring de-protecting buys time.
2. Detect debuggers and anti-debugging tools e.g. FrogsICE, SoftICE, only a cracker is going to be running the former and the latter is unlikely on any of your customers machines, use at least 2 routines for your detection and DON'T tell the cracker you've found it, if you do alter the program flow subtlely, redirect the cracker to a routine that he really doesn't want to analyse, don't do anything illegal like formatting hard disks, just one instance of this happening to a legitimate user will render your product obsolete. See my anti-debugging page for many detection possibilities. Also encrypt your "bad guy" message strings otherwise a disassembler will easily isolate them. Like tip 1, eventually we'll find a way around, but time is what you are buying ;-).
3. For the most part a cracker won't be familiar with the operation of your program and the warez peddlers generally don't test very well, this is the most powerful weapon you can ultimately use, words from your dongle can be used as encryption seeds, values in switch statements or variables critical to specific functions, if your program performs any mathematical or statistical analysis/calculations a dongle word is just begging to be used and for gods sake don't check its value :-). The more doubt you place in a crackers mind about a word's value the more time he'll waste staring blankly at his debugger and the less likely an illegitimate commercial user will make do with the cracked version, if you can, use proprietary encryption (say like hash functions) on your dongle data.
4. Sometimes a cracker will be fortunate enough to have a "dump" of your hardware keys contents or he may possess the actual dongle (very unlikely in my experience of the warez scene), if you can spare the dongle memory space use a registry query to retrieve the RegisteredOrganization key and encrypt it before storing it to the dongle's memory (this might at least help you identify your disloyal customer). Any cracker worth his salt with access to a legitimate dongle will break your protection (eventually), try therefore to educate your customers a little with regards to software piracy, small organisations with 1 or 2 licenses are much more likely candidates to leak your software, support them if you can with friendly licensing policies or stop charging full price for a lost dongle, you might appeal to their conscience :-).
5. If you are using Hardlock, HASP or Sentinel then most of the commercial crackers already have generic vxd/sys files which they will merely configure with registry keys and distribute, this of course means they will not actually alter your program, attacking instead the dongle manufacturers code, consider therefore adding additional protection means such as strongly encrypted keyfiles, server validation checks, encrypted registry keys, basically anything that will add hours to a crackers progress. For example I'll give you CimaRender Pro v7.0 (a program I recently reversed), the HASP dongle on this target took me under 4 minutes (literally) to crack, using pure finger movements, yet reversing the Key algorithm required near 2hrs analysis (although I acknowledge I could have patched after around 20 minutes).
Finally take a little visit to some of the search engines and find out if a crack exists for your program, if you can actually obtain it, download and study the weak links in your protection.
The objective of mastering the art of dongle reversing rests inside the ASIC's used by these parasites. In virtually every off-the-shelf dongle I've seen sold to developers there is an API function provided which uses unrecoverable algorithms to manipulate passed parameters, this occurs independent of the EPROM. In HASP this API is HaspCode() or Service 2 which has been completely broken (see above for the source code), although I can tell you now that this was only achieved with careless leaks inside Aladdin.
Sentinel's equivalent RNBOsproQuery() is not so widely studied and can't be generically broken according to their API guide because the internal algorithms are apparently different for each customer, from a dongles review site I snatched this fairly useful snippet '...SentinelSuperPro features 14 field-activated algorithms, memory, and Rainbow's proprietary ASIC...the key is the industry's only software protection device to combine the benefits of multiple algorithms and read/write memory in one solution'.
The standard Sentinel query has been broken yet the default Sentinel API implementation isn't robust enough because rarely is the query being used to decrypt the program. HASP would have remained secure if its algorithm hadn't been discovered because it is responses from the ASIC which are used to decrypt the code section, no dongle = no execution.
The name of the game with real dongle reversing is "API awareness", don't think you'll break good dongle implementations by just SoftICE'ing and reversing a few jumps, you may do a few weak implementations this way but not many. Get the documentation and WATCH the queries and word reading API's very closely, then emulate the main routines. Remember it can sometimes be impossible to recover the exact response data because you'll sometimes end up with TEST [ESI+38], 1 which tests only a specific bit of the response data (this example from a real dongle, STAAD Pro).
If you have access to the original dongle endeavour to study it DEEPLY, bpr or bpm on returned words from the dongle. Certain dongle manufacturers sadly see it fit to try and obfuscate our debuggers, so patch your SoftICE against the most common anti-debugging tricks.