first of all, hi all forum members..
i have dealt with a win32 program protected by hardlock envelope.. this program is a vb one, at the start it behaves as p-code,then turns native code.. anyway.. i read M4V3RiCk HL-API hardlock essay.. it is really helpful tut. then I tried to de-envelope the program.. in envelope I found Hl-login,Hl-Avail and Hl,version services.. i emulated these services.. envelope decrypted encrypted sections and filled some imports from kernel...then the program crashed in .protect section when it called some imports from kernel: getmodulefilenamea,virtualqueryex etc... the error message is related to page error (virtualqueryex) instead of a envelope error..
I have some Qs about that: maybe some of among u had some experiences.. is my decryption without right dongle successful ? maybe envelope read some decryption key from dongle... another Q is that Crackz wrote at the beginning of Maverick's tut about envelope mechanisms. He said that after decryption there is also import trashing.. is this the reason for the crash???
tnx everyone right now...

Maybe i can give you a little help.
When you have emulate the login , avail and version.
you get to the part where first the importtable is decrypted hl_crypt and afterwarts the importtable is rebuild .
These can (in my opinion) only be done with the real dongle.

But if you have for short time the original one,
i have the following solution depending on the envelop version.
For me the following work very well :-)

When you have start the original Programm dump it with Procdump.
Then replace the segments in the orignial version which hold the crypted importtables with the one of the dumped version.

Now you have only to change the call in the near of the OEP which call the envelop routine to the address of the call which du the importtable rebuild. It can be found in the near of the ret from envelop.
The best thing is that the jmp to eax is the also be corrected and you need only to change some values in the importtables which were double decrypted to the original value back.
But these are very obvios You can detect them by the value very simple.

Now the program should work without the dongle.
But only if there is no futher checkinside the main program.

By my target they use hl_crypt also inside the main program and so it is very hard to go on. Also the api-Calls are done always via jump tables which make it not really good to disamble and to understand what happen inside the program.

Maybe there is a better solution with a emulated hl_crypt routine.
but for this you need some more information about the dongle.

tnx for your interest..
unfortunately, i havent the original dongle but your reply still helped me.. if you didnt reply probably i would spend more hours on making the program run
yes, dump methode is the best solution against dongle envelopes.. I think without using dongle's high level apis, Hl crypt mechanism does some checks while program runs, not only at the start of the program... so after dumping we still must deal with hlcrypt))
though I dont support dongles, I should accept that Hl crypt is a good protection unless we have the original dongle some programs run as demo mode if no dongle is present,so we can have a chance because program is decrypted ) my program doesnt have a demo mode..
tnx again...

Maybe i should tell it to you more exactly.

Normally if the producer of the target use only the Envelope, the protection can be beated very easy with my methode.
Because after you have used it, no dongle is needed anymore. :-)

Only if the target is protected more well, then the coder use also inside the target before he crypt it with the envelope dongle calls.
But there are also good and bad solutions.
If he only check the presents it is no bit deal to use mov eax, 1;ret :-)
But if also some parts are decrypted dynamic it is much more difficult.

There is a very easy methode to find the correct oep on some versions of the HL_crypt envelope.
Together with some zen you can check if there is hl_crypt used inside the decrypted target.
You must just use the information what the target give to you :-)

Have something forgotten :-)
The envelope starts normal a continues check of the dongle. So if you only emulated the first 3 HL-API calls. you get later problems with the timetriggert HL-api calls. But with my methode.
The check is canceled before the begin to use it :-)
The mainpart of the envelop is not executed anymore. also not the init routine which start the timetriggert check :-)



Maybe there are more parts of your target.
for example my target have a very great main program eveloped and some small utilities also enveloped as additional tools.
These are very small but use the same technic. so you can try to learn with the small ones before handle the big one.