How to determine if an exported symbol is a variable in EAT

NTDEV
1

Hi

Is there some by which we can determine whether an exported symbol in a DLL is a variable or a function.

The Export Address Table just has name, ordinal number and the RVA for the exxported symbol. From this we can’t say what kind of symbol it is.

I was expecting that the exported variables will be present in the .rdata section and exported functions i the .text section, but I observed that exported variables were also present in .text section in some cases.

Another way could be to identify exported variables based on some specific string paatern in the name, like in case of exported class the virtual function table gets exported, for ex symbol for the exported vftable in class CComPlusObject is ??_7CComPlusObject@@6B@
In case we compile using VC++ compiler, this kind of name is generated due to name mangling. Taking hint from this we can check if for some specific string in the name, like in this case we can check for ??_7, similarly for other names like

?xxxxx@CAutoWindows@@1UAFX_INTERFACEMAP@@B
?xxxxx@CApplication@@1UAFX_DISPMAP@@B
?xxxxx@CApplication@@2U_GUID@@B
?xxxxx@CDocObjectDoc@@1UAFX_MSGMAP@@B

Is there some standard way by which we can know whether the exported symbol is a variable or a function.

Thanks

2

Why do you want to make this distinction?

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hcl.in
Sent: Wednesday, May 20, 2009 10:03 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] How to determine if an exported symbol is a variable in EAT

Hi

Is there some by which we can determine whether an exported symbol in a DLL is a variable or a function.

The Export Address Table just has name, ordinal number and the RVA for the exxported symbol. From this we can’t say what kind of symbol it is.

I was expecting that the exported variables will be present in the .rdata section and exported functions i the .text section, but I observed that exported variables were also present in .text section in some cases.

Another way could be to identify exported variables based on some specific string paatern in the name, like in case of exported class the virtual function table gets exported, for ex symbol for the exported vftable in class CComPlusObject is ??_7CComPlusObject@@6B@
In case we compile using VC++ compiler, this kind of name is generated due to name mangling. Taking hint from this we can check if for some specific string in the name, like in this case we can check for ??_7, similarly for other names like

?xxxxx@CAutoWindows@@1UAFX_INTERFACEMAP@@B
?xxxxx@CApplication@@1UAFX_DISPMAP@@B
?xxxxx@CApplication@@2U_GUID@@B
?xxxxx@CDocObjectDoc@@1UAFX_MSGMAP@@B

Is there some standard way by which we can know whether the exported symbol is a variable or a function.

Thanks

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

3

What is your need for making this distinction?

Regards
Deepak

On Thu, May 21, 2009 at 10:32 AM, wrote:

> Hi
>
> Is there some by which we can determine whether an exported symbol in a
> DLL is a variable or a function.
>
> The Export Address Table just has name, ordinal number and the RVA for the
> exxported symbol. From this we can’t say what kind of symbol it is.
>
>
> I was expecting that the exported variables will be present in the .rdata
> section and exported functions i the .text section, but I observed that
> exported variables were also present in .text section in some cases.
>
> Another way could be to identify exported variables based on some specific
> string paatern in the name, like in case of exported class the virtual
> function table gets exported, for ex symbol for the exported vftable in
> class CComPlusObject is ??_7CComPlusObject@@6B@
> In case we compile using VC++ compiler, this kind of name is generated due
> to name mangling. Taking hint from this we can check if for some specific
> string in the name, like in this case we can check for ??_7, similarly for
> other names like
>
> ?xxxxx@CAutoWindows@@1UAFX_INTERFACEMAP@@B
> ?xxxxx@CApplication@@1UAFX_DISPMAP@@B
> ?xxxxx@CApplication@@2U_GUID@@B
> ?xxxxx@CDocObjectDoc@@1UAFX_MSGMAP@@B
>
> Is there some standard way by which we can know whether the exported symbol
> is a variable or a function.
>
> Thanks
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

4

Actually we have to find whether someone has put inline hook in the exported functions.

To do this we read the RVA of the exported function from the EAT and go to the start of the function, there we disassemble the binay code to check whether there is some jump or call instruction and accordingly check where they are pointing, this is to determine if someone has put a inline hook or not.

But if we find an exported variable in the EAT, then also we go to the start of the variable and try to disassemble the code there. Since we do not have any valid instructions there we sometimes incorrectly find a call instruction and an incorrect address next to it, and assume that we have found an inline hook.

To avoid checking the exported variable for inline hook we need to know if the exported symbol is a variable or a function.

Thanks

5

hmm…, I think that’s why sections are there.
Functions go in code section while exported globals should go in data
sections.

Where does the RVA of your exported variable lies, is it in code section
limits or out of code sections limits.

I think this check should work.

Regards
Deepak

On Thu, May 21, 2009 at 11:37 AM, wrote:

> Actually we have to find whether someone has put inline hook in the
> exported functions.
>
> To do this we read the RVA of the exported function from the EAT and go to
> the start of the function, there we disassemble the binay code to check
> whether there is some jump or call instruction and accordingly check where
> they are pointing, this is to determine if someone has put a inline hook or
> not.
>
> But if we find an exported variable in the EAT, then also we go to the
> start of the variable and try to disassemble the code there. Since we do not
> have any valid instructions there we sometimes incorrectly find a call
> instruction and an incorrect address next to it, and assume that we have
> found an inline hook.
>
> To avoid checking the exported variable for inline hook we need to know if
> the exported symbol is a variable or a function.
>
> Thanks
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

6

Well I have just confirmed it on my machine.
Exported some variables from my dll and they does go into non code sections.
That’s an enough check I assume.

Regards
Deepak

On Thu, May 21, 2009 at 1:49 PM, Deepak Gupta wrote:

> hmm…, I think that’s why sections are there.
> Functions go in code section while exported globals should go in data
> sections.
>
> Where does the RVA of your exported variable lies, is it in code section
> limits or out of code sections limits.
>
> I think this check should work.
>
> Regards
> Deepak
>
>
> On Thu, May 21, 2009 at 11:37 AM, wrote:
>
>> Actually we have to find whether someone has put inline hook in the
>> exported functions.
>>
>> To do this we read the RVA of the exported function from the EAT and go to
>> the start of the function, there we disassemble the binay code to check
>> whether there is some jump or call instruction and accordingly check where
>> they are pointing, this is to determine if someone has put a inline hook or
>> not.
>>
>> But if we find an exported variable in the EAT, then also we go to the
>> start of the variable and try to disassemble the code there. Since we do not
>> have any valid instructions there we sometimes incorrectly find a call
>> instruction and an incorrect address next to it, and assume that we have
>> found an inline hook.
>>
>> To avoid checking the exported variable for inline hook we need to know if
>> the exported symbol is a variable or a function.
>>
>> Thanks
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
>

7

Thanks for looking, I also tried to export a variable and a class having virtual function from a DLL. These exported symbols went to the .rdata section.

But if we check some windows DLLs like “catsrvut.dll” in system32 folder there are some symbols for virtual function table like…
??_7CComPlusMethod@@6B@
??_7CComPlusObject@@6B@

all these are present in the .text section.

If we check these in IDAPro it will show something like

.text:6FB135A0 ; Exported entry 28. ??_7CComPlusObject@@6B@
.text:6FB135A0 public ??_7CComPlusObject@@6B@
.text:6FB135A0 ; const CComPlusObject::`vftable’

.text:6FB135A0 ??_7CComPlusObject@@6B@ dd offset ??_ECComPlusObject@@UAEPAXI@Z
.text:6FB135A0 ; DATA XREF: CComPlusObject::CComPlusObject(CComPlusObject const &)+Ao
.text:6FB135A0 ; CComPlusObject::CComPlusObject(ITypeInfo *)
.text:6FB135A0 ; CComPlusObject::`vector deleting destructor’(uint)

.text:6FB135A4 dd offset ?xxxxx@CComPlusObject@@UAEJXZ ; CComPlusObject::Init(void)
.text:6FB135A8 dd offset __purecall
.text:6FB135AC dd offset __purecall
.text:6FB135B0 dd offset ?xxxxx@CComPlusObject@@UAEJPAK@Z ;
.text:6FB135B4 dd offset ?xxxxx@CComPlusObject@@UAEJPAPAG0PAK0@Z
.text:6FB135B8 dd offset ?xxxxx@CComPlusObject@@UAEJPAU_GUID@@@Z
.text:6FB135C0 dd offset ?xxxxx@CComPlusObject@@UAEJPAK@Z
…

8

hmm interesting.
May be some C++ compiler expert can give suggestions here on how names are
mangled and what does they signify.
Because loader must also know about this on how to fill the vftable.
So there must be a way to distinguish.

Regards
Deepak

On Thu, May 21, 2009 at 2:34 PM, wrote:

> Thanks for looking, I also tried to export a variable and a class having
> virtual function from a DLL. These exported symbols went to the .rdata
> section.
>
> But if we check some windows DLLs like “catsrvut.dll” in system32 folder
> there are some symbols for virtual function table like…
> ??_7CComPlusMethod@@6B@
> ??_7CComPlusObject@@6B@
>
> all these are present in the .text section.
>
> If we check these in IDAPro it will show something like
>
> .text:6FB135A0 ; Exported entry 28. ??_7CComPlusObject@@6B@
> .text:6FB135A0 public ??_7CComPlusObject@@6B@
> .text:6FB135A0 ; const CComPlusObject::vftable'<br>&gt;<br>&gt; .text:6FB135A0 ??_7CComPlusObject@@6B@ dd offset ??_ECComPlusObject@<br>&gt; @UAEPAXI@Z<br>&gt; .text:6FB135A0 ; DATA XREF:<br>&gt; CComPlusObject::CComPlusObject(CComPlusObject const &amp;)+A o<br>&gt; .text:6FB135A0 ;<br>&gt; CComPlusObject::CComPlusObject(ITypeInfo *)<br>&gt; .text:6FB135A0 ;<br>&gt; CComPlusObject::vector deleting destructor’(uint)
>
> .text:6FB135A4 dd offset ?xxxxx@CComPlusObject@@UAEJXZ ;
> CComPlusObject::Init(void)
> .text:6FB135A8 dd offset purecall
> .text:6FB135AC dd offset purecall
> .text:6FB135B0 dd offset ?xxxxx@CComPlusObject
> @@UAEJPAK@Z ;
> .text:6FB135B4 dd offset ?xxxxx@CComPlusObject
> @@UAEJPAPAG0PAK0@Z
> .text:6FB135B8 dd offset ?xxxxx@CComPlusObject
> @@UAEJPAU_GUID@@@Z
> .text:6FB135C0 dd offset ?xxxxx@CComPlusObject
> @@UAEJPAK@Z
> …
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

9

For the name mangling look at
http://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B_Name_Mangling

–
Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“Deepak Gupta” wrote in message news:xxxxx@ntdev…
> hmm interesting.
> May be some C++ compiler expert can give suggestions here on how names are
> mangled and what does they signify.
> Because loader must also know about this on how to fill the vftable.
> So there must be a way to distinguish.
>
> Regards
> Deepak
>
> On Thu, May 21, 2009 at 2:34 PM, wrote:
>
>> Thanks for looking, I also tried to export a variable and a class having
>> virtual function from a DLL. These exported symbols went to the .rdata
>> section.
>>
>> But if we check some windows DLLs like “catsrvut.dll” in system32 folder
>> there are some symbols for virtual function table like…
>> ??_7CComPlusMethod@@6B@
>> ??_7CComPlusObject@@6B@
>>
>> all these are present in the .text section.
>>
>> If we check these in IDAPro it will show something like
>>
>> .text:6FB135A0 ; Exported entry 28. ??_7CComPlusObject@@6B@
>> .text:6FB135A0 public ??_7CComPlusObject@@6B@
>> .text:6FB135A0 ; const CComPlusObject::vftable'<br>&gt;&gt;<br>&gt;&gt; .text:6FB135A0 ??_7CComPlusObject@@6B@ dd offset ??_ECComPlusObject@<br>&gt;&gt; @UAEPAXI@Z<br>&gt;&gt; .text:6FB135A0 ; DATA XREF:<br>&gt;&gt; CComPlusObject::CComPlusObject(CComPlusObject const &amp;)+A o<br>&gt;&gt; .text:6FB135A0 ;<br>&gt;&gt; CComPlusObject::CComPlusObject(ITypeInfo *)<br>&gt;&gt; .text:6FB135A0 ;<br>&gt;&gt; CComPlusObject::vector deleting destructor’(uint)
>>
>> .text:6FB135A4 dd offset ?xxxxx@CComPlusObject@@UAEJXZ ;
>> CComPlusObject::Init(void)
>> .text:6FB135A8 dd offset purecall
>> .text:6FB135AC dd offset purecall
>> .text:6FB135B0 dd offset ?xxxxx@CComPlusObject
>> @@UAEJPAK@Z ;
>> .text:6FB135B4 dd offset ?xxxxx@CComPlusObject
>> @@UAEJPAPAG0PAK0@Z
>> .text:6FB135B8 dd offset ?xxxxx@CComPlusObject
>> @@UAEJPAU_GUID@@@Z
>> .text:6FB135C0 dd offset ?xxxxx@CComPlusObject
>> @@UAEJPAK@Z
>> …
>>
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
>
>
> Information from ESET NOD32 Antivirus, version of virus
> signature database 4093 (20090521)
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>

Information from ESET NOD32 Antivirus, version of virus signature database 4093 (20090521)

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

10

So it gets clear from the link given by Don.
Code 7 with a preceeding underline means a ‘vftable’

Regards
Deepak

On Thu, May 21, 2009 at 3:36 PM, Don Burn wrote:

> For the name mangling look at
> http://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B_Name_Mangling
>
> –
> Don Burn (MVP, Windows DDK)
> Windows Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
>
>
>
> “Deepak Gupta” wrote in message news:xxxxx@ntdev.
> …
> > hmm interesting.
> > May be some C++ compiler expert can give suggestions here on how names
> are
> > mangled and what does they signify.
> > Because loader must also know about this on how to fill the vftable.
> > So there must be a way to distinguish.
> >
> > Regards
> > Deepak
> >
> > On Thu, May 21, 2009 at 2:34 PM, wrote:
> >
> >> Thanks for looking, I also tried to export a variable and a class having
> >> virtual function from a DLL. These exported symbols went to the .rdata
> >> section.
> >>
> >> But if we check some windows DLLs like “catsrvut.dll” in system32 folder
> >> there are some symbols for virtual function table like…
> >> ??_7CComPlusMethod@@6B@
> >> ??_7CComPlusObject@@6B@
> >>
> >> all these are present in the .text section.
> >>
> >> If we check these in IDAPro it will show something like
> >>
> >> .text:6FB135A0 ; Exported entry 28. ??_7CComPlusObject@@6B@
> >> .text:6FB135A0 public ??_7CComPlusObject@@6B@
> >> .text:6FB135A0 ; const CComPlusObject::vftable'<br>&gt; &gt;&gt;<br>&gt; &gt;&gt; .text:6FB135A0 ??_7CComPlusObject@@6B@ dd offset ??_ECComPlusObject@<br>&gt; &gt;&gt; @UAEPAXI@Z<br>&gt; &gt;&gt; .text:6FB135A0 ; DATA XREF:<br>&gt; &gt;&gt; CComPlusObject::CComPlusObject(CComPlusObject const &amp;)+A o<br>&gt; &gt;&gt; .text:6FB135A0 ;<br>&gt; &gt;&gt; CComPlusObject::CComPlusObject(ITypeInfo *)<br>&gt; &gt;&gt; .text:6FB135A0 ;<br>&gt; &gt;&gt; CComPlusObject::vector deleting destructor’(uint)
> >>
> >> .text:6FB135A4 dd offset ?xxxxx@CComPlusObject@@UAEJXZ ;
> >> CComPlusObject::Init(void)
> >> .text:6FB135A8 dd offset purecall
> >> .text:6FB135AC dd offset purecall
> >> .text:6FB135B0 dd offset ?xxxxx@CComPlusObject
> >> @@UAEJPAK@Z ;
> >> .text:6FB135B4 dd offset
> ?xxxxx@CComPlusObject
> >> @@UAEJPAPAG0PAK0@Z
> >> .text:6FB135B8 dd offset ?xxxxx@CComPlusObject
> >> @@UAEJPAU_GUID@@@Z
> >> .text:6FB135C0 dd offset
> ?xxxxx@CComPlusObject
> >> @@UAEJPAK@Z
> >> …
> >>
> >>
> >>
> >> —
> >> NTDEV is sponsored by OSR
> >>
> >> For our schedule of WDF, WDM, debugging and other seminars visit:
> >> http://www.osr.com/seminars
> >>
> >> To unsubscribe, visit the List Server section of OSR Online at
> >> http://www.osronline.com/page.cfm?name=ListServer
> >>
> >
> >
> >
> > Information from ESET NOD32 Antivirus, version of virus
> > signature database 4093 (20090521)
> >
> > The message was checked by ESET NOD32 Antivirus.
> >
> > http://www.eset.com
> >
> >
>
>
>
> Information from ESET NOD32 Antivirus, version of virus
> signature database 4093 (20090521)
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

11

So your EAT parser should handle C++ mangled and Managed mangled exports
correctly.
Parsing mangled names properly will let you know if it is exported function
or not.

Regards
Deepak

On Thu, May 21, 2009 at 4:35 PM, Deepak Gupta wrote:

> So it gets clear from the link given by Don.
> Code 7 with a preceeding underline means a ‘vftable’
>
> Regards
> Deepak
>
>
> On Thu, May 21, 2009 at 3:36 PM, Don Burn wrote:
>
>> For the name mangling look at
>> http://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B_Name_Mangling
>>
>> –
>> Don Burn (MVP, Windows DDK)
>> Windows Filesystem and Driver Consulting
>> Website: http://www.windrvr.com
>> Blog: http://msmvps.com/blogs/WinDrvr
>>
>>
>>
>> “Deepak Gupta” wrote in message
>> news:xxxxx@ntdev…
>> > hmm interesting.
>> > May be some C++ compiler expert can give suggestions here on how names
>> are
>> > mangled and what does they signify.
>> > Because loader must also know about this on how to fill the vftable.
>> > So there must be a way to distinguish.
>> >
>> > Regards
>> > Deepak
>> >
>> > On Thu, May 21, 2009 at 2:34 PM, wrote:
>> >
>> >> Thanks for looking, I also tried to export a variable and a class
>> having
>> >> virtual function from a DLL. These exported symbols went to the .rdata
>> >> section.
>> >>
>> >> But if we check some windows DLLs like “catsrvut.dll” in system32
>> folder
>> >> there are some symbols for virtual function table like…
>> >> ??_7CComPlusMethod@@6B@
>> >> ??_7CComPlusObject@@6B@
>> >>
>> >> all these are present in the .text section.
>> >>
>> >> If we check these in IDAPro it will show something like
>> >>
>> >> .text:6FB135A0 ; Exported entry 28. ??_7CComPlusObject@@6B@
>> >> .text:6FB135A0 public ??_7CComPlusObject@@6B@
>> >> .text:6FB135A0 ; const CComPlusObject::vftable'<br>&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; .text:6FB135A0 ??_7CComPlusObject@@6B@ dd offset ??_ECComPlusObject@<br>&gt;&gt; &gt;&gt; @UAEPAXI@Z<br>&gt;&gt; &gt;&gt; .text:6FB135A0 ; DATA XREF:<br>&gt;&gt; &gt;&gt; CComPlusObject::CComPlusObject(CComPlusObject const &amp;)+A o<br>&gt;&gt; &gt;&gt; .text:6FB135A0 ;<br>&gt;&gt; &gt;&gt; CComPlusObject::CComPlusObject(ITypeInfo *)<br>&gt;&gt; &gt;&gt; .text:6FB135A0 ;<br>&gt;&gt; &gt;&gt; CComPlusObject::vector deleting destructor’(uint)
>> >>
>> >> .text:6FB135A4 dd offset ?xxxxx@CComPlusObject@@UAEJXZ
>> ;
>> >> CComPlusObject::Init(void)
>> >> .text:6FB135A8 dd offset purecall
>> >> .text:6FB135AC dd offset purecall
>> >> .text:6FB135B0 dd offset ?xxxxx@CComPlusObject
>> >> @@UAEJPAK@Z ;
>> >> .text:6FB135B4 dd offset
>> ?xxxxx@CComPlusObject
>> >> @@UAEJPAPAG0PAK0@Z
>> >> .text:6FB135B8 dd offset ?xxxxx@CComPlusObject
>> >> @@UAEJPAU_GUID@@@Z
>> >> .text:6FB135C0 dd offset
>> ?xxxxx@CComPlusObject
>> >> @@UAEJPAK@Z
>> >> …
>> >>
>> >>
>> >>
>> >> —
>> >> NTDEV is sponsored by OSR
>> >>
>> >> For our schedule of WDF, WDM, debugging and other seminars visit:
>> >> http://www.osr.com/seminars
>> >>
>> >> To unsubscribe, visit the List Server section of OSR Online at
>> >> http://www.osronline.com/page.cfm?name=ListServer
>> >>
>> >
>> >
>> >
>> > Information from ESET NOD32 Antivirus, version of virus
>> > signature database 4093 (20090521)
>> >
>> > The message was checked by ESET NOD32 Antivirus.
>> >
>> > http://www.eset.com
>> >
>> >
>>
>>
>>
>> Information from ESET NOD32 Antivirus, version of virus
>> signature database 4093 (20090521)
>>
>> The message was checked by ESET NOD32 Antivirus.
>>
>> http://www.eset.com
>>
>>
>>
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
>

12

Thanks Don, Deepak
The name mangling rules will be useful in determining the type of exported symbols.

13

This is not going to work reliably. There is no identifying information about whether an export is code or data as the loader has no need to care about that.

Other constant globals could be in .text, or even writable globals if .text and .data were merged. Decorated name parsing will not help there, nor with an app written against a different compiler or language entirely. Furthermore, as I recall, cl’s name decoration format is undocumented and subject to change.

To the OP, what is the underlying goal that is driving you down this path? Note that there might be a hotpatched QFE applied to a particular system, and that may entail a jump sequence at the beginning of a function.

  • S

From: Deepak Gupta
Sent: Thursday, May 21, 2009 04:13
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] How to determine if an exported symbol is a variable in EAT

So your EAT parser should handle C++ mangled and Managed mangled exports correctly.
Parsing mangled names properly will let you know if it is exported function or not.

Regards
Deepak

On Thu, May 21, 2009 at 4:35 PM, Deepak Gupta > wrote:
So it gets clear from the link given by Don.
Code 7 with a preceeding underline means a ‘vftable’

Regards
Deepak

On Thu, May 21, 2009 at 3:36 PM, Don Burn > wrote:
For the name mangling look at
http://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B_Name_Mangling

–
Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“Deepak Gupta” > wrote in message news:xxxxx@ntdev…
> hmm interesting.
> May be some C++ compiler expert can give suggestions here on how names are
> mangled and what does they signify.
> Because loader must also know about this on how to fill the vftable.
> So there must be a way to distinguish.
>
> Regards
> Deepak
>
> On Thu, May 21, 2009 at 2:34 PM, > wrote:
>
>> Thanks for looking, I also tried to export a variable and a class having
>> virtual function from a DLL. These exported symbols went to the .rdata
>> section.
>>
>> But if we check some windows DLLs like “catsrvut.dll” in system32 folder
>> there are some symbols for virtual function table like…
>> ??_7CComPlusMethod@@6B@
>> ??_7CComPlusObject@@6B@
>>
>> all these are present in the .text section.
>>
>> If we check these in IDAPro it will show something like
>>
>> .text:6FB135A0 ; Exported entry 28. ??_7CComPlusObject@@6B@
>> .text:6FB135A0 public ??_7CComPlusObject@@6B@
>> .text:6FB135A0 ; const CComPlusObject::vftable'<br>&gt;&gt;<br>&gt;&gt; .text:6FB135A0 ??_7CComPlusObject@@6B@ dd offset ??_ECComPlusObject@<br>&gt;&gt; @UAEPAXI@Z<br>&gt;&gt; .text:6FB135A0 ; DATA XREF:<br>&gt;&gt; CComPlusObject::CComPlusObject(CComPlusObject const &amp;)+A o<br>&gt;&gt; .text:6FB135A0 ;<br>&gt;&gt; CComPlusObject::CComPlusObject(ITypeInfo *)<br>&gt;&gt; .text:6FB135A0 ;<br>&gt;&gt; CComPlusObject::vector deleting destructor’(uint)
>>
>> .text:6FB135A4 dd offset ?xxxxx@CComPlusObject@@UAEJXZ ;
>> CComPlusObject::Init(void)
>> .text:6FB135A8 dd offset purecall
>> .text:6FB135AC dd offset purecall
>> .text:6FB135B0 dd offset ?xxxxx@CComPlusObject
>> @@UAEJPAK@Z ;
>> .text:6FB135B4 dd offset ?xxxxx@CComPlusObject
>> @@UAEJPAPAG0PAK0@Z
>> .text:6FB135B8 dd offset ?xxxxx@CComPlusObject
>> @@UAEJPAU_GUID@@@Z
>> .text:6FB135C0 dd offset ?xxxxx@CComPlusObject
>> @@UAEJPAK@Z
>> …
>>
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
>
>
> Information from ESET NOD32 Antivirus, version of virus
> signature database 4093 (20090521)
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>

Information from ESET NOD32 Antivirus, version of virus signature database 4093 (20090521)

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

14

Deepak Gupta wrote:

hmm interesting.
May be some C++ compiler expert can give suggestions here on how names
are mangled and what does they signify.

You can easily reverse engineer this. The “undname” utility that ships
with Visual C++ (which stands for “undecorate name”) will show you the
original function declaration.

C:\VS9\VC\bin>undname ?xxxxx@CComPlusObject@@UAEJPAK@Z
Microsoft (R) C++ Name Undecorator
Copyright (C) Microsoft Corporation. All rights reserved.

Undecoration of :- “?xxxxx@CComPlusObject@@UAEJPAK@Z”
is :- “public: virtual long __thiscall
CComPlusObject::GetChildCount(unsigned long *)”

C:\VS9\VC\bin>

Because loader must also know about this on how to fill the vftable.

Why do you think the loader cares? To the loader, they are all just
addresses. It’s only the code that assigns meaning to the number (that
is, is this address a function or a piece of data). The loader has no idea.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

15

> To the OP, what is the underlying goal that is driving you down this path? Note

that there might be a hotpatched QFE applied to a particular system, and that
may entail a jump sequence at the beginning of a function.

Our main goal is to find any inline hooks in an exported function. Even if its a valid inline hook due to a patch still its fine, but due to exported variables we incorrectly assume them to be exported functions and try to find inline hooks in the binary data in the memory area where they are present. This way we find false hooks.

I was wondering how do tools like IDA Pro identify whether the exported symbol is a vftable or a function. If we see the vftable in IDA Pro it correctly shows the binary data next to them as addresses to class functions.

16

On 5/22/09, xxxxx@hcl.in wrote:
>
> > To the OP, what is the underlying goal that is driving you down this
> path? Note
> > that there might be a hotpatched QFE applied to a particular system, and
> that
> > may entail a jump sequence at the beginning of a function.
>
> Our main goal is to find any inline hooks in an exported function. Even if
> its a valid inline hook due to a patch still its fine, but due to exported
> variables we incorrectly assume them to be exported functions and try to
> find inline hooks in the binary data in the memory area where they are
> present. This way we find false hooks.
>
> I was wondering how do tools like IDA Pro identify whether the exported
> symbol is a vftable or a function. If we see the vftable in IDA Pro it
> correctly shows the binary data next to them as addresses to class
> functions.

UnDecorateSymbolName(x, x, x, UNDNAME_COMPLETE)

thats all it takes to undecorate any mangled symbol

UndecorateSymbolName() is a wrapper to __unDName in msvcrt.dll

and results for mangled names in your posts will turnout to be

?xxxxx@CAutoWindows@@1UAFX_INTERFACEMAP@@B
protected: static struct AFX_INTERFACEMAP const CAutoWindows::interfaceMap
?xxxxx@CApplication@@1UAFX_DISPMAP@@B
protected: static struct AFX_DISPMAP const CApplication::dispatchMap
?xxxxx@CApplication@@2U_GUID@@B
public: static struct _GUID const CApplication::guid
?xxxxx@CDocObjectDoc@@1UAFX_MSGMAP@@B
protected: static struct AFX_MSGMAP const CDocObjectDoc::messageMap
??_7CComPlusMethod@@6B@
const CComPlusMethod::vftable'<br>??_7CComPlusObject@@6B@<br>const CComPlusObject::vftable’

17

Name decoration might be able to help in some cases, but not in all, and anyone who wishes may with a little effort produces names that happen to look like a vftable or whatever. Now, that’s not a very likely scenario, but if you’re looking for inline hooks, I can’t say that I would assume it wouldn’t happen under those circumstances.

As others have already pointed out, to the loader, they are all just addresses, so in my opinion, that’s the only way you can processes them. That is, to rule out the case of disassembled data, you need to be able to rule of the target address; if you can’t, then you’re stuck.

As far as IDA goes, take a look the FLAIR SDK.

Good luck,

mm

18

Not to mention that behavior that looks like an inline hook could be completely normal even under other mundane circumstances. Consider also an exported function that forwards the call on to another dllimport (not a forwarder export); on optimized builds, that would often show as an immediate jump out of file.

The whole premise that hooks vs things that are supposed to be there can be detected for general purpose code without diffing against a known-good copy seems fundamentally inacheivable to me.

  • S

-----Original Message-----
From: xxxxx@evitechnology.com
Sent: Saturday, May 23, 2009 14:10
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to determine if an exported symbol is a variable in EAT

Name decoration might be able to help in some cases, but not in all, and anyone who wishes may with a little effort produces names that happen to look like a vftable or whatever. Now, that’s not a very likely scenario, but if you’re looking for inline hooks, I can’t say that I would assume it wouldn’t happen under those circumstances.

As others have already pointed out, to the loader, they are all just addresses, so in my opinion, that’s the only way you can processes them. That is, to rule out the case of disassembled data, you need to be able to rule of the target address; if you can’t, then you’re stuck.

As far as IDA goes, take a look the FLAIR SDK.

Good luck,

mm

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

19

+1

If you’ve got specific scenario with costs for false positives acceptable to all involved, perhaps, but otherwise, I don’t see how this can be done without causing problems.

mm