I am new to PE analysis, so please bear with me for my basis question.
Loading PE in Windows XP and Windows 7 are showing different Entry Point
Hello.exe created in Windows XP.
CFF Explorer is showing ImageBase 0x00400000 and AddressOfEntryPoint 0x00001578. But when I load hello.exe in OllyDbg (running on Windows 7), it is showing EP at 0x773201C8
When I load hello.exe in OllyDbg (running on Windows XP), its showing the correct EP at 0x00401578.
I would like to know why the EP is different on Windows 7.
Address OF Entry Point in PeHeader is an RVA (Relative Virtual Address)
it is relative to the Imagebase
C:\>dumpbin /headers c:\Windows\System32\calc.exe | grep -iE "entry|im.*base"
12D6C entry point (01012D6C) _WinMainCRTStartup
1000000 image base (01000000 to 010BFFFF)
Image base can be different for different loads ( Read Upon ASLR Address Space layout Randomization )
so you are seeing these differences
Related
I'm doing some remote kernel debugging with IDA + WinDBG plugin and I want to set a breakpoint in some function inside the DLL, which I found while disassembling it in IDA. I switched to the process, which loads the target DLL, but unfortunately I found out that the DLL in memory is partly missed including my function.
Examples for proof are below. Here IDA recognized the function sub_180001FC8, but in WinDBG this disassembly breaks off on address 0x7fff3d131fff.
Screenshot 1 - DLL loaded into memory in live kernel debugging
Screenshot 2 - same DLL opened in IDA "statically"
What's wrong and how to recover missed parts?
Finally I found the answer.
The region where disassembly breaks off with ?? is paged out memory region.
To "restore" the page I used the command:
.pagein /f /p <process_address> <page_start_address>
For my situation:
.pagein /f /p 0xffffbc4a4405efc0 0x7fff3d132000
This command loads memory pages from secondary storage and they become visible in disassembly.
References:
https://en.wikipedia.org/wiki/Memory_paging
https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/-pagein--page-in-memory-
Can I manually insert ImageBase value of PE file?
Basically..
ImageBase of DLL = 10000000
ImageBase of EXE = 00400000
If can, I want change ImageBase to random address.
I wonder How to do.
You can easily change the base address AND prevent Windows from relocating your executable module to a random base. I should stress that if you have access to the build environment, you should prefer specifying the base address and preventing the DYNAMICBASE flag from being placed in the module to begin with at build time, allowing the linker to make the proper optimizations. To do this with MSVC, you'd specify linker flags:
/BASE:400000
/DYNAMICBASE:NO
Altering the image base after the fact CAN be done and will work for simple modules, but in some instances could result in crashes depending on how the code was generated. Sometimes there is little choice when one does not have access to the original source code.
The code and data accesses may hardcode values based on the original ImageBase linked with. If you want to modify a module after it has been build, read on.
While Address Space Layout Randomization (ASLR) behavior was introduced in Windows Vista, the modifications suggested here WILL work on ANY version of Windows.
NOTE: The preceding statement assumes Microsoft, in the future, doesn't start randomizing image base addresses without regard to the relevant PE flags in the header or refuse to load these modules altogether. As of the present versions of Windows 10, Windows currently honors images that DO NOT contain IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE flag, preventing dynamic relocation.
Using a hex editor, a tool like MSVC's editbin, or even your own code, the following modifications should be made to the PE headers of the desired module to set a FIXED base-load address:
-set desired IMAGE_OPTIONAL_HEADER -> ImageBase (e.g. 0x400000)
i.e. editbin.exe /rebase:base=0x400000 <YOUR_MODULE>
-remove the the 0x0040 (DYNAMIC_BASE) bit from the IMAGE_OPTIONAL_HEADER -> DllCharacteristics flags or use editbin:
i.e.: editbin /dynamicbase:no <YOUR_MODULE>
-if not using editbin, you will need to recalculate the header checksum or just leave at zero for any non-driver or start-up Windows service; editbin updates the checksum automatically.
NOTES:
-manually changing the module's base address may require that you walk the .reloc section entries and perform manual fixups for your new base address either statically or at runtime (simulating what the Windows loader does); not doing so could result in crashes. To avoid this hassle, just remove the DYNAMIC_BASE flag and leave the base address the same as when the module was built. Then you still prevent ASLR, even if the original base address doesn't change.
-the editbin version must have come from MSVC 2005 SP1 (8.0.50727.161) to support the /dynamicbase argument; any free modern version of the MSVC C++ toolset's editbin will have this feature; my experience is that the /rebase option might report the cryptic "LNK1175: failed to rebase ; error 487" even for modules without a .reloc section - this ultimately forces you to use a PE editor to change ImgBase.
-The changes above may break embedded digital signature checks or anything that verifies the integrity of the original file since we've modified it.
As far as I remember, windows PE loader decides on base loading address(ImageBase in your question) and you cannot select it manually unless you write PE loader yourself.
Starting Windows Vista, windows uses address randomizer for selecting a random base loading address. So it is not like 0x10000000 or 0x00400000 anymore and it changes in every run unless the process is started in special situations like debug mode.
(Sorry for the analogous question I posted, I've modified it.)
I'm trying to debug an excutable PE file on windows XP to see how PDE and PTE works in a real system. I've learned that windbg have some commands to see the details. It seems that !pte would be able to see the corresponding PDE and PTE of a virtual address. But I come across
0:000> !pte
No export pte found
I did some google work and find that it is an extension command, but I don't see any description on how to enable these extensions. It seems that everybody is using it directly except me.
I wonder what I have missed but I couldn't figure out. Could anyone please give me some advice?
Thanks.
since you are using xp Local Kernel Debugging support is available without having to edit boot configuration and rebooting
if you are on an operating system higher that xp you need to edit the boot configuration of the os with /debug on switch and reboot for local kernel debugging support
bcdedit /debug on and reboot only then windbg -kl will work on os greater than XP
if you don't want to edit your boot configuration download livekd
from sysinternals and use it instead for local kernel debugging
open windbg with this command-line
windbg -kl
this will open windbg with the prompt lkd> instead of the 0:000>
now you can use the !pte command
substitute explorer.exe with the name of the binary that is running which you want to examine (be aware this is not usermode you are looking at the kernel mode part of your binary)
in the example below i am using livekd in windows 7 x86 32 bit physical machine
C:\>livekd
LiveKd v5.40 - Execute kd/windbg on a live system
Sysinternals - www.sysinternals.com
Copyright (C) 2000-2015 Mark Russinovich and Ken Johnson
Launching C:\Program Files\Windows Kits\8.1\Debuggers\x86\kd.exe:
Microsoft (R) Windows Debugger Version 6.3.9600.17298 X86
Copyright (c) Microsoft Corporation. All rights reserved.
kd> !process 0 0 explorer.exe
PROCESS 864b2638 SessionId: 1 Cid: 05f8 Peb: 7ffde000 ParentCid: 05e4
DirBase: 7e28c2c0 ObjectTable: 964ccad8 HandleCount: 1062.
Image: explorer.exe
kd> .process /p /r 864b2638
Implicit process is now 864b2638
Loading User Symbols
kd> !pte explorer
VA 00400000
PDE at C0600010 PTE at C0002000
contains 000000000FFB2867 contains 80000000103F7025
pfn ffb2 ---DA--UWEV pfn 103f7 ----A--UR-V
kd> $$ page table entry contains 103f7025
kd> dc c0002000 l1
c0002000 103f7025 %p?.
kd> $$ the top 5 bytes are page frame nos lets see if the physical page contains MZ
kd> !dc 103f7000 l1
#103f7000 00905a4d MZ.......L`...ac
kd>
You are debugging an executable. This means you're debugging in user mode. Looking at an application in user mode, you'll see virtual memory only. The debugger will present you the same view as the application/executable has.
Virtual memory is provided to application in different ways. It could be physical memory, page file content or even nothing (for reserved memory).
Whatever it is in reality, this is hidden from the application. That's what the kernel does for you. To see how it does that, you need to use kernel debugging. The debugger will then let you see what the OS sees internally and allow the use of kernel related commands like !pte (and many more).
PTE (page table entry) and PDE (page directory entry) are exactly the "objects" the kernel uses to perform the mapping between virtual memory and physical memory.
To analyze that, you probably want to perform kernel debugging and user mode debugging at the same time, to verify that the results you get on kernel side really match the results you get on user mode side.
Since it seems you're a novice on this topic, I'd suggest doing that in a virtual machine or on a dedicated PC. Don't use a PC which has important data. In kernel mode, you can potentially cause blue screens and lose all unsaved work.
There are articles from the NT debugging blog like Understanding !pte - Part 1 - Let's get physical which get you started, followed by Part 2 - Flags and Large Pages and Part 3 - Non-PAE and X64.
I have PE file that was made with 16bit delphi. I spent all day trying to use WriteProcessMemory() on this file. It doesn't work. I can't find adresses in cheat engine nor tsearch. Peid says that file is not valid PE, I guess thats because of 16 bits?
Do you have any ideas how to read these adresses ?
I can post exe if needed.
Delphi 16bit didn't make PE files. It made NE files... IOW, NE = "New Executable" and PE = "Portable Executable" NE files were introduced in Windows 32bit with the release of Windows NT 3.1 around '92 or '93.
It is not likely that you'll be able to read the memory of a running 16bit process from a 32bit process. This is because a 16bit application will run within a special subsystem that emulates the 16bit environment.
From a Microsoft article:
Address Space Layout Randomization (ASLR)
ASLR moves executable images into random locations when a system
boots, making it harder for exploit
code to operate predictably. For a
component to support ASLR, all
components that it loads must also
support ASLR. For example, if A.exe
consumes B.dll and C.dll, all three
must support ASLR. By default, Windows
Vista and later will randomize system
DLLs and EXEs, but DLLs and EXEs
created by ISVs must opt in to support
ASLR using the /DYNAMICBASE linker
option.
I don't quite get it. Take the base system DLLs loaded by every process on WIndows: NtDll.dll and kernel32.dll.
If a have a non-aware executable, will these system DLLs use ASLR? That is, will they load at a different base address after every system reboot on Win 7 for this executable or will they always load at the same base address after system reboot like they do on Win XP?
To make it more clear what I mean: My typical dummy program's startup stack will look like this:
write_cons.exe!wmain() Line 8 C++
write_cons.exe!__tmainCRTStartup() Line 583 + 0x19 bytes C
write_cons.exe!wmainCRTStartup() Line 403 C
> kernel32.dll!_BaseProcessStart#4() + 0x23 bytes
Looking at the asm of BaseProcessStart, I see on my XP box here:
_BaseProcessStart#4:
7C817054 push 0Ch
7C817056 push 7C817080h
7C81705B call __SEH_prolog (7C8024D6h)
7C817060 and dword ptr [ebp-4],0
...
Now what interests me is the following:
On Windows XP, the address will always be 0x7C817054, regardless of how many times I reboot this machine. If I were on Win7 with ASLR, will this address change between reboots if the executable that loads kernel32.dll is not enabled for ASLR?
(Note: For me, atm., there is only one minor use-case this address would be useful for: In Visual Studio, I can only set a "Data Breakpoint" for assembly level functions, that is a breakpoint # 0x7... - If I want to break in a specific ntdll.dll or kernel32.dll function, in Windows XP I do not have to adjust my breakpoints between reboots. With ASLR kicking in (the scope of this question) I would have to change the Data Breakpoints between reboots.)
Technically whether the system dlls get relocated or not, it shouldn't matter, as the linker will bind to symbols, not addresses. These symbols are resolved by the runtime loader into to addresses for the instanced system dlls, thus your binary should be none the wiser. From what i've seen however, windows 7 will reset the base randomization every reboot, including system dlls(note: this is from debuging WOW64 apps on widows server 2008 R2). You can also do a system wide disabling of ASLR via some registery edits, but thats not really relevant...
Update:
the section on ASLR in this article explains what gets relocated and when.
it doesn't mention if the base will reset every reboot, but for system dlls, its never going to be guaranteed to load at the same address twice, reboot or no reboot.
the important thing is according to article, everything needs to opt-in to ASLR for system dll's to be relocated.
Your program will resolve calls into system DLLs wherever they happen to be loaded. But, unless your executable is linked with /DYNAMICBASE, it will not be given a randomized base address. In other words, your exe will always load at the same base address.
If you want your exe to load at a randomized address, then you have to link it with /DYNAMICBASE, and every DLL that it references must also have been linked with /DYANMICBASE. The system DLLs (starting in Vista) are all linked with /DYNAMICBASE.