[FIXED] Renaming OpenAL32.dll to lwjglaudio.dll again

[princec]

Recently I've come across a few buggered OpenAL installations that LWJGL picks up in preference to the library shipped LWJGL. It'd be better if this was impossible by virtue of using our own name for the OpenAL lib. Anybody else in favour?

Cas

[Matzon]

we're forcefully loading the one in our directory ...  not sure how that can even happen?

[princec]

Hm how forcefully? There are some quirks about how Windows loads dlls, particularly from the local directory, for which there are some specific APIs (just recently read about this on arstechnica as well). Are we using them?

Cas

[Matzon]

heh, saw that article too and thought wtf, what a coincidence

However, to the best of my knowledge, we're not using that flag. However a user may specify the safe loading globally using a registry value. This could be what is happening.

I am not sure about the consequences of changing the name. Could possibly let it be a system property ?

[princec]

A system property would be good. I reckon something like -Dorg.lwjgl.openal.library=./OpenAL32.dll etc. would do the trick. That'd be used first before it went off and did its usual path searching.

Cas

[Matzon]

I was actually thinking about a property specifying a name for the dll - not the path. I am pretty sure that the safe dll loading mechanisms also mean that .\OpenAL32.dll == OpenAL32.dll - I could be wrong tho.

Fwiw, we should consider renaming it entirely, since this could possibly be an issue for everyone (technically, only for those that have the safe loading activated AND OpenAL32.dll installed in the System path). I just dont have an overview of the consequences of such a change. Moreover it would also mean that its not that obvious that the dll is OpenAL - if thats an issue...

[kappa]

instead of using -Djava.library.path="" you could use the existing -Dorg.lwjgl.librarypath="" to set the path to the natives, it should have the most priority of all the methods iirc, the code attempts to load the natives only from there if that parameter is used.

If that works for you, lwjgl won't need any changes

[kappa]

@princec can you confirm if the above works for you?

[jediTofu]

Yeah, org.lwjgl.librarypath would be the best bet.  Renaming the dll to lwjglopenal wouldn't really do much in regards to that article; malicious hackers would then just either rename their own dll or drop two copies of the dll's (one named OpenAL and one named lwjglopenal).

A quick fix for Microsoft would be to just require admin privileges when dropping a dll somewhere.

This actually means that Java is (a tiny bit) safer than other languages in regard to this issue, as exe installers would install OpenAL into System32 and have their apps expect the dll being used is from there while Java programs usually ship the dll's in the current directory and use the JVM's way of finding it.  If you're using Web Start and have offline disabled, you're even safer.

Anyway, if someone is able to go into your system and drop a dll somewhere, you're pretty much screwed anyway.  If they're able to put a dll in the current directory of some software, they are able to do much, much worst, but decided not to for some reason.  Users nowadays should be aware of what they download and run and have some type of virus protection (unless they know how to use Linux properly)...

[princec]

Sorry didn't spot that reply. I'm not in the least bit bothered about malicious hackers and renamed dlls, just broken ones that don't work, and unfortunately I've not got contact from anyone who has this problem, only logs recorded in my database of it happening. (Customers tend to just move on and forget about the game).

Well, I can always twiddle the source myself, it's no big deal.

Cas

[kappa]

k, i'll mark this as fixed then.