<?xml version="1.0"?>
<rss version="2.0">
    <channel>
        <title>OpenRCE: Blog</title>
        <link>http://www.openrce.org/rss/feeds/blog</link>
        <description>OpenRCE: The Open Reverse Code Engineering Community</description>
                <item>
            <title>blog moved</title>
                            <pubDate>Tue, 07 Jun 2011 16:42:46 -0500</pubDate>
                                        <link>https://www.openrce.org/blog/view/1654/blog_moved</link>
                                        <author>ReWolf &lt;email-suppressed@example.com&gt;</author>
                                                    <description>All new posts will be published on my new blog &lt;a href=&quot;http://blog.rewolf.pl&quot;&gt;http://blog.rewolf.pl&lt;/a&gt;, so pleas update your bookmarks ;)</description>
                    </item>
                <item>
            <title>dirtyJOE - Java Overall Editor</title>
                            <pubDate>Sat, 18 Sep 2010 03:39:00 -0500</pubDate>
                                        <link>https://www.openrce.org/blog/view/1612/dirtyJOE_-_Java_Overall_Editor</link>
                                        <author>ReWolf &lt;email-suppressed@example.com&gt;</author>
                                                    <description>&lt;b&gt;dirtyJOE - Java Overall Editor&lt;/b&gt; is a complex editor and viewer for compiled java binaries (.class files). Current version still have some limitations, but hopefully those will be removed within the next releases.&lt;br /&gt;
&lt;br /&gt;
dirtyJOE is &lt;b&gt;free for non-commercial&lt;/b&gt; use.&lt;br /&gt;
&lt;br /&gt;
dirtyJOE is entirely written in C++, no third party libraries were used.&lt;br /&gt;
&lt;br /&gt;
&lt;b&gt;Main features:&lt;/b&gt;&lt;br /&gt;
 - Viewer for: constant pool, methods, fields, attributes&lt;br /&gt;
 - Editor for: constant pool, bytecode&lt;br /&gt;
&lt;br /&gt;
You can download it from &lt;a href=&quot;http://dirty-joe.com&quot;&gt;http://dirty-joe.com&lt;/a&gt;&lt;br /&gt;
</description>
                    </item>
                <item>
            <title>When memory management goes bad...</title>
                            <pubDate>Thu, 04 Mar 2010 13:00:59 -0600</pubDate>
                                        <link>https://www.openrce.org/blog/view/1553/When_memory_management_goes_bad...</link>
                                        <author>ReWolf &lt;email-suppressed@example.com&gt;</author>
                                                    <description>Few months ago I've encountered a strange behavior in cmd.exe when I wanted to list some big collection of files and execute some command on every single file. I used for this task 'for' command similar to this:&lt;br /&gt;
&lt;code&gt;&lt;br /&gt;
for /R c:\ %c in (*.*) do echo %c &amp;gt;&amp;gt; cmd_ptc.log&lt;br /&gt;
&lt;/code&gt;&lt;br /&gt;
After few hours of processing I get a very disturbing message:&lt;br /&gt;
&lt;code&gt;&lt;br /&gt;
&amp;quot;Not enough storage is available to process this command.&amp;quot;&lt;br /&gt;
&lt;/code&gt;&lt;br /&gt;
Actually cmd.exe can eat all memory available for the process. I decided to check why it needs such amount of memory and if it will be possible fix it. Below you can find link to the full article and package with the fixed binaries (from Windows Vista SP2):&lt;br /&gt;
&lt;br /&gt;
&lt;a href=&quot;http://rewolf.pl/stuff/rewolf_cmd_research.pdf&quot;&gt;http://rewolf.pl/stuff/rewolf_cmd_research.pdf&lt;/a&gt; - &lt;i&gt;article&lt;/i&gt;&lt;br /&gt;
&lt;a href=&quot;http://rewolf.pl/stuff/rewolf_cmd_research.zip&quot;&gt;http://rewolf.pl/stuff/rewolf_cmd_research.zip&lt;/a&gt; - &lt;i&gt;article and binaries&lt;/i&gt;&lt;br /&gt;
&lt;br /&gt;
Happy reading !&lt;br /&gt;
&lt;a href=&quot;http://rewolf.pl&quot;&gt;ReWolf&lt;/a&gt;</description>
                    </item>
                <item>
            <title>Hacker Challenge 2008</title>
                            <pubDate>Wed, 15 Apr 2009 15:10:10 -0500</pubDate>
                                        <link>https://www.openrce.org/blog/view/1434/Hacker_Challenge_2008</link>
                                        <author>ReWolf &lt;email-suppressed@example.com&gt;</author>
                                                    <description>My reports from &lt;a href=&quot;http://hackerchallenge.org/&quot;&gt;Hacker Challenge 2008&lt;/a&gt; are already available online:&lt;br /&gt;
&lt;br /&gt;
&lt;i&gt;(zip archives contains original challenge, cracked binary and report)&lt;/i&gt;&lt;br /&gt;
&lt;br /&gt;
&lt;b&gt;Phase 1:&lt;/b&gt;&lt;br /&gt;
&lt;a href=&quot;http://rewolf.pl/stuff/rewolf_hc2008_phase1.zip&quot;&gt;http://rewolf.pl/stuff/rewolf_hc2008_phase1.zip&lt;/a&gt;&lt;br /&gt;
&lt;a href=&quot;http://rewolf.pl/stuff/rewolf_hc2008_ph1_report.pdf&quot;&gt;http://rewolf.pl/stuff/rewolf_hc2008_ph1_report.pdf&lt;/a&gt;&lt;br /&gt;
&lt;br /&gt;
&lt;b&gt;Phase 3 (third place in &amp;quot;quality of report&amp;quot; category):&lt;/b&gt;&lt;br /&gt;
&lt;a href=&quot;http://rewolf.pl/stuff/rewolf_hc2008_phase3.zip&quot;&gt;http://rewolf.pl/stuff/rewolf_hc2008_phase3.zip&lt;/a&gt;&lt;br /&gt;
&lt;a href=&quot;http://rewolf.pl/stuff/rewolf_hc2008_ph3_report.pdf&quot;&gt;http://rewolf.pl/stuff/rewolf_hc2008_ph3_report.pdf&lt;/a&gt;&lt;br /&gt;
&lt;br /&gt;
&lt;a href=&quot;http://rewolf.pl&quot;&gt;http://rewolf.pl&lt;/a&gt;</description>
                    </item>
                <item>
            <title>Old dbghelp and an old exploit...</title>
                            <pubDate>Fri, 30 Jan 2009 08:42:38 -0600</pubDate>
                                        <link>https://www.openrce.org/blog/view/1369/Old_dbghelp_and_an_old_exploit...</link>
                                        <author>ReWolf &lt;email-suppressed@example.com&gt;</author>
                                                    <description>&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;Recently I've came across some &amp;quot;strange&amp;quot; problems during loading some executables into OllyDbg. After loading the file, OllyDbg just crashed without any error. During a quick research I've figured out that the problem lays in the extension of the loaded file. In fact, the problem laid in the old version of &lt;b&gt;dbghelp.dll (5.1.3590.0)&lt;/b&gt;. I've asked google if &amp;quot;she&amp;quot; (or &amp;quot;he&amp;quot;, who knows) knows something about this bug, and that was a good choice. I've found a discussion on tuts4you forum:&lt;br /&gt;
&lt;br /&gt;
&amp;nbsp;&amp;nbsp;&lt;a href=&quot;http://forum.tuts4you.com/index.php?showtopic=16445&quot;&gt;http://forum.tuts4you.com/index.php?showtopic=16445&lt;/a&gt;&lt;br /&gt;
&lt;br /&gt;
and a link to an exploit on milw0rm:&lt;br /&gt;
&lt;br /&gt;
&amp;nbsp;&amp;nbsp;&lt;a href=&quot;http://www.milw0rm.com/exploits/6031&quot;&gt;http://www.milw0rm.com/exploits/6031&lt;/a&gt;&lt;br /&gt;
&lt;br /&gt;
As you can read, it was related to &amp;quot;export name buffer overflow vulnerability&amp;quot;. My problem was different, but debugging OllyDbg lead me to the call to &lt;i&gt;SymLoadModule&lt;/i&gt; at the same place like in the mentioned exploit. Further debugging revealed that my problem is related to the wrong use of &lt;i&gt;_splitpath&lt;/i&gt; function from &lt;b&gt;msvcrt.dll&lt;/b&gt;. Calling tree looks like this:&lt;br /&gt;
&lt;br /&gt;
&lt;code&gt;&lt;br /&gt;
SymLoadModule (exported)&lt;br /&gt;
&amp;nbsp;&amp;nbsp;-&amp;gt; SymLoadModule64 (exported)&lt;br /&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; -&amp;gt; SymLoadModuleEx (exported)&lt;br /&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;-&amp;gt; InternalLoadModule&lt;br /&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; -&amp;gt; load&lt;br /&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;-&amp;gt; GetDebugData&lt;br /&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; -&amp;gt; FileNameIsPdb&lt;br /&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;-&amp;gt; msvcrt.splitpath&lt;br /&gt;
&lt;/code&gt;&lt;br /&gt;
&lt;br /&gt;
function &lt;i&gt;FileNameIsPdb&lt;/i&gt; has a local variable:&lt;br /&gt;
&lt;br /&gt;
&lt;code&gt;&lt;br /&gt;
&amp;nbsp;&amp;nbsp;char _str_extension[20];&lt;br /&gt;
&lt;/code&gt;&lt;br /&gt;
&lt;br /&gt;
which is passed to the &lt;i&gt;splitpath&lt;/i&gt;, and if our prepared file extension is longer than 20 bytes it overwrites values on the stack, next 8 bytes overwrite some local variables, and finaly next 4 bytes overwrites the return address:&lt;br /&gt;
&lt;br /&gt;
&lt;code&gt;&lt;br /&gt;
&amp;nbsp;&amp;nbsp;extension: &amp;quot;.dll1234567890qwertyuiopasdfxxxx&amp;quot;&lt;br /&gt;
&lt;/code&gt;&lt;br /&gt;
&lt;br /&gt;
it is not enough to crash OllyDbg though (for exploiting it should be sufficient), because there is SEH that can deal with this stack corruption. I figured out that overwriting another 26 bytes should crash OllyDbg, so the file extension should look like this:&lt;br /&gt;
&lt;br /&gt;
&lt;code&gt;&lt;br /&gt;
&amp;nbsp;&amp;nbsp;&amp;quot;sample.dll1234567890qwertyuiopasdfxxxxlzxcvbnmQWERTYUIOPASDFGHJK&amp;quot;&lt;br /&gt;
&lt;/code&gt;&lt;br /&gt;
&lt;br /&gt;
If someone has not updated &lt;b&gt;dbghelp.dll&lt;/b&gt; in the olly directory, we can use this method as a simple anti-debug. We don't need to rename executable to such form, we can dump a sample dll (with malformed extension) on the disk during the execution of the program, and just load it with &lt;i&gt;LoadLibrary&lt;/i&gt; function. Development of an exploit could prove to be problematic because of limitations of charset that can be used to craft filename.&lt;br /&gt;
&lt;br /&gt;
&lt;b&gt;This bug cannot be applied to newer versions of dbghelp.dll&lt;/b&gt;.&lt;br /&gt;
&lt;br /&gt;
&lt;i&gt;Original paper at:&lt;/i&gt; &lt;a href=&quot;http://rewolf.pl/stuff/rewolf_dbghelp.txt&quot;&gt;http://rewolf.pl/stuff/rewolf_dbghelp.txt&lt;/a&gt;</description>
                    </item>
            </channel>
</rss>
