Hi ,+Tsehp:
I am unpacking the proggy now,I find it EOP at 6e7c,IAT 1561cc,length 844,so I dumped it,and pasted IT.bin,but it still can't work,how can I do??? Would you please give me a tutorial ,OK?
Best Regards!

Forgive me, but this makes me want to cry. This forum is supposed to be a portal to learning and knowledge. There could be many reasons why your dump doesn't work. Giving up and asking for a tut is not the solution. You need to take it one step further and understand *why* it's not working. Try breaking on the error message and see what's causing it. Set a 'BPM address X' on the error address given and you should be able to break before it crashes. There's likely an invalid memory address being accessed because of a redirected API call.

Now you need to trace to this exact address in the *packed* file and find out what it *should* be processing. Then you work from there. You may find you can simply patch this point with a RET, a valid flag/address, or the correct API call which perhaps you can edit in Revirgin and regenerate an IT. If this works and you get past this point and get another error, repeat the process until you've exhausted all possibilities. This is a lot more work than getting someone else to write a tut, but you'll learn a lot more. Then YOU write a tut about it and contribute to the knowledge base.

Please don't take this as a put-down, I'm only trying to help and to help this board. I don't know, with almost 500 members on this board we should be awash with new, creative ideas, innovative techniques and just a pure reversing-for-the-hell-of-it mentality. I know it's not just me who feels this board could be better. I'm not trying to be leet. I'm not trying to be judgemental. And neither am I dissing the board. I'd just like to see this forum and everyone on it reach their full potential. Learn and pass on what you learn, at any level. Follow tuts to a point, then give up on them and find your own path through the codewoods. Think different! Then teach others your new ideas. Above all, remember the name of this forum - Reverse Software Engineering - please let's strive towards whatever that ideal might mean and shy away from simply becoming another cracking site. Excuse the diatribe, but I love this board and just want to see the quality maintained.

Regards,
Kayaker

Hi
That's right Kayaker (lo ).
To newbie, there is already a thread about T&R with some tricks:
http://www.woodmann.net/cgi-bin/Ultraboard/UltraBoard.cgi?action=Read&BID=5&TID=2312&SID=

Cheers
SV

Kayaker,

you should win the next Nobel Peace prize for your diplomatic and eloquent MB replies.......

I will propose you and I think SV will second it

+SplAj

Hi All,

If SV does not second it I will. Well done Kayaker.

Regards, Kugi

Heh, heh, Mother Teresa I ain't ^_^ Thanks for the support guys, appreciate it. I'm glad that the sentiment is generally shared, gives me hope for the board after all

Cheers,
Kayaker

Well said, props to you all.

hiya,
"Nobel Peace", oh cmon this guys head won't fit in his helmet if you keep that up.
regards

hiya,
"Nobel Peace", oh cmon this guys head won't fit in his helmet if you keep that up.
regards

S'OK, I can always buy a bigger helmet ^_^

better to rent one .......

http://www.globaleffects.com/rentalC1.html

take yer pick I paid the deposit, hz will pay the balance on return

+SplAj

PS
==
while browsing I picked up the sexy S1030, looks great on me }>

btw excuse me for lamelessly trying to back to the first message from newbie ;-)

as kayaker said, some iat entries can lead to nowhere, revirgin now detects simple ret ones, or just let some direct inside code references (like an iat leading to 410544) and will not try to resolve them, trace them and you will crash because there is no api at the end.
alexey in asprotect is actually spending his last bullets and putting some entries like this :
iat leads to :
mov eax [01455212] (asprotect some kind of flag)
ret

well in this case, you create yourself in some free space of the dumped exe the routine that takes the real value and point the iat to it.
lots of cases, so experiment and come back here if you want to ask some precise questions, I'll be pleased to answer them.

Hi newbie and +Tsehp (or Tshelp as someone posted hehehe )

Thanks for bringing us back to the point of the Q. If you do the 'search' query on RCE for 'TAG&' you will get a few threads that
disect this target since late 2000. The first by SV then also by me from Rot8 Q - sorry SV - thought I found somethin new but you had it covered already .........So we all yawned and said aaaaaaaahhhh tag&rename AGAIN boring...... !

However we MUST not forget that our foe Alexey is very much in here and obviously changes things for his customers ASAP - good service BTW ! and obviously this target has had some cosmetic surgery so we must keep up with him.

This means i'll DL it soon and have another look...ahhhhh tag&rename AGAIN....}>

SplAj

Is there a new tr19? I don't think so.

Thanks +Tsehp!,Maybe I will be back soon.
And Kayaker,your advice are very precious.
Sv, I had read your post,but I can't find 555ac in my dump.

Hi Newbie,

I'm glad you didn't take my post as a rebuke, it wasn't meant as such. I just d/l T&R, I'll have a look at it and see if I can't make more positive suggestions this time. Of course if it's like the latest Asprotect where API's other than GetProcAddress are unresolved, it could take a bit of work...

Regards,
Kayaker

Hi All,

Yup, this is this weeks version of Asprotect To get to the OEP you now need to trace into a JMP [EBP-14] which contains a lot of SMC. You need to single trace through this and set advanced breakpoints to get out of the half-dozen or so loops until what appears to be the correct OEP:

0167:012F9A24 8944241C MOV [ESP+1C],EAX
0167:012F9A28 61 POPAD
0167:012F9A29 FFE0 JMP EAX ;551370

Start IAT at 1571CC, Length 844

Revirgin resolves everything except about 11 Kernel calls. This is where Asprotect is getting tricky, a couple of these can be replaced with GetProcAddress but the rest seem to be doing different things or seem to be other redirected API's such as GetModuleFilenameA, GetModuleHandleA and who knows what else. This is why you need to scope out what's happening in the packed file.

It can be done, it's a lot of work, I'm still slowly working through another app protected like this, but man, what a learning opportunity to study the redirection implementations if you're into that kind of thing.

Cheers,
Kayaker

Thanks,Kayaker, I will try.

Thanks to report here when someone manages to find what the left entries are doing, I'll update revirgin to automatize it.

Hi I had a go last night and as suspected things always change a little ....I had a auick look last night...

Beloved Revirgin still has a few probs with the following entries (using Win ME Arabic Enabled) :-

15721C 012DC468 --> GetProcAddress
157220 012DC818 --> GetModuleHandleA
157230 012DC86C --> GetCommandLineA
157348 0054FA78 --> SizeofResource
157380 0054FAF8 --> LockResource
1573B8 012DC834 --> GetVersion
157410 012DC864 --> GetCurrentProcesId
15741C 0054FB24 --> FreeResource

And also maybe when this IAT/IT is corrected there is that dead end call as explained previously. But I never got that far as was school homework for the kids.........

So 'newbie' get a better handle as this is a common one and welcome to RCE. Glad we did not p*ss you off or put you off.

SplAj

There are some trick under ASPR
Author use MD5 hash of code section to decrypt some resources, such as TMainForm etc ... =)
So, good luck !

wow he did found something new this time !
I'll download tag+rename and correct this.

+tsehp, who do you mean, when say
"wow he did found something new this time !" ?

+tsehp, who and what do you mean, when say
"wow he did found something new this time !" ?

T&R 1.9 is finished Unpacked on both WinME & Win2K...until next week when Alexey reads this and changes to (re)build h

OEiP 0x551370

The IAT/IT is correct as newBie said at 0x1571CC. I fixed up the new IAT at offset 0x249000 with a new section .SplAj length 0x3100.

The only problem came with the 'Initialisation Error' that is programmed in the code so it must be an anti-dump trick
This is fixed by changing the 4 bytes at offset 0x556CBC to ACA05500.

Look at the ORIGINAL code called by 0x5513B3.... trace it and you will see what I mean.

The rebuilt IAT/IT is enclosed.....see attached tagrename.ace

+SplAj

15721C 012DC468 --> GetProcAddress
157220 012DC818 --> GetModuleHandleA
157230 012DC86C --> GetCommandLineA
157348 0054FA78 --> SizeofResource - internal author's redirect
157380 0054FAF8 --> LockResource - internal author's redirect
1573B8 012DC834 --> GetVersion
157410 012DC864 --> GetCurrentProcesId
15741C 0054FB24 --> FreeResource - internal author's redirect

He uses such technic to decrypt resources "on the fly".

Hi guys I had chance to play further with the latest T&R 1.9
protected with ASprotect 1.2 (evolution) version...

After unpacking and fixing up the dumped exe I tried to patch the opening 'nag screen' not to show ... and I came across the SAME hash/encryted code loop as I described in my 'Bloatware Commview 2.5' message a while ago... that crashes the exe if any bytes are changed. So this routine was not made up by Tamo but our dear friend Alexey !

So how to bypass it. Rather easy actually... just read my notes below and that should get you on your way :-

TagRename v1.9 (DL 26th April 2001)
===================================

OEiP @ 0x551370 / IAT @ 0x1571CC length 0x844

Create new section .SplAj @ 0x249000 length 0x3100
and use Revirgin to restore the API calls and create a new IT 249000
an paste it in your dumped exe.

Set the OEiP and IT addresses with PEditor 1.7 and fix it up to be Win2K compliant (rebuilder)

It does not run :-(

Problem at 0x5513B3 Call [556CBC] - was a high call that did this in Windows ME :-

0187:012DC7C8 833DA835410000 CMP DWORD PTR [004135A8],00
0187:012DC7CF 7406 JZ 012DC7D7
0187:012DC7D1 FF15A8354100 CALL [004135A8]
0187:012DC7D7 C3 RET

Now we have got rid of ASprotect this call no longer exists so the exe CRASHES !
But 'Call [004135A8]' is actually equivalent to 'Call 00550AAC' .....
so change the 4 bytes at offset VA 556CBC to AC0A5500
(thats raw offset 156CBC for Hex editor)

Fixed :-)

Now it runs.

Next is the 'encryted' checksum problem. If you patch any bytes in the unpacked exe
then you get an 'initialisation error' cos you f*cked the checksum. This is stored
in VA 0x556CAC (raw 156CAC) and the expected value is 879FCC2641A64A6893E91A5A5C8777ED. This is just before the above 0x556CBC bytes !

The code that puts this value there is at 0x550A19, check it out at the REPZ MOVSD !

So just PUT the expected bytes in the dumped exe with a hex editor and change the code that 'pokes' the wrong hash to point to 556CCC so it is always correct ! Change 1 byte at VA 0x550A22 :- AC to CC (raw 150A22) . Now you can patch what you want

Note: this 'checksum' error is also generated with a 'BPX' in SI as part of the calculation !!! .... so a BPX 550A21 would generate an error before. Now it won't

SplAj