I was playing with a nice tool, PacthFactyory from hxxp://www.patchfactory.com/ that let you try for 30 days. Borland C++ 6, not packed, with a little nag before the start of the proggie. No packing, no antidebugging, just a time protection scheme based on registry. But, first surprise: The keys keeping time of trial rest on an ASProtect key. So, is it a only registry ASProtect protection? No packing? Sadly not. There is a df.dll that is in fact asprotected. Anyway it is easy to locate the comparison regarding trial, end of trial and regged version. But how to change? No loaders working (fuckfmn from smola - I really like this-; either yoda loader ). AsprStripperXP 1.35 not working, tried all options and traced the dumped (heap of shit). Tried to unpack the dll and rebuild IAT. It Seems easy, emulated and redirected API`s as usual. But then ... Loadlibrarya doesn`t find the new oep of the dll. Ah!... maybe I have to change the import section of the exe file. Second surprise: No df.dll imported library in the vp.exe import section. How is this possible? I can trace throght the LoadLibrayA call within the vp.exe to df.dll. Even more, it looks clear that this dll is responsible of the trial and the nag. It is the first time i see something like this. Any clues?

Thz

mR_gANDALF

1023481 JMP EAX

10003873 PUSH EBP
10003874 MOV EBP,ESP

44CCE0 is the call to LoadLibraryA of df.dll...

How to unpack this dll?

The keypoint of the protection is in F93D23 jz (either in W98 or WinXP in mycomp). This is RVA of the asprotect code. I guess that unpacking that dll would reverse the protection regarding that it is the only asprotected file in the program. Any clues.

mR_gANDALF
[Breaking the bRaIn]

Since the DLL is loaded by the main prog, and the main prog itself is not packed, can't you allow the main prog to load it and then patch the unpacked process image from the main prog? This would seem the easiest way to handle it.

set an bp on 10003873 dump the dll, change oep and rebuild the iat for the dll. the question is had anyone ever rebuilded an iat for an .dll file

A little late, and shoobs been trying to tell us this was pretty easy.... but here is some info...

IAT Start: 09000 (RVA) BASE: 010000000
End: 09110 (RVA)
Length: 110

Fix it!

Dip-Table at adress: 1016988
100023B0 100022F0 0 0 10002420 0 0 0 0 0 0 0 0 0

Jump over all of those!

Jump to OEP at: 1023048 ( Code: 61FFE000 4C300201 )
OEP at: 10003873 reached from 1023049

Dump?

/Manko

i'am junior thanks for the suggestion manko

Now I see you posted the question, had anyone ever rebuilt IAT for dll... Actually, I had not. And untill I finally saw that button in the upper right corner of ImpREC, I didn't know how...

...and about those dips... I'm guessing they don't matter much. Skip or not... I think it won't do much difference, but I did...

/Manko

every day a new fact for me i'm new to this but this dll thingie is a nice option.

rva: 9034,9068 aren't reacheable (hook and tracer freezes imprec.) An idea without softice?

Hmm... I guess you're trying to use option 2 & 3 tracer? Don't use them. They are not needed, and often do not work.

Use plugins to resolve asprotect special emulated apis instead. Or do them manually.

It worked perfectly for me. I have it unpacked and running, so we need to figure out what goes wrong for you.

Plugins exist in this forum if you search.

If this is not it, explain further...

(I guess I'd be a fool to ask if you used the button up in the right corner... since it seems you could get at them... you must have done this...)

YUP! I just checked and those RVA contain normal apsr-emulated apis... do them manually, if you have not practiced this much... if you have and are bored with this bit use a plugin.
Ofcourse you HAVE to use sice or olly or something else that can show you what this code looks like... also ther's tons of info on these things here if you search.

If you need more help, you can always pm me.

/Manko

These are my reults for df.dll:

oep: 100023B0 (Tracex)
IAT RVA: 9000 (ImpRec)
Size of IAT: 114 (ImpRec)
Unresolved IAT entries (Revirgin)
F90EFO, F91360, F91388 : False entries.
RVA (9034) Adress (F91388) -> Equivalent to Mov EAX, C000A04 (but any value will work)
RVA (9030) Adress(F913CC) -> Equivalent to push 0, GetModuleHandleA, Mov Eax, 81985580 (in my comp this a pointer to the name of the exe loading the dll)

Then I dump the dll at its oep (icedump). Then dump IAT from revirgin , make a new section in df.dll to inject the rebuilt IAT and redirect 9030 and 9034 to a graft with the equivalent code. Then redirect the oep of vp.dll and the IAT adress.

But tracing through the LoadLibraryA call within vp.exe takes you to a odd RVA, not 100F001 as in the original dll or the new oep set in the LordPE editor. Then I thougth maybe I should change also the df.dll functions adresses imported by the exe file. But when looking the imported functions in vp.exe the surprises is that df.dll doesnt appear.

Thats how the story is.
Surely I`m doing something wrong. Need clues.

Hi!



Oep is wrong. The adress you found is just the adress where aspr-code checks to see if the section is executable. It was a simpel ret, when you found it.

How do you mean those are false IAT-entries?!

And the way you resolved those 2 other APis... Hmm...

Read up good on asprotect and things will become clearer.

The fact that you don't see df.dll in imports of vp.exe is simply that it's not done that way here. You always have a choice when you build program. Either put it in importstable or load it with code. This programs code loads the dll and then uses APIs to get the adresses of the functions in it.

/Manko

It`s true, the first RVA breaking into Sice is a ret. Strange code to be a oep. The next time Sice breaks is 100023B0 that checks registry (I misstyped oep , tracex points 1000023B0).
I know that functions from dll`s may be imported that two ways (chapter 17 of Iczelion assembler tutorials) but thought it was a possibility of error.
I also thought that F90EF0, F91360 AND F913B4 were false entries becuse they are never called from the code.
Never read anything about asprotect in dll ONLY.

So i guess from your words that dumping at the ret RVA and making that oep, and rebuilding IAT with ALL unresolved entries (included those NEVER referenced) injecting the code and redirecting, the program should work.

I`ll try that way.

Thanks.

Hi!

I didn't mean you should read up on aspr related to dlls. I meant you needed to study IAT rebuilding in aspr, dip-handling and anything else is never bad.

Nope! YOU mentioned 10001014 first... I explained what that was, but never suggested you should dump at it. You should dump from OEP which comes after ALL dips.

I questioned your method to resolve IAT entrys, because sometimes answers are not the same. (Like if you change system, or similar...) And you might be right about some entries NOT being used. But do you know this for sure? Have you tested ALL functions of the program, so you can know they are not being used?

Ahh! When I look at dissassembly now, they are all used in code...

(btw, when you have managed all, you will still notice that when you try to make patch, you get an exception... It's just the usual trick... This time, they do not even try and hide it...)

/Manko

Having played with AsprStripper on a few targets to check against my manual unpacking with Imprec and/or RV, I find that AsprStriper had been identifying three "API's" with multiple addresses.

AsprStripper has both an "unpacking" and a "Reversing" button. The "unpacking" button will identify the three "unresolved" entries and the "reversing" button will attempt to "resolve" them. However, in reviewing the disassembly of the files when using both of the alternative methods, I did not find any additional API's after using the "Reversing" button and the program seemed to run fine without the three "extra" entries. Imprec revealed nothing other than the "junk" between API's and the usual suspects unresolved.

I have not looked at this target yet.

Regards.

Hi Manko!

I did mention 10001014 at first. It was misstyping of my notes, sometimes happens. As you can see, I proposed 100023B0. Of course I dumped from that oep. I am talking ALL time about that (see ABOVE).

I havent taken a look at the "dissasembly". Better I traced through the code with a bpm on that 5 entries. Notice that the three I mentioned are not referenced.

Better than general suggestion, it should be gratefull a concrete reference or a personal experience. That what I asked for.
Tracing the code often helps, dont think so?.

Thz

mR_gANDALF

Hi!

It's cool!

But we still need to find what's wrong with your dumped file.

ABout 100023B0... It is not OEP. If this was a normal app and not a dll. You would have a file that sets that registry item and exits into thin air... But now, that might not matter much. As it's mainly those functions in the dll that are important. The good thing about dumping at first dip is ofcourse that no internal values have been set yet... (There are cases when some values actually must be set, but not here... I write to much... hrm...)

Ok, What exactly do you wich me to tell you?

The only data that hasn't been posted in this thread already is what I resolved those api to...

But there might be many other problems too I guess... I don't use icedump, so I can't say what might happen there...

Maybe something else...?

/Manko

From my point of view, there are several unresolved matters :

1. Asprotect protection ONLY from a dll. I didn`t see this before. Maybe there is something written deep in the web i didn`t find, maybe its a mistake.
2. Trying to dump that dll. Apart form unresolved entries, that could break the program, the dumped dll doesnt work at all. I mean, the LoadLibraryA that loads the dumped dll doesnt reach the modified oep although you change it with a PE Editor. It goes to a 00000000 RVA or something like that. So, I think this step is previous to resolving IAT. Ill try as SHOOB says, maybe he found the correct oep and thats half of the problem.
3. Dumping the dll and leaving it free from asprotect would break the protection? Probably yes, as it is in asprotected code where the "jz bad guy" is present. Regarding what SQUIDGE says, it is not possible to patch dll from the exe, as when the dll give back the control to the exe file, the protection has already been checked, and before it is loaded you cannot pacth. Teorically you could pacth inside asprotect code, but this must be really heavy.



Thz

mR_gANDALF

Hi!

The steps for unpacking a dll are so similar to that of an exe, and as you say it's not as common, that I think none to many would care to make a tut about it. If you read up on aspr... There are tons of info in this board. It will apply to the dll too...

Yes. Shoobs OEP is right. I'm fairly certain as I've found it to be so independently, and I do have some amount of excperience in this matter. (Besides, my dumped dll works.)

A suggestion for dumping, is to try LordPe, instead. There is nothing wrong with icedump, but I can't help you with it, so...
The trick to use for this is putting a "jmp eip" (eb fe) into code before or at eip, so it won't continue execution. If you put it AT oep you need to edit it back to original bytes later. (jmp eip, is
endless loop...)

btw, if you use OllyDebug you don't need to alter code for pause. Though I realise unpacking aspr with ollydbg is pretty different, a tut was just posted on this board... The good thing here is that u can use any number of other tools at the same time.

Yup! Unpacking it, is your best bet. (Patching will be much more work in my opinion.)

/Manko

I tried both with Icedump and LordPE, using the EB,FE trick, of course. Dont think i post this thread at the first inconvenient.
I have red a lot about ASP, long time ago, also written something.
I`ll try again, but any help will be wellcome.

Thz

mR_gANDALF

Hi!

Right now I can only think of two problems...

1. I jumped over all dips. Did you? Maybe some things have been setup so that it won't work... Try dumping at first dip. The one you mentioned. Before any of it's code has been executed.

You still have to use the proper OEP though as LoadLibraryA expects to get back the right info and initdll code is at proper oep...

2. Maybe you accidentally skipped out an entry in iat.rebuilding causing many other entries to get displaced? This would make calls to wrong apis...

/Manko

Thz to all you, guys, without your help i wouldnt get out from my "brain omelette"

This are my final results:

OEP10003873
RVA 9000
length 110

Unresolved IAT entries:

9098, 9034 and 9030. Both 90dc and 9068 are false entries. 90dc is used to import GetModuleHandleA.

I make the following graft to substitute the first 3 entries:

9098:
Push ebp
Mov ebp, esp
Mov eax, [ebp+8]
push eax
call [100090DC]; here i placed GetModuleHandleA
pop ebp
ret 04

9034:
mov eax, c0000a04
ret

9030:
push 0
call [100090DC]
mov eax, ecx
ret

Working perfectly and free of protection in win98 and WinXp

Thz you all guys, speacially to Manko, to whose patience i owe the knowledge of unpacking DLL ASPROTECTED.

Hi!

Cool!

I'm so glad you made it!
Thought you had given up! :P

Now, I have to give you next task...

If you run your proggy now and try to make a patchfile, you will be dissapointed...

Exception!

It's a common trick used to check if aspr is still present...

But you can find it.

You just need something that will show you on wich adress an exception has occured.

They have not even "hidden" it, like they usually do.

/Manko

Something like

1000126a push dword ptr [eax]
1000126c pop dword ptr [eax]

changeable for

1000126a mov eax, eax
1000126c mov edx, edx

Maybe?



Maybe inline patching of Mov byte ptr[4F9C0E ], 0 would remove unregistered label?



Thz again Manko for your support. Be around here, I`m having problems with arm

mR_gANDALF

I don't know if this may be relevant, but thought I'd throw it out there for your consideration, bare in mind that I have not looked at this target. I have been recently working on some aspr targets and was reading and re-reading crUsAdEr's tut on the aspr dll. He reported problems disassembling because its "header" had been striped. Eventually, recognizing that aspr was a Delphi product, he stole and adjusted a header from another Delphi dll and then was able to disassemble it in IDA, using the Delphi Flirts. Just a thought of something which might be of some assistance here, even though the project may be completed.

Regards.

Hi!

Yeah! If alexey would actually do some major changes for once, we'd all be doing that.

I have tried this a couple of times before, but stupid me, I was trying with a pe header from a delphi app, not from a dll...

Maybe, I'll have to try this again, now that I've understood one source of my failure... ok, it worked, except that it didn't show any apis...

Not now though... I should be buzy commenting the source of my small aspr-debugger... But I get sidetracked...
(I'll give away app and source when I'm done...)

/Manko

I think Magnetoman and me are in the same point: How to download the jmp tables to rebuild the jz/jnz replaced with int by arm. As Crushader found and explained in his marvellous tute, you have to dump the 4 tables and then rebuild with the help of his own utility. The question is: How do we dump that 4 tables...

mR_gANDALF
PD: I think i posted this in the wrong place...

If you've found them?

Winhex. or dump partial in imprec... or whatever... shouldn't be a problem, IF you have found them...

But I never tried any of this, so...

But I have to say, you're just a tad bit off topic here, mr gandalf! ;P
(Actually, you weren't even replying to something...?)

/Manko

Which params are you guys feeding tracex? I have been trying tracex on this one DLL that I have here, and I am getting no results. First I tried /tracex 00400000 eip-8 and then I tried /tracex 10000000 eip-8.

i've did it with a bp on memory access at the df code section.
no tracex used here..