extracting native module

WINDBG
1

Hi, When doing managed debugging with sos.dll there is a !SaveModule command that allows you to extract the managed assembly to the disk. Is there similar command to do so for native modules? I tried using .writemem however the loaded module seems to be bigger in the dump compared to the original one. Is there a way to extract the native module from a dump as it was originally before loading into memory? Thank you, Martin Kulov

2

I don’t know of one.

Things like the loaded .bss are going to be different from the on disk
image.

Mm
On Dec 22, 2011 2:34 AM, “Martin Kulov” wrote:

> Hi,
>
> When doing managed debugging with sos.dll there is a !SaveModule command
> that allows you to extract the managed assembly to the disk.
>
> Is there similar command to do so for native modules? I tried using
> .writemem however the loaded module seems to be bigger in the dump compared
> to the original one.
>
> Is there a way to extract the native module from a dump as it was
> originally before loading into memory?
>
> Thank you,
>
> Martin Kulov
>
>
>
> —
> WINDBG is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

3

The fact that a module is larger in memory than its disk image should come
as nosurprise, because there is some compression that takes place. A
simple example is variables, where a long sequence of zero-initialized
storage can be “run-coded”. In addition, if there are code-alignment
issues, the PE file just saves the boundary information, but the image
really consumes bytes.

I’m not at all sure how an image can be “saved” because relocation binding
is a one-way transfer; one the symbols are relocated, no information is
retained to build a relocatable image again.

Since a “managed assembly” has no such issues, it could be saved, but I
doubt there can really be a way to do this for native code with the
current tooling. What is the purpose of writing this out? You can never
re-load it, and it seems unlikely you could use the debugger to examine it
(particularly for a driver, where all the interesting data is going to be
in an unmanaged heap).
joe

Hi, When doing managed debugging with sos.dll there is a !SaveModule
command that allows you to extract the managed assembly to the disk. Is
there similar command to do so for native modules? I tried using .writemem
however the loaded module seems to be bigger in the dump compared to the
original one. Is there a way to extract the native module from a dump as
it was originally before loading into memory? Thank you, Martin Kulov

WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

4

There is no compression or run-length encoding in the PE format. Sections can be declared in such a way that trailing zero fill is not required to be present in the physical file on disk which is pehraps what you are referring to.

What makes you think that base relocations are a one-way process only?

  • S (Msft)

From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] on behalf of xxxxx@flounder.com [xxxxx@flounder.com]
Sent: Thursday, December 22, 2011 10:30 AM
To: Kernel Debugging Interest List
Subject: Re: [windbg] extracting native module

The fact that a module is larger in memory than its disk image should come
as nosurprise, because there is some compression that takes place. A
simple example is variables, where a long sequence of zero-initialized
storage can be “run-coded”. In addition, if there are code-alignment
issues, the PE file just saves the boundary information, but the image
really consumes bytes.

I’m not at all sure how an image can be “saved” because relocation binding
is a one-way transfer; one the symbols are relocated, no information is
retained to build a relocatable image again.

Since a “managed assembly” has no such issues, it could be saved, but I
doubt there can really be a way to do this for native code with the
current tooling. What is the purpose of writing this out? You can never
re-load it, and it seems unlikely you could use the debugger to examine it
(particularly for a driver, where all the interesting data is going to be
in an unmanaged heap).
joe

Hi, When doing managed debugging with sos.dll there is a !SaveModule
command that allows you to extract the managed assembly to the disk. Is
there similar command to do so for native modules? I tried using .writemem
however the loaded module seems to be bigger in the dump compared to the
original one. Is there a way to extract the native module from a dump as
it was originally before loading into memory? Thank you, Martin Kulov

WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

5

On 12/22/11, Martin Kulov wrote:

> one. Is there a way to extract the native module from a dump as it was
> originally before loading into memory? Thank you, Martin Kulov

i dont dabble much in .net so i havent had an opportunity to dump any
.net modules

but with pe files yes they can be dumped and yes they can be bigger
that what is in file dependent on how Section Size is defined
/ALIGN:4096 /FILEALIGN:4096 switches by default have 0x200

if section size is in its default size 0x200 / 512 bytes in file it
will be 0x1000 / 4096 bytes in memory

cdb.exe -c “.writemem yourbin_dumped.exe yourbaseaddress L?yoursize
;q” -pn yourbin.exe

and with some tweaking you can reload and run them as well on some
cases especially when the bin is loaded in its preferred BaseAddress
cases.

6

Are you aware of any extension that does all the required stuff?It will be pretty time consuming to do this manually. Happy Holidays!Martin > Date: Fri, 23 Dec 2011 14:30:38 +0530

Subject: Re: [windbg] extracting native module
From: xxxxx@gmail.com
To: xxxxx@lists.osr.com

On 12/22/11, Martin Kulov wrote:
>
> > one. Is there a way to extract the native module from a dump as it was
> > originally before loading into memory? Thank you, Martin Kulov
>
> i dont dabble much in .net so i havent had an opportunity to dump any
> .net modules
>
> but with pe files yes they can be dumped and yes they can be bigger
> that what is in file dependent on how Section Size is defined
> /ALIGN:4096 /FILEALIGN:4096 switches by default have 0x200
>
> if section size is in its default size 0x200 / 512 bytes in file it
> will be 0x1000 / 4096 bytes in memory
>
>
> cdb.exe -c “.writemem yourbin_dumped.exe yourbaseaddress L?yoursize
> ;q” -pn yourbin.exe
>
>
> and with some tweaking you can reload and run them as well on some
> cases especially when the bin is loaded in its preferred BaseAddress
> cases.
>
> —
> WINDBG is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

7

> Are you aware of any extension that does all the required stuff?It will be

pretty time consuming to do this manually. Happy Holidays!Martin

unfortunately no on some occasions i have hexed the dump
using ollydbg view -> file -> special -> peheader ->modify integer

000001A8 55 50 58 30>ASCII “UPX0” ; SECTION
000001B0 00400100 DD 00014000 ; VirtualSize = 14000 (81920.)
000001B4 00100000 DD 00001000 ; VirtualAddress = 1000
000001B8 00000000 DD 00000000 ; SizeOfRawData = 0
000001BC 00040000 DD 00000400 ; PointerToRawData = 400

a bit tedious for sure