Anyone besides me getting the "Please update tracer.dll to its latest version into your %systemroot% directory" from Revirgin 1.4. When I check the file properties in the systemroot and in revirgins directory the tracer.dll is version 1.31. Though I don't know if it matters I am running Win2k.

Tshep great program, I have just started to use it and learn what it can do.

-robber804

Had same problem too. It seems that the exe does not look for the version info, but for a date-time stamp of the tracer dll.

So I changed mine to 27/04/2002 10:55 (that's European format -
dd/mm/yyyy). Now RV does work.

Hi +Tsehp:

Are you planning a fix for this

Signed,
-- FoxThree

Hi Fellow RCEs:

What Stone() has remarked is correct! I did the same and it worked. So, I thought many guys would benefit with a simple code snippet to do this (until +Tsehp fixes this ) Attached below is the snippet to change the timestamp of tracer.dll. Modify it to reflect the tracer.dll's location in your system.

SYSTEMTIME sys ;

sys.wYear = 2002 ;
sys.wMonth = 4 ;
sys.wDay = 27 ;
sys.wDayOfWeek = 6 ;
sys.wHour = 15 ;
sys.wMinute = 36;
sys.wSecond = 0 ;
sys.wMilliseconds = 0 ;

HANDLE hFile = CreateFile ("D:\\Program Files\\revirgin\\tracer.dll",
GENERIC_READ | GENERIC_WRITE,
0,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL) ;

if (TouchFileTimes (hFile, &sys) == FALSE)
{
printf ("GetLastError= %d\n", GetLastError()) ;
}

That's all folks ...

Signed,
-- FoxThree

PS: Note the actual time does not matter; only the date... Also, include imagehlp.h and link against imagehlp.lib (only on Win2K)

Nice idea foxthree, but problem is still not solved as RV gets updated without change of version number and problem is still there, thus I found it easier to patch the exe.

I also now have the feelings that RV now a stranger behaviour. I can't follow if this depends on my particular config and progs installed, but when using latest RV I always get a cold reboot on XP when trying to trace some asp apps. That does not happen with 1.3.

Also on ME I always get a protection fault of the traced app.

I wonder if I'm the only one having such problems.

Hiya Stone():

Mmmmm....

/me thinks some bug in 1.4 Beta...

See, when I first started unpacking ASPR targets, I started with a standard soft that has no "tricks"... plain simple ASPR. With 1.3, I run the tracer and whoa, get the OEP in seconds.

But with 1.4 beta, I run trace with the exact same params on the same OS (Win2K) and whoa it jums to some 0x7XXXXXXX address and the apps just shows up. It looks as though the tracer lost control along the way.

I've raised the bug by email to +Tsehp along with the target details but yet to hear from him. +Tsehp, did you receive my earlier email or do I need to resend it?

This may *not* be related to what you face Stone(), but there is some similarity here. Hmmm, just wanted to say 1.4 Beta *may* be buggy. So, use it with care

Signed,
-- FoxThree

Regretfully have to agree, had to go back to 1.3.

With tracer I mean the tracer to resolve the imports.

I just can get some on W2K to resolve (always the same are missing RegisterWindowMessageA, GetVersion, etc.) thus it's fairly easy to manually edit them.

On some asp apps I even don't get nothing when inserting the OEP (like CustomizerXP, VoptXP, Reg Organizer, etc.).

Version 1.3 resolving Reget 118 ok, 9 or 10 not resolved, tracer
get's some more, after that RV has to be killed as it doesn't close

Version 1.4 resolving Reget 118, run the tracer on the 1st not resolved import: Cold Reboot!

So let's wait for +Tsehp, until then Olly does the trick

Hi Stone():

RV needs to be killed is pretty common. I mean this was there. The way to avoid this is to uncheck the show IAT referres while resolving. This way RV does not find the Refs counts of each API. If this option is checked, after resolving RV takes sometime (CPU 100%) to find the API Ref count to point out bogus APIs to the user! [Something like show suspect in ImpRec].

So, uncheck it and everything is fine. Others may be "genuine" bugs

Signed,
-- FoxThree