LoadLibrary: Support For Loading Windows DLLs On Linux

[Weasel]

While we're at it, the Windows OS kernel should replace the Linux kernel, and lets use NTFS by default as well. Brilliant!

Nah, just as DLLs are much more superior to ELF, so is the Linux kernel superior to the Windows kernel.

[Weasel]

The joke is on you. ELF supports local ("private") symbols just fine. On the other hand, DLLs do not have symbol versioning, so you end up having to provide multiple library versions (the WinSxS dance).

It's not about it supporting local symbols, it's about it supporting global symbols. Every library and its mom uses global symbols, except a select few (glibc is sane, for example). The important thing is to remove support for global symbols completely so that they cannot use it. Period.

Of course that's not gonna happen, because already-compiled apps expect global symbols. That's why migration to DLLs is more likely. At least new apps are forced to be sane in that regard, and ELF will only remain a relic of backwards compatibility with its global symbol shit.

In short: LD_PRELOAD should never work to replace a symbol by loading another library first. If it does work, it means the symbol is global and not associated with a given library. That's how you know it is a global symbol and thus a horrible, horrible thing.

And anyway you don't need symbol versioning, you can just export different names yourself. Windows does it with its own API, like CreateWindow -> CreateWindowEx, and so on. Really not hard.

[Weasel]

I believe the original term is "dll hell".

That's the 16-bit Windows term, and it's not "original". Nobody is talking about 16-bit DLLs here.

Please educate yourself before mindless hate: https://en.wikipedia.org/wiki/DLL_Hell

Original: https://en.wikipedia.org/wiki/Dependency_hell

[Remdul]

That's the 16-bit Windows term, and it's not "original". Nobody is talking about 16-bit DLLs here.

The phrase 'DLL hell' certainly isn't limited to 16-bit but applies to n-bit DLLs alike.

[kpedersen]

I am assuming it would be good for reverse engineering?

I used to use this in the past: http://www.ollydbg.de/Loaddll.htm
It allows for a better knowledge of what the hell a binary is doing than static analysis.

So possibly with LoadLibrary I could strip out DRM from Windows software from the safety of Linux and Radare2? Possibly still a little bit more awkward than just doing it on Windows itself for testing but nonetheless, Nice!

[ferry]

That's the 16-bit Windows term, and it's not "original". Nobody is talking about 16-bit DLLs here.

Please educate yourself before mindless hate: https://en.wikipedia.org/wiki/DLL_Hell

Original: https://en.wikipedia.org/wiki/Dependency_hell

Whatever you say Sir. Now go check https://en.wikipedia.org/wiki/Dependency_hell for the references at the bottom and see on which platform this problem appeared first.

I must be a lot older then you, unless you also have seen Windows 2.1 running on real hardware.

No matter the platform, hell arises from a lack of discipline from the library writers, who should make sure the latest revision is backwards compatible with all earlier ones.
Of course on windows the problem is worsened because in general no sources of libraries are public and users of a library tend to work around bugs instead of making the library publisher fix them (Crystal Reports comes to mind). So when some application installs an updated library with a fix, the earlier installed application breaks.

[oiaohm]

It's not about it supporting local symbols, it's about it supporting global symbols. Every library and its mom uses global symbols, except a select few (glibc is sane, for example). The important thing is to remove support for global symbols completely so that they cannot use it. Period.

Really its not ELF exactly blame. Glibc loader and historic optimisations to the loader to save on memory. There is such things as platforms that use PE format that use global symbols they just have a special library name GLOBAL.

You really need to look at the work by Collabora in combination with Valve https://gitlab.collabora.com/vivek/libcapsule. Yes Segregated dynamic linking works with elf. Libcapsule shows you could do a ELF loader with a unique global symbols per loaded .so file so not global symbols any more.

Of course that's not gonna happen, because already-compiled apps expect global symbols.

Is this basic idea true. So far everything Valve and Collabora have tested Linux native with Segragated dynamic linking that takes away application wide global symbols does not care wide global symbols are there or not at application or libraries as long as they exist as local global symbols(as in global only to the .so /main executable So a global symbol in the main executable does not need to appear in .so symbol table in most cases) everything is good. Now ld preload missing has made some forms of application debugging trickier that appears to be the only price for 99.99 of cases if the glibc provided loader swap to segragated dynamic linking by default.

I guess this is a surprise to you. That a majority of Linux elf based applications really don't expect global symbols crossing the dynamic link boundaries this is part of the reason why running legacy applications with newer libraries explode so badly. Valve got serous due to having lots of really old Linux binaries they want to run to pay a party to properly investigate this that there is a logic error here.

The elf format does not say global symbols when dynamic loading have to propagate most applications developer don't code expecting propagation why if you look .so and so you will basically see all called functions be attended to come from all listed .so files. Its be a historic dynamic loader choice on Linux/Unix to propagate global symbols across dynamic link boundaries. Valve/Collabora work here is interesting that a optional feature is on that really does not have to be.

Yes Weasel the reality is you could change ld-linux.so to Segregated dynamic linking always and majority of end users would not even notice because the number of applications that depend on global symbols being global is insanely low. What would be the cost of doing this. Slightly higher memory usage because instead of having 1 global look up table you would have a look up table per .so and per application loaded and ld preload would not work any more.

Remember the elf system is designed to have more than 1 dynamic loader so you could keep a dynamic loader that has a global symbol table for the handful of applications that depend on it.

So the arguement that need to move to PE to fix this has no base in reality. The problem is fixable by changing the loader for dynamic ELF files with the majority of existing applications not giving a rats one way or the other.

[theriddick]

I ponder if this could somehow help remap windows anticheat software to function with native Linux versions of said software (proton). (apparently battleye and EAC have Linux versions). Seems like Steam/Valve should look into that!!!!!

[Spacefish]

Well why not, i personally cross compile windows software on linux just because all the build pipeline steps run faster on linux than on windows and it´s much easier to do things like overlayfs, containers and so on..
Software Devs prefer the Linux Userland for a lot of things as it just offers a lot of tools you don´t get on windows per default..

Some things on windows are a pain in the A***, like UNC paths, .bat scripts, case insensitive file system (per default) or limited path length.

If you need a reproducable environment, containers like docker or kubernetes are nice, but they don´t really work on windows, yes there is docker for windows, but the "nano" image is multiple 100 MB and lacks almost everything you need to build something.

[ssokolow]

Really its not ELF exactly blame. Glibc loader and historic optimisations to the loader to save on memory. There is such things as platforms that use PE format that use global symbols they just have a special library name GLOBAL.

...and, given how much Linux development money comes from enterprise customers and the like, I expect that such a thing would become standard in "PE for Linux" to preserve the ability for sysops to tune arbitrary programs using tricks like swapping out the system allocator using LD_PRELOAD or LD_LIBRARY_PATH tricks.

(The designed purpose of having global symbols in ELF. Allowing reliable launch-time selection of dependencies.)