|
There is no specific address where each section resides.
You will need to understand the PE format.
It is a chain of data structures.
You will need to examine the PE Header and the PE optional header of the executable to get the starting relative virtual address of each section.
« Superman »
|
|
|
|
|
Thanks Santosh,
Sorry I do not agree with you. Suppose my application loads a DLL and I want to debug into the DLL, since DLL could be loaded into any address (possible reload), how could you just get the actual address using static analysis tool without running it?
Please feel free to correct me if I am wrong.
regards,
George
|
|
|
|
|
OK. Now I'm not sure if I understand your requirement.
« Superman »
|
|
|
|
|
I have a question for you, Santosh.
A DLL could be loaded at any arbitrary address, how could you use PEDUMP to analysis information at some address without actually run/load it. Let me know if I have not made myself understood.
regards,
George
|
|
|
|
|
Well if you read about PE is very helpful for you and if you like to see it I saw a very good article on the www.codeguru.com about it.
|
|
|
|
|
Thanks Hamid,
Could you post the link of the good article you referred please? CodeGuru is a big site.
regards,
George
|
|
|
|
|
you can search with PE,its more five page I think.
|
|
|
|
|
|
|
|
Dont you know C#?
|
|
|
|
|
Does it relates to my question, Hamid?
regards,
George
|
|
|
|
|
You said it was C# I asked do you know C#?
|
|
|
|
|
Sure, Hamid!
Let us discuss the original question?
regards,
George
|
|
|
|
|
Did you see those articles? are they helpful?
|
|
|
|
|
Thanks Hamid,
I will read them today and response with you.
regards,
George
|
|
|
|
|
Yes, Hamid!
I have read the articles and tried the PEDUMP tool. I think it is used for analyze the physical binary file format, not to analyze the loaded in memory binary.
Any comments?
regards,
George
|
|
|
|
|
I think I found your answer but I dont remember your question (you have lot of questions) you want to read memory of a process(thread) with an address,right? well see ReadProcessMemory .
|
|
|
|
|
Sorry for my bad English, Hamid!
My question is, I can get the content of the memory, but I want to know what exactly resides in the memory -- i.e. does the memory content represents code or data? If I have symbol file, could I decode the memory content to human readable information? Any ideas?
regards,
George
|
|
|
|
|
To get the module the address is in use SymGetModuleInfo64().
This will resolve for all 'global' variables (functions and global data in exe's or dll's).
To get the raw (mangled) symbol name use SymGetSymFromAddr64().
To get the unmangled name use UnDecorateSymbolName() or SymUnDName64().
To check if the address is on the _current_ stack:
bool IsOnCurrStack( cvoid *ADDR )
{
NT_TIB *tib((NT_TIB*)::NtCurrentTeb());
return( tib->StackLimit < ADDR && ADDR < tib->StackBase );
}
You should never see/care about an address on the stack of another thread unlesss you are a debugger.
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
Thanks cmk,
Great reply!
1.
I think "module" means EXE or DLL, it contains code (.text) and global data (.data), my question is whether a module's .text (or .data) segments are loaded as continuous address? I have this question is because when we use new/malloc to get memory from heap, they may not be continuous. I am not sure about .text (or .data)?
2.
Function "SymGetSymFromAddr64" is useful. But suppose the following scenario, I am using WinDbg or some other debugger to debug, and want to "decode" at some specific address to symbol names. How could I call such function? Any ideas?
regards,
George
|
|
|
|
|
1. There may be multiple code and data segments, so no, you can not assume the address' are continuous.
2. How you resolve the address is debugger specific. I would expect most to have built-in address-to-name resolution functionality.
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
Thanks cmk,
1.
I have debugged some programs, and using lm command in WinDbg to list all loaded DLLs by the debugged program. I saw all DLLs are loaded a continuous address. Why do you say "can not assume the address' are continuous" -- could you show a sample please?
2.
I think your built-in programatic solution is more comprehensive. Any ideas about how to do it in debugger?
regards,
George
|
|
|
|
|
1.
- A given module will be mapped into a single continuous block of memory.
- For a program with multiple modules, the modules may not be in adjacent blocks of memory, there may be gaps.
- Within a module there may be more than 1 code and/or data blocks, these may not be adjacent.
2.
You will have to read the instructions for the debugger.
If WinDbg isn't showing the symbols then either:
- the module was not compiled with symbols (e.g. release build)
- windbg isn't setup right, the symbols server/paths are wrong
- the address isn't at the start of a symbol and winddbg isn't looking for the nearest symbol
You can always write a windbg extension and use the windbg api GetSymbol().
See:
http://www.codeproject.com/KB/debug/cdbntsd4.aspx[^]
http://72.14.205.104/search?q=cache:w_6GRVNQR5wJ:www.osronline.com/article.cfm%3Fid%3D52+windbg+getsymbol&hl=en&ct=clnk&cd=3&gl=ca[^]
Maybe if we step back and you explain exactly what you are trying to do it might be easier. It's been years since i needed a debugger other than the one built into VS.
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
Cool cmk!
I like both the article and the forum you recommended.
What I am trying to do is to solve a sort of specific issues, when there is OS error box which indicates my application is broken at some address (e.g. 0x12345678), because of unhandled exception or something. I want to find out what actually resides in address 0x12345678? Is it code or data?
Any advice or documents to refer?
regards,
George
|
|
|
|