Wine Traffic #210 For 13 Feb 2004

WHAT'S NEW with Wine-20040213: (see ChangeLog for details)

• Improved support for screen resolution changes.
• More shell32 improvements.
• Several Winelib compatibility fixes.
• Beginnings of support for typelib creation.
• Lots of bug fixes.

Attached is a prototype of a technique we can use to solve the problems caused by exec-shield and prelink. Yes, it's complicated. I wish it wasn't, but simpler attempts at this haven't worked. I can't think of another way to do it, given my limited knowledge. It's possible Alexandre can figure something out, but as that hasn't happened yet here is my contribution.

This is not useful inside Wine. It's a prototype only - it requires a C99 compiler, the code is a mess, and all it shows is the loader app running "target" which just prints out the mappings. Some more work would be needed to turn this into a patch, but I don't know when I'll get time to do this, so here is my work for others to pick up the baton if they want to.

You can see if it's working by ensuring there is only one /dev/zero entry every time when exec-shield-randomize is on. When it is on, the output of "loader" should be different each time, use diff to see this. When exec-shield is off, there should be no differences.

Prelink has the same effect but the addresses are randomized in a cron job, not on every program load.

Don't worry if you don't fully understand this code, neither do I ;) It's some pretty hardcore voodoo, at least by my standards.....

Here is the README contained within:

Mike Hearn

• OK, so what is this? This is a prototype of some code that will allow us to solve the problems exec-shield and prelink are giving Wine. They stop us working because they randomize the load addresses of DSOs, so any linux libraries we link against might get dropped in the middle of the load area we need. This is Bad News. By default EXE files on Windows have their relocation records stripped (to save space). They must be loaded at 0x400000. Because an EXE is always the first thing into an address space, this is no problem. Unfortunately on Wine of course the EXE isn't the first thing into memory - Wine is. Basically, the problem is that the dynamic linker thinks we have a clear and empty address space. In fact we don't, we want a specific region reserved for later use. The dynamic linker (rtld or "elf interpreter") is the first thing that runs in a dynamically linked binary, so we have a problem. Wine doesn't get control until the damage is already done.
• How does it work?
  We have a stub binary, the preloader, which is statically linked. It gets control direct from the kernel, and the rtld isn't run.
  We mmap the PE load area, with the MAP_FIXED (so we grab the exact range of addresses we need) and MAP_NORESERVE (so we don't try and allocate the memory, which is what scuppered earlier attempts to fix the issue).
  That's the easy part. It's, what, 4 lines of code? Nothing. It's piffling. The hard part, which is what takes up the other 320 lines of code is restarting the standard boot process. We must do what the kernel would normally do - map in the target (wine-pthread/kthread), relocate the sections to the right place, set up the entry stack for the ELF interpreter and then jump into it in order to convert our static binary, into a dynamic one.
  Once we reach the other side of the dynamic linker rollercoaster, we can then unmap the load area and tada! we now have a space we can map PE binaries into.
  This works, for a simple target binary. Will it work once we start throwing more complex stuff (TLS initialization etc)? I just don't know. Only time will tell. I expect so, but there's no way to be 100% sure. This sort of stuff is simply not done anywhere else.
• Did you really write this all yourself?
  Nope, I was aided by the sources to ul_exec (BSD licensed): http://lists.netsys.com/pipermail/full-disclosure/2004-January/015143.html
  The rtld and kernel sources were valuable references but I didn't use any code from them.
• How portable is it?
  I only tested this on Linux. The problem only manifests itself on Linux - other UNIXy platforms don't have technologies like exec-shield (for security) or prelink (for speed), so it's not a problem there. It's possible they will develop them in future though, so portability is still a concern.
  In theory it's 100% portable. ELF is a standard, and even though it embedded asm and such, it should still work. MAP_NORESERVE *might* be a GNU extension, I'm not sure, but I don't think it is. We can't work reliably without this flag anyway so it's a moot point.

I have updated Darwine binary to version 1.06 and it is being released as a Developer Preview. It does not yet support the running of x86 exe's, however we are begging to work on this feature. The binary should be downloaded from either the home page link here

http://darwine.sourceforge.net/download.php

or the projects file release page here

http://sourceforge.net/project/showfiles.php?group_id=69890

to insure that the latest version is being used.

The binary requires Mac OS X 10.3 or higher and for the X11 SDK to be installed. The new installer checks for these before installs, fixes a numerous amount of bugs, including installation of default configuration that were present with the first release and now includes the wine headers.

Having a look at the documentation for the CP* functions on MSDN would be a good start.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/security/cpacquirecontext.asp

The next thing to do would be to write your own test program that works in Windows, and uses those functions. Maybe just start by encrypting a few bytes, then check they're encrypted right, then decrypting them again, and checking they come out to the right thing.

Once your test program works on Windows, run it in Wine, and start implementing FIXMEs.

It looks like the CryptXxxx functions are wrappers for each dll's CPXxxx functions... eg. ADVAPI32's CryptGenRandom() calls to the CPGenRandom() function in the crypt provider's DLL.

Perfect! We need a guy like you on the team, we're not that graphically inclined :)

There is no official list of things that need work. But you can try by reviewing what we already have in there, and see what needs love (I'm sure you'll find stuff < g >).

Here are the list of icons: (Please note that to get these you'll need to build wine. These resources are not includes "as is" in the code, rather they are hex encoded as text in resource files (.rc). The build process extracts them from there into the files listed below, via a tool of ours (tools/bin2res). If you modify these extracted files, this same tool can be later used to encode them back into the .rc files where they belong. Once there, you can just create a regular patch and send it over to wine-patches_at_winehq.org for inclusion into the tree)

./dlls/commdlg/cdrom.ico
./dlls/commdlg/floppy.ico
./dlls/commdlg/folder2.ico
./dlls/commdlg/folder.ico
./dlls/commdlg/hdisk.ico
./dlls/commdlg/network.ico
./dlls/commdlg/pd32_collate.ico
./dlls/commdlg/pd32_landscape.ico
./dlls/commdlg/pd32_nocollate.ico
./dlls/commdlg/pd32_portrait.ico
./dlls/shell32/desktop.ico
./dlls/shell32/document.ico
./dlls/shell32/drive.ico
./dlls/shell32/folder.ico
./dlls/shell32/folder_open.ico
./dlls/shell32/mycomputer.ico
./dlls/shell32/000.ico
./dlls/shell32/003.ico
./dlls/shell32/004.ico
./dlls/shell32/008.ico
./dlls/shell32/015.ico
./dlls/shell32/034.ico
./dlls/user/resources/oic_bang.ico
./dlls/user/resources/oic_hand.ico
./dlls/user/resources/oic_note.ico
./dlls/user/resources/oic_ques.ico
./dlls/user/resources/oic_sample.ico
./dlls/user/resources/oic_winlogo.ico
./dlls/user/oic_bang.ico
./dlls/user/oic_hand.ico
./dlls/user/oic_note.ico
./dlls/user/oic_ques.ico
./dlls/user/oic_sample.ico
./dlls/user/oic_winlogo.ico
./programs/cmdlgtst/about.ico
./programs/uninstaller/uninstaller.ico
./programs/wcmd/wcmd.ico
./programs/winefile/winefile.ico
./programs/winemine/winemine.ico

And the list of bitmaps:

./dlls/comctl32/idb_hist_large.bmp
./dlls/comctl32/idb_hist_small.bmp
./dlls/comctl32/idb_std_large.bmp
./dlls/comctl32/idb_view_large.bmp
./dlls/comctl32/idb_view_small.bmp
./dlls/commdlg/800.bmp
./dlls/commdlg/fontpics.bmp
./dlls/user/resources/obm_btncorners.bmp
./dlls/user/resources/obm_btsize.bmp
./dlls/user/resources/obm_check.bmp
./dlls/user/resources/obm_checkboxes.bmp
./dlls/user/resources/obm_close.bmp
./dlls/user/resources/obm_combo.bmp
./dlls/user/resources/obm_dnarrow.bmp
./dlls/user/resources/obm_dnarrowd.bmp
./dlls/user/resources/obm_dnarrowi.bmp
./dlls/user/resources/obm_lfarrow.bmp
./dlls/user/resources/obm_lfarrowd.bmp
./dlls/user/resources/obm_lfarrowi.bmp
./dlls/user/resources/obm_mnarrow.bmp
./dlls/user/resources/obm_old_close.bmp
./dlls/user/resources/obm_old_dnarrow.bmp
./dlls/user/resources/obm_old_lfarrow.bmp
./dlls/user/resources/obm_old_reduce.bmp
./dlls/user/resources/obm_old_restore.bmp
./dlls/user/resources/obm_old_rgarrow.bmp
./dlls/user/resources/obm_old_uparrow.bmp
./dlls/user/resources/obm_old_zoom.bmp
./dlls/user/resources/obm_reduce.bmp
./dlls/user/resources/obm_reduced.bmp
./dlls/user/resources/obm_restore.bmp
./dlls/user/resources/obm_restored.bmp
./dlls/user/resources/obm_rgarrow.bmp
./dlls/user/resources/obm_rgarrowd.bmp
./dlls/user/resources/obm_rgarrowi.bmp
./dlls/user/resources/obm_size.bmp
./dlls/user/resources/obm_trtype.bmp
./dlls/user/resources/obm_uparrow.bmp
./dlls/user/resources/obm_uparrowd.bmp
./dlls/user/resources/obm_uparrowi.bmp
./dlls/user/resources/obm_zoom.bmp
./dlls/user/resources/obm_zoomd.bmp
./dlls/user/obm_btncorners.bmp
./dlls/user/obm_btsize.bmp
./dlls/user/obm_check.bmp
./dlls/user/obm_checkboxes.bmp
./dlls/user/obm_close.bmp
./dlls/user/obm_combo.bmp
./dlls/user/obm_dnarrow.bmp
./dlls/user/obm_dnarrowd.bmp
./dlls/user/obm_dnarrowi.bmp
./dlls/user/obm_lfarrow.bmp
./dlls/user/obm_lfarrowd.bmp
./dlls/user/obm_lfarrowi.bmp
./dlls/user/obm_mnarrow.bmp
./dlls/user/obm_old_close.bmp
./dlls/user/obm_old_dnarrow.bmp
./dlls/user/obm_old_lfarrow.bmp
./dlls/user/obm_old_reduce.bmp
./dlls/user/obm_old_restore.bmp
./dlls/user/obm_old_rgarrow.bmp
./dlls/user/obm_old_uparrow.bmp
./dlls/user/obm_old_zoom.bmp
./dlls/user/obm_reduce.bmp
./dlls/user/obm_reduced.bmp
./dlls/user/obm_restore.bmp
./dlls/user/obm_restored.bmp
./dlls/user/obm_rgarrow.bmp
./dlls/user/obm_rgarrowd.bmp
./dlls/user/obm_rgarrowi.bmp
./dlls/user/obm_size.bmp
./dlls/user/obm_trtype.bmp
./dlls/user/obm_uparrow.bmp
./dlls/user/obm_uparrowd.bmp
./dlls/user/obm_uparrowi.bmp
./dlls/user/obm_zoom.bmp
./dlls/user/obm_zoomd.bmp
./programs/regedit/folder1.bmp
./programs/regedit/folder2.bmp
./programs/regedit/folder3.bmp
./programs/winecfg/idb_wine.bmp
./programs/winefile/drivebar.bmp
./programs/winefile/images.bmp
./programs/winefile/toolbar.bmp
./programs/winemine/faces.bmp
./programs/winemine/leds.bmp
./programs/winemine/mines.bmp

I find the following program to be an excellent test program for anything that acts like Windows. The program is Vast and may be downloaded from http://www-306.ibm.com/software/awdtools/smalltalk/. The program you want is the 6.0.2 fixpack which is also a fully operational evaluation version of Vast. It gives an evaluation notice on startup but is not disabled and has no timeout. The value of this program is that it runs on everything from Win 95 on and uses just about every feature in a Windows system. It is one of the best tests of system integrity I have been able to find. It almost installs and runs on Wine.