Where does IDA load binary in Ida64.exe process?

Question

I quickly checked the address range shown in IDA within the ida64.exe process using a kernel debugger, and the memory is question marks, indeed there is no VAD allocation for the range.

I don't want to reverse engineer IDA code, and I've searched for the byte sequence within the process using a kernel debugger, getting a match on the thread stack in the same exact place every time (0x17dc58) regardless of byte sequence searched, presumably due to the debugger attaching a thread to compare the byte sequence. It is taking too long to search the rest of the process, 8TiB of virtual memory, so where is it? On a heap? Clearly IDA must be pretending it is at whatever virtual address you base it at and transparently translates the virtual address to the real virtual address.

I want to do this because I want to check what is actually behind question marks in certain situations,like in the IAT where it shows question marks instead of the offsets to names

Answer 1

IDA doesn't have to, and often doesn't, store a complete copy of the binary loaded as input. That all depends upon whatever the loader module thinks it needs to display the binary to the user, possibly influenced by options selected by the user at load time. If IDA's showing you question marks at specific addresses, it's probably because it doesn't actually have the bytes in its database in order to show them to you.

For example, you might have had the experience where you needed to look at the resource section of a file you previously loaded, only to discover that the resource section has not been loaded into the database. Similarly, for uninitialized regions of the file, it has no reason to store byte contents for those regions (after all, it has none).

Think about it: if the PE header says there's an uninitialized section that's 1MB in size, the binary isn't going to waste 1MB on disk by storing useless uninitialized data. Instead, the operating system's loader is going to interpret the section data in the PE header and create that 1MB region when the binary executes. Since the addresses in that section don't correspond to actual bytes in the PE file, which bytes would you want IDA to show you?

Answer 2

If you study e.g. idc.idc, for the built-in scripting, you can get some idea how IDA works internally with the data:

/*
 *      Each byte of the program has 32-bit flags
 *      (low 8 bits keep the byte value).
 *      These 32 bits are used in GetFlags/SetFlags functions.
 *      You may freely examine these bits using GetFlags()
 */
...
//      Flag bit definitions (for GetFlags())
#define MS_VAL  0x000000FFL             // Mask for byte value
#define FF_IVL  0x00000100L             // Byte has value ?
...
// Get byte value from flags
#define byteValue(F)    (F & MS_VAL)    // quick replacement for Byte()
...
#define MS_CLS  0x00000600L             // Mask for typing
#define FF_CODE 0x00000600L             // Code ?
#define FF_DATA 0x00000400L             // Data ?
#define FF_TAIL 0x00000200L             // Tail ?
#define FF_UNK  0x00000000L             // Unknown ?
...
#define isCode(F)       ((F & MS_CLS) == FF_CODE) // is code byte?
...
#define FF_COMM 0x00000800L             // Has comment?
#define FF_REF  0x00001000L             // has references?
#define FF_LINE 0x00002000L             // Has next or prev cmt lines ?
#define FF_NAME 0x00004000L             // Has user-defined name ?
...

I.e. each byte of the address space is represented by a 32-bit value, where the lowest 8 bits are the original data and the remaining 24 bits are used for various flags and further information about the particular byte in the database space.

If anything, I would expect you to find fragments of data structured like this in the process memory, instead of the raw original bytes stored linearly.

I want to do this because I want to check what is actually behind question marks in certain situations,like in the IAT where it shows question marks instead of the offsets to names

I doubt question marks are hiding something that is actually known. Either the underlying data is there - and then you can just open the Hex View subview and check - or not.