Hello, I'm playing around with trying to remove ASPR 1.3 from a .dll Below I've documented what I've done so far. I'm looking to see if I'm on the right track and any tips or tricks on .dll dumping and rebuilding.

Target: WebsnatcherIE v2.1
Files: webbnd32.dll in program dir, bdsutils.dll in windows\system
Protection: ASProtect 1.3 (?) on webbnd32.dll
Tools Used So Far: Sice 4.05/334, Icedump 6.025, Peditor 1.7

Basically, this is an Internet Explorer plug-in which displays all the
files a web page uses in a window like the history or favorites.
It allows point-and-click downloading of any of the files the page uses.

There is a stand-alone version also, Websnatcher 2.4. I have successfully removed ASP 1.3 from that. FWIW, the .idata needed rebuilding, as usual, but so far as I can tell there are no other ASPR tricks in there. Once ASPR was removed, the nag went away automatically ( I believe it was part of the ASPR wrapper itself).

I *think* I've found the OEP of the webbnd32.dll. After the break in softice at the getversion (the GetWhatWeWant API cluster is there) , I do a /tracex 022D1000 02314000, in reference to the loader info below:

Loader info on the .dll:
WINICE: Load32 Obj=0001 Add=0167:022D1000 Len=0000F200 Mod=WEBBND32
WINICE: Load32 Obj=0002 Add=0167:022F9000 Len=00004000 Mod=WEBBND32
WINICE: Load32 Obj=0003 Add=0167:022FD000 Len=00000E00 Mod=WEBBND32
WINICE: Load32 Obj=0004 Add=0167:02302000 Len=00010600 Mod=WEBBND32
WINICE: Load32 Obj=0005 Add=0167:02314000 Len=00001A00 Mod=WEBBND32
WINICE: Load32 Obj=0006 Add=0167:02317000 Len=0000C800 Mod=WEBBND32
WINICE: Load32 Obj=0007 Add=0167:02324000 Len=00000000 Mod=WEBBND32

This seems to break three times in the WebBnd32.dll code before
actually getting to the OEP. First, it breaks at a RET at 22D1014.
, which returns to the ASPR code. Tracex again and it breaks at
WEBBND32.DLL!?GetRunApplicationFunction

WebBnd32!?GetRunApplicationFunction@@YGXP6AXXZ@Z
015F:022E77FE PUSH EBP
015F:022E77FF MOV EBP,ESP
015F:022E7801 MOV EAX, [EBP+08]
015F:022E7804 MOV [WebBnd32!?ExecuteTrial@@YAXXZ],EAX
015F:022E7809 POP EBP
015F:022E780A RET 0004
015F:022E780D PUSH EBP
015F:022E780E MOV EBP,ESP
015F:022E7810 CALL [WebBnd32!?ExecuteTrial@@YAXXZ]
015F:022E7816 CMP DWORD PTR [EBP+0C],01
015F:022E781A JNZ 022E7840
015F:022E781C PUSH 022F9560
015F:022E7821 MOV EAX, [EBP+08]
015F:022E7824 PUSH EAX
015F:022E7825 PUSH 022FDAD8

Tracex again. (At this point, the nag appears and waits for click.)

Breaks again at WEBBND32.DLL!?GetRegistrationInfo:

WebBnd32!?GetRegistrationInformation@@YGXPAD@Z
015F:022D1070 PUSH EBP
015F:022D1071 MOV EBP,ESP
015F:022D1073 MOV EAX,[EBP+08]
015F:022D1076 MOV [022FD120],EAX
015F:022D107B POP EBP
015F:022D107C RET 0004

Tracex again. Finally, breaks at what appears to be the OEP.
At 22F0FDD. (offset 0x1FFDD from the load addr of the 1st
section) It's the usual PUSH EBP stuff. But, it's in WebBnd32!DllUnregisterServer. Is this is OEP, or am I on the wrong track?

Also, the exports may be screwed with. I downloaded ASPR 1.2 just to take a look at it, and this was in the online help:

"The main idea is the following: ASProtect looks through exports section of the module and searches some predefined function names. If it finds this name, the address of the function is remembered and the reference in the export table is deleted. When the module is loaded, the address of the necessary function is determined on different conditions and this function is invoked. "

This seems to occur at runtime (in Peditor, there are the usual
four entries in the exports section, along with five API calls
for ASPR). In the GetRunApplicationFunction routine included
above, the instr @ 7804 replaces the call statement @ 7810 with
one in brackets that looks suspiciously like the redirected
imports in an ASPRotected .EXE file.
I think that's whats going on..

My next step would be to dump the image with icedump, and then figure out from there what to do, as far as fixing the import table, export table, relocations, and anything else (?) I'm not sure how relevant those API calls before the (supposed) OEP are - maybe that part can just be trashed (?) It looks like they
just have to do with deciding whether to let the program run or not, and other useless junk (GetRegINfo?)

Has anyone else removed ASPR 1.3+ from a .dll? Any tips are
appreciated

Hi there:

I'll take a look at this today or tomm. May be you can search the board to get some tips ;-)

Signed,
-- FoxThree

Hi there:

After reading ur post, I thought it really has some interesting tricks. But alas, I think we've got aspr fully covered

Okey, let's see.

You've mentioned OEiP as 22F0FDD! Cross check this. It must be 20FDD (10020FDD). It is relative to image base and not the section addresses themselves. Dump here. Forget about the original dips. It is just setting up ASPR flags.

As usual, IAT is corrupted. Rebuild with RV/ImpREC. You'll find the usual twist but if you find the GetWhatWeWant API cluster you can by pass this one.

Whoa! RS=VS,RO=VO, past iat.bin blah blah...

Attempt to run! Whoops IE crashes and brings up MS Debug report!

This is again another trick that has been extensively analyzed in this board: +splaj/SV's "INDIRECTED function calls"

"Find it, Patch it, Play it" ;-)

Success! ASPR is totally removed! No Nag nothin

Let me know if you have any further problems...

Signed,
-- FoxThree

Thanks for taking a look at this. I'm still running into a bit of problems tho. I think I've done everything right, but the dump is screwed up when I try to run it. I'm not sure what I'm doing wrong.. at the point where I generated the IAT.BIN with RV, I've always just had RV do all the work then.. but it didn't work on the dll file for some reason. So I had to fix everything w/Peditor (which I thought I did) Any ideas what went wrong? Thanks!!


Here's the procedure of what I did:

Loaded SICE, Loaded Icedump. Started WSIE with BPX Getversion, /tracex until OEP reached (RVA 20FDD). Locked process e eip EB FE.
Ran Peditor 1.7, selected process IE, selected module webbnd32.dll . Right click, selected Dump Full

Ran program, Ran RV 1.3, resolved imports, fixed 6 of them,
saved import table. Nothing here I haven't seen before.

Fixed:
8C818 - GetModuleHandleA
8C468 - GetProcAddress
8C834 - GetVersion
8C86C - GetCommandLineA
8C85C - GetCurrentProcess
8C898 - DialogBoxParamA

Reran PEditor 1.7, changed OEP to 20FDD, saved. Noted 55000 as first available position to paste in new imports.

Reran RV1.3, set IAT RVA to 55000, generated IAT.BIN

Reran PEditor 1.7, added IAT.BIN section to end. Fixed
Size of image, Import table RVA and size in Directory.

Tried to run it, some of the code is there but for some
reason starting at 1000 it all goes to crap

015F:021D0FDD PUSH EBP
015F:021D0FDE MOV EBP,ESP
015F:021D0FE0 PUSH EBX
015F:021D0FE1 MOV EBX,[EBP+08]
015F:021D0FE4 PUSH ESI
015F:021D0FE5 MOV ESI,[EBP+0C]
015F:021D0FE8 PUSH EDI
015F:021D0FE9 MOV EDI,[EBP+10]
015F:021D0FEC TEST ESI,ESI
015F:021D0FEE JNZ 021D0FF9
015F:021D0FF0 CMP DWORD PTR [021E1238],00
015F:021D0FF7 JMP 021D101F
015F:021D0FF9 CMP ESI,01
015F:021D0FFC JZ 021D1003
015F:021D0FFE CMP ESI,-01
015F:021D1001 INVALID
015F:021D1003 INVALID
etc etc etc

Hi Lbolt99,

Try using LordPE and dump, i neva dump with PEditor myself but as the experts here says, i think LordPE is the most reliable...

Also, as fox3 said, there is a redirected call so patch it!

You did not mention chaging OEP from eb fe back to 55 8b but i hope u did :>..

Also, if you use /tracex, read Tsehp's comment and use revirgin tracer, it is at least 10 times if not more faster!!!!

Also, if your dll was relocated at run time, you have to change the image base of the dump for it to work properly...

Just a few thoughts, :>

Hi there:

It looks like your DLL has reloced... you need to copy the .reloc section from the packed DLL and paste it in the new DLL and set the .reloc to the first byte of this. Search for some post by DakienDX on this (also by the "ultimate guru" the Owl).

You can use map32 to identify the .reloc table, i guess.

Signed,
-- FoxThree

Hi, thanks for the responses.. I'm going NUTS over this..
I went ahead and did a clean bootup so that WEBBND32.DLL
would definantely load at 10000000, without relocating. That
worked fine - it came up there, and didn't relocate.

I tried dumping with Peditor, LordPE, Icedump.. the problem with
the INVALID's is still there It's like the whole memory area
below 21000 is toasted at runtime..

The bytes are there if I look at it with a hex editor, and other really STRANGE thing is that, after the Page fault, if I go back and
unassemble it (u 10020FDD) THE CODE IS THERE!!! Its like it all
just magically reappeared!

I don't know what to do at this point. 15+ hours so far Any comments on whats going on?
Thanks!!

Hiya there:

Doesn't it make you crazy , Not to worry 'coz been thro' that road many times and still survived ...

Okey, I believe your dump is wrong. So let's take the easy way out. Use ICEDump. No JMP EIP stuff for us. Not yet

So at OEiP do a

: bc * in softice to clear all breakpoints (sometimes this can be such a pain )

: /dump 10000000 <sizeofimage> c:\temp\dumped_dll.dll

Cool? Look at the above base address. Did you get this right?

Lemme know what the problem is (if it is still there )

Signed,
-- FoxThree

Try WinHex,

work great as well

cheers,

thanx for the suggestions, I'll give it all a try tomorrow
Taking a break for now..
I think what I'm going to try 1st is putting ASPR onto a
dll and then try unpacking it.. maybe it'll shed some light
on whats going wrong

Got it, finally Thanks fox3 and bin for the help. It was something dumb that I wasn't doing. Once i put aspr onto a regular dll and compared the two, I realized that I wasn't setting the .reloc entry in the section table to the correct value. I've only dumped exe's up until now so I forgot about the reloc