<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.3.3" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments on: Crash Dump Analysis Patterns (Part 75)</title>
	<link>https://www.dumpanalysis.org/blog/index.php/2008/08/07/crash-dump-analysis-patterns-part-75/</link>
	<description>Structural and Behavioral Patterns for Software Diagnostics, Forensics and Prognostics</description>
	<pubDate>Wed, 06 May 2026 00:19:17 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3.3</generator>
		<item>
		<title>By: Dmitry Vostokov</title>
		<link>https://www.dumpanalysis.org/blog/index.php/2008/08/07/crash-dump-analysis-patterns-part-75/#comment-676544</link>
		<dc:creator>Dmitry Vostokov</dc:creator>
		<pubDate>Fri, 18 Jan 2013 22:12:30 +0000</pubDate>
		<guid>https://www.dumpanalysis.org/blog/index.php/2008/08/07/crash-dump-analysis-patterns-part-75/#comment-676544</guid>
		<description>.imgscan might not be able to find all hidden modules: 
http://www.dumpanalysis.org/blog/index.php/2013/01/18/crash-dump-analysis-patterns-part-194/</description>
		<content:encoded><![CDATA[<p>.imgscan might not be able to find all hidden modules:<br />
<a href="http://www.dumpanalysis.org/blog/index.php/2013/01/18/crash-dump-analysis-patterns-part-194/" rel="nofollow">http://www.dumpanalysis.org/blog/index.php/2013/01/18/crash-dump-analysis-patterns-part-194/</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Crash Dump Analysis &#187; Blog Archive &#187; Crash Dump Analysis of Defective Malware: A Case Study</title>
		<link>https://www.dumpanalysis.org/blog/index.php/2008/08/07/crash-dump-analysis-patterns-part-75/#comment-194870</link>
		<dc:creator>Crash Dump Analysis &#187; Blog Archive &#187; Crash Dump Analysis of Defective Malware: A Case Study</dc:creator>
		<pubDate>Wed, 20 Oct 2010 10:11:21 +0000</pubDate>
		<guid>https://www.dumpanalysis.org/blog/index.php/2008/08/07/crash-dump-analysis-patterns-part-75/#comment-194870</guid>
		<description>[...] This address range was not on a loaded module list so I used image scanning command to detect Hidden Module: [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] This address range was not on a loaded module list so I used image scanning command to detect Hidden Module: [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Crash Dump Analysis &#187; Blog Archive &#187; The Memory Visualization Question from Webinar</title>
		<link>https://www.dumpanalysis.org/blog/index.php/2008/08/07/crash-dump-analysis-patterns-part-75/#comment-180318</link>
		<dc:creator>Crash Dump Analysis &#187; Blog Archive &#187; The Memory Visualization Question from Webinar</dc:creator>
		<pubDate>Wed, 01 Sep 2010 14:59:33 +0000</pubDate>
		<guid>https://www.dumpanalysis.org/blog/index.php/2008/08/07/crash-dump-analysis-patterns-part-75/#comment-180318</guid>
		<description>[...] lm command didn&#8217;t show any duplicated loaded and unloaded modules as well as any hidden modules. So I looked at address information and found two identical relatively large regions at the [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] lm command didn&#8217;t show any duplicated loaded and unloaded modules as well as any hidden modules. So I looked at address information and found two identical relatively large regions at the [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dmitry Vostokov</title>
		<link>https://www.dumpanalysis.org/blog/index.php/2008/08/07/crash-dump-analysis-patterns-part-75/#comment-37760</link>
		<dc:creator>Dmitry Vostokov</dc:creator>
		<pubDate>Tue, 12 Aug 2008 10:02:15 +0000</pubDate>
		<guid>https://www.dumpanalysis.org/blog/index.php/2008/08/07/crash-dump-analysis-patterns-part-75/#comment-37760</guid>
		<description>No it wasn't loaded at its preferred address which is in PE header specified as:

0000000000400000 image base</description>
		<content:encoded><![CDATA[<p>No it wasn&#8217;t loaded at its preferred address which is in PE header specified as:</p>
<p>0000000000400000 image base</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Crash Dump Analysis &#187; Blog Archive &#187; Hooksware</title>
		<link>https://www.dumpanalysis.org/blog/index.php/2008/08/07/crash-dump-analysis-patterns-part-75/#comment-37544</link>
		<dc:creator>Crash Dump Analysis &#187; Blog Archive &#187; Hooksware</dc:creator>
		<pubDate>Sun, 10 Aug 2008 11:27:29 +0000</pubDate>
		<guid>https://www.dumpanalysis.org/blog/index.php/2008/08/07/crash-dump-analysis-patterns-part-75/#comment-37544</guid>
		<description>[...] - Hidden Module [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] - Hidden Module [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Marc Sherman</title>
		<link>https://www.dumpanalysis.org/blog/index.php/2008/08/07/crash-dump-analysis-patterns-part-75/#comment-37314</link>
		<dc:creator>Marc Sherman</dc:creator>
		<pubDate>Fri, 08 Aug 2008 17:57:03 +0000</pubDate>
		<guid>https://www.dumpanalysis.org/blog/index.php/2008/08/07/crash-dump-analysis-patterns-part-75/#comment-37314</guid>
		<description>Did you notice if usrxcptn.dll was loaded at its preferred address? Otherwise manual fixups of global addresses within the module would have to be done (the OS loader takes care of this for you). Unless of course they know the code to execute doesn't reference any globals.

Marc</description>
		<content:encoded><![CDATA[<p>Did you notice if usrxcptn.dll was loaded at its preferred address? Otherwise manual fixups of global addresses within the module would have to be done (the OS loader takes care of this for you). Unless of course they know the code to execute doesn&#8217;t reference any globals.</p>
<p>Marc</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dmitry Vostokov</title>
		<link>https://www.dumpanalysis.org/blog/index.php/2008/08/07/crash-dump-analysis-patterns-part-75/#comment-37309</link>
		<dc:creator>Dmitry Vostokov</dc:creator>
		<pubDate>Fri, 08 Aug 2008 16:13:27 +0000</pubDate>
		<guid>https://www.dumpanalysis.org/blog/index.php/2008/08/07/crash-dump-analysis-patterns-part-75/#comment-37309</guid>
		<description>I've just checked that this DLL is present in address space only if we add the application to Process Dumper applet in Control Panel. Process Dumper applet is installed when we do full installation of userdump package. Actually I added notepad.exe there and open it under WinDbg with loader snaps enabled in gflags.exe and I don't see this DLL in loader traces. 

The alternative to OS loader is widely used. You can just read the file into memory and jump to its code (of course after changing page protection and some other stuff). You can also map the file from the disk into virtual memory and in this case OS will load entire file contents for you.

usrxcptn.dll is a Microsoft DLL - you can find it in their userdump package.</description>
		<content:encoded><![CDATA[<p>I&#8217;ve just checked that this DLL is present in address space only if we add the application to Process Dumper applet in Control Panel. Process Dumper applet is installed when we do full installation of userdump package. Actually I added notepad.exe there and open it under WinDbg with loader snaps enabled in gflags.exe and I don&#8217;t see this DLL in loader traces. </p>
<p>The alternative to OS loader is widely used. You can just read the file into memory and jump to its code (of course after changing page protection and some other stuff). You can also map the file from the disk into virtual memory and in this case OS will load entire file contents for you.</p>
<p>usrxcptn.dll is a Microsoft DLL - you can find it in their userdump package.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Marc Sherman</title>
		<link>https://www.dumpanalysis.org/blog/index.php/2008/08/07/crash-dump-analysis-patterns-part-75/#comment-37297</link>
		<dc:creator>Marc Sherman</dc:creator>
		<pubDate>Fri, 08 Aug 2008 13:57:29 +0000</pubDate>
		<guid>https://www.dumpanalysis.org/blog/index.php/2008/08/07/crash-dump-analysis-patterns-part-75/#comment-37297</guid>
		<description>Every once in a while someone will ask how to execute code in a PE image without having to use the OS loader. For ex, someone will ask how to read a DLL from a socket and then execute it (without saving to disk and then calling LoadLibrary).

This post implies that it can be done and it *is* done with usrxcptn.dll ("it" referring to not using the OS loader).

Is usrxcptn.dll a Microsoft DLL? If so, do they have an alternative to the OS loader?

thanks,
Marc</description>
		<content:encoded><![CDATA[<p>Every once in a while someone will ask how to execute code in a PE image without having to use the OS loader. For ex, someone will ask how to read a DLL from a socket and then execute it (without saving to disk and then calling LoadLibrary).</p>
<p>This post implies that it can be done and it *is* done with usrxcptn.dll (&#8221;it&#8221; referring to not using the OS loader).</p>
<p>Is usrxcptn.dll a Microsoft DLL? If so, do they have an alternative to the OS loader?</p>
<p>thanks,<br />
Marc</p>
]]></content:encoded>
	</item>
</channel>
</rss>
