Hi Jeremy,
I was wondering how I could get (at run-time) the address of the jump table entry for an API function. For clarification, when GoAsm calls say GetModuleHandleA it actually calls an address in a jump table that usually looks like
push 0
call 0x00409000
...
00409000: jmp D[hInstance+0x926c (0040926c)]
The following will obtain the true address of GetModuleHandleA (0x74E51245)
push [GetModuleHandleA]
pop eax
Examining the code shows that the PUSH [GetModuleHandleA] encodes as PUSH [0x0040926c], which I assume is the address of the "fixed up" procedure entry point in the jump table. What I am looking for is the address of the JMP instruction (0x00409000) since I am looking to map the symbol based on the CALL instruction, is there an easy way to get this address at run-time ?
Edgar
mov eax, dword ptr [DispatchMessage+2] ; eax->jmp address of DispatchMessage
mov ESI, [eax] ; esi->real addres of DispatchMessage API
....
....
....
MsgLoop:
invoke GetMessage, addr msg, 0,0,0
test eax, eax
je ExitProcess
invoke TranslateMessage, addr msg
PUSH MSG
CALL ESI ; call DisapatchMessage API
jmp MsgLoop
mov eax,GetModuleHandleA
:P
Hi Edgar
Unfortunately mov eax,GetModuleHandle throws up an error.
However this works:-
MyLabel: CALL [SendMessageA]
;
START:
MOV EAX,[MyLabel+2]
RET
The code at MyLabel is never actually called, it just serves as a code label.
The code at "START" should load (in your example) the value 40926Ch.
Is this what you are after?
hi Jeremy
it works with masm
Quote from: jorgon on April 29, 2011, 08:14:23 AM
Hi Edgar
Unfortunately mov eax,GetModuleHandle throws up an error.
However this works:-
MyLabel: CALL [SendMessageA]
;
START:
MOV EAX,[MyLabel+2]
RET
The code at MyLabel is never actually called, it just serves as a code label.
The code at "START" should load (in your example) the value 40926Ch.
Is this what you are after?
That's perfect, thanks Jeremy. I'll have to figure out how to get it done dynamically. It shouldn't be too much of an issue as I know that GetModuleHandle should always be the first entry in the table (with GetProcAddress second) I will be able to locate the jump table and use that to unravel the imports and get the data I need.
Quote from: dedndave on April 29, 2011, 11:35:17 AM
hi Jeremy
it works with masm
Hey Dave,
Two different assemblers I'm afraid, there are many things that GoAsm does that would give MASM fits and vice versa. Jeremy never designed GoAsm to be MASM compatible.
Quote...GetModuleHandle should always be the first entry in the table (with GetProcAddress second)
is that always the case ?
i would like to be able to locate the table for an idea i had - to work backwards and find the strings :P
i can locate one, then step backwards, but that isn't very clean - lol
it would be nice to find the base of the table easily
Hi Dave,
I have never seen a PE file without those as the first two entries, at worst they will be in the first few so if you find the lower page boundary of the entry you should be at the start of the jump table. But AFAIK they are always 1 & 2. If your looking for the strings, they are not there, at least not in the executable once the PE loader is done. You can use SymFromAddr but I am desperately trying to solve an "Invalid Parameter" error that is dogging the function for me. As it is I have enumerated all possible calls in all loaded modules and sorted them by entry point (its actually pretty fast) and am searching for the entry in the array by address. I can post a snippet if you like.
I believe that MASM defines a symbol for each import in the form user32!GetDlgItem, you can get that symbol through a dump of the symbol table. Try my debug tool for RadAsm and use DumpSymbols to check it.
by all means, Edgar - post the snippet - maybe someone can provide a fresh look at it :bg
i looked inside an exe...
i didn't assemble with any special switches
ml /c /coff OSInfo30.asm
polink /SUBSYSTEM:WINDOWS /OPT:NOREF OSInfo30.obj OSInfo30.res
i am pretty sure i get the same result using Link
my thinking was - you could make a neat little error reporting routine with the strings that are already there :bg
jump tables:
(http://www.masm32.com/board/index.php?action=dlattach;topic=16576.0;id=9173)
strings:
(http://www.masm32.com/board/index.php?action=dlattach;topic=16576.0;id=9174)
the attachments are the above PNG images renamed to ZIP
Hi Dave,
They are in the PE but are they in the memory image of the running process ? I have always assumed they were discarded by the PE loader once they have been located and fixed.
Mmmm. The definition for SYMBOL_INFO at msdn is:
typedef struct _SYMBOL_INFO {
ULONG SizeOfStruct;
ULONG TypeIndex;
ULONG64 Reserved[2];
ULONG Index;
ULONG Size;
ULONG64 ModBase;
ULONG Flags;
ULONG64 Value;
ULONG64 Address;
ULONG Register;
ULONG Scope;
ULONG Tag;
ULONG NameLen;
ULONG MaxNameLen;
TCHAR Name[1];
} SYMBOL_INFO, *PSYMBOL_INFO;
Now if you count the bytes, you come up with 81 bytes. However, if you do as MS does in its examples and pass SIZEOF SYMBOL_INFO in the buffer for SymFromAddr, you get the "Invalid Parameter" error. On inspection of the output from dbghelp, SizeOfStruct should be set to 88 bytes, though I have no idea where they get that number from. There is at least one member missing from the definition for 32 bits, one of the ULONG parameters is actually a ULONG64 though I haven't found which one yet, this could be an alignment issue though, its just very difficult to check the parameters to see if they are valid.
At any rate I've been working out the kinks in SymByAddr and hopefully I can use that function eventually but for now I am building my own table like this:
SYMBOLENTRY struct
Name DB 64 DUP
Module DB 32 DUP
Address DQ ?
Type DD ?
ends
GetSymbols FRAME DbgType
LOCAL hProcess:%HANDLE
// Use common controls DPA, this will be replaced with a more
// efficient array once testing is done, for now its reliable and
// one less thing to debug.
invoke DPA_CreateEx,32,NULL
mov [hSymbols],eax
// You can just use -1 in place of hProcess
invoke GetCurrentProcess
mov [hProcess],eax
// Initialize. invade the process and load all modules
invoke SymInitialize,[hProcess],0, TRUE
// Enumerate everything (usually over 13,000 symbols)
invoke SymEnumSymbols,[hProcess],0,0,"*!*",offset SymEnumSymbolsProc, [DbgType]
// Shut it down
invoke SymCleanup,[hProcess]
// Sort the symbols by address
invoke DPA_Sort,[hSymbols],offset SortSymbolTable,0
ret
endf
SymEnumSymbolsProc FRAME pSymInfo, SymbolSize, UserContext
uses edi,ebx
LOCAL mbi:MEMORY_BASIC_INFORMATION
LOCAL SymModInfo:IMAGEHLP_MODULE64
mov edi,[pSymInfo]
add edi,4
// Get the protection for this symbol
invoke VirtualQuery,[edi+SYMBOL_INFO.Address],offset mbi,SIZEOF MEMORY_BASIC_INFORMATION
mov eax,[mbi.Protect]
mov D[SymModInfo.SizeOfStruct],SIZEOF IMAGEHLP_MODULE64
invoke SymGetModuleInfo64,-1,[edi+SYMBOL_INFO.Address],[edi+SYMBOL_INFO.Address+4],offset SymModInfo
lea edx,SymModInfo
add edx,IMAGEHLP_MODULE64.ModuleName
lea eax,edi+SYMBOL_INFO.Name
invoke AddSymbolToTable,eax,edx,[edi+SYMBOL_INFO.Address],[edi+SYMBOL_INFO.Address+4],[mbi.Protect]
.EXIT
mov eax,TRUE
RET
ENDF
AddSymbolToTable FRAME pszSymbol, pszModule, pSymbol, pSymbolHi,iType
uses ebx
invoke GlobalAlloc,GMEM_FIXED,SIZEOF SYMBOLENTRY
mov ebx,eax
invoke lstrcpyn,ebx,[pszSymbol],63
lea eax,ebx+SYMBOLENTRY.Module
invoke lstrcpyn,eax,[pszModule],31
mov eax,[pSymbol]
mov [ebx+SYMBOLENTRY.Address],eax
mov eax,[pSymbolHi]
mov D[ebx+SYMBOLENTRY.Address+4],eax
mov eax,[iType]
mov [ebx+SYMBOLENTRY.Type],eax
invoke DPA_InsertPtr,[hSymbols],DPA_APPEND,ebx
ret
endf
SortSymbolTable FRAME pItem1,pItem2,lParam
// Sort the array by SYMBOLENTRY.Address
mov eax,[pItem1]
mov eax,[eax+SYMBOLENTRY.Address]
mov ecx,[pItem2]
mov ecx,[ecx+SYMBOLENTRY.Address]
cmp eax,ecx
jle >
xor eax,eax
inc eax
ret
:
jl >
xor eax,eax
ret
:
xor eax,eax
dec eax
ret
endf
DestroySymbolTable FRAME pItem, pData
invoke GlobalFree,[pItem]
ret
endf
Well, I have finally got the bugs out of my FindSymbol routine, so all of the above work was for nothing :) The last issue was that unmentioned by the entry at MSDN, you *MUST* use CoTaskMemAlloc to allocate the buffer for SymByAddr, I could not get it to work with GlobalAlloc and it was a tough bug to track down. Here's how to search for a symbol using the DBGHELP api. It also gives the displacement from the symbol found, in this example the symbol found is GetModuleHandleA and the displacement is +5:
push [GetModuleHandleA]
pop eax
add eax,5
invoke FindSymbol,-1,eax
FindSymbol FRAME hProcess, pAddress
LOCAL Displacement:Q
LOCAL pSymInfo:D
LOCAL SymModInfo:IMAGEHLP_MODULE64
invoke CoTaskMemAlloc,SIZEOF SYMBOL_INFO+MAX_SYM_NAME
mov [pSymInfo],eax
mov D[eax+SYMBOL_INFO.MaxNameLen],MAX_SYM_NAME
mov D[eax+SYMBOL_INFO.SizeOfStruct],88
// invade process, load all modules
invoke SymInitialize,[hProcess],0, TRUE
invoke SymFromAddr,[hProcess],[pAddress],0,offset Displacement,[pSymInfo]
mov eax,[pSymInfo]
add eax,SYMBOL_INFO.Name
add eax,4 // The annoying displacement I can't figure out
// EAX points to the symbol name
mov D[SymModInfo.SizeOfStruct],SIZEOF IMAGEHLP_MODULE64
invoke SymGetModuleInfo64,[hProcess],[pAddress],0,offset SymModInfo
lea eax,SymModInfo+IMAGEHLP_MODULE64.ModuleName
// EAX point to the module name (eg Kernel32)
// Shut it down
invoke SymCleanup,[hProcess]
invoke CoTaskMemFree,[pSymInfo]
xor eax,eax
RET
ENDF
Note that this is GoAsm code so QWORDs require 2 pushes, in any MASM translation you can remove the second push.
For some reason the MSDN structure is different from the structure in the 2003 PSDK.
The Microsoft compilers align the structure according the rules specified here:
http://msdn.microsoft.com/en-us/library/Aa290049
Edit: Added code to display the alignment of the structure, and the 4-byte alignment does not appear to match what the linked article specifies.
Output for the EXE in the attachment, compiled with the Microsoft Visual C++ Toolkit 2003 compiler:
sizeof(si) 88
address of si 12FE8C
alignment of si 4
SizeOfStruct 12FE8C 4
TypeIndex 12FE90 12FE90 4
Reserved 12FE94 12FE94 16
Index 12FEA4 12FEA4 4
Size 12FEA8 12FEA8 4
ModBase 12FEAC 12FEAC 8
Flags 12FEB4 12FEB4 4
Value 12FEBC 12FEB8 8
Address 12FEC4 12FEC4 8
Register 12FECC 12FECC 4
Scope 12FED0 12FED0 4
Tag 12FED4 12FED4 4
NameLen 12FED8 12FED8 4
MaxNameLen 12FEDC 12FEDC 4
Name 12FEE0 12FEE0 1
Hi Michael,
I'm not quite sure about the output you posted, there are some values that don't make sense to me, for example size of Reserved should be 16 bytes (2 x DQ). I will have to continue my investigation to try to get this thing right. Thanks for the alignment link, however since the only change that has to be made to conform to the requirements is to make Name 4 bytes instead of 1, the structure still presents the same problem, the annoying 4 byte alignment error.
Since your output shows that the Value member is moved ahead 4 bytes I am going to go on the assumption that that is the issue and try it out like this:
typedef struct _SYMBOL_INFO_ {
ULONG SizeOfStruct;
ULONG TypeIndex;
ULONG64 Reserved[2];
ULONG Index;
ULONG Size;
ULONG64 ModBase;
ULONG Flags;
ULONG Reserved2; <<<<<<< Added padding
ULONG64 Value;
ULONG64 Address;
ULONG Register;
ULONG Scope;
ULONG Tag;
ULONG NameLen;
ULONG MaxNameLen;
TCHAR Name[4]; <<<<<<< Added 3 bytes for alignment
} SYMBOL_INFO_;
The only members of interest with the exception of SizeOfStruct are from Address on and they appear to work so.
EDIT: Flags appears to be correct (shows 0x200 for exports, 0 for internal) so I am going with this as the final structure fix.
QuoteWas due to C using 8 byte packing whereas VB uses 4 byte packing. Inserting a padding long integer before .Flags fixed it.
http://www.boards.ie/vbulletin/showthread.php?t=175286
Hi Dave,
That appears to be incorrect, my tests have shown that the Flags are only right if the padding is inserted after them, otherwise I don't get the correct value for export symbols just 0 which is not what the output should be (except for internals).
here's another one where they padded between Register and Scope :lol
Public Type SYMBOL_INFO
SizeOfStruct As Long
TypeIndex As Long
Reserved(1 To 2) As Currency
Index As Long
size As Long
ModBase As Currency
Flags As Long
Value As Currency
Address As Currency
Register As Long
padding As Long
Scope As Long
Tag As Long
NameLen As Long
MaxNameLen As Long
End Type
http://www.codeguru.com/forum/showthread.php?t=303118
and another that reports a discrepancy between ansi and unicode docs
http://jpassing.com/2008/02/19/glitch-in-documentation-of-symbol_info/
this structure has all kinds of problems - lol
Hi Dave,
The correct structure, properly aligned is:
SYMBOL_INFO STRUCT
SizeOfStruct DD
TypeIndex DD
Reserved DQ 2 DUP
Index DD
Size DD
ModBase DQ
Flags DD
Reserved2 DD
Value DQ
Address DQ
Register DD
Scope DD
Tag DD
NameLen DD
MaxNameLen DD
Name DB 4 DUP
ENDS
The example code at MSDN (http://msdn.microsoft.com/en-us/library/ms680578%28v=vs.85%29.aspx) shows that the SizeOfStruct member is filled with SIZEOF SYMBOL_INFO, allowing for the padding of Name to 4 bytes that is 88 bytes:
All members that are verifiable (SizeOfStruct, ModBase, Flags, Address, Tag, NameLen, MaxNameLen and Name) are correct with this version of the structure. It will be corrected in the GoAsm header files in the next upload on Sunday.
Edgar
This is the final version of FindSymbol as it will appear in my application if anyone is interested. It uses the SYMBOL_INFO above.
DATA SECTION
SymName DB 256 DUP (?)
ModName DB 256 DUP (?)
Displ DD ?
CODE SECTION
push [GetWindowLongA]
pop eax
add eax,5
invoke FindSymbol,-1,eax,offset SymName,offset ModName,offset Displ
FindSymbol FRAME hProcess, pAddress, pszSymbol, pszModule, pdwDisplacment
LOCAL pSymInfo:D
LOCAL SymModInfo:IMAGEHLP_MODULE64
invoke CoTaskMemAlloc,SIZEOF SYMBOL_INFO+MAX_SYM_NAME-4
mov [pSymInfo],eax
mov D[eax+SYMBOL_INFO.MaxNameLen],MAX_SYM_NAME
mov D[eax+SYMBOL_INFO.SizeOfStruct],SIZEOF SYMBOL_INFO
// invade process, load all modules
invoke SymInitialize,[hProcess],0, TRUE
invoke SymFromAddr,[hProcess],[pAddress],0,[pdwDisplacment],[pSymInfo]
mov eax,[pSymInfo]
add eax,SYMBOL_INFO.Name
invoke lstrcpy,[pszSymbol],eax
mov D[SymModInfo.SizeOfStruct],SIZEOF IMAGEHLP_MODULE64
invoke SymGetModuleInfo64,[hProcess],[pAddress],0,offset SymModInfo
lea edx,SymModInfo+IMAGEHLP_MODULE64.ModuleName
invoke lstrcpy,[pszModule],edx
// Shut it down
invoke SymCleanup,[hProcess]
invoke CoTaskMemFree,[pSymInfo]
xor eax,eax
RET
ENDF
Output of the above test:
Line 130: SymName = GetWindowLongA
Line 131: ModName = USER32
Line 132: [Displ] = 5 (0x00000005)
Now I have to map this to GoAsm and MASM jump tables :)
Matt Pietrek has written some articles regarding DbgHelp that you may find useful
http://blog.csdn.net/is01sjjj/archive/2007/12/25/1966545.aspx
reading through that article, i see that he has written a demo program with well-commented source
http://www.wheaty.net/
in the downloads section...
http://www.wheaty.net/DbgHelpDemo.zip
i don't know how i got to this one - lol
but, it tells you some of the values of the Register member
http://msdn.microsoft.com/en-au/library/a0fcdkb9%28VS.71%29.aspx
Thanks Dave,
I occasionally exchange emails with the author of DbgHelp at Microsoft (he has some funny stories about how he managed to get it redistributable), I just don't like to bother him too much with questions that appear to be more about the language I am writing in than functional issues. Good articles and I like Pietrek, he doesn't clog up the works with a lot of useless information, I'll read through them.
The CV_ register members are defined in cvconst.h in my headers.
Hi Edgard,
Here is the SIMBOL_INFO struct as defined in the Windows SDK v7.1:
typedef struct _SYMBOL_INFO {
ULONG SizeOfStruct;
ULONG TypeIndex; // Type Index of symbol
ULONG64 Reserved[2];
ULONG Index;
ULONG Size;
ULONG64 ModBase; // Base Address of module comtaining this symbol
ULONG Flags;
ULONG64 Value; // Value of symbol, ValuePresent should be 1
ULONG64 Address; // Address of symbol including base address of module
ULONG Register; // register holding value or pointer to value
ULONG Scope; // scope of the symbol
ULONG Tag; // pdb classification
ULONG NameLen; // Actual length of name
ULONG MaxNameLen;
CHAR Name[1]; // Name of symbol
} SYMBOL_INFO, *PSYMBOL_INFO;
typedef struct _SYMBOL_INFOW {
ULONG SizeOfStruct;
ULONG TypeIndex; // Type Index of symbol
ULONG64 Reserved[2];
ULONG Index;
ULONG Size;
ULONG64 ModBase; // Base Address of module comtaining this symbol
ULONG Flags;
ULONG64 Value; // Value of symbol, ValuePresent should be 1
ULONG64 Address; // Address of symbol including base address of module
ULONG Register; // register holding value or pointer to value
ULONG Scope; // scope of the symbol
ULONG Tag; // pdb classification
ULONG NameLen; // Actual length of name
ULONG MaxNameLen;
WCHAR Name[1]; // Name of symbol
} SYMBOL_INFOW, *PSYMBOL_INFOW;
SizeOfStruct
The size of the structure, in bytes. This member must be set to sizeof(SYMBOL_INFO). Note that the total size of the data is the SizeOfStruct + (MaxNameLen - 1) * sizeof(TCHAR). The reason to subtract one is that the first character in the name is accounted for in the size of the structure.
I hope it can help you.
Ramon
Hi Ramon,
Yes, I have that structure, however using it without the padding for alignment after Flags and without padding Name to 4 bytes will cause it to fail (Value must be aligned to begin on a 8 byte boundary within the structure). Also if you count the bytes, there are 81 bytes allocated in that structure however, all Sym functions that use SYMBOL_INFO will fail if SizeOfStruct is not 88. This was the issue I was having with searching symbols.
I had the same issue with SYMBOL_INFO :) http://www.masm32.com/board/index.php?topic=11525.msg87167#msg87167
I see.
Hi Ramon,
Yeah it really threw me for a loop as well. Without knowing why I kept getting "Invalid parameter" errors and everything seemed perfect until I saw Michael's test program. Ah well, it will be fixed in the next update of the headers. For now I have the code that walks the jump table and gets the CALL addresses for the entry in the table (the JMP XXXX entry not the actual import table). I haven't done the building of my table yet but hockey is about to start so I'm done for today.
WalkJumpTable FRAME hProcess
uses ebx,edi,esi
LOCAL Displacement:D
LOCAL pSymInfo:D
LOCAL SymModInfo:IMAGEHLP_MODULE64
invoke CoTaskMemAlloc,SIZEOF SYMBOL_INFO+MAX_SYM_NAME-4
mov [pSymInfo],eax
mov D[eax+SYMBOL_INFO.MaxNameLen],MAX_SYM_NAME
mov D[eax+SYMBOL_INFO.SizeOfStruct],SIZEOF SYMBOL_INFO
invoke SymInitialize,[hProcess],0, TRUE
// Trick to get the jump table address - Thanks Jeremy !
jmp >JMPTABLEREL
JUMPTABLETEST: call GetModuleHandle
JMPTABLEREL:
mov ebx,[JUMPTABLETEST+1]
add ebx,offset JMPTABLEREL
and ebx,0xFFFFF000
.NEXTENTRY
mov ax,[ebx]
cmp ax,0x25FF
jne >>.EXIT
mov eax,[ebx+2]
mov eax,[eax]
push eax
invoke SymFromAddr,[hProcess],eax,0,offset Displacement,[pSymInfo]
test eax,eax
pop eax
jz >>.NOSYM
mov esi,[pSymInfo]
add esi,SYMBOL_INFO.Name
mov D[SymModInfo.SizeOfStruct],SIZEOF IMAGEHLP_MODULE64
invoke SymGetModuleInfo64,[hProcess],eax,0,offset SymModInfo
lea edi,SymModInfo+IMAGEHLP_MODULE64.ModuleName
invoke AddSymbolToCallTable,esi,edi,ebx
.NOSYM
add ebx,6
jmp .NEXTENTRY
.EXIT
invoke SymCleanup,[hProcess]
invoke CoTaskMemFree,[pSymInfo]
ret
endf
This will pass the symbol, module and address of the jump table entry address to a function called AddSymbolToCallTable (on the todo list).
Edgar
Although the method to get the address of the jump table works every time, it looks too much like a kludge to me and is not easily portable to other assemblers. Since the section that the jump table is in is .idata, we can find that sections address by parsing from the address of hInstance. This routine will return the address of the jump table in EAX or zero if it was not found. Haven't tried it on MASM yet but I will later this weekend or if someone wants to rewrite it for MASM and try it I'd appreciate knowing whether it works or not.
invoke GetModuleHandle, 0
invoke GetJumpTable,eax
GetJumpTable FRAME hInst
uses esi,edi,ebx
// Get the IMAGE_NT_HEADERS structure
mov ebx,[hInst]
mov edi,ebx
add ebx,[ebx+IMAGE_DOS_HEADER.e_lfanew]
// Get the offset of the first IMAGE_DATA_DIRECTORY entry
mov esi,[ebx+IMAGE_NT_HEADERS.FileHeader.SizeOfOptionalHeader]
and esi,0xFFFF
add esi,ebx
// jump past the IMAGE_FILE_HEADER and signature
add esi, SIZEOF IMAGE_FILE_HEADER + 4
movzx ebx,W[ebx+IMAGE_NT_HEADERS.FileHeader.NumberOfSections]
// ESI now points to an array of IMAGE_SECTION_HEADER structures so walk them
// EBX holds the number of entries in the array
.NEXTSECTION
invoke lstrcmpi,esi,".idata"
test eax,eax
jnz >.NOTOURS
mov eax,[esi+IMAGE_SECTION_HEADER.VirtualAddress]
add eax,edi
ret
.NOTOURS
add esi,SIZEOF IMAGE_SECTION_HEADER
dec ebx
jnz .NEXTSECTION
xor eax,eax
ret
ENDF
Quote from: donkey on April 29, 2011, 05:27:34 PM
I'm not quite sure about the output you posted, there are some values that don't make sense to me, for example size of Reserved should be 16 bytes (2 x DQ).
Sorry, I somehow posted the output for some earlier version of the code. I have updated my post. The structure is padded ahead of the Value member to place it at an 8-byte alignment, and padded at the end to make the size a multiple of 8 bytes.
Quote from: MichaelW on April 30, 2011, 03:07:36 AM
Quote from: donkey on April 29, 2011, 05:27:34 PM
I'm not quite sure about the output you posted, there are some values that don't make sense to me, for example size of Reserved should be 16 bytes (2 x DQ).
Sorry, I somehow posted the output for some earlier version of the code. I have updated my post. The structure is padded ahead of the Value member to place it at an 8-byte alignment, and padded at the end to make the size a multiple of 8 bytes.
Thanks Michael,
That confirms what I thought, that I needed to add 4 bytes of padding between Flags and Value and extend Name to 4 bytes.
@donkey
from your code :
.NEXTSECTION
invoke lstrcmpi,esi,".idata"
test eax,eax
jnz >.NOTOURS
mov eax,[esi+IMAGE_SECTION_HEADER.VirtualAddress]
add eax,edi
ret
.NOTOURS
add esi,SIZEOF IMAGE_SECTION_HEADER
dec ebx
jnz .NEXTSECTION
why do you presume that section name will be '.idata' ?
in fasm I can name it what ever I want...
shoudn't be better to check DataDirectory array in IMAGE_OPTIONAL_HEADER for import table address ?
Edgard,
Great! Congratulations!
Ramon
Quote from: dancho on April 30, 2011, 09:16:57 AM
@donkey
from your code :
.NEXTSECTION
invoke lstrcmpi,esi,".idata"
test eax,eax
jnz >.NOTOURS
mov eax,[esi+IMAGE_SECTION_HEADER.VirtualAddress]
add eax,edi
ret
.NOTOURS
add esi,SIZEOF IMAGE_SECTION_HEADER
dec ebx
jnz .NEXTSECTION
why do you presume that section name will be '.idata' ?
in fasm I can name it what ever I want...
shoudn't be better to check DataDirectory array in IMAGE_OPTIONAL_HEADER for import table address ?
It is for GoAsm, the import directory entry is always called .idata. I did try to get the RVA from the IMAGE_DATA_DIRECTORY structure and use that but the value I was getting was wrong. For example:
// EBX holds the address of the IMAGE_OPTIONAL_HEADER
mov eax,ebx
add eax, 104 // import directory
mov eax,[eax+IMAGE_DATA_DIRECTORY.VirtualAddress]
add eax,[hInst]The result is 0x00409188 while the address I'm looking for is 0x00409000. The following is a dump of the IMAGE_DATA_DIRECTORY.VirtualAddress entries in my test executable. None of them are particularly useful (Import address table is correct however I don't need that) though I could round the Import Table entry down to the nearest page boundary to get the proper result searching for idata gives it directly.
Export table = 0x00400000
Import table = 0x00409188
Resource table = 0x00407000
Exception table = 0x00400000
Certificate table = 0x00400000
Base relocation table = 0x00400000
Debugging information = 0x00408000
Architecture-specific data = 0x00400000
Global pointer register = 0x00400000
Thread local storage table = 0x00400000
Load configuration table = 0x00400000
Bound import table = 0x00400000)
Import address table = 0x00409278
Delay import descriptor = 0x00400000
The CLR header = 0x00400000
Reserved = 0x00400000
This appears to work, it assumes that the section table entries are in reverse order to the data directory entries, which appears to be the case. Since the export table can exist it is checked and the routine adjusts which section header it reads:
GetJumpTable FRAME hInst
uses esi,edi,ebx
// Get the IMAGE_NT_HEADERS structure
mov ebx,[hInst]
mov edi,ebx
add ebx,[ebx+IMAGE_DOS_HEADER.e_lfanew]
// Get the offset of the first IMAGE_DATA_DIRECTORY entry
mov esi,[ebx+IMAGE_NT_HEADERS.FileHeader.SizeOfOptionalHeader]
and esi,0xFFFF
add esi,ebx
// jump past the IMAGE_FILE_HEADER and signature ("PE\0\0")
add esi, SIZEOF IMAGE_FILE_HEADER + 4
mov eax,[ebx+IMAGE_NT_HEADERS.OptionalHeader.DataDirectory]
movzx ebx,W[ebx+IMAGE_NT_HEADERS.FileHeader.NumberOfSections]
dec ebx
test eax,eax
jz >
// Take the second last entry if an export table exists
// otherwise take the last entry
dec ebx
:
mov eax,SIZEOF IMAGE_SECTION_HEADER
mul ebx
add eax,esi
mov eax,[eax+IMAGE_SECTION_HEADER.VirtualAddress]
add eax,edi
ret
endf
I'm just not sure about the ordering of the IMAGE_SECTION_HEADER structures, are they always in the same order ?
@donkey
could you compile and attach some small exe for further testing,
atm Im programming small tool for processing exe files and
I would really like to see what number would I get...
thx
Hi dancho,
This routine can't really be used for other processes since it involves reading the process memory and that can be sticky even using ReadProcessMemory. I can try to work something out but that is outside of the scope of my current project which needs to get the information from itself. Not sure if I can get to it this weekend though.
@donkey
no problem at all,I understand...
btw
Quote
I'm just not sure about the ordering of the IMAGE_SECTION_HEADER structures, are they always in the same order ?
as far as I can say from my tests it is always from low to high VirtualAddress values...
something like this ( for exe type )
.bss
.code
.rdata
.data
.idata
.rsrc
.reloc
Hi dancho,
That's what I was afraid of, there is no entry that I can find that will match the section header entry to the data directory entry. I'll have to keep digging...
@donkey
this is copy/paste from the first resource I read about pe ( LUEVELSMEYER's description about PE file format ) and I think
that nicely fits here :bg
There is one section header for each section, and each data directory
will point to one of the sections (several data directories may point to
the same section, and there may be sections without data directory
pointing to them).
Hi dancho,
This should find the table no matter what the ordering is or name. This routine keeps getting smaller, I like it :)
GetJumpTable FRAME hInst
mov edx,[hInst]
add edx,[edx+IMAGE_DOS_HEADER.e_lfanew]
lea eax,[edx + IMAGE_NT_HEADERS.OptionalHeader + 104]
invoke ImageRvaToSection,edx,0,[eax+IMAGE_DATA_DIRECTORY.VirtualAddress]
mov eax,[eax+IMAGE_SECTION_HEADER.VirtualAddress]
add eax, [hInst]
ret
ENDF
In GoAsm it returns the correct entry.
@donkey
nice one,dbghelp functions FTW,
I should really study more Debugging and Error Handling section of sdk ... :U
Well, lots of work for nothing I guess, the SymAddSymbol function returns no error but the new symbols don't appear in the symbol table when I dump it. The docs say the function adds a virtual symbol to the symbol table but I can't figure out how to access it. I was hoping to add API references directly to the symbol table in GoAsm (MASM already does this) but I've pretty much given up on the idea. Did learn quite a bit along the way though.
ouch !
I guess I should explain a little more clearly what I was experimenting with the jump table for. This is the disassembly using WinDbg of a GoAsm jump table:
00409000 ff2578924000 jmp dword ptr [MainModule!LastSymbol+0x2e34 (00409278)]
00409006 ff257c924000 jmp dword ptr [MainModule!LastSymbol+0x2e38 (0040927c)]
0040900c ff2580924000 jmp dword ptr [MainModule!LastSymbol+0x2e3c (00409280)]
00409012 ff2584924000 jmp dword ptr [MainModule!LastSymbol+0x2e40 (00409284)]
00409018 ff2588924000 jmp dword ptr [MainModule!LastSymbol+0x2e44 (00409288)]
0040901e ff258c924000 jmp dword ptr [MainModule!LastSymbol+0x2e48 (0040928c)]
GoAsm does not assign symbols to the addresses, for example 0x00409278 is the offset of the fixed up address of GetModuleHandleA, 0x00409000 is the address of the entry in the jump table that is called when you use CALL GetModuleHandleA. In MASM the symbol GetModuleHandleA is in the symbol table with the address 0x00409000 and the symbol _imp_GetModuleHandleA is added with the address 0x00409278. In this way WinDbg can properly display the call instruction as CALL GetModuleHandleA. In GoAsm it will display something like call MainModule!LastSymbol+0x2bbc (00409000) which is a bit tough to read. I was trying to add the symbol GetModuleHandleA with an address of 0x00409000 in order to make the output more readable. Unfortunately it doesn't work as WinDbg's IDebugControl interface seems to ignore the virtual symbols I add. Truly unfortunate since I had high hopes for this method, I might end up being forced to write a complete disassembler in order to get it looking the way I want or use Beatrix's BeaEngine, which I've found to be exceptional and does both 32 and 64 bit.
maybe you can get the info from the PE file (i.e. an "unloaded" copy of it)
easy enough to get its' path and name :P
you cannot (easily) write to the file while it's being executed, but should be able to read it
Hey Dave,
I can get all of the information I need its just that I can't pass it on the the debugger (WinDbg). WinDbg doesn't seem to have the facility to add virtual symbols and though DbgHelp can do that, WinDbg ignores them. BeaEngine is probably the route I'm going to take, it has a lot of flexibility and though it doesn't handle labels, I can always sub them in from the tables.
Donkey you're doing exceptional work here man.
I noticed you mentioned BEAEngine I recentrly started experimenting with trying to disassemble some of my own code.
Although I can't get BEAEngine working at all I was wondering how you managed to get it running properly.
The documentation on his websites show a little example on how to use it with GoASM.
Using BeaEngine with GoAsm
Below is a paste from his website.
#include BeaEngineGoAsm.inc --> no problem here
Disasm = BeaEngine.lib:Disasm --> no problem here
.data
MyDisasm _Disasm <> --> This structure is not recognized by GoASM and is kinda causing the first problems.
szoutofblock db "Security alert. Disasm tries to read unreadable memory",0
i db 100
.code
start:
; *********************** Init EIP
mov eax, offset start
mov [MyDisasm.EIP], eax
; *********************** loop for disasm
MakeDisasm:
push offset MyDisasm
call Disasm
cmp eax, OUT_OF_BLOCK
jne >
push offset szoutofblock
call puts --> this call is not in any of the object files I added to my project. In his package I picked the BEAEngine.lib (384 kb) and the BEAEngineGoASM32.inc --> I know on the include above it points to GoASM and not GoASM32
add esp, 4
push 0
call ExitProcess
:
cmp eax, UNKNOWN_OPCODE
jne >
inc d[MyDisasm.EIP] --> structure not recognized
jmp Display
:
add [MyDisasm.EIP], eax
Display:
push offset MyDisasm.CompleteInstr
call puts
add esp, 4
dec b
jne MakeDisasm
push 0
call ExitProcess
and I get compiling errors about symbols not found in object files:
MyDisasm.Eip
puts
strlen
strcpy
memset
sprintf
You know of any other documentation?
QuoteThe documentation on his websites show a little example on how to use it with GoASM
HER site :bg
Beatrix, as i recall
Dedndave,
You are right. The example I posted above is from his website.
and the only documentation I could find on his website about using it with GoASM.
Weird thing the includes work etc.., but it still says certain symbols en structures can't be recognized. It's either me missing some symbols in my project or
the example on his website isn't complete. That's why I was wondering if someone tried it before and if there is any more documentation.
Quote from: FlySky on July 30, 2011, 04:09:33 PM
Dedndave,
You are right. The example I posted above is from his website.
and the only documentation I could find on his website about using it with GoASM.
Weird thing the includes work etc.., but it still says certain symbols en structures can't be recognized. It's either me missing some symbols in my project or
the example on his website isn't complete. That's why I was wondering if someone tried it before and if there is any more documentation.
:bg
Beatrix is a lady
Edgar is the guy to talk to (donkey) - he plays with GoAsm a lot and probably has experience with her lib
or, maybe Beatrix, herself
she is a forum member and pops in from time-to-time
her site probably has an email addy
beaengine gmail.com
replace the space with @
oo a lady you say huh, offcourse I should have noticed that. We've got a queen with that name :lol
oh - you're a Nederlander ?
Yeah I am dutch aka a Nederlander :U you aswell?? I will wait for Edgar to pop up, and mainwhile trying to get it working, will post the solution to my findings aswell if I figure it out.
no - i am not Dutch
well, way back in my ancestory you will find what was known as "German Dutch"
I've fixed the issue.
There is actually 1 issue that I had to change.
1. You need to link msvcrt.dll like this:
;this links in necessary imports
#DEFINE LINKFILES
#DynamicLinkFile msvcrt.dll
With this included the example program listed on the website compiles fine in GoASM
This is mentioned by E^Cube about a year ago. In this topic: http://www.masm32.com/board/index.php?topic=13686.30
*UPDATED*
With link to answer E^Cube posted a year ago.