<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Windows on cat /dev/snapshot</title><link>https://rumpf.eu/michael/tags/windows/</link><description>Recent content in Windows on cat /dev/snapshot</description><generator>Hugo -- 0.154.5</generator><language>en</language><lastBuildDate>Wed, 27 Jul 2005 07:45:00 +0200</lastBuildDate><atom:link href="https://rumpf.eu/michael/tags/windows/index.xml" rel="self" type="application/rss+xml"/><item><title>Setting up a free Microsoft debugging environment on Windows XP</title><link>https://rumpf.eu/michael/posts/2005-07-27-setting-up-free-microsoft-debugging/</link><pubDate>Wed, 27 Jul 2005 07:45:00 +0200</pubDate><guid>https://rumpf.eu/michael/posts/2005-07-27-setting-up-free-microsoft-debugging/</guid><description>&lt;p&gt;This is a short guide on how to debug applications or dynamic link libraries created by the post &lt;em&gt;free Microsoft C++ compile environment&lt;/em&gt;.&lt;/p&gt;
&lt;p&gt;The following tools need to be installed:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href="http://msdl.microsoft.com/download/symbols/debuggers/dbg_x86_6.5.3.7.exe"&gt;Microsoft Debug Tools&lt;/a&gt; (13MB): &lt;strong&gt;c:\msdev\debug&lt;/strong&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="http://msdl.microsoft.com/download/symbols/packages/windowsxp/WindowsXP-KB835935-SP2-slp-Symbols.exe"&gt;Windows XP with Service Pack 2 symbols&lt;/a&gt; (195MB)&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Then extend your environment&amp;rsquo;s LIB path by adding the &lt;em&gt;Visual Studio .NET 2003&lt;/em&gt; lib folder. &lt;em&gt;Visual Studio .NET 2003&lt;/em&gt; was installed during the former &lt;em&gt;.NET SDK&lt;/em&gt; installation, unfortunately the path, specified for the &lt;em&gt;.NET SDK&lt;/em&gt; is not taken as installation path for Visual Studio but the usual program folder is used instead, in my case &lt;code&gt;C:\Programme\Microsoft Visual Studio .NET 2003&lt;/code&gt;. Find out the path&amp;rsquo;s short name with &lt;code&gt;dir /X&lt;/code&gt; and add the following line with your specific path to the &lt;code&gt;setenv.cmd&lt;/code&gt; script below the three &lt;code&gt;call&lt;/code&gt; statements:&lt;/p&gt;</description></item><item><title>More Reverse Engineering</title><link>https://rumpf.eu/michael/posts/2005-07-06-more-reverse-engineering/</link><pubDate>Wed, 06 Jul 2005 09:26:00 +0200</pubDate><guid>https://rumpf.eu/michael/posts/2005-07-06-more-reverse-engineering/</guid><description>&lt;p&gt;I did more reverse engineering on the &lt;em&gt;DataRecorder&lt;/em&gt; Windows tool that comes with the &lt;em&gt;TFA Klima-Logger&lt;/em&gt; hygrometer in order to find out which serial lines are used as input lines.&lt;/p&gt;
&lt;p&gt;The evaluation version of &lt;a href="http://www.hex-rays.com/idapro/"&gt;IDA Pro Disassembler and Debugger&lt;/a&gt; did a great job here. The only thing I had to do was to load the executable &lt;code&gt;DataRecorder.exe&lt;/code&gt; into the disassembler and find the places where the Win32 API function &lt;code&gt;GetCommModemStatus&lt;/code&gt; gets called. A search for the function name revealed two sub-routines inside the huge pile of Assembler code. Looking at the references to data segment constants it was quite easy to determine which of the two sub-routines was the Assembler version of &lt;code&gt;CI2CDriver::Sda()&lt;/code&gt; and which one was the Assembler version of &lt;code&gt;CI2CDriver::Scl()&lt;/code&gt;. The first sub-routine was referencing an error message&lt;/p&gt;</description></item><item><title>Intercepting Win32 API system calls</title><link>https://rumpf.eu/michael/posts/2005-07-03-intercepting-win32-api-system-calls/</link><pubDate>Sun, 03 Jul 2005 01:04:00 +0200</pubDate><guid>https://rumpf.eu/michael/posts/2005-07-03-intercepting-win32-api-system-calls/</guid><description>&lt;p&gt;For reverse-engineering the Windows software of the &lt;em&gt;TFA Klima-Logger&lt;/em&gt; I tried to analyze the I2C protocol over the serial line by intercepting Win32 API system calls.&lt;/p&gt;
&lt;p&gt;Searching with Google about the topic &lt;em&gt;intercept Win32 function&lt;/em&gt; I stumbled over the Microsoft Research tool &lt;a href="http://research.microsoft.com/sn/detours/"&gt;Detours&lt;/a&gt; which was exactly what I was looking for. Version 1.5 of the tool is freely available for download and already comes with an example to intercept serial API system calls which served as a starting point for my serial communication interception library.&lt;/p&gt;</description></item></channel></rss>