bayunn2.htm More undocumented HASP..

	Undocumented HASP Part II "xDEAD:xBEEF: extending HASP manufacturer's services"	Advanced
12 March 1998	by bajunny
	Courtesy of Fravia's page of reverse engineering	slightly edited by fravia+
fra_00F3 980312 bajunni 0010 AD P3	Another great contribution by bajunny. Hasp misteries and vagaries are tackled and resolved. A must reading for all dongle interested serious researchers! This is definitely not for beginners, either you know how to send and check bytes from your PC ports, or you don't (and you better know it :-) If you are a beginner, leave this stuff for a while and delve inside +HCU's project 3until you have at least a rough global knowledge of dongle reversing.	Dongle
	There is a crack, a crack in everything That's how the light gets in
Rating	( )Beginner ( )Intermediate (x)Advanced ( )Expert

Second and most probably the final part of MemoHASP reversing saga.

Undocumented HASP - Part II
"xDEAD:xBEEF: extending HASP manufacturer's services"
Written by bajunny

Introduction

Second part of the text deals primarily with accessing HASP memory. Some aspects of software protection are also included (not very organised, though).

Tools required

Brains (obligatory). C compliler (quite optional). JavaScript manual (to land the teapot on).

Program History

See Part I for the first part of the text.

Essay


                              Open mind for a different view

                              And nothing else matter..

          

                                      an old song by Metallica

--------------------------------------------------------------



                    Undocumented HASP - Part II

                              by -bajunny





    4. Memo-  ..stands for memory!

    ------------------------------



  The HASP documentation says that MemoHASP-I has a total incredible 

amount of 112 bytes of memory ready for programmer use, while all happy 

buyers of NetHASP and MemoHASP-IV (which are essentially the same thing 

I believe) can take even more - 496 bytes. 

One can immediately realize, that in both cases HASP had reserved 16 bytes for 

its own use,  because 112 +16 == 128 and 496 +16 == 512 and memory 

manufacturers enjoy power_of_2_numbers. This fact was further

acknowledged by the following fragments of disassembled HASP

driver code:



; API_service#6



. . . 

mov word ptr ds:[bp + 0ea], fff9; 

call 6496

. . .

mov word ptr ds:[bp + 0ea], fff8; 

call 6496

. . .

mov ax, ds:[bp + si + 0d3]       ; HASP memory access commands

. . .

add ax, word ptr ds:[bp + 0ea]   ; reasons for ADD will follow

add ax, 8                        ; !

. . .



  So real addressing for user-accessible memory begins from 

offset 8, while in offsets 0 and 1 resides the "unique HASP ID". 

In fact, the following 6 words are never user by any HASP

software (I didn't look for Net- and Time- devices, though)

so you will be able to place something even more _unique_ here.. 

But you need more details on HASP memory access indeed 

before...



  As we already have seen in the first part of this essay, HASP 

wouldn't give anything useful without proper activation. 

 Memory access is no exception, and this is the sad news. 

The good news is that we actually have already acquired all

necessary items for this activation. I mean the opening combination

that we have found in the first part of this text. But we should stop at

the correct moment: in fact we need to know that after the 15th 

outbyte() is issued, one of  HASP's internal flip-flops 

switches output to query its booleans..

The moment after 14th outbyte() is right. It's amazing, but if

you will try to retrieve Boolean at that moment HASP returns 

only zeros to you - it definitely indicates some change in HASP 

internal state! Change for some memory work! 



  Technically speaking, all memory ops are issued through 

appropriate commands. These commands along with their arguments

and subsequent results are passed to HASP serially - that is

bit by bit by signalling specific bits just like bit0 was

signalled in the outbyte function, forcing HASP to parse its input

as command bytes. 14th byte of opening sequence was used as a 

background for this. - This is the reason why this byte was set

to certain value (x9C) irrelevant of  all other password related 

fiddlings.



  Command length is 10 bit. HASP driver provides the 7 following

values as command ops (all presented as bit strings, x's stand

for address values):

0110xxxxxx - read word from address specified

0101xxxxxx - write word to  -------//--------

0111xxxxxx - erase word at  -------//--------

0100110000 - enable write ops

0100000000 - disable write ops

0100100000 - ? unknown, apparently no effect on Memo-'s

0100000000 - ? the same.. 



So, to read word from address 9, one should send the following

10 bits to MemoHASP: 0110001001. Sending are performed by

signalling bit6, along with bit5 alterations (see my code at 

appendix). Do not forget to begin and end all memory operations by 

signalling bit1.. Resulting word is received also in a serial

manner, see below the code inside hasp_read_word()..



If you happen to torture MemoHASP-IV, just expend these 

command strings by two more bits, allowing full 256 words

address space (and of course call hasp_send_cmd( ..., 12 )!:)



Writing is analogous, but first one must enable write using a 

special command. HASP driver also issues obligatory erase 

before each write, but it's not really necessary: write 

successfully sets both 1s and 0s. One feature for erasure 

and writing: HASP driver has a specific code that waits for 

state change after each of those two operations, I put something 

analogous to wait_till_burned() routine below, though no actual 

wait was ever detected during my own experiments...



If you dare to use my routines to read/write some HASP memory, 

you won't see any expected values, because once again HASP

designers used  some silly obfuscating schemes to conceal 

their data. 

So you need first of all a password number to correctly decipher it. 

I already warned you there could be some ambiguities in password

detection, well, here is the place where they can be encountered.



But in fact this obfuscation CAN HELP to get the right 

password: many areas inside HASP memory holds initial

xFFFF's (you see, erasure sets bits this way) - and this

is especially true for all hidden words at 2..7! They are set

to xFFFF.





Obfuscation algorithm is presented inside the code fragments in 

appendix, it uses simple XOR of 1st word of the password, 

address of word and constant of xFF00 for addresses 0..7 

(well, actually xFFF8..xFFFF inside the HASP driver). 



I played a little with command opcodes, hoping to fish something

interesting, but without success. Maybe you will be more

successful... if so write about it.





    5. HASP ID story.

    -----------------



  The extremely vague HASP documentation warns you that: 

"You cannot order HASP keys with specific ID Numbers. These are 

assigned pseudo-randomly during manufacturing and are 

guaranteed not to repeat".. So if your HASP has some ugly ID

like xA60D:x12F7 you have to live with it?? 

No, no,no! 

Bajunny CAN help you to change it to something "prominent" 

like xDEAD:xBEEF or x1234:x5678 (as in all my HASPs) or 

whatever you like... extending thus the manufacturer's services, 

power of good cracking ;)



  Of course everything is already prepared: HASP ID lives at

the very beginning of memory, words at _0 and _1, this area

is accessible and is not write protected.. You already have all

necessary information to carne your own HASP ID. Nothing much 

to be added to the ID story except to mention that ID is 

checked sometimes by the envelope routines.. But for other crucial 

HASP parts: password and booleans I have no way to modify by 

means of software (but who knows.. what if... we will see ;) 

my wish to invent some mechanism to make one HASP start mocking 

another failed... So end of the story... for now ;)



    6. Conclusion (again too long).

    -------------------------------  

  When writing these words I have to admit to you I finally

got awfully bored of all this HASP super protection. Well, once

more we have to observe the old banal truth, so common in our 

cryptography intense world: security through obscurity is worse than 

no security at all. So what we have in these "ultrastrong" HASP

dongles? What's inside them? Almost nothing interesting. 

In fact, today already exist more decent dongles, documentally presenting 

strong algorithms inside (or I'm still dreaming, are they as easy to 

reverse?) having at least PIC-complexity rather than a simple set 

of flip-flops and memory cells.. 



Well, the HASP people can and will surely argue that they have 

at least implemented a strong software protection. 

It's complete bullshit - all info I have given to you in my essay 

has been gathered by myself through disassembling and experimenting 

with software. No ion-beams or layer etching intervention. 

Nothing in my hands! 

And I didn't encounter _any_ cool anti-debugging tricks! Well, some 

folks say they implemented anti-softicing like disabling 

breakpoints and firing something like "hboot" to your debugger's 

command line.. I don't know.. In fact, I've used winice only to 

get rid of HASP for the InscriberVMP program... and it was my first 

experience with windoze debugging.. Yeah, I use windoze only 

to format something to print on laser or to browse those great pages 

of fravia+ :) - all other experimenting still in good old doze.. 

Where else can one find such a well documented, inexpensive, 

_true_ real-time OS ? :))



  Maybe in the future I will present a  more comprehensive survey of

HASP software protection. All this enveloping stuff, and the like. 

Right now I'm not sure it will ever materialise. Not because

its difficult, but because its very boring, and I've almost spent my

strategic supply of Homeric laughters looking at something like:

"FAS - Full Authorization System" 



This seller's hypo stands for some feature in enveloping: you can assign 

a number to a program and specify a maximum number of activations. 



Sounds good? In fact, this FAS system eats half of your MemoHASP cell 

space - 2 words for each 16 possible program numbers, first word to 

check if corresponding  slot was occupied (xFFFF if not, any other value 

if yes, HASP... puts x0000) while the second word keeps the counter (xFFFF if 

unlimited activations..). Of course you can edit everything with my 

functions below or even using HASPEDIT. 



Well, what should I say? I sip a good cup of tea, observing this moronical 

hype once again and have decided to give up, my dear reader... it's too easy 

and too stupid... 

Even fighting windmills is better than fighting stupidity..



    APPENDIX

    --------

  Here are some fragments to be added to my little cracking

program  from the first part of this work of mine

// --------------------------------------------------- int hasp_answer(void) { return (inportb(PORT +1) & 0x20) ? 1 : 0; } int sticky = 0x9c; // hardcoded, HASP software always sets this value.. void memo_open(void) { int i; outportb( PORT +2, 0x0c); outbyte( 0xc6); for( i=0;i<14;i++) outbyte( tmp[i]); //sticky = tmp[13]; } void memo_close(void) { outbyte( 0xc6); } void tease_bit( int t, int b) { int teaser = 1<<b; if(t) sticky |= teaser; else sticky &= ~teaser; outportb( PORT, sticky); } void hasp_send_word( unsigned cmd, int len) { for( ; len; len--) { tease_bit( cmd & (1<<(len-1)), 6); tease_bit( 1, 5); tease_bit( 0, 5); } } unsigned hasp_read_word( void) { int i; unsigned res = 0; tease_bit(1,5); // a necessary "phase shift".. tease_bit(0,5); for( i=16; i>0; i--) { res |= hasp_answer() <I-1); tease_bit(1,5); tease_bit(0,5); } return res; } int wait_till_burned(void) { time_t t; t = time(0); tease_bit( 1, 1); for( ; time(0)-t<5;) { if(hasp_answer()) { tease_bit( 0, 1); return 0; } } return -1; } . . . void main() { int addr; unsigned short passwd1=0x347f, passwd2=0x13b3; // known from previous invocation of cracker.. . . . // read _all_ HASP memory memo_open(); for( i=0; i<0x40; i++) { tease_bit( 1, 1); hasp_send_word( 0x180 +i, 10); k = hasp_read_word(); tease_bit( 0, 1); printf("%04x ", k ^ passwd1 ^ (i-8) ^ ( i<8 ? 0xff00: 0) ); // obfuscator: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ if(0==(i+1)%8) printf("\n"); } memo_close(); . . . // read/erase/write _one_ word addr = 0x3f; memo_open(); tease_bit( 1, 1); hasp_send_word( 0x180 +addr, 10); k = hasp_read_word(); tease_bit( 0, 1); printf("original read: %04x\n", k); tease_bit( 1, 1); hasp_send_word( 0x130, 10); tease_bit( 0, 1); // erasure.. tease_bit( 1, 1); hasp_send_word( 0x1c0 +addr, 10); tease_bit( 0, 1); wait_till_burned(); tease_bit( 1, 1); hasp_send_word( 0x180 +addr, 10); k = hasp_read_word(); tease_bit( 0, 1); printf("after erasure read: %04x\n", k); // burn smth in.. tease_bit( 1, 1); hasp_send_word( 0x140 +addr, 10); hasp_send_word( 0x55aa, 16); tease_bit( 0, 1); wait_till_burned(); tease_bit( 1, 1); hasp_send_word( 0x180 +addr, 10); k = hasp_read_word(); tease_bit( 0, 1); tease_bit( 1, 1); hasp_send_word( 0x100, 10); tease_bit( 0, 1); memo_close(); printf("final read: %04x\n", k); } // ------------- end of transmission -----------------

Final Notes


The author encourages you always to look one level deeper,

of course if the time and patience would permit it... if you do, by all means, 

write and document and publicize your findings...

Ob Duh

I wont even bother explaining you that you should BUY any of your target programs if you intend to use them for a longer period than the allowed one or on a greater number of machines than the allowed one. Should you want to STEAL those buggy software instead, you don't need to crack its protection scheme at all: you'll certainly find it on most Warez sites, complete and already regged or undongled, farewell.

You are deep inside fravia's page of reverse engineering, choose your way out:

homepage

links

search_forms

+ORC

students' essays

academy database

reality cracking

how to search

javascript wars

tools

anonymity academy

cocktails

antismut CGI-scripts

mail_fravia+

Is reverse engineering legal?