Steam Survey Reports The Latest Linux Gaming Marketshare For October

[Weasel]

It is still hooking. That is what the loader is in fact up to. Job of a dynamic loader is to hook everything together.

LD_PRELOAD is not the loader. LD_PRELOAD preloads a library. A normal library loaded would also hook in the same way. LD_PRELOAD simply loads that library before anything else, and uses THE SAME MECHANISM for hooking, so the hooking is NOT part of LD_PRELOAD.

ELF has versioned symbols and versioned gives filtered symbols that should be just as safe as DLL. That these features are not implemented and used a lot is another problem.

Yeah, you love going back in circles don't you?

Clearly we're talking about global namespace here, not versioned symbols. Global namespace -- without versioning -- should simply not exist.

Its not safer because each dllmain executed individually can be distrupted while hooking and in fact mangle everything.

And ELF has constructors that can fuck everything up. Your point?

Seriously, stop grasping for straws.

Everything else you said literally applies to ELF as well, just different naming (constructor vs DllMain).

[oiaohm]

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

It is still hooking. That is what the loader is in fact up to. Job of a dynamic loader is to hook everything together.

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.

ELF has versioned symbols and versioned gives filtered symbols that should be just as safe as DLL. That these features are not implemented and used a lot is another problem.

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.

Its not safer because each dllmain executed individually can be distrupted while hooking and in fact mangle everything.

Hooking need to be processed in a order. Even without LD_PRELOAD the libraries and applications files in ELF hook themselves in a predictable order.

Weasel the nightmare with AppInit_DLL is if you read careful the Appinit_DLL can only use kernel32.dll You don't have a global namespace. So now the dllmain has to go to sleep until more of the application loads. This creates a race condition.

Like it or not having a global symbol namespace to fill in with information from the start line has some serous advantages particularly if you have to hook stuff and not to race condition it.

Would I like to see the information in the global symbol namespace more used. Yes the ELF global symbol namespace records what file the symbol comes from. Would I like to see applications use versioned symbols more include filters. The more usage of filters would lead to having to add in extra information for exports. Like this export please pretend that it comes from x file for hooking. This would cure your problems. The global symbol namespace of elf is storing all the need information. The general elf import without versioned does not check what one it gets.

You really want you dll exported symbols to have all the information for hooking. So that only the dynamic loader has to perform hooking and you don't have hooking order cat fight.

ELF format has something right. Now I am not going say that lacking usage of versioned and complete implementation of versioned on ELF is right.

Windows style of hooking where it can race condition and end up applied in wrong order..... is absolutely dangerous. Yes hooking in the wrong order can happen by mistake under windows and randomally.

ELF symbol conflicts happen because you are mixing binaries with each other but when you have a error is absolutely reproducible nothing random about it. Usage of versioned with ELF would block a lot of these conflicts.

[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.

[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]

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]

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 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.

[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.

[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.

[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.