The Leading Linux Desktop Platform Issues Of 2018

[Weasel]

So was I what reads a library from disc and copies it into memory under Windows. Ntdll.dll.

No YOU said that you can live off without ANY imports, smartass. "Just with syscalls". YOU SAID IT. ntdll is not your savior, it is the contrary, sorry to burst your bubble.

Maybe next time think twice before opening your mouth if you don't want to embarrass yourself.

I have been talking about how desktop applications get loaded under Windows NT and comparing to Linux.

Problem is you say not services so you can ignore that Microsoft has done something as a subsystem service/library that is a userspace library on Linux.

What? The whole point was about functions like HeapAlloc always being "the same" on Windows, on any sane app, analogous to POSIX malloc/free. That's it.

Of course not services, is anyone even discussing systemd in this thread and the startup services? WTF is your point? Much less kernel modules.

Really Weasel when you stop being clueless on this topic you will wake you that you have been horribly wrong.

Says the moron who even used "AppInit DLLs" as an argument. So laughable.

Nt native subsystem flagged application can be a desktop application. Turns out its how some games do there anti cheat systems.

Take a closer look at chkdsk.exe on your windows partition. Yes there are applications that you use that are flag nt native subsystem. So yes they are some of the desktop applications provide by Microsoft and other parties.

How is chkdsk a desktop application?!? That's a system app. Who the fuck would package fsck on Linux as flatpak?!?? These things are part of the OS.

[oiaohm]

No YOU said that you can live off without ANY imports, smartass. "Just with syscalls". YOU SAID IT. ntdll is not your savior, it is the contrary, sorry to burst your bubble.

No you are pure incompetent. ntdll.dll is a nice NT oddity. Not only is it loaded in userspace it is also loaded in kernel space. When you syscall to load a library to call the kernel loaded ntdll.dll by syscall. If you load a .dll by any method that is recognised by the kernel you are using ntdll somewhere. You load a program that you see in your process list under Windows NT based operating systems you have also used ntdll somewhere. There is no other way to perform those registrations

So you don't need to import ntdll.dll when you can use the version of ntdll.dll already loaded by the kernel in kernel space.

Maybe next time think twice before opening your mouth if you don't want to embarrass yourself.
Applies to you more than me.

Says the moron who even used "AppInit DLLs" as an argument. So laughable.

LOL so incompetent that you did not get what I was referencing.

https://blogs.msdn.microsoft.com/oldnewthing/20071213-00/?p=24183

There are things about the way the Windows dynamic link loader works can go horribly south and this is due to subsystem extensions to ntdll. Lacking the means to intentionally start new link maps in user32 can fact makes Appinit Dll go south.

Yes start dlls(so) in elf equal to dllmain(init) is perfectly safe as long as you use dlopen yet loadlibrary from user32.dll dllmain is in fact playing with fire. If you are loading something that might have conflicting libraries that is what dlmopen is for.

But the tree of unique that you think you have under the kernel32.dll/user32.dll start falling in on you head once you start breaking a few rules. Rules Linux application don't have to obey.

There are ways you want you link maps processed and run. Failures in some of these areas leads you to the fact that ntdll is modified by subsystem setting badly.

There is a libraries you are not seeing fixing over ntdll.dll and Microsoft has never bothered fixing up ntdll.dll fully either. So Windows and Linux loaders are both broken. We don't want to copy exactly how Windows loader works. Get ideas yes. Copy no.

How is chkdsk a desktop application?!? That's a system app. Who the fuck would package fsck on Linux as flatpak?!?? These things are part of the OS.

It a easy to find application that is on the desktop using nt native to get clues what you can get upto.

Flatpak is designed not to give high privillage. Now this is another reason I don't exactly like snapcraft or appimage you can create root privillage applications as snap or appimage so they could contain fsck if someone decide to put like gparted inside them. Sorry your define of what is part of OS is not set in stone.

[oiaohm]

No it's not. -nostdlib is perfectly workable on Windows. A desktop application without a subsystem is completely worthless. Wouldn't be surprised if it's marked automatically by virus scanners as malware, but sure, let's argue over pointless crap.

No it not. As you said kernel32.dll and the like are still loaded into your program address space until you change subsystem to nt native. nt native is still a subsystem.

Yes starting up win32 subsystem for a dll loaded by a nt native subsystem application is possible. Microsoft of course does not document all this but some of those making anti cheat systems have worked out how to-do these evils.

[Weasel]

No it not. As you said kernel32.dll and the like are still loaded into your program address space until you change subsystem to nt native. nt native is still a subsystem.

Yes starting up win32 subsystem for a dll loaded by a nt native subsystem application is possible. Microsoft of course does not document all this but some of those making anti cheat systems have worked out how to-do these evils.

Like what and for what purpose? kernel32 functions can be hotpatched, and anti-cheat systems need to load a normal binary which expects kernel32 to begin with.

And this point is completely irrelevant to the discussion, not even sure why you still continue about it. You realize your original point was that no imports at all are possible, then you babbled about AppInit DLLs (again, dead wrong), which is still not true even without them (ntdll is still an import), and kernel32 would get special treatment even if you load it yourself (which again is REQUIRED for any normal desktop app if you don't want it flagged by an anti-virus).

So even a malware anti-cheat would have to load kernel32 eventually to be able to load the normal app which expects it.

[Weasel]

No you are pure incompetent. ntdll.dll is a nice NT oddity. Not only is it loaded in userspace it is also loaded in kernel space. When you syscall to load a library to call the kernel loaded ntdll.dll by syscall. If you load a .dll by any method that is recognised by the kernel you are using ntdll somewhere. You load a program that you see in your process list under Windows NT based operating systems you have also used ntdll somewhere. There is no other way to perform those registrations

So you don't need to import ntdll.dll when you can use the version of ntdll.dll already loaded by the kernel in kernel space.

Maybe next time think twice before opening your mouth if you don't want to embarrass yourself.
Applies to you more than me.

Are you fucking retarded? That was YOUR POINT moron.

It's funny how you realize just how pathetically wrong you were, now you use MY WORDS after you realized your arguments got crushed, and claim them as YOURS when they were MINE and what I've been saying all along (well, except the native subsystem part which I'm not aware of a single desktop app (i.e. without elevated privileges) uses, so whatever -- ntdll is still there though).

And yes, I will quote you right now to prove how much of an incompetent lying scum you are.

Here's what you said on page 10 (bolded for emphasis):

That is a two incorrect presume. The only dll that has to be loaded by a win32/64 program on NT operating system is in fact none if you are mad enough to use the unstable syscall interface. Application compatibility shim can in fact give you a different kernel32.dll in a dll under you application to your main application so it not 100 percent guaranteed but is expected behavour.

Keep lying like a piece of shit scum.

ntdll is an import with normal functions, not syscalls. Yes, it uses syscalls itself, but you don't have to use syscalls yourself, just use ntdll's functions, since ntdll is apparently "none", what a joke.

And you've yet to prove the second part of that quote btw.

It a easy to find application that is on the desktop using nt native to get clues what you can get upto.

Flatpak is designed not to give high privillage. Now this is another reason I don't exactly like snapcraft or appimage you can create root privillage applications as snap or appimage so they could contain fsck if someone decide to put like gparted inside them. Sorry your define of what is part of OS is not set in stone.

Ok, let me put it another way. If an app is not suitable for flatpak, then it's out of topic. Is that too hard for you to understand?

We're talking about the desktop platform here and distribution. Which means no elevation.

You know, apps you can run from USB thumbdrive as a normal user.

[oiaohm]

Like what and for what purpose? kernel32 functions can be hotpatched, and anti-cheat systems need to load a normal binary which expects kernel32 to begin with.

It straight forwards really have the anti-cheat system run as subsystem native so it can patch over the dll loaded to make hotpatching harder. Also means the anti-cheat system avoid race conditions like AppInit DLL can suffer from.

Please note they don't stop at just patching the dlls.

http://www.drdobbs.com/windows/windows-nt-system-call-hooking/184410109

They started patching syscalls as well back in 1998.

except the native subsystem part which I'm not aware of a single desktop app.

So not aware use to Asian e-sports games anti cheat systems.

ntdll is an import with normal functions, not syscalls. Yes, it uses syscalls itself, but you don't have to use syscalls yourself, just use ntdll's functions, since ntdll is apparently "none", what a joke.

I stated the long name once. NT Dyanmic Link Loader.
I will admit to one error its called ntdll in the kernel space is a section of NTOSKRNL.LIB. When using it from userspace you access it by ntdll.dll normally.

Yes anti-cheat game loaders you do find .exe with no dll files. Installer of the anti-cheat installs the right version matching your windows version normally backed up by a kernel module these don't have any dll imports. Why they use the syscalls directly. Control the ntdll in kernel space.

https://docs.microsoft.com/en-us/windows/desktop/dlls/dynamic-link-library-search-order

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\Session Manager\KnownDLLs
This a big one. If library game should load from game path is already in KnownDLLs from a different location it may not load.

Taking straight control over the ntdll in the kernel allows you to prevent particular attacks it also allows to create a stack of particular issues. Yes you can override kernel32.dll with one that is in the applications directory by deleting kernel32.dll out of KnownDLLs just before loading the application so anti-cheat system cannot trust that kernel32.dll will not get swapped on it.

This KnownDLLs bit is why you see the same kernel32.dll in each dll own link map. All dll are different link maps. Of course once you know how it works the idea that you only have on kernel32.dll your application is that a hack works. If something disrupts this everything can go to hell quickly under windows.

Yes some anti-cheat systems use to use this KnownDLLs abuse to alter system libraries with own versions of course this was fine if the game loading was the only thing starting at the time. Not fine of some other application loaded at that time.

Ok, let me put it another way. If an app is not suitable for flatpak, then it's out of topic. Is that too hard for you to understand?
We're talking about the desktop platform here and distribution. Which means no elevation.
You know, apps you can run from USB thumbdrive as a normal user.

So games with complex anti cheat systems are not desktop applications. Weasel you have just attempted to move the goal posts and I am not buying it.

By sticking to everything that runs on windows desktop include games that install anti-cheat services that run with elevation means you have to look under Window hood and see what in fact the beast is doing.

What libcapsule is doing is a lot like what Windows is doing in background. Libcapsule allows doing things that if you do them under windows you risk bring the complete system down. Yet can be done safely with libcapsule. LD_AUDIT also allows doing things that are totally unsafe under windows.

KnownDLLs being global system wide is not a good thing once someone want to over ride them. KnownDLLs per application is better with this being the case the application global link map is not exactly bad. Lacking means to split this sanely is the problem.

So you have a application global symbol/library namespace this is not a bad thing. It a problem when you don't have means to flag please start this library/application area in its own link_map with duplication of what in the global symbol name space.

KnownDLLs is basically a hack to take per dll/exe link maps and attempt to make some what global namespace. Think about it as a application developer would it not be handy to list what libraries should be globally shared over your application and any library not there should be local.

There is no reason at all to get rid of the ELF platform global link map it not a bad idea. What is a problem is poor control over link_map allocation.

[Weasel]

It straight forwards really have the anti-cheat system run as subsystem native so it can patch over the dll loaded to make hotpatching harder. Also means the anti-cheat system avoid race conditions like AppInit DLL can suffer from.

You don't need it for AppInit DLLs, just don't load user32.dll and load it manually. So, you are wrong there.

Hotpatching what harder? Anti-cheat's kernel32 would load first anyway, there's no reason to not load it if you have to load it later. Provide evidence for the contrary, cause you've been claiming only nonsense so far.

Please note they don't stop at just patching the dlls.
http://www.drdobbs.com/windows/windo...king/184410109
They started patching syscalls as well back in 1998.

This has nothing to do with loading kernel32 or not. Stop grasping for straws.

So not aware use to Asian e-sports games anti cheat systems.

Bullshit, I said I'm not aware of any native subsystem anti-cheat unless they are DRIVERS (which again is out of scope for "desktop platform"). So exclude any anti-cheat that uses drivers. period.

You seem to have this mentality that just because YOU CLAIM something it means it's fact, but it's not, nobody gives a shit about your claims. You CLAIMED that anti-cheat systems use native subsystem. This is not fact. You need to prove THAT.

I stated the long name once. NT Dyanmic Link Loader.
I will admit to one error its called ntdll in the kernel space is a section of NTOSKRNL.LIB. When using it from userspace you access it by ntdll.dll normally.

Yes anti-cheat game loaders you do find .exe with no dll files. Installer of the anti-cheat installs the right version matching your windows version normally backed up by a kernel module these don't have any dll imports. Why they use the syscalls directly. Control the ntdll in kernel space.

https://docs.microsoft.com/en-us/win...y-search-order
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\Session Manager\KnownDLLs
This a big one. If library game should load from game path is already in KnownDLLs from a different location it may not load.

Taking straight control over the ntdll in the kernel allows you to prevent particular attacks it also allows to create a stack of particular issues. Yes you can override kernel32.dll with one that is in the applications directory by deleting kernel32.dll out of KnownDLLs just before loading the application so anti-cheat system cannot trust that kernel32.dll will not get swapped on it.

This KnownDLLs bit is why you see the same kernel32.dll in each dll own link map. All dll are different link maps. Of course once you know how it works the idea that you only have on kernel32.dll your application is that a hack works. If something disrupts this everything can go to hell quickly under windows.

Yes some anti-cheat systems use to use this KnownDLLs abuse to alter system libraries with own versions of course this was fine if the game loading was the only thing starting at the time. Not fine of some other application loaded at that time.

First, this is completely off topic to the discussion: if you abuse Windows, it's not DLL's problem in the least.

Secondly, provide proof or give examples of anti-cheat systems that do what you claimed -- I'm actually curious but I have a feeling you're just speaking made up stuff.

Third, again, this has nothing to do with DLLs being superior to ELF. You can abuse Windows and DLLs and the fault is on you, just like how you can abuse ELF and even load DLLs on Linux.



I also never said anything about KnownDLLs. When the fuck did I say that's a good thing? I was talking about the DLL format itself. You realize PE is also used by UEFI right? No registry there, dude.

Please separate the format specification from the implementation.

[oiaohm]

Hotpatching what harder? Anti-cheat's kernel32 would load first anyway, there's no reason to not load it if you have to load it later. Provide evidence for the contrary, cause you've been claiming only nonsense so far.

There is a reason not to let system load kernel32.dll and load it yourself.

First, this is completely off topic to the discussion: if you abuse Windows, it's not DLL's problem in the least.

You just called it off topic. Abusing knowndlls allows a person who cheating to have kernel32.dll replaced with a modified version if you leave it to the system to load into your application.

I said I'm not aware of any native subsystem anti-cheat unless they are DRIVERS (which again is out of scope for "desktop platform"). So exclude any anti-cheat that uses drivers. period.

Then you have most likely not looked closely enough. Wine has to provide fake dlls this include real executable stub dlls on kernel32.dll. Why because the evil I am referring to where the anti-cheat has overrides the windows dynamic link loader and totally avoids kernel32.dll and user32.dll in early part of application start up.

The ones pulling native subsystem some use native subsystem exe others have a stub windows exe trigger the sys driver in to load particular program. So the version of kernel32.dll the application and individual dll has was chosen by the anti-cheat loader.

Wine would not need winedevice if drivers were in fact completely out of scope of the desktop platform. Really your excludes lets you overly narrow down what the desktop platform is.

Secondly, provide proof or give examples of anti-cheat systems that do what you claimed -- I'm actually curious but I have a feeling you're just speaking made up stuff.

Due to the fact the anti-cheat systems I am talking about are why wine has fake dlls that are in fact executable PE files that chain load the wine dll.so files. Asking me this question make me believe you are not a wine developer. Yes this goes on the back of you not knowing how testbot was working. So what is your wine developer name you don't have to tell me here. I am in freenode #winedeveloper under the same handle.

You realize PE is also used by UEFI right? No registry there, dude.

https://github.com/tianocore/tianocore.github.io/wiki/ArmPkg-Debugging

This is where you should never have gone. Yes UEFI standard format is PE. But for Arm platform all the UEFI PE binaries that UEFI loads starts life as ELF binaries. Correctly built ELF file can contain all the same symbol information as a PE file. Yes symbols with dll/so those symbols are from and this is without using gcc symbol version extention. There are variations of UEFI implementation that can just load the ELF files without needing them converted to PE. So UEFI dll files can be ELF or PE all depending on the implementation of UEFI you are dealing with. Really the fact ELF and PE are used interchangeably in different UEFI implementations clearly shows there is no special advantage to PE in the import symbol table and the ELF import symbol table can in fact contain the same information.

When building linux elf applications and libraries you run into problems with the dynamic loader not supporting what the UEFI ELF loaders support and compilers linker skipping out on include the extra information in the symbol table to mark what the symbol is from.

UEFI implementations is one of the places where you can find a ELF dynamic loader done supporting all the features of PE that UEFI standard says should be there include declaring where symbols are from in the symbol table. Of course these UEFI ELF dynamic loaders are not doing anything outside ELF specification.

So like it or not UEFI implementations show that ELF issues are implementation issues not format ones.

[Weasel]

There is a reason not to let system load kernel32.dll and load it yourself.

Cool story dude, I was asking you what reason and what purpose like 2 times already.

You just called it off topic. Abusing knowndlls allows a person who cheating to have kernel32.dll replaced with a modified version if you leave it to the system to load into your application.

WHAT DOES THAT HAVE TO DO with the DLL format? KnownDLLs is a Windows thing. Nowhere in the DLL format is that required or enforced.

I don't give a f about Windows as the system. I'm talking about Windows as the platform. I'm talking about DLL as the binary format spec.

Then you have most likely not looked closely enough. Wine has to provide fake dlls this include real executable stub dlls on kernel32.dll. Why because the evil I am referring to where the anti-cheat has overrides the windows dynamic link loader and totally avoids kernel32.dll and user32.dll in early part of application start up.

The ones pulling native subsystem some use native subsystem exe others have a stub windows exe trigger the sys driver in to load particular program. So the version of kernel32.dll the application and individual dll has was chosen by the anti-cheat loader.

Wine would not need winedevice if drivers were in fact completely out of scope of the desktop platform. Really your excludes lets you overly narrow down what the desktop platform is.

Ehm, I specifically said do not include drivers as examples.

I'm not sure what else I can do beside bolding + capitalizing it, cause you clearly refuse to read.

Don't bring drivers into it, because on Linux they would never happen due to ABI instability for drivers, so it's even worse (but off topic).

So, I want you to show me an app without using a driver that uses the native subsystem. Is that really so hard to understand? I don't care about anything else you say in regards to this until you at least show me 1 such app.

Again, NO DRIVERS. None, zero. Not even 1.

Due to the fact the anti-cheat systems I am talking about are why wine has fake dlls that are in fact executable PE files that chain load the wine dll.so files. Asking me this question make me believe you are not a wine developer. Yes this goes on the back of you not knowing how testbot was working. So what is your wine developer name you don't have to tell me here. I am in freenode #winedeveloper under the same handle.

Dude, stop going off track, STOP SWITCHING SUBJECT.

The subject was NATIVE SUBSYSTEM. That's what I fucking asked you, not fake dlls. What is your problem? Stop dodging the question!

You claimed anti-cheat use NATIVE SUBSYSTEM without drivers. That's what I'm asking you. ffs.

https://github.com/tianocore/tianoco...mPkg-Debugging
This is where you should never have gone. Yes UEFI standard format is PE. But for Arm platform all the UEFI PE binaries that UEFI loads starts life as ELF binaries. Correctly built ELF file can contain all the same symbol information as a PE file. Yes symbols with dll/so those symbols are from and this is without using gcc symbol version extention. There are variations of UEFI implementation that can just load the ELF files without needing them converted to PE. So UEFI dll files can be ELF or PE all depending on the implementation of UEFI you are dealing with. Really the fact ELF and PE are used interchangeably in different UEFI implementations clearly shows there is no special advantage to PE in the import symbol table and the ELF import symbol table can in fact contain the same information.

As if UEFI is demanding in dependency requirements...

I was making the point that you don't need Windows-specific implementation for DLLs. Simple as that.

But that's too much for you to understand I guess.

So like it or not UEFI implementations show that ELF issues are implementation issues not format ones.

No, they're format ones, for allowing poor implementations still be legal in terms of ELF.

KnownDLLs has nothing to do with the DLL format. Instead, a global symbol namespace does. The fact you can encode symbols without an associated module in ELF does. It's not that you have alternatives to be "as good as DLLs".

The problem is that you have alternative to use the global namespace. It should be forbidden, because most people are morons, you can't trust them to use it sensibly.

[oiaohm]

KnownDLLs has nothing to do with the DLL format. Instead, a global symbol namespace does. The fact you can encode symbols without an associated module in ELF does. It's not that you have alternatives to be "as good as DLLs".

Global symbol namespace was added to ELF.

Before global namespace you just have symbol tables with STT_FILE entries. .so loaded into global name space come from "Dynamic Section" in elf format. Where .so loaded into local namespace of program comes by STT_FILE from .dynsym.

The problem is that you have alternative to use the global namespace. It should be forbidden, because most people are morons, you can't trust them to use it sensibly.

STT_FILE fell out of usage because for most people building programs targeted at just solaris/one distribution did not need it and global was good enough.

When STT_FILE fell out of usage it also fell out of being implemented in ELF dynamic loaders. People making third party applications having STT_FILE in the .dynsym would be a god send to load .so files independent of the global symbol resolve.

Thing you are missing KnownDLLs and Global symbol namespace is both to address the same problem. When you need 1 version of a particular symbol you want the resolve to get down to 1 this is what the Global symbol namespace and KnownDLLs attempts todo. Now when you have application declaring everything in the global namespace and declaring nothing in the local namespace(STT_FILE) you are playing with fire. Distributions shipping all their own built applications have no need for the STT_FILE local name space. Most of the time they have only 1 version of libraries they want loaded.

STT_FILE and DT_RUNPATH working in combination allows you to have the same so name with same functions loaded in different libraries in the same application with the libraries being from different paths. This is more flexible that the PE option. You are not going to get screwed over by system tricks attempting to make a global symbol namespace like KnownDLLs.

ELF global symbol namespace is going to eat you alive if you are not using STT_FILE . It a bit hard to use it when dynamic loaders are not implementing original form of ELF(original form of elf you have STT_FILE and no global symbol name-space resolve).

What you are missing as a application developer on ELF systems you should be able to choose what is a global resolve and what is a local to .so/executable.

Don't bring drivers into it, because on Linux they would never happen due to ABI instability for drivers, so it's even worse (but off topic).

Don't be too sure on this one. We are seeing ebpf be extended in more and more ways. So I would not be surprised if anti cheat systems end up using ebpf hooks in kernel space.

Remember totally fix ELF systems could take 10 to 15 years.

Reality is Weasel you did not know what original dynamic loaded elfs looks like. The original dynamic loaded elfs would be quite nice to third party developers.