Hi Folks:

I'm literally at my wits end with Reg. Organizer. It all started with me reading +spl/\j guru's post of ASProtect 1.4!!! ;-). I wanted to try out Reg. Organizer which has two weirdo Asprotect functionality.

(1) As +spl/\j mentions, we no longer have our GetWhatWeWantAPIs in one convenient place. The IAT is full of holes (Thanks to sv and +spl/\j for an earlier post for clearing my doubts about this)

(2) Asprotect does double dipping! (Still not clear about this one)

See I've managed to work out part 1 perfectly. But whenever I attempt to understand Part 2 of the trick, I hit a empty wall.

Moreover the problem is compounded by the fact that this particular target is updated weekly (the week before last was Beta 2, last week Beta 3 and now Beta 4) hence I'm unable to get reference values for understanding Part 2.

So, with all my frustration growing inside me, I finally dled 1.3 B4.

I've managed to find the following:

1. ASPR dips into code at 00412A7C
2. Back to OEiP at 00401000

Now the problem I'm having is: Where to dump? Should I do it at 00412A7C or at OEiP (like we do always). +spl/\j mentions to dump earlier and patch the jmp 00401000. But my question is How this is done? In my disassembly (after dumping at 00412A7C) such an instruction is not present.

SV mentions the same thing about RegOrg 1.2Beta 3 ("There is a call (412d34) to do before OEP (401000). ". I also have a similar situation (412A7C before 00401000).

Again, how is this done? Should I dump it at 412A7C? After that what, because again after doing some init at 412A7C, we go back to aspr. So if we dump here, we still have some unpacked code, right?

To add to all this, there is a good tut by nchantA where in he explains how to unpack EBook Processor 2.2. I'm having the exactly similar code layout when I break at 00401000: I have a jmp 00401012. Now in this tut, he says that to look down until the first jmp occurs. In our case it occurs at 00526C88. So according to his tut, OEiP RVA = 126C88 and he does a /pedump in icedump.

I did the exact same thing but when I run my rebuilded app, it crashes at 00526C94 (Invalid Page Fault :-<

What am I doing? Please please please clear my doubt. I'm going crazy with this!

Signed,
-- FoxThree

PS: Sorry for this lengthy post but I needed to get this one off my chest ;-). Thanks once again to sv and +spl/\j for helping me out with the earlier "IAT hole theory"

Hi:

Sorry me again <grin>. I'm attaching my rebuilt IAT.txt file for reference.

Pls. pls. throw some light on this one....

Driving me kwazy.... :-(

Signed,
-- FoxThree

Hi Foxthree,

Think Spl/\j has been busy, he hasnt posted anything for weeks... my post redarding this initialisation wasnot answered either... guess noone has yet to find out what AsProtect really does in those "dip in"..

I tried to see what AsProtect does when it dips into original code, but i did not gather much... anyway, as Tseph and Spl/\j has pointed sometimes ago... if you skip those two initialisation and then dump at OEP = 401000 as usual then it works no problem...

Yeah, i did that and have a working dump now...

Hope that helps.

Hi fellow RCE's. It makes me happy to see 2 new guys here (bin81 & fox3). I have seen all your posts and you are making some good contributions. Thanks and welcome.

hmmm D-D....

I thought It was made it clear that in *most* cases the reason for D-D is to Initialize some memory and/or set some variables BEFORE OEiP as an anti-dump measure.

There are a couple of things to do (after learning a LITTLE ASM) :-

1) At 1st dip manually RET back to ASPR WITHOUT calling the code
and DUMP at OEiP. ie SKIP this call.

2) Let the code run to OEiP and then DUMP... and manually CLEAR the .data area that has been flagged with 'initialized ok' and/or variables set with hex editor.


Ok.

Rebuild IAT etc etc.

Now EXAMINE the code at OEiP. Is there enough space to CALL 1stDIp code and let it RET as is ? For me with RO v123bulit on 19th January I did the following. :-

OEiP 401000
1stDip 419A2C

So at OEiP re-coded to CALL 419A2C and then immediately after JMP 401012 to skip some unwanted bits ? and continue. This worked for me. However what i would recommend is to find a spare block of 000000000000000000 to code some changes.

ie change OEiP to your new location and then CALL 1stDip and then JMP OEiP

hmmm is that enough ?

Ok i'll d/l the latest RO and maybe I can help you exactly- if we all get the same build !!!

Also use LordPE to Dump/hex edit. It's the best way so far.

Spl/\j


PS. I was busy...... then had an accident, so I spent a few weeks with the men in white coats but i'm back now, not full time tho.

Hi foxthree

As +SplAj said, i have done exacltly same process :

Dump at 401000 without call 419A2C execution.
Rebuild and paste IT.
Recode a small code at free space : call 419A2C & jmp 401000.
Change EOP to this piece of code.

I don't remember if there is an indirect call, sometime used in ASprotect

Regards
SV

Hello again
and special greets to sv ...BIG hello m8

now I can confirm the following regarding RegOrganizer v1.3b4

OEiP 401000 duh !
1stdip 412A7C

Break at 412A7C and make EIP to the RET. Or clear the area around offset 0x1CA980 to reset flag/variables with 00 for about 50 bytes or so

ImportTable has 505 entries from 1D1134 TO 1D212C

Tricky API :-
Line 35 1D13F0 == FreeResource
Line 38 1D13FC == GetCommandLineA
Line 40 1D1404 == GetCurrentProcessId
Line 59 1D13FC == GetModuleHandleA
Line 62 1D145C == GetProcAddress
Line 76 1D1494 == GetVersion
Line 104 1D13F0 == LockResource

make new IAT/IT to fit 0x2C1000 save as IAT.bin and use LordPE to add section from disk. Fix up header etc etc....

replace ASPR high call at RVA/raw 0x199398 == 8C 2D 41 (call 412D8C)

D-D fix :- make bytes at RVA/raw 0x1000 == E8 77 1A 01 00 EB 0B

401000 CALL 412A7C
JMP 401012


That's ASPR 1.4 gone

Spl/\j

Hi SplAj, *the arrogant bastard* :>

Yep, thanx for the welcome thought, I have never received so much help and guidance before and I should be grateful to the board and the people here ... Yep, Thank you all...

OK, back to business... :>... so far my finding for Reg Organizer is that the dip at 412A7C allocate heap memory and set up initialisation flag like you said... also i think it check for the key file "regon.bin" with the hash table to check our registration status...

I skipped this dip and dumped at OEP 401000 as you said, rebuilt IAT and the dump runs fine without calling 412A7C... thus I reckon 412A7C is some kind of addon by AsProtect when the programmers select key file protection feature in AsProtect... hence there is no need to call it at OEP.... i am not sure though...

However, the OEP at 401000 does look weird...

That is all folks, :>

PS : Hope you have recovered from the accident, SplAj :>... Take care when you drive around next time...

Hi there:

Firstly my humble thanks to +spl/\j guru for his posting on this topic. Hope you're feeling better!

Now, I clearly understand the double dipping concept. Yes, ASPR uses this to initialize some memory flags to prevent dumping... but just ret at the PUSH EBP instruction and we can dump all we want ;-) (Once again, my thanks to +spl/\j/SV... )

Still I have two small questions for SV: <grin>

1. Since we've bypassed the original call, why do we need to change the OEiP and CALL 412A7C and then jmp to 00401000. If you disassemble the dump, what you see at CALL 412A7C is a simple ret (which we'd coded earlier for dumping).

So, I think this step is not needed. Correct me if i'm wrong but this step is only needed if you adopt +spl/\j's 2nd method of allowing ASPR to do the initialization and then dump at OEiP and then resetting all the unncessary variables (that cause Page faults btw :-< to NOPs heh !

2. What is meant by indirect calls? R u referring to redirected calls?

Once again, I learnt a valuable lesson in unpacking today. RegOrganizer is no more (not patched yet but unpacked... yes!)

Like +spl/\j writes in his tutorials, "Patch and play" <grin>

Signed,
-- FoxThree

Fox3,

u got it wrong, both Splaj and sv meant said that you use "r eip" to skip the call 412A7C, not patch the byte there with a "ret"... which might be bad sometimes if the actual ret is "ret 4" or something like that, u might cause a stack fault...

Hence, they both still called for 412A7C at OEP again...

I think so at least :>

Regards,

Hi foxthree, binh81, (yo +SplAj )


"1. Since we've bypassed the original call, why do we need to change the OEiP and CALL 412A7C and then jmp to 00401000. If you disassemble the dump, what you see at CALL 412A7C is a simple ret (which we'd coded earlier for dumping). "

As binh81 said, when landing in at 412a7c, i just change manually eip to only do a ret (no patching) and continue tracing until 401000. Perhaps this call is no needed to run unpacked exe (humm), i haven't tested !

"2. What is meant by indirect calls? R u referring to redirected calls? "

Sometime in Asprotected exe, when tracing , you land in some code like mov [5cafa4],eax with eax = e2c9a0, and at this location (asprotect code) there is code like call [xxxxxx] where xxxxx contain 5c55a0.
You just have to change at 5cafa4 right value : 5c55a0.
This exemple is about last Tag&Rename

Redirected call is more explicit !!!

Regards

SV

Hi Folks:

Firstly thanx to +spl/\j (u're da man ;-)), SV, my buddy binh81 (hi there) and others who have actively posted their solutions to overcome ASPR D-D.

I personally think D-D is finished !!! <grin>

Thanks again for your analysis, folks.

Signed,
-- FoxThree

Hi again

the 412A7C call can be missed out - Evaluator and I discussed this point about previous versions of RO. However I am highly suspicious that if this call is NOT made then using it on ur registry could cause a major fuckup on ur PC

The redirected call is the one at offset RVA/raw 0x199398 == 8C 2D 41 (call 412D8C) . U can see this cos at startup massagebox comes up about cannot read memory blah blah. Just trce this call in original target and you will see the code call is 412D8C. Again the unpacked target appears to run anyway after the mesagebox....but do you trust this program with ur regitry ....

BTW I can't walk, never mind drive yet........poor me sob sob.


cya

Spl/\j

Hi +spl/\j:

As they say in Star Wars: "The training is now complete!" <grin>. Yes. I got what you said. I'll try again later today.

Thanks once again for your gracious contributions.

Wish you a very speedy recovery.

Take care,

Signed,
-- FoxThree

Hi +spl/\j:

The "learning" is complete now. Thanks for all your gracious help!

BTW, can you up the discompress.com. I believe newbies like me can do a lot of learning by reading your tuts. Does it have a mirror?

Thanks for sharing ur wisdom,

Signed,
-- FoxThree

hmmmm....

I have been asked several times for 'discompress' site'. I thought I had a god angle when I started 2 years or so ago on it. But actually, if you get all the packers/protectors from exetools or wherever and pack Notepad.exe...you can soon gain good experience from unpacking it cos you know the header already.

....and thats my point....learning the basics of PE format especially IAT/IT gives a good grounding for unpacking.

I must say the new tools like RV/Imprec/LordPE/Icedump with tracer make the task a lot easier these days so I don't think there is any real need for a disco comeback......just yet.

Spl/\j

Hi Spl/\j,

Yep it is me again :>... worry not i am not chasing your arse for the unpaxor king post... not YET :>>>>>>>>>

Hmm... okie, there were a few call into original code section by AsProtect in the decrypting process, the first one was a simple ret, nothing else, the second one was the one that change the memory location [599398] (originally store 412D8C) to a redirected call in AsProtect memory, the third one is the long dip which access file "regon.bin" and check it with the hash table....

I skipped all these dip back and dumped at OEP 401000, the dumped runs fine without any further patching, no error message box at start up, i did a test with registry cleaning and as well as tried to delete some registry entries... it works fine no problem... I used the 1.3 beta 4 version....

I have tried with other AsProtected apps that have dipped in

Advanced Link Catalog : dip in check serial in registry... i skipped this dip in and dumped at OEP, no patching needed to call the skipped procedure....

Website Watcher 3.4 : dip in check keyfile... no patching needed either....

Chameleon Clock 2.51 : dip in initialise options saved by users... check if registered user then allow initialisation if not set back to default start up options... This call has to be made for the program to run properly....

I have yet to find any other AsProtect apps that have dipped in to conduct further research.. maybe u guys can put up some links to AsProtect Apps with dip in....

So far, only Chameleon Clock requires to patch OEP to call the skipped procedure... i think more work has to be done on this to confirm it....

That is all i have for now....

Cheers....

Hi guys,

I don't know if you're interested in what's happening in those
double-dip regions, but here's something you can play with.
Softice Backtrace outputs of the complete double-dips at
412A7C and 412D8C for RegOrganizer 1.3b4.

It's not quite as informative as manual tracing and having the
register and variable values on hand, but it might be handy to
make it easier to follow the action, scribble notes, home in on
certain areas, or whatever. Consider them Cole's notes
These are the exact sequence of code lines executed in each
double dip in *program* code, not including any jumps to
packed code. But, you should be able to source those out from
your IAT dumps or from within SI.

Here's the idea. As an example, from the 412D8C D-D is this line,
which you could find by manual tracing:



Now you've all done this before in searching for redirected IAT
entries.
5D144C contains a redirected address in packed code:



So
JMP NEAR [5D144C]
is a redirected call to GetModuleFileNameA. In the trace outputs,
all the "JMP NEAR [xxxxxx]" will be redirected API's. In the
412D8C D-D many are to EnterCriticalSection and
LeaveCriticalSection, but a few are to GetDC and similar User
API's, including DrawTextA. I don't know what that is exactly,
but perhaps it's how the registration info is drawn into the
About box. Just a guess there, but quite possible if this is the
code called for that, and is normally missing if you skip that D-D
before dumping, but doesn't affect the program operation.


Anyway, just something to look at, it may make no sense to you,
but if you want to explore these DD regions closer then you can
have these on hand as disassembly outputs. They won't give
you all the answers since we haven't implemented a tracer
function yet that traces the redirected addresses, but go ahead
and make what use you can of them. They're big, 17000 and
30000 lines of code in the two DD areas. Probably blow you
away and is of no use if all you want to do is unpack the proggy,
but if you're curious, go for it ;-)

You can do a text search for "JMP NEAR [" (note there's a
double space between jmp and near) and this will quickly get
you to each redirected API call.

It was interesting what binh81 mentioned about the DD areas
doing slightly different things on different apps. Asprotect must
use the DD implementation to do different things depending on
how the user set up the options during packing.

btw, I had to break them into 2 files. One of them I RARed then
zipped, the other is just zipped. I kept having CRC errors on the
d/l's so hopefully these will now be OK after several attempts.
Around 100K for the first, 70K for the second.

Have fun,
Kayaker

And here's the 2nd one