I'm writing an OS awareness plugin. I need to read a symbol name to get the tasklist. In our system, the OS is running on 2 different cores, so that the symbol name which I want to read is presented on 2 different cores with the same symbol name. When I call T32 API to get the symbol address by passing the symbol name, it says "Symbol not found".
I tried giving the complete symbol path but still it is failing.
Is there a way to get the symbol address when the same symbol name is present on 2 different cores?
Thank you.
If you have two symbols with the same name (but pointing to different memory locations), it is totally the correct approach, to use the fully qualified symbol path names for both memory locations.
To find the fully symbol path names open the TRACE32 GUI, load your application and open the window sYmbol.Browse.sYmbol (via the command line or via Menu>View>Symbols>Browse). In the window sYmbol.Browse.sYmbol replace the last asterisk in the upper left corner by the name of your symbol. This should look like this:
In my case the symbol is called "mcount". As you can see I have it twice.
Now move the slider in the left lower corner (left to the horizontal scroll bar) to the right and you will see the fully qualified symbol name:
The columns labeled with "path" and "symbol" show now together the fully qualified symbol names.
In my example the full symbol name of my first variable is \\sieve\itm\mcount, which means that this symbol comes from the module "itm" in the ELF file "sieve". (A module is a compilation unit aka. an object-file)
If you have two symbols with the same name in the same ELF which are in two different modules, which also have the same name, TRACE32 will extend the module name by parts of the file path to have again unique symbol path names.
Alternatively you can also replace the module name by the file path (of the underlying source file) in double-quotes. E.g. like this: \\sieve\"C:\project\src\itm.c"\mcount
Finally use the fully qualified symbol name with the API function T32_GetSymbol() to get the symbol's address via the remote API. E.g.: Like this
int main(void)
{
const char *symbol = "\\\\sieve\\itm\\mcount";
uint32_t address, size, reserved;
T32_Config( "NODE=", "localhost");
if ( T32_Init() != T32_OK )
exit(-1);
if (T32_Attach(1) != T32_OK)
exit(-2);
if (T32_GetSymbol (symbol, &address, &size, &reserved) == T32_OK)
printf("Symbol %-30s is at address 0x%08X with size %d\n", symbol, address, size);
T32_Exit();
return 0;
};
Related
I have written a C++ code for application, in which there are some variables that must have different values for every user will use it ( lets call it the variable X for simplicity)
X have different values for different user. This (X)should be not changed and also embedded in the exe itself ( so I can't read it from a file or any other similar solution)
I don't want to distribute the source code then compile. Instead, I want a method that makes me edit the final exe directly without need to compile ( it is just value of variable X which differs !) Is this possible ?
My idea to do this is if I can force this (X) at a constant memory location, I can then edit its value easily from Hex-editor as example. ( I mean the same ideas when hackers writes cheat tool for a certain game )
Is the mechanism of fixed memory position possible?
Is there any other idea to make what I want?
I hope my question is clear enough
In this answer I'll use Visual Studio 2017 Community Edition because I wanted to be sure to a have a development environment fully compatible with Windows.
I'll present five methods, from the most maintainable to the less. Of course the focus of this answer in strictly limited to the goal of "sharing" a C++ variable with an external tool.
Security of such an operation is a different topic and ultimately a futile attempt anyway.
Method 1 - Resources
Windows APIs1 and the PE2 support embedding resources in an executable3.
Resources are typically images, icons or localized strings but they can be anything - including raw binary data.
With Visual Studio is quite easy to add a resource: In the Solution Explorer > Resource files > Add > New item > Resource > Resource file (.rc)
This will open the Resource view, right-click on Resource.rc and select Add resource....
It's possible to create the standard resources but we need a Custom... type that we can call RAW.
This will create a new binary resource, gives it an ID and makes a few files in the solution.
Switching back to the Solution explorer we can see these new files and eventually edit the .bin file with a better hex editor than the VS's integrated one.
Of particular interest is the resource.h file that we can include to have the definition for the resource id, in my case it was IDR_RAW1.
After the bin file has been crafted we are ready to read it in the application, the pattern to use is the usual one - I don't feel like going over these API one more time a new answer so I'll link the Official documentation and provides a sample code:
#include <Windows.h>
#include "resource.h"
int WINAPI WinMain(HMODULE hModule, HMODULE hPrevModule, LPSTR lpCmdLine, int showCmd)
{
//Get an handle to our resource
HRSRC hRes = FindResource(hModule, MAKEINTRESOURCE(IDR_RAW1), "RAW");
//Load the resource (Compatibility reasons make this use two APIs)
HGLOBAL hResData = LoadResource(hModule, hRes);
LPVOID ptrData = LockResource(hResData);
/*
ptrData is out binary content. Here is assumed it was a ASCIIZ string
*/
MessageBox(NULL, (LPCSTR)ptrData, "Title", MB_ICONINFORMATION);
return 0;
}
Resources are good because they allow for an easy integration with other automatic build tools: it's easy to add a build step before the resources are compiled to generate them on the fly.
It is also very easy to alter them after the exe file as been generated - CFF Explorer III is a simple and effective tools to edit a PE module's resources.
It's even possible to replace a resource entirely thereby not limiting ourselves to keeping the new resource the same size as the old one.
Just open the module in CFF, select Resource editor, browse to the raw resource and edit/replace it. Then save.
Method 2 - PE exports
Executable are ordinary PE module just like Dlls, the difference is really a batter of a bit.
Just like Dlls can exports functions and variables4 so can exes.
With VC++ the way to tag a symbol as exported is __declspec(dllexport):
#include <Windows.h>
__declspec(dllexport) char var[30] = "Hello, cruel world!";
int WINAPI WinMain(HMODULE hModule, HMODULE hPrevModule, LPSTR lpCmdLine, int showCmd)
{
MessageBox(NULL, var, "Title 2", MB_ICONINFORMATION);
return 0;
}
The C++ side of the matter is little affected.
The editing of the PE module is less user friendly but still very easy for everyone to follow.
With CFF open the export directory, all the exports will be listed.
C++ compilers have to mangle variables names when they can be shared due to the C++ features they support - so you won't find a nice name like var in the exports but something like ?var##3PADA.
The export name doesn't really fulfil any goal in this context but you must be able to identify the correct export.
This should be easy since it's very likely to be only one.
CFF will show you the function RVA, this is the RVA (relative to the image base) of the variable, you can easily convert it into a file offset or simply use the Address converted integrated in CFF.
This will open an hex editor and points you at the right bytes.
Method 3 - Map files
If you don't want to have a PE exports pointing right at your variable you can tell VS to generate a MAP file.
Map files will list all the symbols exported by an object file (note: an object file, not a PE module).
So you must make sure a variable, in this case, is exported by your translation unit - this is the default case for "global" variables but make sure to remember to not attach the static linkage modified to it and eventually make it volatile to prevent the compiler from eliminating it during the constants folding step.
#include "Windows.h"
//extern is redundant, I use it only for documenting the intention
//volatile is a hack to prevent constant folding in this simple case
extern volatile int var2 = 3;
int WINAPI WinMain(HMODULE hModule, HMODULE hPrevModule, LPSTR lpCmdLine, int showCmd)
{
//A simple use of an int
return var2;
}
A MAP file will be generated in the output dir, along with the exe, inside it's present a row like this one:
0003:00000018 ?var2##3HC 00403018 Source.obj
This gives you the VA of the variable (403018) that you can use in CFF Address translator.
Method 4 - PE scan
You can initialise the variable with an unique value.
To be able to do so the variable size must be big enough that the probability that a random sequence of bits of equal size end up with the same value is negligible.
For example, if the var is a QWORD the probability of finding, in the PE module, another QWORD with the same value is very low (one in 264) but if the var is a byte then the probability is just one in 256.
Eventually, add a marker variable (I'd use a random array of 16 bytes) before the variable to mark it (i.e. act as the unique value).
To modify the PE use an hex editor to look for that unique value, this will give you the offset of the var to edit.
Method 5 - Reverse engineering
After each release, reverse engine the application (this is easy as you can debug it with VS along with the sources) and look where the compiler allocated the variable.
Take note of the RVA (nota bene: RVA not VA, the VA is variable) and then use CFF to edit the exe.
This requires a reverse engineering analysis each time a new release is built.
1 To be correct, "Win32" APIs.
2 I strongly advice the reader to be at least accustomized with the PE file format as I must assume so to keep this answer in topic and short. Having no understanding of the PE file format will likely result in no understanding of the question as a whole.
3 Actually, in any PE module.
4 Symbols in general.
I'm trying to find a way to resolve a memory address and a DLL file name for a particular API when it's mapped into a process. Most of this can be resolved with the import/export tables in a DLL and by analyzing the Import Address Table of a mapped module. That is for most functions.
But the issue happens with some forwarded functions. An example of such function happens to be DeleteProcThreadAttributeList on my Windows 10 system. So for instance, if I build a test 32-bit process with such function, or better yet, let's use a 32-bit version of cmd.exe from c:\windows\syswow64\cmd.exe image, and then try to analyze its import table. It turns out that this function is imported from the API Set with a virtual name API-MS-WIN-CORE-PROCESSTHREADS-L1-1-2.DLL:
To find an actual file that it redirects to I do the following:
HMODULE hMM = ::LoadLibraryEx(L"API-MS-WIN-CORE-PROCESSTHREADS-L1-1-2.DLL",
NULL, DONT_RESOLVE_DLL_REFERENCES);
WCHAR buffModPath[MAX_PATH];
::GetModuleFileNameEx(::GetCurrentProcess(), hMM, buffModPath, _countof(buffModPath));
::FreeLibrary(hMM);
Which gives me buffModPath as C:\Windows\System32\KERNEL32.DLL.
Since I'm calling it from a 32-bit process, I now inspect the export table of c:\windows\syswow64\KERNEL32.DLL module:
that shows that DeleteProcThreadAttributeList is forwarded to api-ms-win-core-processthreads-l1-1-0.DeleteProcThreadAttributeList.
OK, I then use my method again to resolve redirection of the virtual api-ms-win-core-processthreads-l1-1-0.dll API set:
HMODULE hMM = ::LoadLibraryEx(L"api-ms-win-core-processthreads-l1-1-0.dll",
NULL, DONT_RESOLVE_DLL_REFERENCES);
WCHAR buffModPath[MAX_PATH];
::GetModuleFileNameEx(::GetCurrentProcess(), hMM, buffModPath, _countof(buffModPath));
::FreeLibrary(hMM);
Which gives me C:\Windows\System32\KERNEL32.DLL, that brings me back to where I started.
So how do I resolve this circular dependency to actual DLL address/entry point the way OS module loader does it?
I think whatever happens if you GetProcAddress one of these exports is supposed to be a black box.
The PEB has a ApiSetMap member in Windows 7+ that contains set information that the loader uses. The format of this data has changed at least 3 times but the mapping is not just from "API-*.dll" to "*32.dll".
You can read the Microsoft patent of this concept here.
I'm out of ideas how to do this :
You have one file, let's call it test.exe,
it has const int value = 5; in it, and all it does is cout << value;
I want to create other executable which patches the test.exe so it now outputs 10 instead of 5. I want this to be done before runtime.
I've tried turning off the ASLR, getting the address of that variable and then patching in, but addresses in disk and in memory differ AFAIK.
Sorry, this remark assumes you are working on a Windows System. If not, I'm sure that with other executable image formats you can follow similar method.
Assuming you are trying to ask how you alter data within a target and not how to, in this particular example, change the screens output...
Have you considered looking at the executable image's PE Header? You can translate the address of a particular piece of data once loaded into memory to its offset in the PE file but taking a look at the IMAGE_SECTION_HEADER structure inside of PE Header of the image in question.
First, calculate the RVA of your data in memory. This is the address of the data relative to the section it is located inside of.
Second, index through the IMAGE_SECTION_HEADER structures inside of the executable's PE header by reading the header from file into a buffer. Once you've loaded this header into a memory buffer, you can process it using pointers. Like so,
IMAGE_NT_HEADERS* pImageHeader = &peHeaderBuffer[0];
After finding the correct IMAGE_SECTION_HEADER that contains your data,you can access the PointerToRawData member of the structure which will give you the offset from the start of the PE file at which this section is, if you add the RVA, you will get the offset from the start of the file from which your data is located.
Obviously, my response doesn't explain how to index through the section headers as this is a fairly tedious task that would take a while to explain. I would suggest you take a look at an exectuable's PE header from within a simple debugger, like OllyDbg, and reference MSDN's documentations on the PE Header - which can be found here:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms680336%28v=VS.85%29.aspx
If all you want to do is reverse this information our of a target, it is very easy to do using OllyDbg. Just skim down the PE Header view until you see the section that corresponds to your data, and OllyDbg will list the PointerToRawData member there, which you can add to your RVA.
Find it by signature: get 8-16 bytes around your value 5 and then search for them in .exe binary.
Also note that usually const int values are inlined into the assembler code, so if you have 2 or more statements referencing to it you have to patch all of them.
I'm having trouble with the Win32 NT headers giving me odd RVA's for import names. Here is the relevant code that is giving me the problem:
//Get a pointer to the import table
PIMAGE_IMPORT_DESCRIPTOR piidImportTableAddr;
piidImportTableAddr = (PIMAGE_IMPORT_DESCRIPTOR)(pImgNtHeaders->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress + (DWORD)pMemFile);
while(piidImportTableAddr->Name != 0)
{
//Itterate over every IMAGE_IMPORT_DESCRIPTOR structure, extracting the names of the DLLs to import
char* name = (char*)((DWORD)piidImportTableAddr->Name + (DWORD)pMemFile);
//Do nothing for now
piidImportTableAddr++;
}
However, the piidImportTableAddr structure's members contain addresses that are bad pointers, here is a table of the members:
Characteristics 0x42746553
OriginalFirstThunk 0x42746553
TimeDateStamp 0x646f4d6b
ForwarderChain 0x02260065
Name 0x54746547
FirstThunk 0x4d747865
These are all bad RVA's and memory locations. Is there something I'm doing wrong when looking up the DLL name by this method? I have compared the RVA of the import table to the one that is shown in PE Lord, they are the same, so I am not sure why the IMAGE_IMPORT_DESCRIPTORs are incorrect.
Here is a link to the source code in it's entirety: http://pastebin.com/32MBEvWU
You have the RVA of the import table, but since the module hasn't been loaded the sections are still in their physical locations. The physical offset of the import section is usually different from the RVA. You will have to iterate through the section headers (_IMAGE_SECTION_HEADER), and using the VirtualAddress and VirtualSize values find the section that contains the import table. Then get the physical address of that section from PointerToRawData.
So the actual address you want is something like this:
importTableRVA - importSectionRVA + importSectionPhysicalAddress + pMemFile
Your code gives the impression that your are inspecting the IAT of a module thats already been virtualized (loaded into memory), which means the IAT will not contain RVA's, but instead the addresses will have been adjusted by the windows loader to the required dynamic offsets.
However, with that being said, the data reported by LordPE is suspect, if the binary module is actually valid (ie: windows can load it and it runs), then you might be dealing with an obfuscated file, else the binary is corrupt or not a win32 PE file.
I am currently writing a PE parser/loader.
I have successfully loaded the PE file into memory using standard c file io, retrieved valid DOS and PE headers (the optional header) as well as gaining access to the PE's sections.
My next target is to gain access to the Export table to retrieve exported symbols.
To do this i have used the RVA stored in the optional headers data-dictionary array at index 0 (which i believe points to the export table) and added this address to the address of the PE file loaded into program memory, then casted this into a valid export table header. I am turning up NULL addresses and data when i do this. here is a small code snippet;
// RVA from optional headers data dictionaries array cast to Export directory type
IMAGE_EXPORT_DIRECTORY* ied(
(IMAGE_EXPORT_DIRECTORY*)((void*)
((unsigned char*)buffer + ioh->DataDirectory[0].VirtualAddress)));
Do i have to use memory mapped IO to do this properly? Am i calculating the address wrong? Information on PE RVA's seems sparse.
thanks in advance.
I opened one my old project from the time as I like you examined the structure of import and export directories (IMAGE_DIRECTORY_ENTRY_EXPORT, IMAGE_DIRECTORY_ENTRY_IMPORT, IMAGE_DIRECTORY_ENTRY_IAT and IMAGE_DIRECTORY_ENTRY_DELAY_IMPORT). I can in short explain the part where you have a problem. I mean the part how to find out the pointer to for example IMAGE_EXPORT_DIRECTORY inside of PE.
First of all of cause it is possible to use Read/Write file operations to analyse a PE file, but it is much easier to use file mapping like following:
hSrcFile = CreateFile (pszSrcFilename, GENERIC_READ, FILE_SHARE_READ,
NULL, OPEN_EXISTING, 0, NULL);
hMapSrcFile = CreateFileMapping (hSrcFile, NULL, PAGE_READONLY, 0, 0, NULL);
pSrcFile = (PBYTE) MapViewOfFile (hMapSrcFile, FILE_MAP_READ, 0, 0, 0);
after we have the pointer pSrcFile which point to the PE file contain we can find another important places inside of PE:
pDosHeader = (IMAGE_DOS_HEADER *)pSrcFile;
IMAGE_NT_HEADERS32 *pNtHdr = (IMAGE_NT_HEADERS32 *)
((PBYTE)pDosHeader + pDosHeader->e_lfanew);
IMAGE_SECTION_HEADER *pFirstSectionHeader = (IMAGE_SECTION_HEADER *)
((PBYTE)&pNtHdr->OptionalHeader +
pNtHdr->FileHeader.SizeOfOptionalHeader);
Now we have all needed virtual address of any directory. For example,
pNtHdr->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT].VirtualAddress
is a virtual address of export directory. After that to convert the virtual address to the memory pointer, we should find out the section of PE which has this virtual address inside. To do this we can enumerate sections of PE and find an i greater or equal to 0 and less then pNtHdr->FileHeader.NumberOfSections where
pFirstSectionHeader[i].VirtualAddress <=
pNtHdr->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT].VirtualAddress
and at the same time
pNtHdr->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT].VirtualAddress
< pFirstSectionHeader[i].VirtualAddress + pFirstSectionHeader[i].Misc.VirtualSize
then you should search for export data in the section pFirstSectionHeader[i]:
IMAGE_SECTION_HEADER *pSectionHeader = &pFirstSectionHeader[i];
IMAGE_EXPORT_DIRECTORY *pExportDirectory =
(IMAGE_EXPORT_DIRECTORY *)((PBYTE)pbyFile + pSectionHeader->PointerToRawData +
pOptionalHeader->DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT].VirtualAddress -
pSectionHeader->VirtualAddress);
The same procedure you should repeat to find (IMAGE_IMPORT_DESCRIPTOR *) which corresponds to IMAGE_DIRECTORY_ENTRY_IMPORT and (IMAGE_BOUND_IMPORT_DESCRIPTOR *) which corresponds to IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT to dump import information inclusive a binding information (if exist).
To dump information from IMAGE_DIRECTORY_ENTRY_DELAY_IMPORT (corresponds to (ImgDelayDescr *) defined in delayimp.h) you should use also information from the IMAGE_DIRECTORY_ENTRY_IAT (corresponds to (IMAGE_THUNK_DATA32 *)).
For more information about PE I recommend you http://msdn.microsoft.com/en-us/magazine/cc301808.aspx
Not all PE images will have an export directory table. You need to check the optional header's Windows-specific "NumberOfRvaAndSizes" field. If it is less than or equal to IMAGE_DIRECTORY_ENTRY_EXPORT (0), then there is no export directory table (i.e. there is nothing valid located at ioh->DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT]).
See the answer to this question for an example.
There is macro defined to get first section
PIMAGE_SECTION_HEADER FisrtSection = IMAGE_FIRST_SECTION(NtHeaders)
I have written the python code to print all import and export functions of pe file. You will get the nice idea of how to do that in C. In data directory we have to check if the export directory rva and size is '0' or not. if not '0' we can proceed. You can use tool 'CFF explorer' from Nt core website. this is very good tool which will show how the data maps into export directory and then you can parse it easily. Here is the blog.