[Bug 26284] Crysis 2 demo needs msvcr90.dll._snscanf (purist)

http://bugs.winehq.org/show_bug.cgi?id=26284

--- Comment #5 from Anastasius Focht  2011-03-03 02:54:52 CST ---
Hello,

--- quote ---
CrySystem.dll just gave me a bunch of ordinal addresses, not proper imports...
--- quote ---

Hmm ok, I took a look at it. The demo is a whopping 1.5 GiB download :|
As suspected these PE files are wrapped with some custom protection (PEid tools
don't reveal a known protection).

After installation you start the demo with msvcr90 set to Wine builtin.

--- snip ---
~/.wine/drive_c/Program Files/Electronic Arts/Crytek/Crysis 2 Demo/bin32$
WINEDEBUG=+loaddll,+process WINEDLLOVERRIDES="msvcr90=b" wine ./Crysis2Demo.exe

...
wine: Call from 0x7b838547 to unimplemented function msvcr90.dll._snscanf,
aborting
trace:loaddll:load_builtin_dll Loaded L"C:\windows\system32\faultrep.dll" at
0x6af60000: builtin
fixme:faultrep:ReportFault 0x32df34 0x0 stub
trace:loaddll:free_modref Unloaded module
L"C:\windows\system32\faultrep.dll" : builtin
--- snip ---

Fortunately due to fault reporting stub, the process is left in zombie state 
;-)
At this point attach using Imprec, select the process and then "pick dll" ->
"crysystem.dll" (it has a default load base of 0x10000000).
You need to fix the OEP offset to some sane value, e.g. 0x1000 (original one
points to protector code).
After that do "IAT auto search". It finds a possible IAT in dynamic memory.

--- snip ---
...
->> Module selected: c:\program files\electronic arts\crytek\crysis 2
demo\bin32\crysystem.dll
Image Base:10000000 Size:010BB000
Original IAT RVA found at: 002BA2E0 in Section RVA: 002BA000 Size:0003C000
--- snip ---

Use "get imports" to retrieve the table.

--- snip ---
IAT read successfully.
...
Current imports:
A (decimal:10) valid module(s) (added: +A (decimal:+10))
171 (decimal:369) imported function(s). (added: +171 (decimal:+369))
--- snip ---

If you look at the list you notice some nodes are marked "valid:NO".
Collapse these.
The 4th node is the one with msvcr90.dll imports we are interested in.
The tool treats the memory location like the original bound IAT - the imports
are grouped by dll and separated by NULL IAT entries.

You can use the "Show Invalid" feature to highlight thunks that the tools
treats as suspect.
Basically the tool expects a NULL IAT entry (like original bound IAT) between
groups of functions belonging to different imported modules.

Because some of the imports are forwarded ones (kernel32.dll -> ntdll.dll,
msvcr90.dll -> msvcrt.dll and the like) they are resolved at this point.
The tool doesn't know the original non-resolved forwards and treats it as
"suspect".

Select the first import that has a different dll name within the thunk group.
For example: there is a single msvcrt.dll _strcmpi import in between the all
msvcr90.dll imports.
Double click it. Select "msvcr90.dll" as module and "_stricmp" (which is the
original import).
Now the node state changes to "valid" -> all imports from this module are
correctly resolved.
You could fix the other remaining entries (kernel32/ntdll) in same manner if
you like but we only interested in msvcrt90 imports.
Just do a quick cut/delete thunk for the remaining ones (right click on first
suspect one and cut). NOTE: this renders the executable unsuable at runtime but
we only want to rebuild PE header for running the "mscodescan.pl" tool.

Keep Imprec running and dump the dll using LordPE. Fire the tool up and select
the correct process.
Right click on desired dll and "dump full". This creates a large (17 MiB)
"dumped.dll" file on disk as raw dump.
Go back to "Imprec" and select "Fix dump", select the file "dumped.dll"
previously created by LordPE.

Now a "dumped_.dll" is created on disk with a new PE header written (additional
section for rebuilt IAT got appended).
NOTE: this PE binary is not runnable at all due to shortcuts previously taken
(some IAT thunks cut/deleted, original entry point still points to wrong
location, section header flags ...).

Now run "mscodescan.pl" again and voila:

./dumped_.dll imports following stub symbols:
  msvcr90:_snscanf

Looks like we got lucky and its really the only one needed here ;-)

Regards