[Bug 40800] New: Montezuma's Return crash on startup.

https://bugs.winehq.org/show_bug.cgi?id=40800

Bug ID: 40800
           Summary: Montezuma's Return crash on startup.
           Product: Wine
           Version: 1.9.12
          Hardware: x86
                OS: Linux
            Status: UNCONFIRMED
          Severity: blocker
          Priority: P2
         Component: -unknown
          Assignee: [e-mail]
          Reporter: [e-mail]
      Distribution: ---

Created attachment 54727
  --> https://bugs.winehq.org/attachment.cgi?id=54727
Output of wine 1.9.12 with WINEDEBUG=+relay,+tid

Montezuma's Return (VGA version, I'm not talking about the 3DFx version) crash
on startup.

I've launched the game on a clean win32 prefix, and set the windows version as
Windows 95. The game was released in 1998, but the game box states Windows 95
as recommended OS.

I've attached the output of wine with the flag WINEDEBUG=+relay,+tid.

[Bug 40800] Montezuma's Return crash on startup.

https://bugs.winehq.org/show_bug.cgi?id=40800

[e-mail] changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
       Distribution|---                         |ArchLinux

[Bug 40800] Montezuma's Return crash on startup.

https://bugs.winehq.org/show_bug.cgi?id=40800

Dmitry Timoshkov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|blocker                     |normal

--- Comment #1 from Dmitry Timoshkov  ---
Demo version of the game doesn't exhibit any problems. is it possible to share
the wine prefix with the installation for investigation?

[Bug 40800] Montezuma's Return crash on startup.

https://bugs.winehq.org/show_bug.cgi?id=40800

--- Comment #2 from [e-mail] ---
(In reply to Dmitry Timoshkov from comment #1)
> Demo version of the game doesn't exhibit any problems. is it possible to
> share
> the wine prefix with the installation for investigation?

Yes, I can, but you I don't know if this will be enough, as the game have a
copy-protection that checks for the original game disc.

I don't know if this a relevant information for this case, but the game is very
easy to crack using a simple debugger like Ollydbg. If I recall correctly, it's
just a matter of replacing a single JE or JNE instruction with a JMP.

I'll upload the wine prefix as soon as possible.

[Bug 40800] Montezuma's Return crash on startup.

https://bugs.winehq.org/show_bug.cgi?id=40800

--- Comment #3 from [e-mail] ---
(In reply to Dmitry Timoshkov from comment #1)
> Demo version of the game doesn't exhibit any problems. is it possible to
> share
> the wine prefix with the installation for investigation?

The wine prefix is available to download (for 30 days) here :
https://bfs.u-bordeaux.fr/telecharge.php?choix=files/99c73860111bf6c27d53207...

sha1sum montezuma-prefix.7z f5d25133dc4a2741b87941eadfbbbc60973a4d37

[Bug 40800] Montezuma's Return crash on startup.

https://bugs.winehq.org/show_bug.cgi?id=40800

Dmitry Timoshkov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #4 from Dmitry Timoshkov  ---
The application contains a custom imports resolver which gets called at
the start of the execution. Since the IAT (the imports table) has been
already processed by the PE loader custom imports resolver tries to access
the addresses calculated from the PE import thunks and that leads to an
access violation because the relative virtual addresses there have been
already replaced by real addresses of the imported APIs.

There is an interesting detail about the process: the application uses
ReadProcessMemory() in order to read the IAT before resolving its contents
(instead of a straight memcpy() or accessing the IAT directly in memory),
perhaps win9x returns original mapped PE file contents in that case, making
this technique work.

Probably it's possible to add a hack to ReadProcessMemory() to read
the mapped file contents in order to emulate win9x behaviour, but I'd
suggest to try writing a simple test app to confirm my theory first.

[Bug 40800] Montezuma's Return crash on startup.

https://bugs.winehq.org/show_bug.cgi?id=40800

--- Comment #5 from Dmitry Timoshkov  ---
It's worth to note that setting Windows 9x compatibility under Windows for
wmonte.exe doesn't help, and leads to a similar access violation exception
that happens under Wine, and a simple debugging session under Windows 7
shows that the IAT returned by ReadProcessMemory() also contains already
processed records. That means that Microsoft didn't bother to implement
such a hack in NT.

[Bug 40800] Montezuma's Return crash on startup.

https://bugs.winehq.org/show_bug.cgi?id=40800

--- Comment #6 from Dmitry Timoshkov  ---
(In reply to Dmitry Timoshkov from comment #4)
> The application contains a custom imports resolver which gets called at
> the start of the execution. Since the IAT (the imports table) has been
> already processed by the PE loader custom imports resolver tries to access
> the addresses calculated from the PE import thunks and that leads to an
> access violation because the relative virtual addresses there have been
> already replaced by real addresses of the imported APIs.
>
> There is an interesting detail about the process: the application uses
> ReadProcessMemory() in order to read the IAT before resolving its contents
> (instead of a straight memcpy() or accessing the IAT directly in memory),
> perhaps win9x returns original mapped PE file contents in that case, making
> this technique work.
>
> Probably it's possible to add a hack to ReadProcessMemory() to read
> the mapped file contents in order to emulate win9x behaviour, but I'd
> suggest to try writing a simple test app to confirm my theory first.

I've set up windows 98 in a virtualbox (a challenge these days) and ran
there a test application that dumps the IAT that was read either directly
or using ReadProcessMemory(). The test proved that my guess was wrong.

With the debugger and another test application I managed to figure out real
differences between win9x and NT PE loaders: win9x modifies the TimeDateStamp
and ForwarderChain in the IAT, while NT (and Wine) leave them intact. Simple
patch that sets these fields to 0xffffffff (meaning there is no forwards)
makes the application's custom PE imports resolver work. However now the app
crashes after it fetches the IDT (using sidt instruction) and tries to patch
it with its own data. I don't see how this could be solved.

Probably a WONTFIX.

[Bug 40800] Montezuma's Return crash on startup.

https://bugs.winehq.org/show_bug.cgi?id=40800

--- Comment #7 from Dmitry Timoshkov  ---
Since I was asked privately about the details here is a part of my answer
that may be useful for an interested person:

---
For an explanation and more details please have a look at the following
comment: https://bugs.winehq.org/show_bug.cgi?id=36023#c2

"Montezuma's Return" contains exactly the same snippet of code listed
in the comment above. It looks like that the game is also protected by
SafeDisc 1.x version which uses the 'sidt' trick under win9x.
---