[Bug 60541] New: Ubersoldier II crashes during startup - corrupted private copies of Wine code observed with bundled StarForce protection
http://bugs.winehq.org/show_bug.cgi?id=60541 Bug ID: 60541 Summary: Ubersoldier II crashes during startup - corrupted private copies of Wine code observed with bundled StarForce protection Product: Wine Version: 11.20 Hardware: x86-64 URL: https://store.steampowered.com/app/281410/UberSoldier_ II/ OS: Linux Status: NEW Keywords: obfuscation Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs@list.winehq.org Reporter: gyebro69@gmail.com Target Milestone: --- Distribution: ArchLinux Created attachment 82407 --> http://bugs.winehq.org/attachment.cgi?id=82407 Wine terminal output + Protection ID log Over the past 7 years, I've acquired 3 different versions of Ubersoldier II, 2 of which come from so-called DRM-free stores. I own the IndieGala, Steam, and Zoom Platform versions, and all three have the exact same issue when launched under Wine: the game crashes immediately upon launch. The startup failure also occurs with the legacy shared WoW64 build configuration. On Windows 11 in VirtualBox, the game reaches the menu properly. All three releases of the game retain the Starforce DRM mechanism (or remnants of it). This was initially verified using Protection ID and subsequently confirmed via AI-assisted analysis. To reproduce, launch xtend.exe from the installed game directory. The game crashes or exits before reaching the menu. The failure varies between runs: page faults, stack overflows and silent termination have all occurred. Investigation under Wine found that private executable copies of Wine function code contain altered instructions, including missing register assignments. In a captured unpatched run, the damaged allocator copy leads to an invalid memory access. This points to a compatibility problem involving the protection-associated code-copying machinery; it does not establish incorrect Wine heap API semantics. I set the affected Wine component to 'ntdll': the strongest evidence for this is the crash occurring in Wine's corrupted private copy of RtlAllocateHeap. This doesn't imply a faulty API implementation, it merely pinpoints the area most relevant to the compatibility issue under investigation. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=60541 --- Comment #1 from Béla Gyebrószki <gyebro69@gmail.com> --- Created attachment 82408 --> http://bugs.winehq.org/attachment.cgi?id=82408 The result of AI-assisted analysis For those interested, the attached file contains the results of the AI-assisted analysis: evidence of the unpatched crash, the faulty code rewriting, the window management error, and the results of the assembly workaround. An experimental Wine workaround using fixed i386 assembly entry stubs for RtlAllocateHeap, RtlSizeHeap, SystemParametersInfoA and NtdllDefWindowProc_A allows allows all 3 editions of the game to run, including gameplay and saving/loading. The four-entry version has also been tested successfully with both -O0 and -O2 builds. I'm not sharing the working patch created with AI assistance here due to Wine's Clean Room guidelines. I am using the patch locally for myself. The game runs stably with it, even during extended play sessions. I am also testing the patch with other games, and so far, I haven't encountered any issues. -- 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.
participants (1)
-
WineHQ Bugzilla