http://bugs.winehq.org/show_bug.cgi?id=33159
Bug #: 33159 Summary: Loading of some copy-protected .dll Files is not working (i.e. activation.dll, awc.dll) Product: Wine Version: 1.5.25 Platform: x86-64 OS/Version: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: frank@ambertation.de Classification: Unclassified
Some .dll Files are packed and stripped of the relocation table in order to provide some level of protection against dissasemblers. Those files are commonly found in DRMed Software.
Trying to start Sim City (2013) in wine on OSX will give a "Activation.dll load failed" Error. Using WINEDEBUG=+map_image you will find the following line in the logs
4348.132:0009:warn:module:map_image Need to relocate module from 0x40000000 to 0x10d0000, but there are no relocation records
The same Application runs without problems on wine for linux.
On OSX the memory range 0x00075000-0x40075000 is reserved for WINE_DOS on startup. When the .dll is loaded, the call to wine_mmap_is_in_reserved_area will indicate that the base-addres of the library (0x40000000) is already reserved forcing it to relocate to another, free address range. Without the relocation table this is impossible and results in the above message.
http://bugs.winehq.org/show_bug.cgi?id=33159
--- Comment #1 from Alexandre Julliard julliard@winehq.org 2013-03-09 14:39:05 CST --- There's unfortunately no way to fix this except by implementing a preloader for OS X (you can of course change the reserved address but that's just moving the problem).
http://bugs.winehq.org/show_bug.cgi?id=33159
Frank frank@ambertation.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Loading of some |Loading of copy-protected |copy-protected .dll Files |.dll-files is not working |is not working (i.e. |(i.e. activation.dll, |activation.dll, awc.dll) |awc.dll)
http://bugs.winehq.org/show_bug.cgi?id=33159
--- Comment #2 from Frank frank@ambertation.de 2013-03-09 15:26:30 CST --- Thanks for the fast answer!
Do you by any chance know any links/whitepapers where I can get up to speed about the preloader stuff?
(In reply to comment #1)
There's unfortunately no way to fix this except by implementing a preloader for OS X (you can of course change the reserved address but that's just moving the problem).
http://bugs.winehq.org/show_bug.cgi?id=33159
--- Comment #3 from Frank frank@ambertation.de 2013-03-09 16:17:30 CST --- Created attachment 43874 --> http://bugs.winehq.org/attachment.cgi?id=43874 Possible fix for the "Activation.dll load failed" problem
This is a quick hack which changes the size of the reserved memory-range on a mac, allowing Activation.dll to load at the proposed base address without relocating.
Be advised that this is very "hacky" and not a clean solution...
http://bugs.winehq.org/show_bug.cgi?id=33159
Frank frank@ambertation.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Loading of copy-protected |[SimCity] Loading of |.dll-files is not working |copy-protected .dll-files |(i.e. activation.dll, |is not working (i.e. |awc.dll) |activation.dll, awc.dll)
http://bugs.winehq.org/show_bug.cgi?id=33159
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |loader
--- Comment #4 from Austin English austinenglish@gmail.com 2013-03-09 17:37:39 CST --- (In reply to comment #2)
Thanks for the fast answer!
Do you by any chance know any links/whitepapers where I can get up to speed about the preloader stuff?
There's some info at: http://www.winehq.org/docs/winedev-guide/x2800
http://bugs.winehq.org/show_bug.cgi?id=33159
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Component|loader |-unknown Summary|[SimCity] Loading of |Loading a .dll without |copy-protected .dll-files |relocations fails under Mac |is not working (i.e. |OS X (needs preloader) |activation.dll, awc.dll) | Ever Confirmed|0 |1
--- Comment #5 from Dmitry Timoshkov dmitry@baikal.ru 2013-03-09 23:31:40 CST --- This has nothing to do with copy protection.
http://bugs.winehq.org/show_bug.cgi?id=33159
--- Comment #6 from Frank frank@ambertation.de 2013-03-10 01:47:40 CST --- Really? I thought it would, since the .dll is described as "EA DRM Library" and PEId described the packer used as "EA Custom Protection"...
But it does not matter. The fact is that this problem exists because a library is missing its relocation table and has to be loaded to a fixed adress that is already reserved on the mac.
(In reply to comment #5)
This has nothing to do with copy protection.
http://bugs.winehq.org/show_bug.cgi?id=33159
--- Comment #7 from Austin English austinenglish@gmail.com 2013-03-10 05:33:35 CDT --- Dmitry,
Who did you remove the loader component?
http://bugs.winehq.org/show_bug.cgi?id=33159
thanoulas thanoulas@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |thanoulas@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=33159
--- Comment #8 from thanoulas thanoulas@gmail.com 2013-04-13 05:46:48 CDT --- Created attachment 44174 --> http://bugs.winehq.org/attachment.cgi?id=44174 +module,+virtual
I'm on OS X 10.8.3 and wine 1.5.28, I'm still getting the Activation.dll error. Using the patch provided here makes no difference.
I've attached a +module,+virtual log, sorry for the extra trace messages.
wine_mmap_is_in_reserved_area returns 0 in "static NTSTATUS map_view" function in dlls/ntdll/virtual.c which is ok after the patch, but ptr != base after wine_anon_mmap as the dll is mapped in 0x10f0000-0x11fd000 instead of 0x4000000
http://bugs.winehq.org/show_bug.cgi?id=33159
--- Comment #9 from Frank frank@ambertation.de 2013-04-13 06:23:48 CDT --- Do you compile with gcc or clang?
http://bugs.winehq.org/show_bug.cgi?id=33159
--- Comment #10 from thanoulas thanoulas@gmail.com 2013-04-13 06:32:54 CDT --- Compiled with xcode's default GCC 4.2 LLVM, I also have GCC 4.8 and clang, would compiling with either alternative make a difference?
http://bugs.winehq.org/show_bug.cgi?id=33159
--- Comment #11 from thanoulas thanoulas@gmail.com 2013-04-13 07:44:17 CDT --- Ok, built with clang and I no longer get the activation.dll message. I still randomly get it but rarely.
http://bugs.winehq.org/show_bug.cgi?id=33159
--- Comment #12 from Frank frank@ambertation.de 2013-04-14 02:55:16 CDT --- Good to know, so the gcc path is still wrong in that patch. Thanks for reporting. I'll try to work on the rel preloader once I have some time on my hand. :)
(In reply to comment #11)
Ok, built with clang and I no longer get the activation.dll message. I still randomly get it but rarely.
http://bugs.winehq.org/show_bug.cgi?id=33159
jre.winesim@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jre.winesim@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=33159
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |paulthetall@gmail.com
--- Comment #13 from Anastasius Focht focht@gmx.net --- *** Bug 36622 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=33159
--- Comment #14 from Paul The Tall paulthetall@gmail.com --- Please someone fix this issue. For Mac users this is a show stopper for many games.
https://bugs.winehq.org/show_bug.cgi?id=33159
Kurt kurtjaeke@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kurtjaeke@gmx.de
https://bugs.winehq.org/show_bug.cgi?id=33159
Ken Thomases ken@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ken@codeweavers.com
--- Comment #15 from Ken Thomases ken@codeweavers.com --- Here's my understanding of the issue:
* On OS X, Wine reserves the WINE_DOS area from 0x00001000 to 0x40001000 by defining a zero-fill segment in the loader executable. It also reserves the WINE_SHAREDHEAP area from 0x7f000000 to 0x82000000, but that's not particularly relevant in this case.
* The game's Activation.dll can only be loaded at 0x40000000 to 0x4010D000.
* It would not actually be a problem if the DLL's address range were completely inside Wine's reserved area nor completely outside it. The problem is that it straddles the boundary.
* The size of the WINE_DOS area was chosen somewhat arbitrarily. It could be adjusted to accommodate this particular DLL, but that is as likely to cause problems for other DLLs as fix them.
* On Linux, when running 32-bit Wine, the preloader reserves:
0x00000000 - 0x00010000 low 64K 0x00010000 - 0x00110000 DOS Area 0x00110000 - 0x68000000 low-memory area 0x7f000000 - 0x82000000 top-down allocations + shared heap + virtual heap
plus whatever address range the main executable needs to load into.
As you can see, this includes everything that's reserved on OS X and substantially more.
* The difference comes in because, when ntdll has finished loading and initializing the app, it calls virtual_release_address_space() and that unreserves much of that area on Linux but not OS X. (Things are somewhat different for large-address-space-aware apps.)
This can't be done on OS X because the reserved areas are "owned" by dyld, the dynamic loader. It wouldn't be a problem if these unreserved areas were used for loading a Windows-style DLL. But once they are unreserved, they could be used to load platform-native dynamic libraries. Since loading those is a job for dyld and it thought it already owned that memory and dedicated it to the segments of the main executable, it freaks out if a new library is loaded into that same address range.
---
I have looked into trying to find ways to convince the kernel and/or dyld to map the ranges we want reserved early in the process lifetime but leave them out of dyld's record-keeping so it wouldn't freak out if they later get used.
At one point, I thought of including an LC_SEGMENT_64 load command, that's normally only used in 64-bit images, in our 32-bit loader. At the time, it seemed that the kernel would map it but dyld would ignore it. However, both the kernel and dyld have tightened up their sanity checking, probably for security, and refuse to load such an executable.
Unfortunately, I think that it probably won't be feasible to implement a preloader on OS X, either. The kernel and dyld are fairly intimately intertwined. Loading an executable is a complicated process that's split between them. The source code for both is theoretically open, but I'm pretty sure that dyld's is incomplete. (For example, it seems to have some capability to load PE executables, but the code for that is not in the source base.)
Also, any preloader would have to do mmap() or mach_vm_allocate() calls to reserve the desired address ranges in a way that they could be subsequently released. On Linux, the preloader just uses a syscall to do the mmap() call. However, on OS X, the syscall interface is not the public interface and Apple does not commit to maintaining binary compatibility across versions of the OS. Instead, Apple states that the system library interfaces are the public and stable interfaces. But we need to reserve our address ranges before the system libraries are initialized because they will use those ranges if they get a chance. So, there's no good way to actually map/reserve the address ranges we want.
This inability to reliably use mmap() without loading the system library also defeats another scheme I had considered. I was thinking that we could craft a dynamic library that didn't link with _anything_ else. It would be the first library in the loader's dependencies. It would have an initializer function that would reserve the desired address ranges. That could theoretically be run before the initializers of the system library. Except it can't, because it would have to mmap() and that a) can't be done until after the system library is initialized, and b) would create a dependency on the system library that would force it to initialize first, anyway.
https://bugs.winehq.org/show_bug.cgi?id=33159
Terry wearenotamused@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wearenotamused@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=33159
Christopher Larson kergoth@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kergoth@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=33159
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
--- Comment #16 from Austin English austinenglish@gmail.com --- So, is this a WONTFIX or are there other options?
https://bugs.winehq.org/show_bug.cgi?id=33159
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |obfuscation
https://bugs.winehq.org/show_bug.cgi?id=33159
--- Comment #17 from Ken Thomases ken@codeweavers.com --- (In reply to Austin English from comment #16)
So, is this a WONTFIX or are there other options?
Just because I don't know how to fix doesn't mean that somebody smarter or more creative won't figure it out. Is there a problem with leaving it open?
https://bugs.winehq.org/show_bug.cgi?id=33159
--- Comment #18 from Austin English austinenglish@gmail.com --- (In reply to Ken Thomases from comment #17)
(In reply to Austin English from comment #16)
So, is this a WONTFIX or are there other options?
Just because I don't know how to fix doesn't mean that somebody smarter or more creative won't figure it out. Is there a problem with leaving it open?
Not as long as you hold out hope :)
https://bugs.winehq.org/show_bug.cgi?id=33159
Tobias silencshadow@posteo.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |silencshadow@posteo.de
--- Comment #19 from Tobias silencshadow@posteo.de --- (In reply to Austin English from comment #18)
(In reply to Ken Thomases from comment #17)
(In reply to Austin English from comment #16)
So, is this a WONTFIX or are there other options?
Just because I don't know how to fix doesn't mean that somebody smarter or more creative won't figure it out. Is there a problem with leaving it open?
Not as long as you hold out hope :)
Can anyone compile me a Wine with clang and the patch, or just upload a working Wine for Mac and Origin Games? I don't know how to compile and only got a little Macbook Air. Not much Harddrive ... I really want to play Command and Conquer 1 ... :)
regards
https://bugs.winehq.org/show_bug.cgi?id=33159
alexchandel@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alexchandel@gmail.com
--- Comment #20 from alexchandel@gmail.com --- The correct solution here is to shrink the size of the WINE_DOS area.
It's obviously causing problems with DLLs that want 0x40000000-0x4010D000. WINE_DOS uses 0x00001000-0x40001000: the change is SO small, and it would assuage thousands of users. (google "Sim City load failed", "Alice load failed", and "awc.dll load failed", and look at the pageviews to see how may users are punished by this bug).
Shrink the WINE_DOS segment to 0x00001000-0x40000000 (or 0x00001000-0x3fffffff inclusive, really) and let us move on.
Fix this issue now, and punt on the problem until it comes up again. And it may never come up again, or it may come up on a different platform.
https://bugs.winehq.org/show_bug.cgi?id=33159
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |loader
https://bugs.winehq.org/show_bug.cgi?id=33159
Gijs Vermeulen acescopezz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |acescopezz@gmail.com
--- Comment #21 from Gijs Vermeulen acescopezz@gmail.com --- This is still present in Wine 2.9 (and Staging). Is the patch in Comment 3 still correct?
https://bugs.winehq.org/show_bug.cgi?id=33159
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |STAGED CC| |dmitry@baikal.ru, | |erich.e.hoover@wine-staging | |.com, michael@fds-team.de, | |sebastian@fds-team.de Staged patchset| |https://github.com/wine-com | |pholio/wine-staging/tree/ma | |ster/patches/loader-OSX_Pre | |loader
https://bugs.winehq.org/show_bug.cgi?id=33159
--- Comment #22 from Sebastian Lackner sebastian@fds-team.de --- Starting with Wine Staging 2.10 we have added an experimental preloader implementation for macOS. So far we have only tested it on a small subset of macOS versions, so please give it a try and report any issues you encounter. If you use official Wine Staging builds, the preloader will be enabled by default.
----
Michael Müller has prepared various executables for testing purposes ( http://fds-team.de/~michael/osx-preloader-test.tar.gz ), which test specific functions of the preloader. The tarball provides the following testcases:
wine test-win.exe
A Windows executable without relocation information, which should fail to load without this patch. It simply prints "Success!" when everything is working as expected. When you give it a try, please also check that that there are no warnings related to the preloader (especially no failures to allocate reserved areas).
wine-preloader test-main wine64-preloader test-main64
MacOS binaries with LC_MAIN entrypoint. If everything works as expected, they will print "wine_main_preload_info not found", and afterwards dump the argv/envp and apple data arguments passed to the main() function.
wine-preloader test-unix wine64-preloader test-unix64
MacOS binaries with LC_UNIXTHREAD entrypoint. If everything works as expected, they will print "wine_main_preload_info not found", and afterwards dump the argv/envp and apple data arguments passed to the main() function.
----
If you encounter any issues with the preloader, and you want to disable it for testing purposes, you can simplify remove execute permissions of the file.
chmod -x wine-preloader chmod -x wine64-preloader
Please be aware that the introduction of the preloader also required other changes, so this will not necessarily give the same results as Wine compiled without the patchset.
https://bugs.winehq.org/show_bug.cgi?id=33159
--- Comment #23 from Sebastian Lackner sebastian@fds-team.de --- Thanks to everyone who provided feedback and helped to test it on more macOS versions. We believe that when using the latest patches, all compatibility issues have been resolved, and it should now work on all versions starting from macOS 10.6 up to the latest one. If you still encounter any issues, please let us know about it!
For all users of our WineHQ packages, we've decided to push an exceptional backport release (Wine Staging 2.10-3), which is available at the usual download locations - feel free to give it a try if the preloader included in the 2.10 release didn't work as expected.
https://bugs.winehq.org/show_bug.cgi?id=33159
tokktokk fdsfgs@krutt.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs@krutt.org
https://bugs.winehq.org/show_bug.cgi?id=33159
thedoctor45 thedoctor45@portingteam.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |thedoctor45@portingteam.com
--- Comment #24 from thedoctor45 thedoctor45@portingteam.com --- The preloader in Wine Staging 2.10+ crashed on OSX Leopard. Is there a way to compile wine without it?
https://bugs.winehq.org/show_bug.cgi?id=33159
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nerv@dawncrow.de Staged patchset|https://github.com/wine-com |https://github.com/wine-sta |pholio/wine-staging/tree/ma |ging/wine-staging/tree/mast |ster/patches/loader-OSX_Pre |er/patches/loader-OSX_Prelo |loader |ader
https://bugs.winehq.org/show_bug.cgi?id=33159
--- Comment #25 from Ken Thomases ken@codeweavers.com --- I have submitted a slightly modified version of the Staging patch to mainstream Wine: https://source.winehq.org/patches/data/154993
Thanks to Sebastian and Michael!
https://bugs.winehq.org/show_bug.cgi?id=33159
--- Comment #26 from Ken Thomases ken@codeweavers.com --- This should finally be working in mainline Wine as of https://source.winehq.org/git/wine.git/?a=commit;h=df8c5a37ecf236085de4f81a225ab06009ee46ec. Please retest.
https://bugs.winehq.org/show_bug.cgi?id=33159
Ken Thomases ken@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|STAGED |RESOLVED Resolution|--- |FIXED
https://bugs.winehq.org/show_bug.cgi?id=33159
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |df8c5a37ecf236085de4f81a225 | |ab06009ee46ec
https://bugs.winehq.org/show_bug.cgi?id=33159
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #27 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 5.1.