Christian Sciberras wrote: >> Yes. Once again: get your homework done! >> >>> http://www.codeproject.com/KB/DLL/dynamicdllloading.aspx >> >> That's a double DYNAMIC there! > > Did you even bother to read the article? The very first paragraph > states the difference between the two. > > Oh, and for the records, you can't statically link to dll files. At > least, not in the way you're imagining.
You should start to read what I wrote in <34a088424c7d499f988d1adca645b...@localhost>: | Static linking occurs when the linker builds a binary (this might be a | DLL.-) using *.OBJ and *.LIB. > Static linking (in your case) only works for object files (.o or .lib). I wrote that already. >> Why should I bother to do the work of the loader? >> I reference the DLL export in my code and expect the loader to resolve >> it. There is no need for fancy do-it-yourself DLL entry resolution! > > Forfuckssake where did this point come from? Your completely superfluous trip to codeproject.com! >> Nobody can load a DLL that does not exist! > > Wow what genius! The hell with that. It's the practice that is wrong. > As the saying goes, one shouldn't cry over spilled milk; > attempting to load a non-existent is asking for trouble. > > Oh, and by the way. Looks like MS just broke your little fact... > ...they've been loading an nonexistent dll via ACROS' POC (via wab.exe). Bloody wrong: the .DLL accompanies the *.VCF in the share. >> Why should I call or even write a routine which checks whether a DLL >> exists instead of just calling the loader and let it search/load it? >> Hint #1: this is exactly what MSFT advices NOT to do! > > And they are right. You shouldn't be doing the OS's work. > >> Hint #2: loading a DLL does not mean to run any code from this DLL! > > But it is still loading the library into memory. That's what I expect when loading a DLL. > From there on, perhaps, some buffer overflow exploit would escalate the issue. Which issue? Ever heard of Occams Razor?! > At which point we all go critical over the damn crap just like you're > doing right now. Why? You wrote that your self-written POC failed! ACROS' POC but works. Who's wrong? >> Who guarantees that your self-written or the OS supplied search routine >> will find the same DLL as the loader (just in case you do not use the >> fully qualified pathname of the DLL)? > > Because that is the damn point of the function, to tell us what the > hell the loader is doing!! Which function then tells me what your function is doing? LoadLibrary*() IS documented, and its rather well documented. There's no need to reprogram it. Just use it. And check its return code! >> Why should someone with a sane mind let a program (or the OS) search >> a DLL twice? Just to waste performance? > > Why search? A simple CreateFile() (aka FileExists in winapi) over the > cached path would suffice. Which cached path? KISS! Remember: for DLL hijacking to work the input to LoadLibrary() needs to be a simple filename or a relative pathname. > Perhaps returning this cached path would completely solve the issue. Perhaps. The Win32 API but does not provide such a function! >> For DLLs: always. For EXEs: it depends. Just read it in the MSDN! >> >> Just in case that you misunderstood "from the very beginning" let me >> rephrase it: from the earliest days of DOS/Windows CWD was in the PATH. > > That is NOT true. OF COURSE THIS IS TRUE! > I don't know if it was, perhaps in the Win95 era, > but it most certainly is not there today. %PATH% is ALWAYS equivalent to .;%PATH% > That was what my POC proved. Did you read the full article? I > mentioned cases where the bad dll (in CWD) would not be loaded (and an > error followed instead). > >> Consult MSDN on the DLL load order. > > I don't have to. If you spared one moment from trolling, you might > have noticed me dumping a list from ProcessMonitor...which clearly > shows what the dll loading order is. > >> BTW: Windows' "base directory" is MSFTs notion of $HOME. >> Use the right terms/words, PLEASE. > > Mind not putting words in my mouth? As far as definition goes, a "base > directory" is where the source program started from... Wrong. That's the "application directory". > that could be a docroot of an index.php file Wrong again. *.PHP is no executable file format, but associated to an application. See CMD.EXE /K ASSOC .PHP and then FTYPE with the output of the ASSOC. > or C:\Windows for notepad.exe. > No one said anything about Windows! ACROS showed a POC for Windows' address book using a *.VCF and a .DLL built for Windows. >> Can I assume that you tested it just like you failed to test your own >> POC? >> SAFER works quite well here (and there too) for about 7 years now. > > Tell THAT to ACROS and their POC! > Why should I care for existence of a certain functionality if it is > not by default (and if doesn't relate to the issue at all)? You obviously need some courses in Windows basics. Just turn SAFER on, WITH logging, and check the log! >> Yes kiddo. I wrote DLLs for mainframes, 35 years ago. I wrote DLLs for >> UNIX, 30 years ago. > > Ahem? UNIX doesn't have "dlls", they're "shared objects". No, UNIX has shared libraries. > Speaking of which, coding for practically dead devices doesn't mean > you have any real knowledge of newer ones. > Just as I wouldn't expect a simple assembly programmer to > automatically debug through and understand a .NET-based application. > > Before you start shouting "they do the same thing" just consider how > this issue (obviously) doesn't relate to those systems at all. > > By the way, oldie, get a darn life an stop accusing people of what > they didn't do. > This whole discussion started from your saying "I did it all > wrong"...perhaps, you ought to look into what I was really doing "all > wrong". > > Since this seems to be a complete waste of my time, don't expect any replies. > I don't usually do this to conversations but really, this dll hijack > crap already took enough of my time, > let alone (attempting) to educate a fellow Seasoned UNIX Expert over > Windows dynamics (which I'm failing anyway). Get a life, kid! Stefan _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/