<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>ReversingLabs &#124; Blog &#187; PE32</title>
	<atom:link href="http://blog.reversinglabs.com/tag/pe32/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.reversinglabs.com</link>
	<description>Everything in reverse...</description>
	<lastBuildDate>Sat, 02 Jul 2011 10:53:01 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.4</generator>
		<item>
		<title>If it ain&#8217;t broke&#8230;</title>
		<link>http://blog.reversinglabs.com/2010/01/if-it-aint-broken/</link>
		<comments>http://blog.reversinglabs.com/2010/01/if-it-aint-broken/#comments</comments>
		<pubDate>Mon, 18 Jan 2010 14:26:28 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Reversing]]></category>
		<category><![CDATA[TitanEngine]]></category>
		<category><![CDATA[PE32]]></category>

		<guid isPermaLink="false">http://blog.reversinglabs.com/?p=284</guid>
		<description><![CDATA[If it ain't broke, don't fix it. But what if it is? What if the file you are trying to unpack with your unpacker is broken, then what? Do you just chuck it marking it as crapware or do you try to fix it? This raises many many question in file handling. Its foolish to [...]]]></description>
			<content:encoded><![CDATA[<p style="text-align: justify;">If it ain't broke, don't fix it. But what if it is? What if the file you are trying to unpack with your unpacker is broken, then what? Do you just chuck it marking it as crapware or do you try to fix it? This raises many many question in file handling. Its foolish to assume that every file your unpacker receives is a valid portable executable. So, how does <em>TitanEngine </em>cope with this?</p>
<p style="text-align: justify;">As you may know <em>TitanEngine </em>has two built in functions to identify and fix damaged PE32/PE32+ files. Those two functions are: <em>IsPE32FileValidExW </em>and <em>FixBrokenPE32FileExW </em>in their UNICODE implementation. If you remember, not too long ago we published a PE validation tool built around our validation function which is available <a href="http://blog.reversinglabs.com/wp-content/uploads/2009/12/PEValidate.zip">here</a>. Today we pay attention on how to use these two functions.</p>
<p style="text-align: justify;">Ideally before initializing the dynamic unpacking process you would validate the file you are unpacking to see if it will actually execute on the system. Windows loader can also show error messages about the broken file but since we are building our own application which might batch files its best to handle these cases statically before the application runs. And <em>TitanEngine's </em>validation function works in just such a way. It statically inspects the file making sure that it is valid or providing as much information about the errors found as possible. If we take a look at the FILE_STATUS_INFO structure we see all aspects of PE file being inspected.</p>
<blockquote>
<pre class="cpp"><span style="">typedef</span> <span style="">struct</span><span style="color: #FFFFFF;">&#123;</span>
	BYTE OveralEvaluation;
	<span style="">bool</span> EvaluationTerminatedByException;
	<span style="">bool</span> FileIs64Bit;
	<span style="">bool</span> FileIsDLL;
	<span style="">bool</span> FileIsConsole;
	<span style="">bool</span> MissingDependencies;
	<span style="">bool</span> MissingDeclaredAPIs;
	BYTE SignatureMZ;
	BYTE SignaturePE;
	BYTE EntryPoint;
	BYTE ImageBase;
	BYTE SizeOfImage;
	BYTE FileAlignment;
	BYTE SectionAlignment;
	BYTE ExportTable;
	BYTE RelocationTable;
	BYTE ImportTable;
	BYTE ImportTableSection;
	BYTE ImportTableData;
	BYTE IATTable;
	BYTE TLSTable;
	BYTE LoadConfigTable;
	BYTE BoundImportTable;
	BYTE COMHeaderTable;
	BYTE ResourceTable;
	BYTE ResourceData;
	BYTE SectionTable;
<span style="color: #FFFFFF;">&#125;</span>FILE_STATUS_INFO, *PFILE_STATUS_INFO;</pre>
</blockquote>
<p style="text-align: justify;">Most important field for file validation purposes is the OveralEvaluation field which can have the following values:</p>
<ul>
<li>UE_RESULT_FILE_OK</li>
<li>UE_RESULT_FILE_INVALID_FORMAT</li>
<li>UE_RESULT_FILE_INVALID_AND_NON_FIXABLE</li>
<li>UE_RESULT_FILE_INVALID_BUT_FIXABLE</li>
</ul>
<p style="text-align: justify;">No matter if the file is fixable or not the rest of the structure will be filled with information about defects found in the file. File is considered invalid and non fixable if the file OveralEvaluation says so, but that doesn't mean that the file will execute. If there are missing dependencies in the file it might not execute but that can be easily fixed by installing the Nexus plugin. If however OveralEvaluation claims that file can be fixed we can call FixBrokenPE32FileExW function to try to repair the file. While file is being repaired  following structure will be filled:</p>
<blockquote>
<pre class="cpp"><span style="">typedef</span> <span style="">struct</span><span style="color: #FFFFFF;">&#123;</span>
	BYTE OveralEvaluation;
	<span style="">bool</span> FixingTerminatedByException;
	<span style="">bool</span> FileFixPerformed;
	<span style="">bool</span> StrippedRelocation;
	<span style="">bool</span> DontFixRelocations;
	DWORD OriginalRelocationTableAddress;
	DWORD OriginalRelocationTableSize;
	<span style="">bool</span> StrippedExports;
	<span style="">bool</span> DontFixExports;
	DWORD OriginalExportTableAddress;
	DWORD OriginalExportTableSize;
	<span style="">bool</span> StrippedResources;
	<span style="">bool</span> DontFixResources;
	DWORD OriginalResourceTableAddress;
	DWORD OriginalResourceTableSize;
	<span style="">bool</span> StrippedTLS;
	<span style="">bool</span> DontFixTLS;
	DWORD OriginalTLSTableAddress;
	DWORD OriginalTLSTableSize;
	<span style="">bool</span> StrippedLoadConfig;
	<span style="">bool</span> DontFixLoadConfig;
	DWORD OriginalLoadConfigTableAddress;
	DWORD OriginalLoadConfigTableSize;
	<span style="">bool</span> StrippedBoundImports;
	<span style="">bool</span> DontFixBoundImports;
	DWORD OriginalBoundImportTableAddress;
	DWORD OriginalBoundImportTableSize;
	<span style="">bool</span> StrippedIAT;
	<span style="">bool</span> DontFixIAT;
	DWORD OriginalImportAddressTableAddress;
	DWORD OriginalImportAddressTableSize;
	<span style="">bool</span> StrippedCOM;
	<span style="">bool</span> DontFixCOM;
	DWORD OriginalCOMTableAddress;
	DWORD OriginalCOMTableSize;
<span style="color: #FFFFFF;">&#125;</span>FILE_FIX_INFO, *PFILE_FIX_INFO;</pre>
</blockquote>
<p style="text-align: justify;">This structure is input/output one. It can be used to set options to what will be fixed in and what will be left as it is. This is totally optional and this structure can be left zeroed before calling the file fixing function. Field OveralEvaluation can have the same values like in the FILE_STATUS_INFO structure and its used the same way. Additionally the value of variable FileFixPerformed indicates if the the file has been fixed. However not all field can be fixed, some can only be temporarily stripped. These fields are saved in the FILE_FIX_INFO structure and must be restored once the file has been dumped to disk. Most commonly this refers to resources which can be corrupted on disk but valid once the file has been decompressed in memory. Currently there isn't a function to automatically restore these fields so it must be done by the unpacker code. This will change for next major release.</p>
<p style="text-align: justify;">To make this blog a little more then just a documentation clarification we have modified our existing UPX unpacker sample to support basic file fixing. Sample which is included in the package has damaged SizeOfImage field and incorrect code section attributes. This is fixed by the unpacked and saved in a new file which is then used for unpacking. As always binary, source code and the samples are included with the blog. Until next week...</p>
<p><!-- Facebook Badge START --></p>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0">
<tr>
<td width="150" align="center" valign="middle"><a style="font-family: &amp;amp;quot; font-size: 11px; font-variant: normal; font-style: normal; font-weight: normal; color: #3b5998; text-decoration: none;" title="TitanEngine" href="http://www.facebook.com/pages/TitanEngine/136818796342291" target="_TOP">TitanEngine</a><br />
<a title="TitanEngine" href="http://www.facebook.com/pages/TitanEngine/136818796342291" target="_TOP"><img style="border: 0px;" src="http://badge.facebook.com/badge/136818796342291.1698.1945128657.png" alt="" width="120" height="144" /></a><br />
<a style="font-family: &amp;amp;quot; font-size: 11px; font-variant: normal; font-style: normal; font-weight: normal; color: #3b5998; text-decoration: none;" title="" href="http://www.reversinglabs.com" target="_TOP">ReversingLabs Corporation</a></td>
<td width="450" align="center" valign="middle">
<p><a href="http://blog.reversinglabs.com/wp-content/uploads/2010/01/RLdeUPX_v2.zip">RL!deUPX</a><br />
(package contains unpacker binary, source and samples used)</p>
</td>
</tr>
</table>
<p><!-- Facebook Badge END --></p>
<p><a class="a2a_dd a2a_target addtoany_share_save" href="http://www.addtoany.com/share_save#url=http%3A%2F%2Fblog.reversinglabs.com%2F2010%2F01%2Fif-it-aint-broken%2F&amp;title=If%20it%20ain%26%238217%3Bt%20broke%26%238230%3B" id="wpa2a_2"><img src="http://blog.reversinglabs.com/wp-content/plugins/add-to-any/share_save_120_16.png" width="120" height="16" alt="Share"/></a></p>]]></content:encoded>
			<wfw:commentRss>http://blog.reversinglabs.com/2010/01/if-it-aint-broken/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
	</channel>
</rss>

