hi chaps,

first off, I confess to being a lurker around these parts since Splaj helped me a long time ago on BeatCreator 1.4

anyway, since then I been unpacking the odd thing but this one has me puzzled. The packed .dll is called SynSonos.dll and it part of the Cubase SX protection created by SynchroSoft. Natively, this .dll doesn't come packed.

The packing of the .dll has been introduced by the group that cracked it, in this case ZONE Team. As part of their crack they have used SetWindowTextA and LoadBitmapA to replace the splash screen and it's caption. I like to NOP these out and ADD ESP,08 to compenstate. This works fine to keep the original splash intact.

I have already done this with this .dll, I dumped the .dll with IceDump at the OEiP = 0x0000C604, fixed the API calls above and it works fine. BUT... I want to unpack this .dll a different way without dumping. This is what I'm really interested in as the .dll appears to be packed with UPX and ASPack 2.xx

The header sigiture in the .dll would indicate it is UPX, esp at offset 0x000003E0 where there would normally be a "UPX!", the section names have been removed.

However, after LoadLibraryA is called the first jump into the .dll is address offset 0x00028200 and this appears to me to be ASPack, it get's to the end of this routine, pushes the address to the UPX de-packer;

PUSH 02FE2F00 <--- depending where it loaded in memory; base addy + 52F000
RET

the UPX process runs and pushes a return address back to another ASPack de-packer;

PUSH 02FDE000 <--- or base address + 4E000
RET

this then does it's thing and FINALLY it jumps into the REAL OEiP of the unpacked library;

PUSH 02F9C604
RET

long-winded I know. I need some advice on how to unpack this, it seems to me that only certain sections of the .dll are being unpacked. I basically want to end up with an unpacked .dll exactly as it was before any packer was applied.

I've tried the obvious like using ASPackDie (which complains about not knowing the exact compressor version) but 'appears' to successfully unpack part of the .dll, it updates the EIP with the offset pointing to the UPX routine. Then I thought... OK lets replace the UPX0 , UPX1 etc... in the section names and try to uncompress the next bit with UPX -d... no joy.

I would love someone to take a look at it and point out what I'm missing. I would have thouht that if a file was packed like this;

1) ASPack <file>
2) UPX -f <file>
3) ASPack <file>

then the process could be reversed, unless... only certain sections have been packed.

if anyway is interested, for curiousity sake, then please email me;

exosys(at)yahoo.com

and I'll send you the .dll in question. thanks guys...

-Ex

PS: I have also dumped this .dll with lordpe and rebuilt the IAT using revirgin (IAT=0x0002015C) also.. that work too.

They might have packed with a modified version of UPX. I have seen it floating around. It confuses UPX so that the -d option doesn't work. I think they just change some of the starting code to screw it up. Not sure if that's the problem you're running into though.

Update:
Just ran into something called UPXFIX on exetools, you might want to take a look at that, might fix your upx -d prob.. also ASpackDie 1.4 is out

thanks for the reply man,

I've been working on this for a few days now and it's pretty much done.

1) I did the first ASPack with ASPackDie, this got rid of two sections in the .dll, I had to patch two bytes in the UPX unpack routines after doing this, these bytes were the addy being loaded into LEA ESI at the start of the UPX routines.

2) I then let the UPX routines do their thing and set a breakpoint on the start of the second ASPack routine

3) I nursed the ASPack routine thru, it unpacked about 8 sections of the .dll, at each time I took the starting address in EDI, and the length from EAX and dumped each section as it was unpacked, this also allowed me to get the original IAT before it was destroyed.

4) I put the .dll back together section by section, modifed the pointers to the IAT , modied pointers to the .RSRC section and the .EDATA sections. (the pointer modifying was a bitch but I learnt heaps)

Now I have a unpacked .dll that is clean of unpacker code and it works... a good learning curve for me.

I have a question tho, does ASPack keep the original file header to get offsets from? I found that during the unpacking stage it was delving into 0xBFF70000 which contained this header...



thanks for your help again LBolt

-Ex