The issue here is not strings, it's the fact that Hex-Rays didn't guess the right calling convention for sub_4022E0. Notice that the disassembly listing moves values into both ecx and edx before the call, whereas the decompilation for that call shows only one argument? Hex-Rays thinks there's only one argument -- maybe even only one stack argument -- whereas ...
The section name can be anything, the OS loader only uses section flags to set up permissions when mapping the file into memory. For example, Delphi compiler uses CODE, and various packers use custom names (UPX00 etc.) or even garbage.
AFAIK the only section name that is somewhat enforced is .rsrc - I think Explorer may not show the file icon if resources ...
I've just received from a friend a *.idb file concerning the pe file i'd like to disassemble in IDA.
a IDB file is IDAs primary project/database format
its the result of an IDA exe load + analyze run
What the file is and how can i load/use it with the exe linked with it in IDA?
just open it with IDA
The other answer is wrong; it's totally possible (assuming the IDB already has a type for the structure in question, and that type has been applied to arguments/variables in Hex-Rays).
In IDA 7.4 and above (I think; might have been 7.3), right-click the variable and press "Jump to xref globally", as follows:
You'll get a popup with all global x-...
Assemblers are faced with a similar problem: the user writes textual labels such as @loop, and references them in conditional branch instructions such as jbe @loop. However, the assembler does not know ahead of time how far the branch is from the label (in order to generate the displacement for the branch). It only learns that after generating machine code ...
The direct call can be generated by the compiler when it knows that the function comes from a DLL at compile time, or whole program optimization is used. If the target function is not marked as dllimport, the compiler generates a simple call to an external symbol and at link time this external symbol is resolved to a stub which actually jumps to the DLL ...
you need to parse the section table, figure out to which section your address belongs (using their VirtualAddress and VirtualSize), then calculate the offset from the section start and add it to the section's physical offset. E.g.:
SectionOffset = addr - section[i].VirtualAddress
offset = SectionOffset + section[i].PointerToRawData
A directory does not ...
I must pass the address of the buffer not the value inside that buffer in WriteProcessMemmory
[Call by reference]
WriteProcessMemory(pinfo.hProcess, (LPVOID)(ctx->Ebx + 8), (LPVOID)(&ntHeader->OptionalHeader.ImageBase), 4, 0)
No it does not all pe files do not start at the same address 0x401000
historically 0x400000 is the ImageBaseAddress Header is 0x1000 bytes
so .code section starts at 0x401000 for a normal exe
since the Exe's module is the first to be loaded it normally gets its Preferred ImageBase Address
but a relocation table is a part of exe in case there is a conflict ...
After some research time, I found a way to do it in CPP but not in python.
The most relevant part of the code dealing with loading PEs from buffer to memory:
void destroy_linput(linput_t* li)
linput_t* create_linput(std::vector< bit7z::...
CreateRemoteThread takes 7 arguments and the 4th of them is called lpStartAddress.
Now, from MSDN docs:
A pointer to the application-defined function of type LPTHREAD_START_ROUTINE to be executed by the thread and represents the starting address of the thread in the remote process. The function must exist in the remote process. For more ...
From Microsoft docs:
The preferred address of the first byte of image when loaded into memory [...] The default for DLLs is 0x10000000.
[...] The default for Windows NT, Windows 2000, Windows XP, Windows 95, Windows 98, and Windows Me is 0x00400000
So, in case of exe, you can usually expect that it will be loaded at 0x400000 address and when you load the ...
I found a solution and gonna leave it here for future reference.
First, you need to calculate the linear address (the one the binary will have in run-time) from the RIP offset of the jump. Let's say the RIP offset is 0x8fe. You add this, and the offset of the instruction itself (offset from start of .text section) plus the instruction size and you get a ...
Loading and successfully running code associated with an arbitrary PE may require some additional steps e.g. relocation. Consider converting the EXE into a DLL like this or this so that you can use Windows APIs to load the code for you.
Sounds possible, the difficulty of achieving it I think would depend on:
how the objects are allocated (inline access vs allocator)
the type of references (direct addressing vs indirect)
the amount of references that there are to the objects
If it's just a small number of references and allocations then it might not matter which method you use - the ...
if using win32 apis are an option you can try something along this line
the first example command uses cdb to gets rva and bytes for counter checking (something like you do with objdump)
the second is a python script which you can use as refernce to adapt in your language of choice
the third is actual execution and bytes fetched from address
:\>cdb -c &...
Obviously you should resolve the address in IAT.
This is a manually mapped dll code, you can take a look.
typedef HMODULE(WINAPI* pLoadLibraryA)(LPCSTR);
typedef FARPROC(WINAPI* pGetProcAddress)(HMODULE, LPCSTR);
typedef BOOL(WINAPI* PDLL_MAIN)(HMODULE, DWORD, PVOID);
Simple, it's a section that will supposedly be mapped as paged memory. This can contain code or data and is governed by the PAGED_CODE macro, among others, at source code level.
That is, whatever gets stored in that section cannot be accessed at arbitrary IRQLs. Quote:
If the IRQL > APC_LEVEL, the PAGED_CODE macro causes the system to ASSERT.
Also see ...
From your question it is not quite clear what you want to achieve: I assume you need the address in memory where you can find the "Address of Entry Point", as well as the file offset where the code at "Address of Entry Point" is stored.
Let us look at your screenshots for the file offset of "Address of Entry Point"
In your ...
First, beside “yours” two tables, I introduce a third one, the Import Lookup Table.
Side by side with the Import Address Table, these two tables look like in this simplified picture:
This picture shows the situation in your executable file on disk. They are totally identical, with the exactly same lists of the API function names (more precisely, pointers to ...