📚 OpenRCE is preserved as a read-only archive. Launched at RECon Montreal in 2005. Registration and posting are disabled.








Flag: Tornado! Hurricane!

 Forums >>  Target Specific - General  >>  SHRINKER 3.5 - NEW CHALLENGE

Topic created on: July 16, 2009 07:51 CDT by chipmaster .

I think it's a good chance for interested hackers to pay attention to this topic for a while. well, here is the story.
=============================================================
I've been depacking a software for days and now I've got some interesting points about it that wanna share with you. The packer is actually another varient of Shrinker called Shrink 3.5 'cause of different OEP(0x00014C54) and OEP jump instruction that is CALL[EBP-20] instead of CALL[EBP-24].
well, I've obtained the OEP as been mentioned earlier and managed to jump to OEP and then stop there for dumping. But, before it was not straigthforward to get to the CALL as you have to pass 31 SE's to program until you get to the CALL to OEP. Now, the problem is after getting to OEP, I CAN NOT DUMP IT AS .SHRINK0 SECTION HAS BEEN PROTECTED. well, during the 31 exceptions, I've changed the .shrink0 section protection to FULL ACCESS and then I've managed to dump it.
Now, another story raised. I've tried ImpRec to reconstruct the IAT of the program. but, when I've changed the EP to OEP in ImpRec it could not manage to find any dll. but, when I use loader EP then it works and finds all imports. maybe, when I change .shrink0 protection to FULL ACCESS then it starts something behind. tracing is not possible as there are many CALLS and CONDITIONAL JUMPS. but, I'm absolutely sure about OEP. by the way, one time I've dumped the unpacked program with ImpRec and it worked. but, concerning IAT, ImpRec could not find anything at OEP. I've tried all Olly Plugins available and they did not work. direct breakpoint on CALL[EBP-20] does not work either, so only sigle stepping and passing 31 exceptions to program works out and gets to the JMP to OEP. even ESP breakpoint technique does not work. so, any idea about this mother...?
Thanks,

  lallous     July 16, 2009 09:18.19 CDT
Post the file, perhaps someone can take a look.

  jumpzero     July 16, 2009 10:03.06 CDT
1. you can change memory read access with "virtualprotectex" at the moment you try to dump it. in fact, any kind of dumper like ollydbg, lordpe already does it. so you don't need to care about section read access if that's what u r talking about.

2. api calls can be redirected. in that case, you need to fix it yourself on memory or write yourself a imprec plug-in.

that's just all talkin, best way is uploading it here.

  chipmaster   July 16, 2009 21:39.48 CDT
Thanks guys.
unfortunatelly, it's not possible to upload it  here as its complex and big in size with different dll's. anyhow, I try to test your solutions that I think are good ones and then come back to you again if does not work. at last if could not find the solution by myself then I will find a way to upload it here for more help from you nice guys.

  chipmaster   July 18, 2009 00:27.36 CDT
ok. I've found the algorithm of the shrinker 3.5 and how it manages the memory. the way it behaves is, it starts allocating 599000 bytes in memory starting from VA 0x00401000.
then it will protect this memory by PAGE_NOACCESS protection scheme. the problem is, it does not load whole the .shrin0 section, unpack and then run. the algorithm is one of the complicated ones but in general it load 32k by 32k pages, change the memory protection to PAGE_READWRITE, then unpack, then change protection to PAGE_EXECUTE_READ, and finally run. it means the algorithm truncated code into bunch of executable parts, unpack and assemble then step by step. so,  I think you've got the problem. see. we can not dump it, not 'cause of memory protection, but because of partial exceution of code and perhaps polymorphic behavior during running. so, the solutio is, let it load 32k pages, unpack and put PAGE_READ_WRITE protection and now we fire dumping and dump 32k pages starting from 0x00401000 and continue this process by dumping into sequential files upto 0x0095A000 that is the end of .shrink0. After that, we assemble whole the files into one and voilla. fixing IAT and exe header makes no problem and you know. have fun.

Note: Registration is required to post to the forums.

There are 31,328 total registered users.


Recently Created Topics
[help] Unpacking VMP...
Mar/12
Reverse Engineering ...
Jul/06
let 'IDAPython' impo...
Sep/24
set 'IDAPython' as t...
Sep/24
GuessType return une...
Sep/20
About retrieving the...
Sep/07
How to find specific...
Aug/15
How to get data depe...
Jul/07
Identify RVA data in...
May/06
Question about memor...
Dec/12


Recent Forum Posts
Finding the procedur...
rolEYder
Question about debbu...
rolEYder
Identify RVA data in...
sohlow
let 'IDAPython' impo...
sohlow
How to find specific...
hackgreti
Problem with ollydbg
sh3dow
How can I write olly...
sh3dow
New LoadMAP plugin v...
mefisto...
Intel pin in loaded ...
djnemo
OOP_RE tool available?
Bl4ckm4n


Recent Blog Entries
halsten
Mar/14
Breaking IonCUBE VM

oleavr
Oct/24
Anatomy of a code tracer

hasherezade
Sep/24
IAT Patcher - new tool for ...

oleavr
Aug/27
CryptoShark: code tracer ba...

oleavr
Jun/25
Build a debugger in 5 minutes

More ...


Recent Blog Comments
nieo on:
Mar/22
IAT Patcher - new tool for ...

djnemo on:
Nov/17
Kernel debugger vs user mod...

acel on:
Nov/14
Kernel debugger vs user mod...

pedram on:
Dec/21
frida.github.io: scriptable...

capadleman on:
Jun/19
Using NtCreateThreadEx for ...

More ...


Imagery
SoySauce Blueprint
Jun 6, 2008

[+] expand

View Gallery (11) / Submit