Is it possible to fix programs that run perfectly under WinMe/98 but return:

xxxxxxxx.exe is not a valid Win32 application

Under XP? I noticed this with unsecurom dumped files!

I have tried utils like PEditor 1.7 that has options to make EXE's NT/Win2k compatible, but no luck!

DrA.

Maybe try LaZaRuS's tool PE-Validator

Thanks, but have already tried about every possible util from protools to do with PE headers, some I just plain don't understand!

The only thing PE Validator said was wrong was 'SizeOfImage' but made no difference to it's execution!

Unsecurom does not run under NT/w2k/XP but has an asm source, so it could be recompiled by a more knowledgeable person to run under XP, but not by me!

Thanks for the suggestion, but looks like this is an excercise in futility!

DrA.

The headers in XP should be the same as in 2K. I cracked Diablo2 a while back and had to fix the header to work for Win2K and the same file now runs properly under XP as well. If the file isn't too big, perhaps attach it to a message here.

Yes, I unpacked Diablo II too. I didn't use an automatic unpacker. I never did on CD-copy-protections.

Then I replaced the sections in the original file with the unpacked ones and corrected IT and OEP. It worked.
Then I looked at the section's physical size and corrected it to the lowest 200h boundary I could find. It worked.
Then I deleted the three SecuROM sections. It worked.
Then I moved the PE header to 80h. It worked.
Then I removed any space in the exe which was not covered by the first 400h header bytes or by the sections. It worked.
Then I corrected the checksum. It worked.

I was sure that I had a Windows compatible file now.

Indeed, it worked on Win98, Win98SE, WinNT, WinME, Win2K. My friends were impressed and we played it all the night.

Two days after that one of my friends told me that he could not play in the internet any more and that the official updates wouldn't work.

Then why had he asked me to crack it even if I warned him that he won't be able to play in the internet any more. So compatibility is a aspect with more than one possibility.

Sorry to post things like this but it's the mood I'm in at the moment.

I hope I showed what points can be checked if a file won't run on NT systems.
Not only the checksum is important. Other possibiliities are a objects physical size, the location of the PE header, the header's size, parts between sections not belonging to them, how the file is aligned. Many more to say, these are the most common.

Hmmm...

Maybe it would be better if someone looked at unsecurom and saw why it creates files that don't work under XP! Mind you, the prog itself won't run under XP, unless you bypass the OS check now that I could do!

DrA.

LordCrass: a sample is here (http://www.gamecopyworld.com/cgi-bin/dl.cgi?cmr2_109!zip). This is unsecurom-ed CMR Rally 2 v1.09. I think that it has something wrong with sections but I don't know how to fix them yet - I'm just a learning newbie

Please no direct links to other pages outside the forum!

Hello VLuka !

I download the file and noticed two things:
1. The Import Table Pointer (PE+00D8h) points outside of the file.
2. The import table is not fully rebuilt, some API calls point to the addresses of the Win9? functions.

I couldn't test more since I haven't the game or the DLLs.

How did you determine points 1 & 2?

I have G-Rom's 'makepe' tool, that let's you rebuild the import table from a list of dll's, but couldn't get it to work! I have the original of Colin McRae 2 but can't even unwrap my original cos unsecurom won't work so used VLuka's link to try it out! He He!

Made a list of dll's the EXE imports but makepe chokes on the rebuild?

dlls:
msvcrt.dll
kernel32.dll
ddraw.dll
dsound.dll
dinput.dll
winmm.dll
user32.dll
advapi32.dll
gdi32.dll
ole32.dll
msacm32.dll
binkw32.dll

Even when something does work with this tool, the EXE comes out 4x bigger?

So how do I rebuild the import table and fix the Import Table pointer!

Damn newbies, eh!

DrA.

Ok, thanks for the reply. I've checked Import Table and tried to rebuild it and still no good. I'm searching now what else can it be

Hehe, yes, dumped's files by public version of UnSecurom (1.0) don't work under NT/2000/XP. This is due WinNT/2000/XP check if VirtualOffset of the sections are equal to VirtualOffset+VirtualSize of the previous section. Also check if SizeOfImage are equal to VirtualOffset+VirtualSize of the last section. ImportAdressTable(IAT) must be a valid address, but is not a necessary value, you can change to 0


Gadix[WKT!2001]

PD: checksum is not needed for exes

Hi f0dder !

I wasn't talking about the IAT (PE+0080h), but about the "Import Table Pointer (PE+00D8h)". This entry is not important for importing DLLs. When looking at it, it is '0' in most cases or points to the beginning of the OriginalFirstThunk.

I thought it might be possible that XP doesn't like any invalid pointers in a Win32 exe.

"SizeOfImage are equal to VirtualOffset+VirtualSize of the last section"?
I don't know about it when loading an .EXE, but it isn't important any more after the .EXE is loaded. Many unprotected programs have an '.data' section where this check doesn't apply, because the VirtualSize is bigger than the PhysicalSize. So there could be a PhysicalSize of 2000h and a VirtualSize of 58ACh and the following section starts at the next boundary. (Real example from a program working under WinNT/Win2K/WinXP).

Thanks for the info Gadix!

Will there ever be an XP friendly version of unsecurom 1.0 so I can redump my older games?

I grabbed a few PE docs to try to understand some of the structures, but alas, I have a long way to go, sniff! I'm totally lost!

Thanks for all the input, hope I haven't wasted anyones time!

DrA.

OK! Working with the Colin mcrae2 EXE that Vluka found, I did some more poking about in the header and found the SizeofImage is suspect!

From Gadix:



Last section of file is .rsrc (Virtual size= 1560h virtual address = 863000h, added together = 864560h) Size0fImage reported as 465000h!!

So last section is bigger! Do I need to alter SizeofImage to compensate!

DrA.

Ok, I have fixed CMR2 1.09. Here's what I've done:

- corrected VSizes to VSize(x) = VOffset(x+1) - VOffset(x)
- corrected last VSize to VSize(last) = SizeOfImage - VOffset(last)
- corrected .rdata flags to C0000040

Now it works under XP

Thanks for Your precious time. You're the best of the best (as said in R6)

He he, it took a while to understand that (x+1) meant the next sections offset, but having figured that out I fixed the sections with Procdumps PE editor (Sections Editor) and also set the data characteristic to C000000H.

.text vsize = 0010F000 (no change)
.rdata vsize = 00005000 (originally 0000421C)
.data vsize = 0034E000 (originally 0030F090)
.rsrc vsize = 00002000 (originally 00001560)

vsize(last) = Size0fImage (465000) - Last section Voffset (463000) = 2000

EXE now works

Thanks for the 'spoon feeding' lesson!

DrA.