Undocumented HASP
by -bajunny
Part I

26 February 1998

---

Courtesy of Fravia's page of reverse engineering

sans espoir et sans regret..


    Live long and prosper dear +Fravia!

  This is my first post to you.. Recently I found your site
(courtesy to Peter Gutmann's links farm) and sit still
for quite a while.. It is SOMETHING.. I only might compare
it to not so many miracles of our time: FSF, Linux, LANAKI's
classical cryptography course.. It's simply GREAT! 

  Then I decided to tribute in some way, coz ideas 
exchange works this way.. by exchanging ideas, not by 
unilateral dataflow.. Hardly I'll ever be a HCUker so I 
don't cry for you to place my text on your pages. But you'll
be the first person seeing my work. Why? Reasons are given..
I also believe presented material might start completely new
branch in the Project3..

  I'm confident this text will be useful for many crackers,
coz dongles are everywhere and any serious cracker inevitably
comes one sunny day to crack HIS DONGLE.. 


Undocumented HASP
by -bajunny

Part I


26 February 1998
               

    1. Introduction (sorry, too long)
    ---------------------------------
  It is amazing to see how many people believe in strength 
of dongle protection. It can be explained for I have some 
affiliation to ad business and know the cuisine pretty well 
but it is still _very_ amazing. Take HASP for example. 
Some of my fellow programmers, even experienced in cracking 
still admit that HASP is #1 protection in the world because 
of: "..97% rating by.., sophisticated API.., ..irreversible 
encryption". Well, decrypting irreversible encryptions is 
my hobby and as for ratings.. Ratings favor who paid more and 
are shit by itself. Just don't pay attention, ratings are for 
stupid jerks like my fellows from ad business. What's left? 
API? Well, we will analyze it a little and I believe you won't 
pay a cent of confidence to HASP superiority at the end 
of this text.

  What we have in our surgery? I am not an expert in 
electrical engineering but still know how to handle soldering 
iron :)  Actually, on may _see_ HASP internals without any 
destruction if got hands over any full HASP software 
distribution - there are pictures out there, I recommend 
ASIC.TIF.. As far as I can imagine, HASP is nothing more than 
modest EEPROM (I'm going to deal with only LPT-pluggable 
MemoHasp here) plus Programmable Logic (factory burned they 
say) plus some flip-flops and power grabber. You send commands,
it changes internal state and sometimes provides you with 
response. Clear picture? Not yet. There's a gap between 
our API calls and actual data sent and read and I'll do my 
best to present to you some findings to shorten the gap. 

  An important notice: I claim that all presented material has
been tested on MemoHASP-I devices only (I found four dongles 
in the neighborhood). I see no particular reason why 
it shouldn't work on other LPT-ing HASP dongles. Whenever 
different behavior is assumed, I'll put appropriate warning. 
But once again: I've tested only Memos.. If you are interested,
all this was explored during torturing of funny buggy proggy
called InscriberVMP. I still like her: no envelope, pure
API calls, no checksumming in memory, no anti-softicing..

  Let's begin with API function #2. HaspCode they call it if 
I am not mistaken. BTW, better got your copy of HASPMAN.PDF
from someplace or read Zafer's essay to understand what this
funny API names mean. This function got from you some 
unimportant crap like port number, and more valuable SeedValue
and HaspPassword. If the last was correct API will supply you
with four 16bit numbers on return - The Great Magic Numbers of 
HaspCode. If not - you'll got a bunch of zeros. As we'll see,
the word Seed* gives us a clue, but now just realize that 
those four numbers are base for almost any protection, 
including enveloping.

  Poor programmer has to pepper flow of execution of his 
proggy by those moronic API calls (not only func #2), gathers
cryptic four-numbers and apply them for smth protective. 
As many of you dear crackers already demonstrated, sometimes
all protection ends in a trivial jxx beggar_off_bad_guy, 
but sometimes not. As for my Inscriber proggy, it has a pool
of 13 coded HASP responses and on some event asks HASP 
for one of them anew, performing various jmp beggar_off later, 
if it fails. Yeah, it could be easily patched the usual way, 
but still not in one place. I decided it would be more cool 
to write full HASP emulator - and did it! So left this proggy 
alone, we are going to crack HASP - it is much more exciting.

  Here's a bit of necessary information on LPT ports in case
you have no clue (shame!). There are three common addresses 
where one may find LPT port: x3BC x378 and x278. You can 
consult BIOS data area at 0:408+ to find out which address
correspond to which LPT. I took x378 as the base for LPT1. 
For our HASP business only following is of relevance:

  x378 data send port, only write command/data bytes here
  
  x379 status port, only read, bit 5 stands for PAPER_OUT
       signal, HASP will fire 0/1 here, talking back to us
  x37A control port, earlier versions used to write x0c here, 
       but modern ones seem to cancel this
       practice; usually it served as dongle power source,
       by firing 0th bit wire (STROBE signal) 
       dongle circuitry recharges; HASP uses another 
       mechanism.. don't care..

    2. Four Magic Numbers
    ---------------------
  Here's a useful add-on to HASP docs: full disclosure of 
"HaspCode" API#2 call internals.  
  ...
  byte  buff[8];
  ...
  do
  {
    do
    {
      seed *= 0x1989; // ooh I see that healthy smile of you
      seed += 5;      // dear crypto fellows ;)
      buff[i] <1;
      buff[i] |= ask_hasp( seed>>8);
    }
    while(..) // 8 times
    i++;
  }
  while(..) // 8 times
  ...
on_return:
  AX = buff[1]buff[0]
  BX = buff[3]buff[2]
  CX = buff[5]buff[4]
  DX = buff[7]buff[6]
  // You see them as resulting four 16bit numbers.

  So this fragment just generates pseudorandom numbers from
the given seed, feeds them to HASP and places resulting bits 
to buffer. In fact, only 6 bits are actually digested! Each 
time HASP performs a calculation of 64-to-one boolean, to
conclude. On each iteration this is THE SAME boolean. Voila,
no more obscured strong cryptography functions!! 

  Not so easy, though. Without appropriate activation, HASP
fires back only 1s.. Exactly this will happen if you supply
wrong password, but software just zeros all xFF for you.
BTW, there's undocumented extension: if you supply 0:0 as a
password for API#2, HASP fires you back not with zeros, but
with xBB58, xE11F, x7A86, xDCD9 quad regardless of SeedValue.
No mystery though. In this case default seed of x1DE3 and
default boolean are used. What's the heck is default boolean?
 
  Ooh, here's the juicy part of boolean story. My research 
detected two booleans in every MemoHASP: which I called 
default and secret. If you activated HASP correctly, secret
function is awakened, if _gently_ not-so-correctly, default
one, and if you send complete gibberish or nothing at all,
eat xFFFF.. So I will picture two such booleans here as neat
8x8 tables (you see, it is much more understandable than 
looong 64bit strings) Left top corner corresponds to x00, 
right bottom to x3F, usual sequential reading order from
left to right, top to bottom.. (I am an european type)

    default                 secret

0 1 0 1 0 0 0 0         0 1 0 1 1 0 0 1
0 1 0 1 0 0 0 0         1 1 0 1 1 0 0 0
0 1 1 1 0 0 1 1         0 1 0 0 0 0 0 1
0 1 1 1 0 0 1 1         1 1 0 0 0 0 0 0
1'1 1 1 1 1 1 1         0 1 1 1 1 0 1 1
0 1 0 1 0 0 0 0         1 1 1 1 1 0 1 0
1'1 1 1 1 1 1 1         0 1 1 0 0 0 1 1
0 1 1 1 0 0 1 1         1 1 1 0 0 0 1 0

  Well, did you see any random patterns here? Especially in
"secret" table? Believe me, all four different MemoHASPs exhibit
this funny patterns with affine booleans as columns.. But it's
the theme for another more cryptographically-intensive text.. 
So now just realize once you know this two booleans, you can 
throw your old good HASPEDIT utility away to dark corner and 
generate all this magic numbers without HASP assistance. I 
actually demonstrated this to my fellow software developers. 
Boyz, were they paralyzed!

  One moment, still what use is of default boolean?? You see,
it is THE FUNCTION to decide whether it is HASP that is plugged
in the port. I have confidence, that all MemoHASPs and
(most probably) simple HASP-3 devices have this very function.
Memo-4 MUST have another, and Time-4 the other one. For I never
tested them, I cannot give relevant tables here but I suppose 
they may be similar, with some columns swapped. It is due to 
intricacies of detection mechanism, that I will omit here for
some space/time limitations, sorry..

  Some peculiarity: if one didn't raise MSB (see commented in
bitcode()), bits marked with ' will be 0s.. Feature?.. 

    3. HASP password.
    -----------------
  All this fiddling with booleans is fun, but there's a cloud
on our sunny sky: even if you have a HASP and its password,
you still have to delve into protection code to fish the
tables, because wily API closes HASP device on return.. Sorry,
one substantial addition here: you CAN reconstruct secret table
by calling API#2 many times (I believe, two times usually are
sufficient, especially with knowledge of its expected symmetry).
But what if no password is at your disposal? Such a neat
HASP device in your hand, but completely useless without 
these two 16bit words.. Ooh, nevermind, my little proggy in 
appendix will reveal password to you and even show tables..
So it is the time to unveil some HASP password secrets..

  First, one MAY bruteforce the password.. But searchspace
is 2**32, HASP is unique (as they say) and API functions spend
our valuable time in useless en/decryptions. Well, after 
looking at booleans I definitely begin to realize that there
must be something "fishy" with passwords. Result: REAL
searchspace is 5**6 or just 15625 which is definitely less
than awful 2**32 (I suspect HASP MIGHT melt down on such 
a huge keysearch BTW).

  Now I will briefly sketch HASP passwording so my proggy
be more understandable. First, two numbers supplied by you 
are XORed, 1st with x1989 (see magic numbers pseudocode
above, these guys obviously cherished this number) while
2nd with x0108. Resulting 4bit nibbles are used as indexes 
in some substitution table later. To make life more 
complicated, 8 nibbles are "stretched", composing 15-byte
resulting table, where first eight elements are genuine
nibbles (with xF substed for x0) and the rest is composed
from 7 of this nibbles by adding 7 mod 16 (reverse order!) 
and again killing zeros. Not very clear? Well, it's all 
unimportant but I still give the picture: suppose, your 
passwd was x5AA8:x866D
XORing gives:
5AA8  866D
1989  0108
-----------
4321  8765 , so array of nibbles-indices will be

 1, 2, 3, 4, 5, 6, 7, 8, F, E, D, C, B, B, 9
                          special case ^^^
No zeros encountered, if so, they would be transformed to Fs.
  ...
  for(i=0;i<8;i++)
  {
    arr[i] = nibble[i];
    if( 0==arr[i]) arr[i] = 15;
    if( i)
    {
      arr[15 -i] = (arr[i] +7) & 15;
      if( 0==arr[15 -i]) arr[15-i] = 15;
    }
  }
  arr[ 13] = 11; // don't ask me why.. till part II
  ...
  But that's not the end! This indices are used to retrieve 
some data from substitution_table[15], which in turn will be 
transformed later in a kinky way, giving depending on 
some variable setting two variant of additions (see resulting
pair1/pair2 in my proggy). This IS relevant however.
See, each element has only one bit set someplace, and there's
no two equal pairs (if we make pair as {pair1[i],pair2[i]}).

  So how exactly HASP is unlocked? There's one more 15-byte
array, copy of it can be found as raw0. Each byte of it is 
disturbed by XORing with result of password
obfuscation (this array of x04, x08, x10, x20, x40 values, 
they are in-the-clair only in proggy, in actual HASP they 
are dynamically expanded into filler[]-values ) Well, it is 
still incomplete! According to settings of some variable 
(as I've already said) BUT ONLY first EIGHT bytes can be 
encoded in two different ways (I almost going' stir crazy 
explaining it..)

  Well, our hypothetical sequence once again:

 1  2  3  4  5  6  7  8  F  E  D  C  B  B  9

raw0 array always holds:
8a f8 da ba 94 c8 a8 80 92 d0 b0 8c 9e dc bc

(Variable set to 1)
XOR raw0 with:         |< ignore variable after 8th byte!
40 40 20 40 20 10 40 20 04 08 10 20 40 40 10
                       |
                       |
(Variable set to 0)    |
XOR raw0 with:         |
20 10 10 08 08 08 04 04 04 08 10 20 40 40 10

  Both sequences will unlock our HASP.

  I hope your brain still ain't fatally damaged, so let's
continue with the heart of passwd cracking. This weird 
two-variant scheme seemed very suspicious to me. I thought 
on it, tried, thought, tried again. Definitely for the eight 
first bytes only complement variants are allowed, if you XOR 
the first with 08 for example, HASP would not unlock. More 
interesting, variants ARE INTERCHANGEABLE all the way through 
first eight bytes.. What if no XORing at all?!! IT WORKS!
And it gives me only the last 7 numbers as a headache.
Well, actually only 6, because the last but one is 
predetermined (ooh, those HASP designers..) But now I have
to spend only 5 variant for each! This is where 5**6 was
distilled, BTW. And after I will find this opening combination
I can proceed with the first eight bytes, isolating EACH
and trying all 15 pair compositions on it! Hey presto..

  Well, one more iceberg: what if I found a xF, substed
for x0 in the original passwd? Theoretically, it can be
resolved by looking at the tail. But 14th byte is constant,
what's then? Not a tragedy, though. The password obtained
is usable for your HASP even if it it not "genuine". One
more speculation: I never met this situation to date, 
and HASP people probably didn't as well :) So use my little 
proggy, and if it won't give you desired passwd you know where 
it smells rat..

  BTW, ever wonder why all HASP-3 passwords (you can see
demo ones in docs) have first number even while MemoHASPs
odd? It is principal: API#5 distinguishes them by this
feature, and so did one internal function before deciding
to fetch/place something into HASP memory.. No more secrets!

-- to be continued ------------------------------------------
  Well, more than enough for the first part. So I didn't
give you any concrete description of how to patch every
HASP-protected proggy neither did I provide you with
totally new cracking technique.. But instead you have some
unique information on "how the thing works". You see, 
sometimes "black boxes" are much simple than you are
forced to believe.

Plans for the future ( part II):
  - fiddling with HASP memory read/writes
  - HASP ID demystified
  - EPROM or EEPROM??
  - HASP software/nightmare (PCS and all that..)
  
I desperately need more information on HASP devices.
Especially on applicability of abovementioned to 
TimeHASPs. You see, there's a lot of new functions 
inside HASP module just for them I start to worry..
If I'll find the time (and/or definitely if I'll find 
the TimeHASP :) I will certainly analyze it.

    APPENDIX.
    ---------
  Here is presented to your attention rather simple but
workable HASP password finder. It won't teach you style
but might help to understand all the crap I typed above.

  Z12_KLUDGE was added just before posting: you see, 
this proggy didn't work on one PC (and modern one, 
with Pentium-II, some problem with ports) so I made this
quick & dirty patch. Anyway, due mirror of actual HASP code 
"be.class" tppabs="http://fravia.org/be.class" better, but it needs bit-level manipulation I have 
no desire to litter my already imperfect proggy.. 
Maybe next time..

Back to dongles
homepage links anonymity +ORC students' essays tools cocktails
academy database Javascript wars antismut CGI-scripts search_forms mail_fravia+
is reverse engineering legal?