http://bugs.winehq.org/show_bug.cgi?id=10273
Summary: satisfy SafeDisc 2.x heuristic API analyzer by "adjusting" API exports/entry statistics of wine builtins Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: wine-kernel AssignedTo: wine-bugs@winehq.org ReportedBy: focht@gmx.net
Created an attachment (id=8924) --> (http://bugs.winehq.org/attachment.cgi?id=8924) Patch which should fix SafeDisc 2.x copy protection api analyzer issue
Hello,
if not interested in technical details goto (2) ;-)
I made this a separate bug report like http://bugs.winehq.org/show_bug.cgi?id=9925 (SafeDisc 1.x stopper) because SafeDisc has many flavors that differ in various technical ways and can't be discussed/handled in a single SafeDisc "metabug" like http://bugs.winehq.org/show_bug.cgi?id=219 SafeDisc Major version based separation allows better tracking of "completion" state (1.x/2.x/3.x/4.x).
----------- (1)
It took me a couple of days to get an idea what SafeDisc 2.x really does with the API exports and to find a way to cope with it... Various anti-debugging techniques and nasty runtime code obfuscation made this journey somewhat challenging.
Parts of SafeDisc 2.x analyze the API code of the following system libraries:
kernel32.dll (wine builtin) user32.dll (wine builtin) gdi32.dll (wine builtin) cdasdtst.dll (developer backdoor?)
The latter one is probably a "developer backdoor", used to verify their code/algorithms (not needed to be present).
For each of these libraries all named exports are taken into account. A number of API entry opcode sequences are read and used for statistical analysis (number depends on type of encountered opcodes).
From what I've seen there is some kind of "behavioural probability" of each API
entry calculated, with typical opcode sequences having a "weighting". Just think of advanced heuristic detection methods of antivirus scanners and you get the idea ;-).
Anyway, wine's builtin libraries differ in their signatures from windows entry code and to make things worse, wine's +relay/+snoop feature heavily interferes with the analyzer results. :-(
First I made some experiments with additional (dummy) function exports, small __asm__ wrappers with opcode sequences to see how the distribution of opcodes influences the analyzer results. The result was rather disappointing. I needed a large number of exports to gain some results but not significantly enough to get below the "bad" threshold.
Then I came across the magic "0" value. As soon as I used this value either as first .byte on API entry or init value for data export, the entry scan was short circuited. This value seemed to have the highest influence of all code/data sequences used. I added quite a number of data exports - aliased to initialized "0" value - safe enough to let even wine's +relay work (remember: relay code influences analyzer). If you look at the patch don't get mad ;-) You will see a crapload of named "__wine_safedisc2" data exports/aliases added to wine builtin kernel32, user32 and gdi32.
For the record: http://bugs.winehq.org/show_bug.cgi?id=9926 which talks about "problematic" gdi32 data exports (pfnPalette stuff) in SafeDisc 3.x. SafeDisc 2.x code triggers SEH upon exported function pointers too but this is gracefully handled. No harm at all. I wonder if this is really a problem in SafeDisc 3.x ...
I thought about other possible solutions but found no one easier to implement to prove my findings without hurting wine too much :-) Making wrappers of the whole kernel32, user32, gdi32 named exports API just to please the entry analyzer is not an option to me.
Another way could be the relocation of export table upon module loading, expanding it at runtime by adding the required number of "statistics fakers" (data exports with zero init). This requires modifying the ntdll loader .. though i'm not sure if this approach breaks other applications/braindamaged PE protection stuff which expect certain conditions to be met (tables present at specific sections/memory areas).
------------------------------ (2)
Well, take it as proof of concept. Play with it.
I tested my patch with a few SafeDisc 2.x games I have original media. No cracks/no-cd patches were used. Only official game patches were used.
Battlefield 1924 (1.6x) - SafeDisc 2.6/2.8 Road To Rome (BF1942 expansion) - SafeDisc 2.8 Battlefield Vietnam - SafeDisc 2.9
All of these work fine for me with the patch applied.
Please test this patch on many SafeDisc 2.x games as possible and report your results (works or works not). Make sure you have original media mounted and drive/data is visible within wine. If it fails for first time, the media might not ready yet, try again then (I experienced this sometimes).
Use this link to verify what SafeDisc Version is used: http://www.120search.net/ (alcohol software copy protection database)
Regards