Hello Fellow RCEs:

I'm excited as I type this 'coz I *think* this may be a long awaited new ASPR strain. Look at this app.

Hide Folders v.2.3.5
hxxp://yyy.fspro.net

Hmmm okay It is ASProtect all right. Find OEiP. Piece o' cake. Now run ImpREC. WTF? IAT Size == 24??? Hmmm something is wrong. Okie! Run RV. "IAT is corrupt..." Enter OeiP and press "Find IAT". What!?? "Found Nothing"

Hmm... Open in SoftICE and find the IAT Decryption loop .. Everything is "normal"...

Okay let's see where we land at the JMP Table and lo! a whole lot of stuff has changed in the way ASPR redirects IAT! WTH??? No wonder RV/ImpREC is blown away...

For eg. Look at the following piece of code that redirects to GetModuleFileNameA:

[CODE]
017F:00C6493C 2BD2 SUB EDX,EDX
017F:00C6493E 681A1DFABF PUSH BFFA1D1A
017F:00C64943 64FF32 PUSH DWORD PTR FS:[EDX]
017F:00C64946 648922 MOV FS:[EDX],ESP
017F:00C64949 E9B62D31BF JMP BFF77704 (JUMP)

BFF77704 == GetModuleFileNameA+000D which is the bytes that are executed by ASPR! Hmmm.

Also, another funny thing is that ASPR now pushes values on stack and then RETs. Which again I belive RV can't find (as found by Eval on Armadillo) [So Alexey steal code from ARMA?]...

Anyways, it is 4.a.m here and I gotta go to sleep.

If this is not what it claims to be, moderators, just delete this post and let me lie in peace or else you'd better give this strain my name

Signed,
-- FoxThree

hi,

Try this


RVA= 8313C
Size=69C

regards

arieri

Mmh, are you sure it's a new version of Asprotect?

I have one of the latest ASprotect 1.23 Betas and I can protect an app I've written in a way that Imprec & RV do not find anything at the OEP. This is however the way I've written my app, same happens when I use Asprotect 1.2 (the ufficial one).

Yo guys:

Yes, I did find the right IAT RVA under Win9x. But that's besides the point. The point is while ImpREC fixes the IAT in a snap and RV in less than a snap , why both of them throw up in this particular ASPR version ? Any reasons would be highly appreciated.

Another thing that is interesting in this version of ASPR is that the IAT redirection style has changed, AFAIK. Pls. do feel to correct me if I'm wrong though

Signed,
-- FoxThree

Well, I managed to unpack it without trouble using RV.
I don't have an answer to you, foxthree, but I noticed something else strange with this program. When I put a bpmb on the address 46F920 in the original file, it breaks, and from tracing down that call you can easily see how this program can be patched to act as regisered. But when I do the same thing in the dumped file, it doesn't break. If I open the register box and fill in name and serial, and then put a bpx hmemcpy and so on, and then put a bpmb on the mentioned address after coming to the program code, it will break, and patching can be made. The call starting from 46F920 is a vital one. In the original file this call is checked during start up (checked it in Sice via breakpoints). But again, if I try it in the dumped file, it doesn' break, even though the program runs.
Anyone interested in investigate this further?

hobgoblin

Hobgoblin:

What was the version of RV that you used? I used v1.5 on Win9x. Though I know that it may not work correctly always, for all ASPR apps till now it used to work correctly. Wonder what is the problem? So is the case with ImpREC.

I'll try later today again with RV 1.3 for Win9x and see what I'm missing.

Signed,
-- FoxThree

I used RV version 1.2 on this program (I'm on WinME). I tried 1.3 also, but it couldn't read the RVA ot size of the IAT.....

hobgoblin

The IAT only seem to be acurately fetched on about 50% of the ASprotected apps I've looked at, that's why I recommended Fox3 write "IATStartFinder

And exactly where did you find that one? Did a quick Goggle search, but no luck...

Got a pointer to it?:-)

hobgoblin

hobgoblin:

Searching on google is always good, but don't forget the "search" button HERE. Part of the problem is that Lbolt99 gave it a generic name, instead of what FoxThree named it. You will find it in the TOT Forum and it is called OEPFinder. Simply open the TOT Forum and it will bite you. "Announcement: OEPFinder v0.3 Tensor Build" with FoxThree as a thread starter is a pretty subtle hint.

Regards.

p.s. a google search of "OEPFinder" leads to a site at hxxt://rrn.mine.nu//data/2002/may/01/11_00/Fravia.html that seems to be a redirector to threads posted here. Just why they are doing it that way I don't know.

Heya all,

I have tested RV 1.3 on my machine and it works fine My os is win98.Rv 1.5 only works on winxp and win2k.
change the oep to 401000 on rv just fetch iat it will resolved fined

Best regards

Hi Esther:

How're ya doing? BTW, putting OEiP as 00401000 works fine in both RV 1.3, RV 1.5 and ImpREC 1.4.2+ .

Now the question is why? when the OEiP is x7863C?

... which raises another interesting question, how does RV/ImpREC trace the IAT once the OEP is known. Do they disassemble memory from the OEP to land at the JMP table?

But on a more serious note:

Stone(): ASPR is famous for what is called as "special" builds that do not come as Betas. This goes directly to registered users on a demand-basis. [Alexey if you're reading this, may be you can vouch for this]. Is it possible that this is one of them?

+SplAj guru, Eval, Crus... and others: Yoohoo, where are you??

Signed,
-- FoxThree

This looks like a job for me, so everybody just follow me.....

Decrypted Sections for the nooooobs
===================================

Fox3 has found a very nice target to play with in hiddenfolders.exe but for Win98 etc only

I found no suprise at all with the IAT redirector. Same ol'shit. However
I did find a very nice feature made by the programmer that uses a key to decrypt
some code AFTER the OEiP of 47863C is called. So if you rebuild at the OEiP your actually
fucked cos features are still encrypted ... but it is made in such a way that you don't really notice !!!!

Lets reverse


//******************** Program Entry Point ********
:0047863C 55 push ebp
:0047863D 8BEC mov ebp, esp
:0047863F B906000000 mov ecx, 00000006

* Referenced by a (U)nconditional or (C)onditional Jump at Address:
|:00478649(C)
|
:00478644 6A00 push 00000000
:00478646 6A00 push 00000000
:00478648 49 dec ecx
:00478649 75F9 jne 00478644
:0047864B 51 push ecx
:0047864C 53 push ebx
:0047864D 56 push esi
:0047864E 57 push edi
:0047864F B824844700 mov eax, 00478424
:00478654 E8CFDBF8FF call 00406228
:00478659 33C0 xor eax, eax

BLAH BLAH BLAH UNTIL :-


:00478694 A124BF4700 mov eax, dword ptr [0047BF24]
:00478699 8B00 mov eax, dword ptr [eax]
:0047869B FFD0 call eax <-- Here aspr code decrypts 7 sections of code.

Start code called VA C4E870

This 'call eax' decrypts the following parts of code :-

Raw Offset :-
0x6F1F5
0x6F510
0x6F93A
0x71B0C
0x76DFA
0x787F9
0x78963

Using the key at offset 0x7BBF5 => 'gw4kjbjhgekljkrt'.

So, Hobgoblin made a point about the code around VA 46F920, lets compare our
real aspr hf.exe with our dumped.exe :-

Decrypted hf.exe code :-

:0046F920 55 push ebp
:0046F921 8BEC mov ebp, esp
:0046F923 83C4F8 add esp, FFFFFFF8
:0046F926 53 push ebx
:0046F927 33C0 xor eax, eax
:0046F929 8945F8 mov dword ptr [ebp-08], eax
:0046F92C 33C0 xor eax, eax
:0046F92E 55 push ebp
:0046F92F 6823FA4600 push 0046FA23
:0046F934 64FF30 push dword ptr fs:[eax]
:0046F937 648920 mov dword ptr fs:[eax], esp
:0046F93A E901000000 jmp 0046F940 <--Code has been decrypted so JMP 46F940 and on..
:0046F93F A6 cmpsb
* Referenced by a (U)nconditional or (C)onditional Jump at Address:
|:0046F93A(U)
|
:0046F940 33C0 xor eax, eax
:0046F942 55 push ebp
:0046F943 6806FA4600 push 0046FA06
:0046F948 64FF30 push dword ptr fs:[eax]
:0046F94B 648920 mov dword ptr fs:[eax], esp
:0046F94E C745FC6F000000 mov [ebp-04], 0000006F
:0046F955 B201 mov dl, 01
:0046F957 A1587F4500 mov eax, dword ptr [00457F58]
:0046F95C E8F786FEFF call 00458058
:0046F961 8BD8 mov ebx, eax
:0046F963 BA02000080 mov edx, 80000002
:0046F968 8BC3 mov eax, ebx
:0046F96A E88987FEFF call 004580F8

* Possible StringData Ref from Code Obj ->"Software\FSPro Labs\Hide Folders"
|
:0046F96F BA3CFA4600 mov edx, 0046FA3C
:0046F974 8BC3 mov eax, ebx
:0046F976 E8ED8DFEFF call 00458768
:0046F97B 84C0 test al, al
:0046F97D 7510 jne 0046F98F

* Possible StringData Ref from Code Obj ->"Software\FSPro Labs\Hide Folders"
|
:0046F97F BA3CFA4600 mov edx, 0046FA3C
:0046F984 B101 mov cl, 01
:0046F986 8BC3 mov eax, ebx
:0046F988 E8D387FEFF call 00458160
:0046F98D EB55 jmp 0046F9E4

*******************************************************

Now the same code from Dumped.exe :-

:0046F920 55 push ebp
:0046F921 8BEC mov ebp, esp
:0046F923 83C4F8 add esp, FFFFFFF8
:0046F926 53 push ebx
:0046F927 33C0 xor eax, eax
:0046F929 8945F8 mov dword ptr [ebp-08], eax
:0046F92C 33C0 xor eax, eax
:0046F92E 55 push ebp
:0046F92F 6823FA4600 push 0046FA23
:0046F934 64FF30 push dword ptr fs:[eax]
:0046F937 648920 mov dword ptr fs:[eax], esp
:0046F93A E9C6000000 jmp 0046FA05 <==Here is JMP over Encrypted Code
:0046F93F 3261CB xor ah, byte ptr [ecx-35] <-- SHIT, oh dear, WTF to do now ? !!!
:0046F942 F7DE neg esi
:0046F944 DA BYTE 0dah
:0046F945 F1 BYTE 0f1h
:0046F946 ED in ax, dx
:0046F947 DAC7 fcmovb st(0), st(7)
:0046F949 0933 or dword ptr [ebx], esi
:0046F94B 8B1F mov ebx, dword ptr [edi]
:0046F94D 29AFE3161C30 sub dword ptr [edi+301C16E3], ebp
:0046F953 E45D in al, 5D
:0046F955 CAAB8A retf 8AAB
etc etc

So lets dump at the point AFTER :0047869B call eax and rebuild....is that good hmmmm lots of memory errors now. Well it appears this call did more than decrypt some code
sections it set up InitialiseCriticalSection etc etc.
So we MUST copy+paste these decrypted sections from our dumpafter.exe to dumped.exe. Pretty easy with HWorks32.

Yes thats it

Nice target Fox3, shame I am so laaaazy to try

BTW Alexey also sent us the latest ASPR 1.23beta to play with.. but alas nothing to report.

Spl/\j

Yes, it was a nice twist.:-)
I worked on it for quite a while, and found the same decryption call as +Splaj did. I made a dump after the decryption call, and also ran into errors trying to run it. What I did was to copy the first section (spanning from offset 0x01000 to 0x79000) into the dump made at the OEP. That fixed the whole thing. All the decrypted sections was within that section.

Nice program to work with.:-)

regards,
hobgoblin

Yoohoo +SplAj guru and others:

What a dumbass I am ! I saw the "Call EAX" and saw the InitializeCriticalSection and stuff but alas failed to get a grasp of what was happening. Too lazy to trace through the ASPR code eh? Sorry!

Nice one, +SplAj guru. But, again a question raises in my puny brain: Why doesn't RV/ImpREC find the IT? Also, I haven't seen ASPR code PUSH <API Address> and RET. This was more of ARMA style. Am I correct?

Signed,
-- FoxThree

The IT tracer engine was allegedly coded by G-Rom

I have discussed this point with him and MackT over on the /37.html MB. He has some ideas to improve the success rate but I think this project was never implemented for the public.

I was trying to point out that the user should NOT rely 100% on these tools and use the brain+SI to examine the JMP table or IT for exact location and length.

Unfortunately they were so overjoyed at my visit, and we got bizzy exhanging pleasant comments , that they forgot the task in hand.

There are several 'features' of each compiler, being either Borland C++, Delphi or M$ VC++ etc etc that produce working IT in different ways. The early version of RV used to re-create the it.bin and IAT.bin in the Borland way. Now the standard is M$. Thats why U only get one it.bin to attach to the end of the target dumped.exe.

Suffice to say after various protectors have mangled the imports for their own use, coding an accurate IAT tracer requires lots of experience of all compiler + protector combo quirks to get a high success rate.

Usually I just type 401000 as entry point.... fetch IAT.....and check with SI

Using 'advanced trial+error' techniques ( there is a technical name for this.... M....err sumthin, like AV code does, but I am just a dumbass cracker) you could surely find the spot.

As far as your code regarding GetModuleFileNameA.... I think maybe u got lost in the codewoods a bit ???? I cannot remember that this API is redirected , ever ! I did not have any problems with resolving at all. So I will check it out tonight on old Win98 PC and revert......


Spl/\j

BTW I just de-aspr'd that HFXP Beta version...no such decrypt here.

+SplAj guru:

Thanks a lot for your rather detailed comments. Yes, I too unpaxed HFXP without any problems and no such tricks there . Actually, the credits for this proggie should go to miltantof (just another idiot thread). His posting got my attention and led me on this pursuit.

Yes, please do check this one out. I've also posted the redirected code in the first post. If you can just verify and let me know where I'm wrong, I'd be very grateful.

Thanks once again,

Signed,
-- FoxThree

+Splaj: Thanks for the info/suggestions, searching from 401000 seems to work sometimes too. I always check with SI, but lately have been having to just navigate my way to Asprotects IAT decryption loop and see where it is.

Maybe some form of pattern search would reveal the general location of the IAT: seems most reference Kernel, and it's usually the first one... a wildcard search thru ram starting @ 401000 for ** ** ** BF ** ** ** BF ** ** ** ** etc..

hello all,


I thougt I had unpacked the proggy to , but
I also discovered that the call eax to asprotect codes did decrypts
some codes at the place where you can easly patch the program to pro version, I also tryed to dump the program after this call was made but was kind of lost from there.
So thanks for the information Splaj guru.

regards
arieri

Hello, FOXThREE!

you asked:
>But why 00401000 OEP works for fetcher?

401000 is not OEP value, but is start of CODE section.
RV needs it for analyze CODE section & find references to IAT. (FarJMPs FarCalls)

Putting another value causes RV to crash.
So always[ladyes?] but 00401000 before fetching...

Hello "Musician Member":

Thanks for your reply. Hmmm, interersting enough. I try some research too .

Signed,
-- FoxThree

Lbolt99

....searching for 'BF' (in win98/me) or '77' (WinNT/2K) should yield zilch in a protected app cos the IT have been redirected !!!

eg Tag&Rename2.1beta :-

0030:005D6210 98 05 36 01 B0 05 36 01-BC 05 36 01 70 12 35 01 ..6...6...6.p.5.

from the table the table the API is redirected to 01360598.....

0167:01360598 2BD2 SUB EDX,EDX 
0167:0136059A 681A1DFABF PUSH BFFA1D1A
0167:0136059F 64FF32 PUSH DWORD PTR FS:[EDX]
0167:013605A2 648922 MOV FS:[EDX],ESP
0167:013605A5 680477F7BF PUSH BFF77704
0167:013605AA C3 RET

hmmm....now u follow the maze

Fox3

I tested a few recent targets like Reget3, T&R2.1 15pack etc etc
and they all give similar JMP table redirected API. The interesting thing is that most JMP to API memory location, however T&R does a PUSH API value and a RET.

Otherwise this is the way ASPR has been redirecting for a while ? ........and RV resolving them proves that.

I also played with the so called latest aspr 1.23beta last night and this gave nothing new as far as regular redirection goes.

Hajo +SplAj guru:

Thanks for your post. Hmmm, wonder how I missed it. Time and again, I tell myself not to debug ASPR apps at 4.a.m. Wow, 4.a.m. does have magical charms of itz own. Alas, I thought I'd get my name by identifying a new ASPR "strain". It seems I'm not the "chosen one" .

Thanks again for everyone for making this interesting.

Signed,
-- Foxthree

Hello +SplAj guru/others:

Heh, nice one this. Yes, I'm guity of just patching the code without delving into it . But I rectified and found the decrypted sections. Dumped, pasted, and all is well. But tell me, shouldn't the CALL EAX and the other one still be patched for the dumped proggie to run?

From: http://www.woodmann.net/forum/showthread.php?s=&threadid=3315



Now that the mysterious C4E870 is a decryption routine, doesn't the above anyhow hold good? 'coz this is what happenz to my dump after pasting the "good" .text section!

Signed,
-- FoxThree