http://bugs.winehq.org/show_bug.cgi?id=25853
Summary: Dead Space 2 digital download installer crashes on start Product: Wine Version: 1.3.11 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: NightNord@gmail.com
Created an attachment (id=32945) --> (http://bugs.winehq.org/attachment.cgi?id=32945) Default deadspace_f_activation.exe log
While game itself isn't released, if you'd preordered it from EA Store, it's possible to download installer.
While trying to launch installer, it's launching "activation.exe", that unpacks itself into C:\users\Temp\mtka_tmp and runs deadspace_f_activation, that crashes (log attached).
It's almost definite, that SecuROM is somehow involved in process, as there is a bunch of SecuROM files and dlls request in WINEDEBUG=+warn, and there is secupacker_launcher.exe, but, probably, crash caused by something else.
It should be runnable before release date, I'm sure, as language files contents strings of "too early" messages and there is "Release Date Check" procedure.
Before closing, it told me, that "To finish activation process, you must have Administrative privileges" (or something like that, translated from Russian)
No tweaks and no additional software installed - pure ~/.wine prefix. Log produced from launching only deadspace_f_activation.exe - otherwise debugger can't produce backtrace.
Kernel: 2.6.37 wine: 1.3.11
http://bugs.winehq.org/show_bug.cgi?id=25853
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #32945|application/octet-stream |text/plain mime type| | Attachment #32945|deadspace_f_activation.exe. |deadspace_f_activation.txt filename|log |
http://bugs.winehq.org/show_bug.cgi?id=25853
Javier Kohen jkohen@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jkohen@users.sourceforge.ne | |t
--- Comment #1 from Javier Kohen jkohen@users.sourceforge.net 2011-01-23 08:01:37 CST --- I think this is a duplicate of 25690.
http://bugs.winehq.org/show_bug.cgi?id=25853
--- Comment #2 from Night Nord NightNord@gmail.com 2011-01-23 09:11:44 CST --- Maybe, I'll check patch from #25690
http://bugs.winehq.org/show_bug.cgi?id=25853
--- Comment #3 from Night Nord NightNord@gmail.com 2011-01-23 12:03:16 CST --- No, patch doesn't fix this issue. Symptoms are different, also. In this case program really crash.
http://bugs.winehq.org/show_bug.cgi?id=25853
--- Comment #4 from Night Nord NightNord@gmail.com 2011-01-24 11:23:33 CST --- Created an attachment (id=32978) --> (http://bugs.winehq.org/attachment.cgi?id=32978) Default deadspace_f_activation.log on non-fglrx system
Just to be sure that no one will see 'fglrx' in backtrace and say 'Hey, that's your broken driver!', I'm attaching log from OSS radeon drivers.
BTW, I understand, that this is, probably, not enough for solving this problem, but I really don't know what WINEDEBUG flags are helpful in this case.
http://bugs.winehq.org/show_bug.cgi?id=25853
--- Comment #5 from Night Nord NightNord@gmail.com 2011-01-25 13:43:01 CST --- Created an attachment (id=32990) --> (http://bugs.winehq.org/attachment.cgi?id=32990) Last 2000 lines of +relay deadspace_f_activation.relay.log
You may see that crash is after 0022:Call KERNEL32.GetProcAddress(7ed50000,1048b8d0 "FT_Thunk") ret=10350330 0022:Ret KERNEL32.GetProcAddress() retval=00000000 ret=10350330 as far as I could understand, that means that program just doesn't check for error and trying to call returned NULL.
Could it be because FT_Thunk is -private?
http://bugs.winehq.org/show_bug.cgi?id=25853
--- Comment #6 from Night Nord NightNord@gmail.com 2011-01-25 15:25:19 CST --- Well, ok, that's not about FT_Thunk, just another check. Guessing from ret= value from last IsBadCodePtr call before crash, it had returned to some kind of checks-run function. But strange, that UnhandledExceptionFilter() returned NULL, while it was given non-NULL value just few lines above. Is it normal?
http://bugs.winehq.org/show_bug.cgi?id=25853
Javier Kohen jkohen@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|jkohen@users.sourceforge.ne | |t |
http://bugs.winehq.org/show_bug.cgi?id=25853
Night Nord NightNord@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |ftp://ftp.niifaq.ru/deadspa | |ce2.exe
--- Comment #7 from Night Nord NightNord@gmail.com 2011-01-27 13:11:12 CST --- Well, I guess my own investigations will go to nothing, so I'll stop spamming bugzilla with this messages.
I've figured out that installer could be used in means of activation without data files, so I'm posting it on my ftp (it has extremely bad connection, so it could be unavailable, but it will go back in few minutes), in case anyone interested. It's compressed by itself, so compressing it further doesn't make any sense, so I'm publishing it as-is.
It contains all activation utilities and unpacks them to drive_c/users/<username>/Temp/mtka_tmp, that contains, among other files, deadspace_f_activation.exe, dfa.dll and copy of installer.
I've tried to disassemble deadspace_f_activation.exe with objdump, but it failed. Maybe it was damaged during unpack procedure, I don't know.
As installer doesn't contain any real game-data, I don't think, that publishing it will lead to some problems, if anyone wonders about this.
http://bugs.winehq.org/show_bug.cgi?id=25853
Night Nord NightNord@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Dead Space 2 digital |Dead Space 2 with SecuROM |download installer crashes |protection crashes on start |on start |
http://bugs.winehq.org/show_bug.cgi?id=25853
--- Comment #8 from Night Nord NightNord@gmail.com 2011-01-29 12:33:20 CST --- I'm sorry for my mistake - this is not 'installer', but the game itself. This crash could be worked around by using No-DVD for retail game version.
http://bugs.winehq.org/show_bug.cgi?id=25853
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com
--- Comment #9 from Dan Kegel dank@kegel.com 2011-02-04 16:09:16 CST --- I see this too with the retail dvd.
http://bugs.winehq.org/show_bug.cgi?id=25853
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |obfuscation Status|UNCONFIRMED |NEW CC| |focht@gmx.net Summary|Dead Space 2 with SecuROM |Dead Space 2 crashes on |protection crashes on start |start (SecuROM Data File | |Activation 2.x/SecuROM SLL | |1.x - Release Date | |Verification) Ever Confirmed|0 |1
--- Comment #10 from Anastasius Focht focht@gmx.net 2011-06-13 04:09:29 CDT --- Hello,
some info (not an in-depth analysis): "RYG News: Analysing SecuROM In Dead Space 2" -> http://reclaimyourgame.com/content/739-RYG-News-Analysing-SecuROM-In-Dead-Sp...
--- snip --- -=[ ProtectionID v0.6.4.0 JULY]=- (c) 2003-2010 CDKiLLER & TippeX Build 07/08/10-17:57:05 Ready...
Scanning -> H:.wine\drive_c\Program Files\EA Games\ds2_temp_unpacked\deadspace_f_activation.exe File Type : 32-Bit Exe (Subsystem : Win GUI / 2), Size : 7570776 (0738558h) Byte(s) -> File Appears to be Digitally Signed @ Offset 0737000h, size : 01558h / 05464 byte(s) [File Heuristics] -> Flag : 00000000000000000000000000000101 (0x00000005) [!] SecuROM Detected - Version 07.42.0001 [!] Possible CD/DVD-Key or Serial Check -> Invalid serial [CompilerDetect] -> Visual C++ 7.1 (Visual Studio 2003) - Scan Took : 0.389 Second(s)
Scanning -> H:.wine\drive_c\Program Files\EA Games\ds2_temp_unpacked\DFA.dll File Type : 32-Bit Dll (Subsystem : Win GUI / 2), Size : 6280680 (05FD5E8h) Byte(s) -> File Appears to be Digitally Signed @ Offset 05FC088h, size : 01560h / 05472 byte(s) -> File has 136 (088h) bytes of appended data starting at offset 05FC000h [File Heuristics] -> Flag : 00000000000000000001000000000111 (0x00001007) [!] SecuROM SLL v 1.6.1 Protected (For SecuROM v 7.42.1) [i] SecuROM Data File Activation Core Module - version 2.2.0 [CompilerDetect] -> Visual C++ 7.1 (Visual Studio 2003) - Scan Took : 0.281 Second(s) --- snip ---
--- quote --- Well, ok, that's not about FT_Thunk, just another check. --- quote ---
The FT_Thunk check is just part of SecuROM prerequisite code which is to determine exact OS version. It is executed before every in-depth security check because the checks are tailored to specific Windows versions.
--- quote --- But strange, that UnhandledExceptionFilter() returned NULL, while it was given non-NULL value just few lines above. Is it normal? --- quote ---
The SEH chain has already been populated at this point and no handler felt responsible so it's ok to bail and pass this unexpected failure to OS crash handler (hence EXCEPTION_CONTINUE_SEARCH).
It seems the crash is located in some kind of obfuscation wrapper for API calls (stack is specially prepared). I've seen this somewhere but can't remember ... maybe I'll look into that later in detail. The problem is if you don't know which API it is be called in the end, you miss essential information to determine where things started to go wrong (these wrappers are pure obfuscated code).
Regards
http://bugs.winehq.org/show_bug.cgi?id=25853
--- Comment #11 from Anastasius Focht focht@gmx.net 2011-06-13 12:24:24 CDT --- Hello,
well I got a bit further but are being hampered by Wine's context restoration code :| It might be related to the actual problem ...
The obfuscation code chunks access the thread stack not only by explicitly reserving space, e.g. "lea esp,[esp-xx]", "sub esp,xx" ... but directly, e.g: "mov ss:[esp-xx], reg" above the current top of stack without adjusting esp at all. Some branch instructions are done in that way too: "jmp dword ptr ss:[esp-xx]"
The problem is the way Wine restores the context from return of exception handling (... -> RtlRaiseException -> __wine_call_from_regs) for instance when single stepping through the target code.
If you keep an eye of the memory area directly above current top of thread stack you can spot values for cs:eip/eflags and ds being written to the stack before the context return (the selector values are easily to spot). You could also place some watchpoint (hw breakpoint on write access) above top of stack to see it trigger when single stepping.
This context return code overwrites values that used to be "invisible" (previous calls scratch area, future locals, whatever). Also values used by direct "[esp-xx]" addressing without adjusting esp at all are affected.
Another problem arises if code reserves a chunk from top of stack (using sub esp,xx). Now these values are within local stack area and become "visible". If the code doesn't fully initialize the stack it sees these values and might get it wrong.
In Windows, the memory neighbouring the current thread stack top is not touched when single stepping/handling exceptions due to different technical architecture. There is a ring switch so "iretd" can fully restore ss:esp while Wine needs to manually restore frame without a ring switch.
The code responsible for this behaviour (emitted __wine_call_from_regs):
http://source.winehq.org/git/wine.git/blob/bea2be5ccebba363b69e8186a102c8bbe...
I don't know a different solution offhand to fully restore the frame without touching memory neighbouring stack top. Maybe Alexandre comes up with a clever idea ...
Regards
http://bugs.winehq.org/show_bug.cgi?id=25853
jhgf bernhardloos@googlemail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bernhardloos@googlemail.com
--- Comment #12 from jhgf bernhardloos@googlemail.com 2011-08-15 13:53:51 CDT --- a bug for the debugging problem mentioned by Anastasius Focht: http://bugs.winehq.org/show_bug.cgi?id=28089
http://bugs.winehq.org/show_bug.cgi?id=25853
--- Comment #13 from jhgf bernhardloos@googlemail.com 2011-08-15 16:10:45 CDT --- try this: http://bugs2.winehq.org/attachment.cgi?id=35972
(from bug #27326
http://bugs.winehq.org/show_bug.cgi?id=25853
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download Status|NEW |RESOLVED Component|-unknown |ntdll Resolution| |DUPLICATE
--- Comment #14 from Anastasius Focht focht@gmx.net 2011-10-14 14:01:11 CDT --- Hello,
--- quote --- try this: http://bugs2.winehq.org/attachment.cgi?id=35972
(from bug #27326) --- quote ---
yep, commit b8629f55f1e5ca827b7708283652d9288b9be288 fixed this bug too. Thanks Bernhard.
Release date verification and activation over Internet works. Though the game itself crashes later but this seems not a copy protection issue.
I'll mark this as dupe.
$ wine --version wine-1.3.30-108-gb80b8f5
Regards
*** This bug has been marked as a duplicate of bug 27326 ***
http://bugs.winehq.org/show_bug.cgi?id=25853
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #15 from Austin English austinenglish@gmail.com 2011-10-17 16:06:42 CDT --- Closing.
-
wine-bugs＠winehq.org