[Bug 11121] Night Watch crashes on startup (StarForce v3, loader: section SizeOfRawData vs. FileAlignment violation, zero padding of section remainder wipes out code executed at runtime)

WineHQ Bugzilla wine-bugs at winehq.org
Tue Nov 19 19:12:17 CST 2019


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

David Seward <bignintyfan at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bignintyfan at gmail.com

--- Comment #19 from David Seward <bignintyfan at gmail.com> ---
(In reply to Anastasius Focht from comment #18)
> Hello folks,
> 
> confirming, the game is protected with StarForce v3 and needs 'no-CD' patch
> to be useful at all.
> The initial crash (attachment from comment #14) is already covered by
> StarForce bug(s).
> 
> I'm making this bug about the crash of no-CD version which highlights a
> valid problem with Wine.
> 
> (msvcr71 and msvcp71 were forced to 'builtin' to give a bit more context)
> ---- snip---- 
> The game tries to load a (non-existing) savegame on startup and throws a C++
> exception for handling the error.
> The catch block is found and executed (dumps error message).
> 
> Next, some validation on the game state is done which fails because the
> savegame didn't restore a valid 'world' state.
> During that (failing) check the execution flow reaches an area which is
> zero-filled - hence the page fault at address 0x90a810.
> 
> I did an off-line analysis of the StarForce v3 protected binary
> (disassembly) and to my surprise I found valid opcodes at the location where
> the fault occurred.
> The code is located in '.idata' section of PE binary.
> Someone played dirty here and partially wiped out the section contents.
> 
> After firing up a debugger I quickly nailed it down ... at the time when the
> entry point was reached the opcodes were already wiped out.
> Code in '.sforce3' section had the same problem - wipe out at the end.
> 
> WINEDEBUG=+module,+virtual to the help ;-)
> 
> 
> The size of the initialized data on disk, in bytes. This value must be a
> multiple of the FileAlignment member of the IMAGE_OPTIONAL_HEADER structure.
> If this value is less than the VirtualSize member, the remainder of the
> section is filled with zeroes. If the section contains only uninitialized
> data, the member is zero.
> --- quote ---
> 
> '.idata at 0x90a000 off 50a000 size 224 virt 1000 flags e0000040'
> 
> VirtualSize = 0x1000
> SizeOfRawData = 0x224
> 
> Dumping the optional PE header with 'LordPE' gives some insight...
> 
> 
> The requirement 'SizeOfRawData = multiple of the FileAlignment' seems to be
> violated here.
> Maybe this is the reason why the Windows loader treats the section remainder
> differently in this case.
> 
> For testing I disabled the zero-padding of section remainder to next
> boundary when this requirement was not met:
> 
> http://source.winehq.org/git/wine.git/blob/
> e8eb781327457b39c3578f8f65167149939503d0:/dlls/ntdll/virtual.c#l1227
> 
> It made the game work ;-)
> 
> * intro movie/cutscenes.
> * main menu
> * gameplay (I played a bit - no crash)
> 
> $ sha1sum Night_Watch_DEMO_english.exe 
> du -sh 826a6318a016d86fab6172eab23b4a15b2b92f54  Night_Watch_DEMO_english.exe
> 
> $ du -sh Night_Watch_DEMO_english.exe 
> 458M	Night_Watch_DEMO_english.exe
> 
> $ wine --version
> wine-1.7.8-232-g3bad812
> 
> Regards

Wow, that's a lot of info! Are you able to test if this still occurs with a
newer version of Wine?

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.


More information about the wine-bugs mailing list