PE delayed import table - need a description.
in [Win32 Kernel]
|
From: Remy Lebeau on 1 Oct 2009 14:26 "R.Wieser" <address(a)not.available> wrote in message news:uUq%23%23bpQKHA.488(a)TK2MSFTNGP05.phx.gbl... > I do not quite agree with you there : the linker may create and insert > such a table in the PE image, but without support for that table by > the OS-provided program-loader-and-starter that table would be > meaningless. The OS loader is not involved with the delay-load table. Delay-loading is handled by the app's own RTL code, in conjunction with the compiler and linker. When the app is being compiled, a delay-loaded function call emits machine code that jumps to the DLL function using the delay-load table instead of the import table. The OS loader is only concerned with filling in the import table. When the app is started, the delay-load table is already filled in with pointers to RTL-implemented thunks. The compiler/linker handle that initialization at compile-time. When a delay-loaded DLL function is then called for the first time at runtime, executable jumps to the coresponding thunk, which calls LoadLibrary() and GetProcAddress() and replaces the thunk with the result so subsequent calls jump into the DLL directly. -- Remy Lebeau (TeamB)
From: R.Wieser on 2 Oct 2009 07:05 Hello Stefan, > However, I asked: "Did you take a look into the MSJ article, that I > mentioned?". Look at the **MSJ** article from December 1998, that I > referred to as well. I hope it is still on the web somewhere. My apologies. Yes, I did look at that page (well before posting my question here). What I saw was a description of the used method, but no specifics about the usage of the table. So I disregarded it. Due to your specific mentioning of it I just have downloaded the executable (dec98hood.exe) mentioned at the top of the page and taken a peek in it. Alas, the "DelayLoadDemo" files again do not reveal (that I can find) anything about the actual delay-load table itself. :-\ > Please send an email to the email address used > for this newsgroup posting. Thank you for the offer. I've just send the email. > Although I really don't think that it is too much > of an effort to sign up at CodeProject. Its not the effort. I simply do not want to leave my contact-address with anyone asking for it, *especially not* when I see no reason for them to ask for it in the first place. -- Disregard if you dislike rants or just like Spam --- I've just looked at their "Logon" page. Seeing them having pre-checked the opt-in for the "Code Project newsletters" (which effectivily makes it an opt-out checkmark) does not ease my feelings (of them being data-aggregator/spammers) about them either. Its allso something that gets "thrown in" that I do not want or need. I just want to get access to a code-sample, nothing more. I continued to take a look at their "privacy" page, and found this *very* funny part (though in a very negative way) : ========= When Information May be Disclosed to Outside Parties: .... iv. To offer you related products and services that might benefit you; .... ========= In other words : Selling-off of the aggregated personal data for the sole purpose of spaming. Other parts in that privacy-page are not as clear as they could be either, like the "vi. Otherwise as permitted ... by law" which seems to make a mockery of any-and-all restrictions they looked to have set above-and-beyond what the Law demands of them ... The whole is exactly what I expected of such a subscription, and why I not even bother anymore to scrutinise such "offers" anymore. Regards, Rudy Wieser -- Origional message: Stefan Kuhr <kustt110(a)gmx.li> schreef in berichtnieuws eK10s8qQKHA.4600(a)TK2MSFTNGP05.phx.gbl... > Hi Rudy, > > R.Wieser wrote: > > Hello Stefan, > > > >> Did you take a look into the MSJ article, that I mentioned? > >> It explains how delayloading atually works. > > > > Where ? > > > > I found four references to the word "delay" : > > > > 1) > > ====== > > Optimizations such as delay loading of DLLs, section merging, and binding > > were still over the horizon > > ====== > > No info there. > > > > 2,3&4) > > ====== > > Visual C++ 6.0 added the delayload feature, which is a hybrid between > > implicit linking and explicit linking. When you delayload against a DLL, the > > linker emits something that looks very similar to the data for a regular > > imported DLL. However, the operating system ignores this data. Instead, the > > first time a call to one of the delayloaded APIs occurs, special stubs added > > by the linker cause the DLL to be loaded (if it's not already in memory), > > followed by a call to GetProcAddress to locate the called API. > > ====== > > Minimal info, nothing explicit. No description of *how* it works anywhere > > in sight. Not even a mentioning what that "delayed import table" is > > actually used for. :-\ > > > > May I mention that I allready found-and-read that article before I posted my > > question/request. > > > Ah I see you are talking about the msdn magazine article I referred to. > However, I asked: "Did you take a look into the MSJ article, that I > mentioned?". Look at the **MSJ** article from December 1998, that I > referred to as well. I hope it is still on the web somewhere. If you > have an older MSDN Library, it is under the "Periodicals" section. This > article might help. > > > > > Your article-code is only available there ? Bummer. (yes, its only > > available there. Although a quick Google-search showed 5 pages, all link > > back to that one article) > > > > Please send an email to the email address used for this newsgroup > posting. I normally do not monitor this email address, but I will do in > this case and send you the article's code. Although I really don't think > that it is too much of an effort to sign up at CodeProject. > > -- > S
From: R.Wieser on 2 Oct 2009 11:33 Hello Remy, > > I do not quite agree with you there : the linker may create and > > insert such a table in the PE image, but without support for > > that table by the OS-provided program-loader-and-starter > > that table would be meaningless. > > The OS loader is not involved with the delay-load table. > Delay-loading is handled by the app's own RTL code, in > conjunction with the compiler and linker. [snip] Thank you. Yes, I was a bit too quick in assuming that that table needed to be OS supported (maybe because I seemed to have read that it would be somethething the same as the import-table). I allso understand how such a mechanism could work. Heck, I've code written for a wedging-DLL that is just one step short of it : it loads all the origional function-adresses at the loading of the wedging DLL. Regards, Rudy Wieser -- Origional message: Remy Lebeau <no.spam(a)no.spam.com> schreef in berichtnieuws ebygtSsQKHA.3296(a)TK2MSFTNGP04.phx.gbl... > > "R.Wieser" <address(a)not.available> wrote in message > news:uUq%23%23bpQKHA.488(a)TK2MSFTNGP05.phx.gbl... > > > I do not quite agree with you there : the linker may create and insert > > such a table in the PE image, but without support for that table by > > the OS-provided program-loader-and-starter that table would be > > meaningless. > > The OS loader is not involved with the delay-load table. Delay-loading is > handled by the app's own RTL code, in conjunction with the compiler and > linker. When the app is being compiled, a delay-loaded function call emits > machine code that jumps to the DLL function using the delay-load table > instead of the import table. The OS loader is only concerned with filling > in the import table. When the app is started, the delay-load table is > already filled in with pointers to RTL-implemented thunks. The > compiler/linker handle that initialization at compile-time. When a > delay-loaded DLL function is then called for the first time at runtime, > executable jumps to the coresponding thunk, which calls LoadLibrary() and > GetProcAddress() and replaces the thunk with the result so subsequent calls > jump into the DLL directly. > > -- > Remy Lebeau (TeamB) > >
From: Ben Voigt [C++ MVP] on 2 Oct 2009 14:10 > If its that your "plain English, and very clearly granting" than pardon > me, > but I think you're a fool. > > Currently I can use the PE info I allready have for/in any program on any > OS > I please. That is way more than I could do if I would accept that EULA. > So > yes, I *do* think its trying to restrict (me) and not, as you seem to > think, > grant (me) anything. You're thinking of trade secret rules, where your rights depend on how you acquire the information (and the burden of proving you got it through an unencumbered source if you were privy to the same information through a restricted source). The paragraph in question refers to patents. You cannot use a patented idea without a license, EVEN IF YOU DEVELOPED IT INDEPENDENTLY. Go see a lawyer for a proper explanation. Of course that puts more money into the hands of lawyers and encourages them to keep writing long complicated license agreements :(
From: Ben Voigt [C++ MVP] on 2 Oct 2009 14:15
> By the way : if you happen to know how relayed entries work (functions > that > are seemingly exported by a DLL, but are actually in another one, like in > kernel32.dll -> ntdll.dll) I would certainly like to know. Its > how-and-why > I came to focus my attention to the delayed-import table. :-) > Maybe this will help: http://blogs.msdn.com/oldnewthing/archive/2006/07/19/671238.aspx I doubt delay-load is used for entry-point forwarding. |