We did, it's number is 253 ... $000000FD.
On Fri, Sep 17, 2010 at 11:07 AM, huj huj huj <datski...@gmail.com> wrote: > hey funboys! get a room! > > 2010/9/16 Stefan Kanthak <stefan.kant...@nexgo.de> >> >> 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/ > > _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/