Comments on: WinDbg as a Binary Editor https://www.dumpanalysis.org/blog/index.php/2008/04/15/windbg-as-a-binary-editor/ Structural and Behavioral Patterns for Software Diagnostics, Forensics and Prognostics Mon, 25 May 2026 00:07:52 +0000 http://wordpress.org/?v=2.3.3 By: Crash Dump Analysis » Blog Archive » WinDbg as a simple PE viewer https://www.dumpanalysis.org/blog/index.php/2008/04/15/windbg-as-a-binary-editor/#comment-37788 Crash Dump Analysis » Blog Archive » WinDbg as a simple PE viewer Tue, 12 Aug 2008 15:19:01 +0000 https://www.dumpanalysis.org/blog/index.php/2008/04/15/windbg-as-a-binary-editor/#comment-37788 [...] needed to quickly check preferred load address for one DLL and recalled that I once used WinDbg as a binary editor. So I loaded that DLL as a crash [...] […] needed to quickly check preferred load address for one DLL and recalled that I once used WinDbg as a binary editor. So I loaded that DLL as a crash […]

]]> By: Jeffrey Tan https://www.dumpanalysis.org/blog/index.php/2008/04/15/windbg-as-a-binary-editor/#comment-23610 Jeffrey Tan Thu, 17 Apr 2008 12:38:13 +0000 https://www.dumpanalysis.org/blog/index.php/2008/04/15/windbg-as-a-binary-editor/#comment-23610 Oh, thanks Dmitry. I am using windbg to launch the exe instead of using a memory dump :-(. You are right. If we use memory dump it will work since windbg will memory mapping the entire dump file as writable. Oh, thanks Dmitry.

I am using windbg to launch the exe instead of using a memory dump :-(.

You are right. If we use memory dump it will work since windbg will memory mapping the entire dump file as writable.

]]> By: Dmitry Vostokov https://www.dumpanalysis.org/blog/index.php/2008/04/15/windbg-as-a-binary-editor/#comment-23592 Dmitry Vostokov Thu, 17 Apr 2008 09:54:37 +0000 https://www.dumpanalysis.org/blog/index.php/2008/04/15/windbg-as-a-binary-editor/#comment-23592 I did it on Vista x64. Did you attach WinDbg to a running process? In this case it seems logical that WinDbg cannot write to that region. In the case of a crash dump any memory seems to be just a buffer or mapped file. I did it on Vista x64. Did you attach WinDbg to a running process? In this case it seems logical that WinDbg cannot write to that region. In the case of a crash dump any memory seems to be just a buffer or mapped file.

]]> By: Jeffrey Tan https://www.dumpanalysis.org/blog/index.php/2008/04/15/windbg-as-a-binary-editor/#comment-23564 Jeffrey Tan Thu, 17 Apr 2008 03:05:52 +0000 https://www.dumpanalysis.org/blog/index.php/2008/04/15/windbg-as-a-binary-editor/#comment-23564 What's OS do you use? When I use the following approach on my Vista machine(using elevated windbg), it will generate error: 0:000> lm start end module name 00800000 0081b000 BinaryEditorTest (deferred) 65f80000 660a3000 MSVCR90D (deferred) 769a0000 76a78000 kernel32 (deferred) 77020000 7713e000 ntdll (private pdb symbols) c:\localsymbols\ntdll.pdb\C0A498F0036E4D4FB5CBF69005B0F9242\ntdll.pdb 0:000> .readmem e:\test.txt 00800000 L0n12 Reading c bytes Unable to write memory at 00800000, load is incomplete I assume this is because PE header is marked as read-only: 0:000> !address 00800000 ProcessParametrs 001e11a8 in range 001e0000 001e3000 Environment 001e0808 in range 001e0000 001e3000 00800000 : 00800000 - 00001000 Type 01000000 MEM_IMAGE Protect 00000002 PAGE_READONLY State 00001000 MEM_COMMIT Usage RegionUsageImage FullPath BinaryEditorTest.exe If I use the address from heap, it will succeed. So I believe we should use a writable memory page instead of read-only. PE file is not a good candidate. What’s OS do you use? When I use the following approach on my Vista machine(using elevated windbg), it will generate error:

0:000> lm
start end module name
00800000 0081b000 BinaryEditorTest (deferred)
65f80000 660a3000 MSVCR90D (deferred)
769a0000 76a78000 kernel32 (deferred)
77020000 7713e000 ntdll (private pdb symbols) c:\localsymbols\ntdll.pdb\C0A498F0036E4D4FB5CBF69005B0F9242\ntdll.pdb
0:000> .readmem e:\test.txt 00800000 L0n12
Reading c bytes
Unable to write memory at 00800000, load is incomplete

I assume this is because PE header is marked as read-only:

0:000> !address 00800000
ProcessParametrs 001e11a8 in range 001e0000 001e3000
Environment 001e0808 in range 001e0000 001e3000
00800000 : 00800000 - 00001000
Type 01000000 MEM_IMAGE
Protect 00000002 PAGE_READONLY
State 00001000 MEM_COMMIT
Usage RegionUsageImage
FullPath BinaryEditorTest.exe

If I use the address from heap, it will succeed. So I believe we should use a writable memory page instead of read-only. PE file is not a good candidate.

]]>