Steam Survey Reports The Latest Linux Gaming Marketshare For October

[ssokolow]

The Win API is a mess in MANY other ways but for those there's no POSIX equivalent so let's leave those out since it's unfair to compare. (for example, COM is a monstrosity; message handling is semi-elegant, since it's riddled with redundancy due to historical reasons, but there's no equivalent in POSIX, so again we leave it out)

I think it's very unfair to not give POSIX credit for stopping rather than standardizing even more bad decisions.

We always seem to undervalue the wisdom necessary to not do something.

But you know what's the best thing about the Windows API compared to POSIX? Win API doesn't claim itself as the "one sole truth of how computing should be done" unlike POSIX fanboys who think POSIX is a gift from God and its word is law.

I don't like fanboys any more than you do.

That said, POSIX is the one API that every major platform other than Windows has managed to agree on... and that in itself has a great deal of value.

[Weasel]

Attempt to tell this to anyone interested in their application performing the best.

You don't get it. The user can always "hack" it, but it should not be by default. Not a default feature.

Why Appinit_DLL is a disaster is those specialised hooks and DLL injections don't have a global. Yes user has to go out of his way to-do it under windows and it also path to failures. So windows users are not use to being able to tweak performance. Please note with blender this tweak can be a 20 percent difference in performance resulting being able to-do 5 days work in 4.

I'm not sure why you bring up AppInit_DLL at all, I never said anything about it. It's still much safer than LD_PRELOAD, but it's also horrible and I do agree.

Sorry no Appinit_DLL is implement in user32 is correct. Appinit_DLL has been deprecated but has been written in the Windows API documentation as required feature of NT 3.5. First bug on AppInit_DLLs was in Windows 95. Yes Appinit is a clear example why DLL injection idea is highly limited and path to failure.

WTF is your point? LD_PRELOAD has *much* worse bugs than AppInit_DLLs and is much more unsafe. If AppInit_DLLs are path to failure (as they are), then LD_PRELOAD is path to insanity.

Windows API is also a C runtime just not to C standard.

It's not. For a long time, msvcrt wasn't even a system DLL. Stop making claims you can't back up.

The Windows API in fact goes out of it way to inverse arguments so you cannot simple one to one the Windows API C functions contained with C standard.

Wat?

Windows people want to make out that C runtime is just another library so they can ignore the elephant in room that you are needing c run-time as a library because windows was made intentionally non conforming. This non conformance leads to a lot of problems.

Non-conforming to what? The C language never specified the std library as a SYSTEM LIBRARY.

If you make the C runtime as a system library, then why not C++ too? Why not other languages? POSIX is clearly biased and wrong approach.

[oiaohm]

WTF is your point? LD_PRELOAD has *much* worse bugs than AppInit_DLLs and is much more unsafe. If AppInit_DLLs are path to failure (as they are), then LD_PRELOAD is path to insanity.

LD_PRELOAD like it or not has less bugs.
1) LD_PRELOAD has a predictable order of application. Appinit_DLL injection order is randomish so you don't want to be overriding the same function more than once with Appinit_DLL or bad things happen. LD_PRELOAD you can override the same function more than once.
2) LD_PRELOAD include feature to calling the override function cleanly. Yes the order of stacking is kept for dlopen/dlsym to use.

Appinit_DLL is like base jumping without a parachute. You might live if you are insanely lucky.
LD_PRELOAD is like jumping out a 10000 feet with only a single parachute. Majority of the time you will be fine but if things go wrong you will be in big trouble quickly.

Yes it possible to inject into running LInux applications as well.
https://blog.gdssecurity.com/labs/20...t-ptrace2.html
All the injection stuff we have on Linux as well. Normally you attempt to avoid this like the plague because its more unstable than using LD_PRELOAD and for security most of the windows forms of injection is in fact restricted to only approved users.

It's not. For a long time, msvcrt wasn't even a system DLL. Stop making claims you can't back up.

No it about time you read the documentation. Microsoft Windows API documentation calls it self a C runtime. This is not referring msvcrt but Windows API itself. Welcome to the elephant.

If you dig back though the historic documentation you will find CRT means something different to what you think. Most people incorrectly think the term means C Run-Time. Microsoft documentation has in recent years include the - in runtime. https://en.wikipedia.org/wiki/Runtime_system. Runtime is 1 word.
C Runtime what is the T. Its in fact C Runtime Transformation. CRT on windows is transforming the non standard C runtime of Windows API into something kind of C standard conforming.

Why is CRT and Windows API what it is. This is a historic thing both OS/2 and VMS both have functions with arguments organised like the C standard. So lead developers Windows inverted arguments under stupid legal advice that this would protect against copyright infringement claims. Microsoft would love this fact lost forever. Yes the reason why Windows API is not more like a standard C API is historic stupid legal advice. Without the stupid legal advice you may not need any of the CRT stuff on Windows at all.

If you make the C runtime as a system library.

The truth of the matter is the Windows API is a C runtime. They system libraries are already a C runtime. Problem is you did not know what CRT meant or the history,

POSIX is clearly biased and wrong approach.

No the Posix operating systems have not had stupid legal advice. Having todo function arguments one way when call the OS core libraries and a different way when doing C standard code is very stupid. Unfortunately without giving up on Windows there is no way to fix this.

[ssokolow]

LD_PRELOAD like it or not has less bugs.
1) LD_PRELOAD has a predictable order of application. Appinit_DLL injection order is randomish so you don't want to be overriding the same function more than once with Appinit_DLL or bad things happen. LD_PRELOAD you can override the same function more than once.
2) LD_PRELOAD include feature to calling the override function cleanly. Yes the order of stacking is kept for dlopen/dlsym to use.

3) Appinit_DLL is a registry-based mechanism, while LD_PRELOAD can be easily scoped to specific applications or even specific invocations of the same application.

[Weasel]

3) Appinit_DLL is a registry-based mechanism, while LD_PRELOAD can be easily scoped to specific applications or even specific invocations of the same application.

No, AppInit_DLLs is less dangerous due to how DLLs work.

With LD_PRELOAD you can load something that will possibly conflict with something else (you know... global symbol namespace...), an unintentional conflict. Say you load a library that exports malloc (as you want) but also exports some other symbol and results in a crash because you don't expect it. You have to literally check every symbol carefully, pure insanity.

You say, be careful with symbol names? I say, why don't you just code only with global variables, see where that gets you? It's the same thing.

This is the definition of insanity. ELF.

[Weasel]

No it about time you read the documentation. Microsoft Windows API documentation calls it self a C runtime. This is not referring msvcrt but Windows API itself. Welcome to the elephant.

If you dig back though the historic documentation you will find CRT means something different to what you think. Most people incorrectly think the term means C Run-Time. Microsoft documentation has in recent years include the - in runtime. https://en.wikipedia.org/wiki/Runtime_system. Runtime is 1 word.
C Runtime what is the T. Its in fact C Runtime Transformation. CRT on windows is transforming the non standard C runtime of Windows API into something kind of C standard conforming.

Nobody cares. Point was about the C standard library. Because that's what POSIX has. A bias towards the C STANDARD LIBRARY. In context it was perfectly obvious.

But of course, you always stray off point and play with words. More comedy than anything.

[oiaohm]

No, AppInit_DLLs is less dangerous due to how DLLs work.

No this is more dangerous. AppInit_DLL start their inject process then have to wait for the application to start and then inject on fly.

https://www.apriorit.com/dev-blog/160-apihooks

Yes each Appinit_DLLs can be using a different library to hook with.

With LD_PRELOAD you can load something that will possibly conflict with something else (you know... global symbol namespace...), an unintentional conflict. Say you load a library that exports malloc (as you want) but also exports some other symbol and results in a crash because you don't expect it. You have to literally check every symbol carefully, pure insanity.

LD_PRELOAD with globals you can in fact have a look at 1 single table and map out everything that has been in fact loaded and from what .so file. So back tracking a conflict like this is straight forwards.

This Appinit has the problem due to each Appinit_DLL can be using different hooking libraries there is no locking for order application of hooks and no table to look up to see what has been overridden by what.

Yes a LD_PRELOAD .so file is a normal .so file so to see what functions it going to override you just run a command to list it exports. Do I need to run the .so or decompile it to see this no.

Now Weasel how do you work out if two Appinit_DLL are going to conflict due to overriding the same function? This is injection so there does not have to be an export table to look at. So run or decomplier here we come.

Unintentional conflict is exactly what Appinit_DLL suffers from. apihooking basically lets break the dll name barrier. Yes you have dlopen a particular .so LD_PRELOAD if it has not replaced dlopen its not going to modify this. Apihooking on windows on the other hand it would have. Why because you are in fact modifying the dll presented to the application in memory.

http://codefromthe70s.org/images/mhook_diagram.png

Weasel do take a close look at this. Notice that the first commands in the function being api hooked had to be copied and moved. LD_PRELOAD in elf due to being a normal library. Its override the normal function call path. So LD_PRELOAD adds 2 jumps worst per hook and Appinit_DLL in fact adds 4 per hook.

libcapsule at runtime has added no extra jump than what normally would have been used if their was not a conflict other than for trapping dlopen.

Weasel apihooking is horrible messy and horrible hard to debug. It would be far better to extend the export table on dll than app hook. Make dll be like versioned in elf so you can state what dll exports are requesting to replace. Then on dynamic link like LD_PRELOAD redirect.

[Weasel]

No this is more dangerous. AppInit_DLL start their inject process then have to wait for the application to start and then inject on fly.

https://www.apriorit.com/dev-blog/160-apihooks

Yes each Appinit_DLLs can be using a different library to hook with.

Again, you have no idea what you are linking to, and I've no interest in explaining things thoroughly at this point.

AppInit_DLLs don't hook anything, they just load a DLL just like LD_PRELOAD.

I don't know how much more simple you want me to make this.

Your article explicitly hooks APIs in the library, which is no different than explicitly fucking shit up in ELF code. It has *NOTHING* to do with AppInit_DLLs, which is used just to load the DLL.

But at least you have no symbol conflicts so it's much safer than LD_PRELOAD.



tl;dr API hooking is NOT the same thing as AppInit_DLLs nor LD_PRELOAD.

Both AppInit_DLLs and LD_PRELOAD are about LOADING the library, not hooking anything. The thing is, ELF automatically "hooks" symbols with same name. With DLLs you have to hook them yourself, which makes it MUCH SAFER because it's not turned on by default, you have to explicitly fuck shit up.

[oiaohm]

AppInit_DLLs don't hook anything, they just load a DLL just like LD_PRELOAD.

https://jvns.ca/blog/2014/11/27/ld-preload-is-super-fun-and-easy/

Just load dll with LD_PRELOAD with global symbols automatically hooks in a order way.

Your article explicitly hooks APIs in the library, which is no different than explicitly fucking shit up in ELF code. It has *NOTHING* to do with AppInit_DLLs, which is used just to load the DLL.

And a appinit_DLL is not really going todo anything unless it hooks something.

But at least you have no symbol conflicts so it's much safer than LD_PRELOAD.

Sorry you have hooking conflit with AppInit_DLL as they attempt to do the same thing as what LD_PRELOAD does simple by exploiting global symbols.

So you do have hooking conflicts over who takes control of what function and how.

Appinit_DLL with hooking that you have to use to perform the same tasks as LD_PRELOAD is way harder to debug when everything goes wrong.

[Weasel]

https://jvns.ca/blog/2014/11/27/ld-p...-fun-and-easy/
Just load dll with LD_PRELOAD with global symbols automatically hooks in a order way.

No, LD_PRELOAD doesn't hook anything. LD_PRELOAD preloads a library. What a shock, right?

The stupid fucking loader that uses the global namespace is what "hooks" the APIs.

A library can get loaded WITHOUT LD_PRELOAD before another library, and it would STILL "hook" the APIs. Because this "automatic hooking" is the insanity that is global namespace in ELF. There's no automatic hooking in DLLs so that's why they are MUCH SAFER.

And a appinit_DLL is not really going todo anything unless it hooks something.

Exactly, you have to be specific about hooking and explicit. It can't happen by mistake, like with ELF. That's EXACTLY my point and why it's much safer.