Hello +Tsehp,

I tried using your wonderful tool on the following target: Cool Mouse v3.4 ( http://www.shelltoys.com/files/cmset.exe )

Problem is that revirgin won't trace the unresolved entries; that is .. it traces one of them (the one at the 'middle' of the list) but not the (quite long) list of entries at the end.
It just crashes, pretty hard ;-)

I'm running win98 build 2222.
I've successfully used the tracer on the Notepad included in your revirgin.ace
I'm using revirgin v1.0a

Original entrypoint: 876B
IAT RVA: D000
IAT length: 625h

I hope this'll be enough info.

BTW, could you change my email address (accountname Predator) from .com to .org ? :-) tnx......

TIA.
~Pred

btw plz ignore the other post with the same topic something went wrong.

you made a little mistake, the iat length is not 625...
iat's are just dword entries pointing usually to an api address or can be redirected into asprotect code, with 625 you included other things than iat and even text bytes...

Hm, that's odd. What would the length be, then?

I found 625h like Kilby says in his Copylok tutorial, the IAT ends with 10x '00' bytes. So I searched for the first occurence starting at the beginning of the IAT and I end up 625 after the beginning.

Why/Is that wrong?

Regards,
~Pred

Hi ~Pred


glad you could log in now !

Ok my big mouth ( hot fingers) can't wait any longer to tell you
the obvious. After a BPX GetModuleHandleA (thats how I find the IAT) and get into the target code. you find youself looking at the area VA 40D000 (1st thunk down) so type in RVA D000 -I remember that now and get the lat mem address or estimate. You said 625, but I get last API at D2A4 so the length is D2A4-D000 = 2A4 ..... now build the IT bins ...

OK ?

SplAj

erm sorry Alexey, that trick is

BPX GetModuleFilenameA

3 x F5 and F12 then dump the memory from the previous call address
eg d 4D014C

Your smack in the middle of the IAT

SplAj

Hi +splaj

I tried looking at the IAT with my hexeditor and found D2AE to be the last one.. so length is 2AE I think

When resolving/tracing with revirgin I indeed get API names upto 2AE so that's probably it.

Thanks for the info And for the email/pwd fix.

Greetings,
pred

btw it's "ended" with 9x '00' bytes .. perhaps 9 would be fine as well instead of 10

a'ight, I unpacked the app and it runs...

afterwards, it was much too easy ;-) just some new stuff..

but, there's 1 thing.. if you unpack the app, and run it, at VA 40821C, ecx is pointing to "nonexisting" memory while in the packed app it points to "existing" memory.. this causes a crash at the instruction at this address..

solved that by replacing those 2 bytes with 90h but I'm not sure if that was the most subtile way.. any suggestions, anyone?

greets,
Predator

Excuse me for not taking the time to explain more, but you should not
work on the dumped file to do this, why ? because you could have mistakes between raw offsets and virtual offsets if you forgot to realign the sections -> raw = virtual for offsets and lengths.
use what +splaj told you and this will always work.

The aspr tendencies :
like I've already told, some target code called (some flags sets, and other inits) back to asp then go to oep. if you dump with the previous code called, this will crash, look for precedent topics.

some news I saw on commview 2.5 , some poor test iats like :
mov eax , [10054521]
ret

just for the target to see if asp is still in mem too funny.

A next revirgin version will soon be available, it will paste the it file directly in the target if sv sends me a good dll or it's source code

but most important, it will analyse the links between code -> iat -> api
then reconstruct even some more iat entries for protection schemes like sd2, there's still work to do...

regards,

+Tsehp

Well,
I never forget to realign the sections plus I know the difference between RVA's and raw offsets - I think I can just work on the dumped file ;-)

no disrespect to +splaj's way of locating the IAT ofcourse - but i choose my "own" way.

like, i didn't really read any tuts on revirgin/asprotect only the one by kilby, that's why i didn't know about the program calling asprotect api's or checking in mem if it's still there - but it wasn't a hard thing to think of reading the asprotect docs, after all.. ;-)