I read the documentation about the PE format on MSDN, there it specifies:
The preferred address of the first byte of image when loaded into memory; must be a multiple of 64 K. The default for DLLs is 0x10000000. The default for Windows CE EXEs is 0x00010000. The default for Windows NT, Windows 2000, Windows XP, Windows 95, Windows 98, and Windows Me is 0x00400000
I don't quite understand this. What is a "preferred address"? How is this field used by windows when making a new process/loading an executable?
It is the address in virtual memory where the executable should be loaded at to avoid any adjustment of absolute jump instructions in the code.
The OS may load the module to a different address (in case e.g. 2 DLLs needed by the same program have the same image base), but in that case the code needs to be patched when loaded.
For more info, see https://msdn.microsoft.com/en-us/library/ms809762.aspx (search for ImageBase there).
Related
I am trying to disassemble the 64-bit ntdll.dll using IDA. From my understand, this DLL is located in C:\Windows\System32 on a Windows 64-bit OS. When I disassemble this DLL, it shows 32-bit addresses and a 32-bit instruction set. However, in the debugger, when I load this library into a process from the same directory, it has a 64-bit instruction set during runtime.
How can I disassemble the 64-bit ntdll?
Please check whether IDA is a 32 bit application in Task Manager (on the Processes page 32 bit processes should have the suffix (32 bit). If you switch to the Details page in Task Manager perform a right click on the column header and choose Select columns from the context menu. Select Platform to display the bit-ness of a process and close the dialog. 32 bit processes are listed as 32 bit in the Platform column.
If IDA is a 32 bit application, use the path c:\windows\sysnative\ntdll.dll to open the DLL. If you specify sysnative instead of System32, Windows uses the SYSTEM32 directory instead of the SysWOW64 for 32 bit apps.
While studying the WinAPI documentation, I stumbled across SCS_POSIX_BINARY. Allegedly, MS Windows can somewhat execute POSIX executables (despite Wine docs listing them as "not implemented")
Assuming POSIX executables can run, what is the standard word size ("bitness") for SCS_POSIX_BINARY ? For example, for MS Windows =< 2010, the word size is typically 32 bits. What would be the equivalent for POSIX, and/or for Microsoft's POSIX implementation if any?
Cheers
The word size is always going to be <= the word size of the kernel so on a 32-bit OS it is going to be 32-bit for all the POSIX tools.
The Microsoft website for SUA (2003 R2) says:
These components include all utilities that install with Windows Services for UNIX 3.5. These are nearly 300 BSD-based and optional SUA GNU utilities. Many of these utilities (around 80) are also available in 64-bit version.
The only conclusion I can draw from this is that a 64-bit version of Windows supports both. To know for sure that this is accurate you would actually have to install SUA on a 64-bit machine.
GetBinaryType is a very old function so my guess is that it only checks if it's a POSIX PE and does not look at the machine type. If you actually care then you can just read the header yourself and see.
Edit:
I downloaded the SUA installer and took a look and it does include both 32 and 64 bit POSIX PE executables.
For 32-bit (dumpbin):
FILE HEADER VALUES
14C machine (x86)
C number of sections
...
OPTIONAL HEADER VALUES
10B magic # (PE32)
...
2736E checksum
7 subsystem (Posix CUI)
SCS_POSIX_BINARY is returned as expected but for
FILE HEADER VALUES
8664 machine (x64)
...
OPTIONAL HEADER VALUES
20B magic # (PE32+)
...
0 checksum
7 subsystem (Posix CUI)
it actually returns SCS_64BIT_BINARY! So you do actually have to inspect the PE header yourself if you want the true answer.
I wrote a 32-bit application that launches a 16-bit executable, which loads some 16-bit DLLs to perform some of the application's functions. It runs fine on Windows 7 32-bit, but not on Windows 7 64-bit since that version of the OS does not include the NTVDM.
The 16-bit portion of the code is pretty extensive and would be pretty expensive to port to 32-bit. Also, it uses some 3rd-party 16-bit APIs from a company that is no longer in business; therefore, that code would have to be recreated completely, thereby increasing the cost.
Is there any possible way to simply load the existing 16-bit DLLs directly from the 32-bit application, removing the 16-bit executable completely?
I've looked into thunking, but it doesn't appear that is supported in Windows 7 either.
You have to use an emulator or a virtual machine.
Or, if that is not an option then you can write a primitive emulator yourself, read the machinecode instruction-by-instruction and modify fake-registers and memory accordingly, and when the program calls outward then you will have to generate responses.
No. This is not possible in Windows.
All WoW64 apps go through WoW64 emulation layer.
I'd like to know what happen in this layer.(especially, how they can convert address space)
Please give me some important points.
Since you have already posted the diagram it is clear that you know why WOW64 exists. Now to answer your question:
I'd like to know what happen in this layer.
I think you want to know how it is implemented.
Process startup: The loader loads 64-bit user-mode part 'Ntdll.dll' as usual, but also loads 32-bit Ntdll.dll in case the process is for 32-bit execution. It is now the loaders responsibility to initialize using Wow64.dll, which sets up process and thread contexts in 32-bit Ntdll and 'switches the CPU to 32-bit mode' for execution.
System Call: Everything is now running in 32-bit mode, until a system call. We know that system calls go through Ntdll.dll, User32.dll, and Gdi32.dll etc; in this case the 32-bit versions. There is a separate 32-bit version of these libraries located in \Windows\Syswow64 bit folder. These are just stubs that instead of issuing 'native system calls,' actually call in Wow64.dll. Now, it's simple for Wow64.dll to transition to 64-bit mode, convert parameters to their 64-bit counterparts, issue the system call using 64-bit versions, get the result, and reconvert the output to 32-bit. It then transitions CPU back to 32-bit mode and returns the output.
Exception dispatching, user callbacks, file system and registry operations, and I/O is handled in the same way, using hooks somewhere down the line. Read the book prescribed below.
(especially, how they can convert address space).
64-bit address space is a superset of 32-bit address space. Plus, the same pointer (actually PTE) in 32-bit/64-bit isn't used to refer to the whole address space, but there are separate page tables for user-space and for system space.
Please give me some important points.
To know windows, the most important point I can give you is to read 'Windows Internals' -- Russinovich
MSDN says:
WOW64 is the x86 emulator that allows 32-bit Windows-based applications to run seamlessly on 64-bit Windows. WOW64 is provided with the operating system and does not have to be explicitly enabled.
The system isolates 32-bit applications from 64-bit applications, which includes preventing file and registry collisions. Console, GUI, and service applications are supported. The system provides interoperability across the 32/64 boundary for scenarios such as cut and paste and COM. However, 32-bit processes cannot load 64-bit DLLs for execution, and 64-bit processes cannot load 32-bit DLLs for execution.
What specifically do you not understand? Have you already read the Wikipedia article on the WoW64 subsystem? I think you'll find that it provides a fairly comprehensive overview.
And Microsoft provides some additional details here: WOW64 Implementation Details
"especially, how they can convert address space"
the key to that is knowing that amd and intel x64 processors have support for running 32bit and 64bit code side by side. this allows the os (when running native x64) to create a context for a 32bit thread that has 32bit addressing that coexists with the 64bit threads
in a similar way when the host os is running 32bit, it can create 16bit threads for running win16 and dos applications.
note, I don't think when running in the os 64bit that it can create 32bit AND 16bit threads - I guess amd decided that was just too much backwards compatability :-)
0x10b : PE32 executable
0×107 : ROM image
0x20b : PE32+ (64 bit) executable
What is the ROM image?
Interesting question, I've dabbled with manipulating PE files but never noticed that.
Here's what I believe they are used for: A ROM image can be executed 'in place' (XIP), if you search MSDN for "rom image", you'll find a number of references to it in the Windows Mobile and older Windows CE tools, e.g. Rom Image Creation.
A ROM image can thus be executed directly from the ROM without having to load and relocate it in RAM, which is pretty handy for a mobile device with limited resources.