Prev: Recommended Debugger for PE?
Next: List View: sort by "foo" does not keep "foo" hilited??
From: [Jongware] on 12 Feb 2010 06:19
[Jongware] wrote:
> [Jongware] wrote:
> >only MSVC generated DLLs will contain decorated names.
>
> -- well, I meant names that UnDecorateSymbolName can recognize and
> undecorate. These are those created with MSVC.

An additional thought: you cannot *call* a non-exported function in a
reliable way. The only way I can think of is relative to an exported
function (of which you can get the address):

call (SomeExportedFunction+0x1234)

[Jw]
From: glitteringsounds on 12 Feb 2010 06:22
On Feb 12, 3:46 pm, "[Jongware]" <so...(a)no.spam.net> wrote:
> glitteringsounds wrote:
> > I need to extract all non-exported (global or member functions of
> > class) methods of certain DLL. GetProcAddress always takes decorated
> > functions of exported functions and returns function pointers against
> > these.
>
> > Is it possible to look up non exported functions of certain DLL.
> > How.??
>
> Not possible.
>
> Exported functions are identified by calling address -- and you need
> additional information on the parameters. GetProcAddress works for *any*
> DLL, but only MSVC generated DLLs will contain decorated names. In any
> case, the name decoration is not a standard or anything; virtually every
>   other version of MSVC decorates in a slightly different way. And
> besides, other compiler brands have other ways of decorating.
>
> NON-EXPORTED functions, on the other hand, can be everything else in the
> file. You cannot "get" the address of a non-exported function.
> Disassembling the DLL will not guarantee you get all functions --
> disassembling is *not* an exact science.
>
> Even if you get a reliable function address, there is *no* information
> at all about its parameters, or even the calling convention. You will
> have to disassemble the full function (and perhaps the functions that
> are called from it, and so on) before you even have an idea if it's
> expecting an unsigned char * __cdecl (struct &whatever, void
> **even_more_data) (etc.).
>
> Besides: there usually are lots and lots and lots of 'non-exported'
> functions in a DLL; and most are just for housekeeping (why make a
> system call to StrToLowerCase when you can just use "strlwr"?).
>
> What does "I need .." mean? If you intended "I want ..", I suggest:
> forget it.
>
> [Jw]

I am just writing a debugger utility that needs to call non exported
functions as well such as all other debugger utilities always do.
Disassembling the PE(DLL) will give useful information about non
exported functions. Some how if we locate the exact place of non
exported functions in PE and temporarily place all of those non
exported functions inside export table of that PE(DLL in my case) and
make them exported temporarily(untill I done with DLL) just making
copy or duplicating those non exported functions so that original DLL
remains consistent.

Any suggestions or recommendations?
From: Kerem Gümrükcü on 12 Feb 2010 11:08
ACK! Nonexported functions could have
many prerequisites or (global) data that
must be initialized before the call can be
made or could share state information or
will need them from another subsequent call.
It is a bad idea to do something like that,...

regards

Kerem

--
-----------------------
Beste Gr�sse / Best regards / Votre bien devoue
Kerem G�mr�kc�
Latest Project: http://www.pro-it-education.de/software/deviceremover
Latest Open-Source Projects: http://entwicklung.junetz.de
-----------------------

"[Jongware]" <sorry(a)no.spam.net> schrieb im Newsbeitrag
news:4b753943$0$22917$e4fe514c(a)news.xs4all.nl...
> [Jongware] wrote:
>> [Jongware] wrote:
>> >only MSVC generated DLLs will contain decorated names.
>>
>> -- well, I meant names that UnDecorateSymbolName can recognize and
>> undecorate. These are those created with MSVC.
>
> An additional thought: you cannot *call* a non-exported function in a
> reliable way. The only way I can think of is relative to an exported
> function (of which you can get the address):
>
> call (SomeExportedFunction+0x1234)
>
> [Jw]

From: [Jongware] on 12 Feb 2010 11:21
glitteringsounds wrote:
> On Feb 12, 3:46 pm, "[Jongware]" <so...(a)no.spam.net> wrote:
>> glitteringsounds wrote:
>>> I need to extract all non-exported (global or member functions of
>>> class) methods of certain DLL. GetProcAddress always takes decorated
>>> functions of exported functions and returns function pointers against
>>> these.
>>> Is it possible to look up non exported functions of certain DLL.
>>> How.??
>> Not possible.
>>
>> Exported functions are identified by calling address -- and you need
>> additional information on the parameters. GetProcAddress works for *any*
>> DLL, but only MSVC generated DLLs will contain decorated names. In any
>> case, the name decoration is not a standard or anything; virtually every
>> other version of MSVC decorates in a slightly different way. And
>> besides, other compiler brands have other ways of decorating.
>>
>> NON-EXPORTED functions, on the other hand, can be everything else in the
>> file. You cannot "get" the address of a non-exported function.
>> Disassembling the DLL will not guarantee you get all functions --
>> disassembling is *not* an exact science.
>>
>> Even if you get a reliable function address, there is *no* information
>> at all about its parameters, or even the calling convention. You will
>> have to disassemble the full function (and perhaps the functions that
>> are called from it, and so on) before you even have an idea if it's
>> expecting an unsigned char * __cdecl (struct &whatever, void
>> **even_more_data) (etc.).
>>
>> Besides: there usually are lots and lots and lots of 'non-exported'
>> functions in a DLL; and most are just for housekeeping (why make a
>> system call to StrToLowerCase when you can just use "strlwr"?).
>>
>> What does "I need .." mean? If you intended "I want ..", I suggest:
>> forget it.
>>
>> [Jw]
>
> I am just writing a debugger utility that needs to call non exported
> functions as well such as all other debugger utilities always do.
> Disassembling the PE(DLL) will give useful information about non
> exported functions. Some how if we locate the exact place of non
> exported functions in PE and temporarily place all of those non
> exported functions inside export table of that PE(DLL in my case) and
> make them exported temporarily(untill I done with DLL) just making
> copy or duplicating those non exported functions so that original DLL
> remains consistent.
>
> Any suggestions or recommendations?

Okay, that's a good point.
It totally depends on how your debugger actually works. Usually, you set
something like a breakpoint "on" an address where you want it to stop.
For that, you *do* need to know that address in advance (because you are
the one who has to enter it into the debugger).
From this point on, I'm going out of my league, because I generally
don't use this very-low-level debugging -- I have no idea how you would
set a breakpoint "in" a DLL at a known function (something like smack on
the first opcode called?).

But still, to be able to debug a DLL's *internal* calls, you need a full
100% correct disassembly before you can stop on one of those internal calls.
It's totally unnecessary to "put the non-exported functions into the
Export table" -- because you need to know where the functions are before
you can do this, and if you know where they are you don't need to do this.

---
gdb, as Auric correctly suggested in your other thread, is open source
code, so you could first check *if* it does what you need, followed by
tracing into *how* they do it.

[Jw]
From: [Jongware] on 12 Feb 2010 11:24

Kerem G�mr�kc� wrote:
> ACK! Nonexported functions could have
> many prerequisites or (global) data that
> must be initialized before the call can be
> made or could share state information or
> will need them from another subsequent call.
> It is a bad idea to do something like that,...

Totally agree with that.

And (I'll just say it again ;-)) you cannot totally reliable get the
address of non-exported functions, because that needs a full and totally
correct disassembly.

The OP does seem a determined fellow, though, so I'm aiming at having
him discover this by himself. A Learning By Error experience.

[Jw]
First  |  Prev  | 
Pages: 1 2
Prev: Recommended Debugger for PE?
Next: List View: sort by "foo" does not keep "foo" hilited??