Log in

View Full Version : Problem with exe files under win2k


hawk_dk
January 21st, 2001, 04:27
I've got a problem plz help.
I've manually unpacked a program packed with aspack,
when i run it under win 98 it works fine but when i run it in win2k i'm getting this error "the applocation failed to initialize properly (0xc0000005).click on ok to terminate the application.

plz help

tsehp
January 21st, 2001, 05:14
how did you unpacked in and on what system ?
you should also try to manually load it with sice symbol loader, just to
see if at loading all the exe's imports are resolved, some imports could only be valid on win 9x and not on win2k.

the pe header could also not be win2k compatible, use pe editor from yoda to correct it.

+Tsehp

McNy@Work
January 21st, 2001, 14:09
Quote:
+Tsehp (01-20-2001 18:14):
how did you unpacked in and on what system ?
you should also try to manually load it with sice symbol loader, just to
see if at loading all the exe's imports are resolved, some imports could only be valid on win 9x and not on win2k.
...
+Tsehp


Tsehp,
How did we know which of the exe's imports
are valid on win9x and not on win2k? can u give
an example ?
THanks aLOt 8-)

hawk_dk
January 21st, 2001, 15:08
when i run the program packed it works fine ,but when it's unpacked it only works on win 98 not my win2k it's packed with aspack

exit
January 26th, 2001, 03:07
You can use PE-Shield with parameter -r. I think it will repair your PE file.


Exit

The Owl
January 26th, 2001, 05:30
Quote:

I've manually unpacked a program packed with aspack,
when i run it under win 98 it works fine but when i run it in win2k i'm getting this error "the applocation failed to initialize properly (0xc0000005).click on ok to terminate the application.


the problem that plagues pretty much all imports rebuilders i've seen so far is that
certain system DLLs in both 9x and NT have exported APIs that have the same
RVA/VA. the problem with this is that *after* the IAT slots have been filled in by
the OS PE image loader (or PE wrapper, whoever happens to resolve the imports),
the one-to-one mapping between the imported API names (as found in the original
PE image) and the IAT slot contents is *gone* for good. any attempt to restore
API names from IAT slots will necessarily fail, what most schemes do is that they
simply resolve a given IAT slot value to the first API name (that resolves to the
given address) they find in a given DLL's export table - obviously it won't be the
correct guess all the time.

there are two ways to do this properly.

1. rebuild imports *before* this one-to-one mapping is destroyed, ie. before the
OS loader or the PE wrapper has performed the imports resolution. this requires
reverse engineering (of the various wrappers) and is not a generic method.

2. 'cure' the problem right at its root: make the colliding API addresses distinct by
changing the export tables of the DLLs in question and then use the existing tools
to reconstruct the imports from the IAT slots (this is the method icedump
implements since 6.021, although it does not work 100% yet - some win95
versions and also the tracer doesn't like it for some reason, the 6.022 release
will hopefully solve this problem).