tag:blogger.com,1999:blog-37138101214317707932024-03-08T15:10:24.366-08:00Debug and conquerAnonymoushttp://www.blogger.com/profile/11316621936237390502noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-3713810121431770793.post-88222192849024703242016-08-15T15:00:00.000-07:002016-08-15T15:24:08.793-07:00Solving .net source code lines problem in windbg with SOSEX<h1></h1> <h5> </h5> <h5>Introduction</h5> <p>The <a href="http://www.stevestechspot.com/NET46UpdateForSosexNowLive.aspx">SOSEX debugger extension</a> has all kinds of commands that work with source code lines, for example <strong>!mk</strong> displays a stack trace with both managed and unmanged frames, potentially mapping managed frames to their source code locations. </p> <p>Like native source code lines support, it requires the <a href="http://www.wintellect.com/devcenter/jrobbins/how-many-secrets-do-net-pdb-files-really-contain">symbols file (PDB)</a> to be available to the debugger. Unfortunately, <a href="http://blogs.microsoft.co.il/sasha/2011/01/16/clr-4-does-not-use-loadlibrary-to-load-assemblies/">.NET doesn’t call LoadLibrary</a> on its managed non mixed-mode assemblies. Not calling LoadLibrary causes the debugger to not see the module (assembly, DLL, I have used those terms interchangeably in this post), thus obviously unable to load its symbols. That happens because the debugger gets the list of modules from the <em>ntdll loader</em>’s list, which is populated by LoadLibrary calls.</p> <blockquote> <p><a href="https://github.com/dotnet/coreclr/blob/29fcfe2938e3890cd6fb302d2f8c6dabc1a09fc4/src/vm/peimage.cpp#L1532">CoreCLR does call LoadLibrary</a>. I’m guessing that not calling is a compatibility issue rather than security issue, as <a href="https://github.com/dotnet/coreclr/blob/29fcfe2938e3890cd6fb302d2f8c6dabc1a09fc4/src/vm/peimagelayout.cpp#L629">CoreCLR calls</a> LoadLibrary with the DONT_RESOLVE_DLL_REFERENCES flag, which prevents native code from running (<a href="https://msdn.microsoft.com/en-us/library/windows/desktop/ms682583(v=vs.85).aspx">DLLMain isn’t called</a>) in an untrusted assembly.</p></blockquote> <p>If the assembly is loaded after we have attached, the debugger actually sees it, because after attaching it receives lower level notifications of module loading, at the <a href="https://msdn.microsoft.com/en-us/library/windows/desktop/aa366761(v=vs.85).aspx">file mapping level</a> (Managed DLLs are still mapped to the process). You can list the loaded modules with the <a href="https://msdn.microsoft.com/en-us/library/windows/hardware/ff552026(v=vs.85).aspx">lm command</a>. </p> <p>So this problem is only relevant to assemblies that were loaded before attaching the debugger.</p> <h5>Solution</h5> <p>Despite its name, Process Explorer’s DLLs pane isn’t limited to DLLs loaded by LoadLibrary, but it actually displays all memory mapped files, including all managed DLLs. </p> <p>For example, some managed application:</p> <p><a href="https://lh3.googleusercontent.com/-WGa0wgdt-u4/V7I_9hjVyxI/AAAAAAAAAQQ/qt8Y79hIr-E/s1600-h/image_thumb1%25255B3%25255D.png"><img title="image_thumb1" style="border-top: 0px; border-right: 0px; background-image: none; border-bottom: 0px; padding-top: 0px; padding-left: 0px; border-left: 0px; margin: 3px 15px 10px 0px; display: inline; padding-right: 0px" border="0" alt="image_thumb1" src="https://lh3.googleusercontent.com/-kJGs2HlXei0/V7JAA0SbREI/AAAAAAAAAQU/fAWYTlhyDzg/image_thumb1_thumb%25255B1%25255D.png?imgmax=800" width="643" height="121"></a></p> <p>Luckily, there’s a way of “hinting” the debugger where a DLL is located in the target’s memory space with the <a href="https://msdn.microsoft.com/en-us/library/windows/hardware/ff564805(v=vs.85).aspx">.reload command</a>, for our case we could run:<br></p> <blockquote> <p><font color="#6f6f6f">.reload /f ClassLibrary1.dll=0x2700000</font></p></blockquote> <p>Notice that I took the base address from the above Process Explorer’s screenshot. <strong>/f</strong><em> </em>simply forces immediate symbols load. After that, all the commands that support sources (like <strong>!mk</strong>) would work on code from that DLL with source lines.</p> <blockquote> <p>The option of specifying base address is usually used for kernel debugging, in cases where some of the memory that contains the loaded DLLs is paged out, so the debugger can’t figure out what is loaded by itself.</p></blockquote>Anonymoushttp://www.blogger.com/profile/11316621936237390502noreply@blogger.com0tag:blogger.com,1999:blog-3713810121431770793.post-88400081191265093262015-08-02T12:29:00.001-07:002015-08-02T12:46:02.111-07:00The Cause of Spurious Mouse Move Messages/Events when task manager is open<p>Recently while programming in JavaScript I noticed that my mousemove event keeps firing without my mouse moving, as long as my mouse is over the relevant object. It seemed strange so I searched for this behavior online and apparently quite a few others encountered it and thought it was strange: <a href="http://stackoverflow.com/questions/17818493/mousemove-event-repeating-every-second">[1] http://stackoverflow.com/questions/17818493/mousemove-event-repeating-every-second</a>, <a href="http://www.quirksmode.org/blog/archives/2008/04/something_odd_h.html">[2]</a>, <a href="https://code.google.com/p/chromium/issues/detail?id=366970">[3]</a>, <a href="http://stackoverflow.com/questions/4579071/jquery-mousemove-is-called-even-if-the-mouse-is-still">[4]</a>.</p> <p><a href="http://www.w3.org/TR/DOM-Level-3-Events/#event-type-mousemove">The specification</a> says <em>“A user agent must dispatch this event when a pointing device is <strong>moved</strong> while it is over an element</em>”<em> (</em>emphasis is mine), confirming that this behavior isn’t originated in the standard. Luckily for me, the first link from above helped me find the source of this behavior: <strong>the <em>Task Manager </em>was open in the background</strong>. </p> <h4>At the OS level</h4> <p>First I wanted to check what’s happening at the OS level, Applications mostly handle input by listening to <a href="https://msdn.microsoft.com/en-us/library/windows/desktop/ff381405%28v=vs.85%29.aspx">Windows Messages</a> and a tool for observing them is <a href="https://msdn.microsoft.com/en-us/library/aa264396(v=vs.60).aspx">Spy++</a>. Because my version of Chrome is <em>32-bit</em>,<em> </em>I opened the <em>32-bit</em> version of Spy++ (<em>spyxx.exe </em>rather than <em>spyxx_amd64.exe</em>). After locating Chrome’s window using the crosshair from the <em>Search –> Find Window </em>dialog we get information about the window: <br><a href="http://lh3.googleusercontent.com/-pnP83HQcGEw/Vb5vik4Mx9I/AAAAAAAAAKQ/IqeHXjMS1JU/s1600-h/image%25255B11%25255D.png"><img title="image" style="border-left-width: 0px; border-right-width: 0px; border-bottom-width: 0px; display: inline; border-top-width: 0px" border="0" alt="image" src="http://lh3.googleusercontent.com/-MbWbG7APcPE/Vb5vjEHjp9I/AAAAAAAAAKU/x6xQL8tatoo/image_thumb%25255B5%25255D.png?imgmax=800" width="350" height="251"></a> <br>Clicking Synchronize will highlight the window on the main windows tree. By right clicking the window entry in the tree and clicking Messages we can capture windows messages targeted at this window:<br><a href="http://lh3.googleusercontent.com/-U1QfkzXaCDQ/Vb5vjhfKk3I/AAAAAAAAAKc/QbykU1rZLuc/s1600-h/image%25255B16%25255D.png"><img title="image" style="border-left-width: 0px; border-right-width: 0px; border-bottom-width: 0px; display: inline; border-top-width: 0px" border="0" alt="image" src="http://lh3.googleusercontent.com/-JMZi18EgFp0/Vb5vkJOvQfI/AAAAAAAAAKo/NwUaJZ81qTA/image_thumb%25255B8%25255D.png?imgmax=800" width="314" height="141"></a> <br>When holding the mouse over the browser window without moving it the following messages keep repeating:<br> <a href="http://lh3.googleusercontent.com/-iiC95or7Nyo/Vb5vlMDlxPI/AAAAAAAAAKw/BHysXkCRTds/s1600-h/image%25255B28%25255D.png"><img title="image" style="border-left-width: 0px; border-right-width: 0px; border-bottom-width: 0px; display: inline; border-top-width: 0px" border="0" alt="image" src="http://lh3.googleusercontent.com/-yoK0mu5F_V4/Vb5vl4_GoiI/AAAAAAAAAK4/7NJ2Bz7U6I0/image_thumb%25255B14%25255D.png?imgmax=800" width="620" height="281"></a><br>One of the repeating messages is <a href="https://msdn.microsoft.com/en-us/library/windows/desktop/ms645616%28v=vs.85%29.aspx">WM_MOUSEMOVE</a> which not surprisingly represents mouse movement, and apparently Chrome doesn’t check whether the mouse has actually moved and passes the event to the web application. Actually Firefox and IE11 behave differently in this case (the mousemove event doesn’t keep firing), probably because they do check whether the mouse has moved each time.</p> <p>That showed that the underlying issue is the continuing arrival of WM_MOUSEMOVE messages, and not a web specific issue.</p> <h4></h4> <h4></h4> <h4>Why does it happen?</h4> <p>I wondered why would a background application (Task Manager) affect in such a way other applications (Although this shouldn’t cause bugs because mouse move handling is usually idempotent), so I wanted to debug this issue.</p> <p>The assumption is that there’s a piece of code in Task Manager that causes it and the goal is finding it. Since Task Manager is a Win32 GUI application much of its code is powered by Windows Messages, and our code of interest is likely run in response to a Windows Message.</p> <p>Since the WM_MOUSEMOVE messages seem to be arriving approximately every 1 second, we can look for similar periodical windows messages with Spy++ (This time with the <em>64-bit </em>version), After Similarly locating the Task Manager main window we can capture messages targeted at this window:<a href="http://lh3.googleusercontent.com/-l4zaom8Sv_g/Vb5vnVLgXVI/AAAAAAAAALA/VhK7GVXnb5Y/s1600-h/image%25255B24%25255D.png"><img title="image" style="border-left-width: 0px; border-right-width: 0px; border-bottom-width: 0px; display: inline; border-top-width: 0px" border="0" alt="image" src="http://lh3.googleusercontent.com/-jbGr9jptbRE/Vb5voMo90FI/AAAAAAAAALI/hTTfqRnw-b8/image_thumb%25255B12%25255D.png?imgmax=800" width="496" height="309"></a> </p> <p>To our expectation, there’s a <a href="https://msdn.microsoft.com/en-us/library/windows/desktop/ms644931%28v=vs.85%29.aspx">user defined Windows Message</a> arriving every 1 second, so we can debug its handling code and likely find the root cause. After attaching WinDBG we can switch context to the <a href="https://msdn.microsoft.com/en-us/library/windows/desktop/ms644928%28v=vs.85%29.aspx#creating_loop">message pumping thread</a> (with ~0s) and look at the call stack:<br></p><pre>0:000> k<br />Child-SP RetAddr Call Site<br />000000eb`dad2f618 00007ffc`2b4013ed ntdll!NtWaitForMultipleObjects+0xa<br />000000eb`dad2f620 00007ffc`2ded3100 KERNELBASE!WaitForMultipleObjectsEx+0xe1<br />000000eb`dad2f900 00007ffc`265311ca USER32!RealMsgWaitForMultipleObjectsEx+0x100<br />000000eb`dad2f9b0 00007ffc`2653134b DUser!CoreSC::xwProcessNL+0x2d6<br />000000eb`dad2fa40 00007ffc`2ded2822 DUser!MphProcessMessage+0xb3<br />000000eb`dad2faa0 00007ffc`2e213034 USER32!_ClientGetMessageMPH+0x52<br />000000eb`dad2fb30 00007ffc`2ded26ca ntdll!KiUserCallbackDispatcherContinue<br />000000eb`dad2fba8 00007ffc`2ded2695 USER32!NtUserGetMessage+0xa<br />000000eb`dad2fbb0 00007ff6`ba4d6d6a USER32!GetMessageW+0x25<br /><strong>000000eb`dad2fbe0 00007ff6`ba4e2144 Taskmgr!wWinMain+0x2aa</strong><br />000000eb`dad2fcc0 00007ffc`2b8113d2 Taskmgr!__wmainCRTStartup+0x1d4<br />000000eb`dad2fd90 00007ffc`2e195444 KERNEL32!BaseThreadInitThunk+0x22<br />000000eb`dad2fdc0 00000000`00000000 ntdll!RtlUserThreadStart+0x34<br /></pre><h1></h1><p>The interesting frame is highlighted above, that’s the message loop frame and there we can start debugging the message handling code. First we can disassemble around it to see where is the current message stored:</p><br><pre>0:000> u Taskmgr!wWinMain+0x270 l30<br />Taskmgr!wWinMain+0x270:<br />00007ff6`ba4d6d30 488b0dc1d60700 mov rcx,qword ptr [Taskmgr!g_MainWindow (00007ff6`ba5543f8)]<br />00007ff6`ba4d6d37 4c8d4510 lea r8,[rbp+10h]<br />00007ff6`ba4d6d3b 488bd3 mov rdx,rbx<br />00007ff6`ba4d6d3e ff1544c30800 call qword ptr [Taskmgr!_imp_TranslateAcceleratorW (00007ff6`ba563088)]<br />00007ff6`ba4d6d44 488d4d10 lea rcx,[rbp+10h]<br />00007ff6`ba4d6d48 ff15eac20800 call qword ptr [Taskmgr!_imp_TranslateMessage (00007ff6`ba563038)]<br />00007ff6`ba4d6d4e 488d4d10 lea rcx,[rbp+10h]<br />00007ff6`ba4d6d52 ff15e8c20800 call qword ptr [Taskmgr!_imp_DispatchMessageW (00007ff6`ba563040)]<br />00007ff6`ba4d6d58 488d4d10 <strong>lea rcx,[rbp+10h]</strong><br />00007ff6`ba4d6d5c 4533c9 xor r9d,r9d<br />00007ff6`ba4d6d5f 4533c0 xor r8d,r8d<br />00007ff6`ba4d6d62 33d2 xor edx,edx<br />00007ff6`ba4d6d64 ff1516c30800 call qword ptr [Taskmgr!_imp_GetMessageW (00007ff6`ba563080)]<br />00007ff6`ba4d6d6a 85c0 test eax,eax<br /></pre><p>The first parameter to <a href="https://msdn.microsoft.com/en-us/library/windows/desktop/ms644936%28v=vs.85%29.aspx">GetMessage</a> is the message (passed in the <em>rcx </em>register), so It’s stored at [rbp+10]. Now we can add a <a href="https://msdn.microsoft.com/en-us/library/windows/hardware/ff556853%28v=vs.85%29.aspx">conditional breakpoint</a> for the user defined message with <em><strong>bp Taskmgr!wWinMain+0x2aa "j poi(@rbp+18)=4df '';'gc'"</strong> </em>(rbp+18 is used because the message number is the second parameter of the <a href="https://msdn.microsoft.com/en-us/library/windows/desktop/ms644958%28v=vs.85%29.aspx">MSG structure</a>, 4df is the user defined message code from the above Spy++ output).</p><br /><p>After we run the app and the breakpoint fires it’s just a matter of tracing until finding the code of interest. A good method for that kind of search is jumping over function calls and seeing how the application reacts, until we jump over the function that causes the suspicious behavior to disappear (sort of binary search). To save time, I’ll skip the search process and show that function, it’s a call to <a href="https://msdn.microsoft.com/en-us/library/windows/desktop/ms644950%28v=vs.85%29.aspx">SendMessage</a> at <em>Taskmgr!WdcDataMonitor::ListUpdate+0x45f:<br></em></p><pre>0:000> u Taskmgr!WdcDataMonitor::ListUpdate+0x45f<br />Taskmgr!WdcDataMonitor::ListUpdate+0x45f:<br /><strong>00007ff6`ba505d0f</strong> ff1583d10500 call qword ptr [Taskmgr!_imp_SendMessageW (00007ff6`ba562e98)]<br /><strong>00007ff6`ba505d15</strong> 418bc4 mov eax,r12d<br />00007ff6`ba505d18 488b8d90010000 mov rcx,qword ptr [rbp+190h]<br />00007ff6`ba505d1f 4833cc xor rcx,rsp<br />00007ff6`ba505d22 e8f9c4fdff call Taskmgr!_security_check_cookie (00007ff6`ba4e2220)<br />00007ff6`ba505d27 488b9c24f0020000 mov rbx,qword ptr [rsp+2F0h]<br />00007ff6`ba505d2f 4881c4a0020000 add rsp,2A0h<br />00007ff6`ba505d36 415f pop r15<br /></pre><p>The trick for constantly jumping over a function call (like a patch) is a breakpoint that changes the value of <em>rip </em>(the instruction pointer in x64) when it fires. In our case, because the code doesn’t check the return value we can advance it to the next instruction with that command: <em><strong>bp Taskmgr!WdcDataMonitor::ListUpdate+0x45f "r @rip=00007ff6`ba505d15;gc"</strong>. </em>Now after the application is run we can see that the spurious WM_MOUSEMOVE messages stop arriving.</p><br /><h4></h4><br /><h4>The Windows message that is being sent – WM_SETREDRAW</h4><br /><p>The call we patched is a <em>SendMessage</em> call that sends a <a href="https://msdn.microsoft.com/en-us/library/windows/desktop/dd145219%28v=vs.85%29.aspx">WM_SETREDRAW</a> with the false parameter. That prevents a window from redrawing until WM_SETREDRAW is sent with the true parameter, it is targeted at the processes list view control in the Details tab and as evident by the stack trace it is sent while it’s being sorted:</p><pre>0:000> k<br />Child-SP RetAddr Call Site<br />000000eb`dad2f520 00007ff6`ba508488 Taskmgr!WdcDataMonitor::ListUpdate+0x45f<br />000000eb`dad2f800 00007ff6`ba50643a Taskmgr!WdcProcessMonitor::ListUpdate+0x38<br />000000eb`dad2f840 00007ff6`ba503dba Taskmgr!WdcDataMonitor::SetSortDirty+0x5e<br />000000eb`dad2f880 00007ff6`ba502dc5 <strong>Taskmgr!WdcListView::Sort+0xaa<br /></strong>000000eb`dad2f8c0 00007ff6`ba4bbe84 Taskmgr!WdcListView::Render+0x115<br />000000eb`dad2f940 00007ff6`ba4f0c5c Taskmgr!WdcDataPortal::Render+0xe8<br />000000eb`dad2f970 00007ff6`ba4c6431 Taskmgr!WdcMonitor::Render+0x2a71c<br />000000eb`dad2f9c0 00007ff6`ba4c6016 Taskmgr!TmTraceControl::ForceRenderUI+0x2d<br />000000eb`dad2fa00 00007ffc`2ded250d Taskmgr!TmWindowProc+0xf6<br />000000eb`dad2fa90 00007ffc`2ded2367 USER32!UserCallWinProcCheckWow+0x149<br />000000eb`dad2fb60 00007ff6`ba4d6d58 USER32!DispatchMessageWorker+0x1a7<br />000000eb`dad2fbe0 00007ff6`ba4e2144 Taskmgr!wWinMain+0x298<br /></pre><p>That message is used to prevent numerous window redraws while many updates are being made to it (sorting could surely cause many updates). <a href="http://blogs.msdn.com/b/oldnewthing/archive/2011/01/24/10119211.aspx">The issue is how it is implemented by default, and that’s by making the window invisible</a>, which along with the WM_SETREDRAW with the true parameter that is being sent later, <a href="http://blogs.msdn.com/b/oldnewthing/archive/2003/10/01/55108.aspx">causes Windows to send WM_MOUSEMOVE messages</a>, and the puzzle is complete.</p><br /><p>In conclusion, as I wrote above, I don’t think this behavior is very problematic, as the extra messages shouldn’t usually change application’s behavior, and if they do, the application should be fixed anyway because Windows doesn’t guarantee sending them on actual mouse movement (the above linked post explains why), and even the web standard is somewhat ambiguous about the mousemove event. </p> Anonymoushttp://www.blogger.com/profile/11316621936237390502noreply@blogger.com1tag:blogger.com,1999:blog-3713810121431770793.post-66690288603359417182015-07-08T12:59:00.001-07:002015-07-08T13:10:27.925-07:00Services Console Snap-in Timeout Error message Causes<p>If you ever encountered a hanging service you probably saw the error: <em>"Error 1053: The service did not respond to the start or control request in a timely fashion"</em> when starting or stopping it from the <em>Services console snap-in </em>(can be quickly displayed with by running <em>services.msc</em>).</p><a href="http://lh3.googleusercontent.com/-1MPD8duHnyQ/VZ2BBiOtjkI/AAAAAAAAAJg/ePNKl2w5ExU/s1600-h/image%25255B5%25255D.png"><img title="image" style="border-left-width: 0px; border-right-width: 0px; border-bottom-width: 0px; display: inline; border-top-width: 0px" border="0" alt="image" src="http://lh3.googleusercontent.com/-dRImDHf6X_4/VZ2BCQ1mrFI/AAAAAAAAAJk/GjGi4HSHA4E/image_thumb%25255B3%25255D.png?imgmax=800" width="532" height="198"></a> <p>You may encounter this error when <a href="http://www.debuginfo.com/articles/debugstartup.html#windbgremote">debugging service startup code</a> and notice that after that error message your service is being terminated and the debug session is ruined. To solve this you can <a href="http://www.debuginfo.com/articles/debugstartup.html#startuptimeouts">set the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\ServicesPipeTimeout registry key.</a> Having this value set you can still notice that this message appears but instead of the default 30 seconds (unlike the 2 minutes default stated in the article, at least since XP) the error message appears after 2 minutes. You may think that windows ignores values higher than 2 minutes but actually the service process isn’t terminated and this error message box appears simply because the progress dialog (pictured below) has reached its end. (Tested on Windows 8.1 and 10)</p> <p><a href="http://lh3.googleusercontent.com/-0rNjg6F_ucE/VZ2BC7r0dlI/AAAAAAAAAJs/gb2iz_zW7Xw/s1600-h/image%25255B10%25255D.png"><img title="image" style="border-left-width: 0px; border-right-width: 0px; border-bottom-width: 0px; display: inline; border-top-width: 0px" border="0" alt="image" src="http://lh3.googleusercontent.com/-C56wg9bxnqc/VZ2BDhqWjSI/AAAAAAAAAJ0/MkGlLZEm_88/image_thumb%25255B6%25255D.png?imgmax=800" width="426" height="201"></a></p> <p>The fact that the displayed error code is the same in both cases, and that it corresponds to the <em>System </em>event log entry that happens when termination occurs (no event log entry is created when the registry key is set to a high value) were confusing to me and I wanted to verify that it actually is a UI only error and the service is not affected.</p> <h5>Debugging</h5> <p>After attaching to <em>mmc.exe </em>I first guessed the relevant DLL by setting a breakpoint (bp) on the user32!MessageBoxW and waited for the message box to appear, the breakpoint hit and that was the top of the stack:<br></p><pre>0:000> <strong>k</strong><br />Child-SP RetAddr Call Site<br />00000000`00bad578 00007ffc`7c054f59 USER32!MessageBoxW<br />00000000`00bad580 00007ffc`7c055039 filemgmt!DoErrMsgBoxHelper+0xa5<br />00000000`00bad5d0 00007ffc`7c05b86c filemgmt!DoServicesErrMsgBox+0x25<br />00000000`00bad620 00007ffc`7c05b1cf filemgmt!<strong>CServiceControlProgress</strong>::<strong>M_ProcessErrorCode</strong>+0x150<br />00000000`00badaa0 00007ffc`7c05bce7 filemgmt!<strong>CServiceControlProgress</strong>::M_EDoExecuteServiceThread+0x6f<br />00000000`00badae0 00007ffc`7c042282 filemgmt!<strong>CServiceControlProgress</strong>::S_EStartService+0xbb<br />00000000`00badb30 00007ffc`7c03a744 filemgmt!CFileMgmtComponentData::Service_FDispatchMenuCommand+0x10e<br />00000000`00badbb0 00007ffc`7c03e2f0 filemgmt!CFileMgmtComponent::Command+0xa4<br />00000000`00badc30 00007ffc`7c03df04 filemgmt!CFileMgmtComponent::OnToolbarButton+0x78<br />00000000`00badc60 00007ffc`7c24aacc filemgmt!CFileMgmtComponent::ControlbarNotify+0x94<br /><em></em></pre><p>filemgmt and particularly <em>CServiceControlProgress </em>seem relevant. Now we can guess that because the progress bar (pictured above) is most likely powered by the <a href="https://msdn.microsoft.com/en-us/library/windows/desktop/ms644906%28v=vs.85%29.aspx">SetTimer API</a> and <a href="https://msdn.microsoft.com/en-us/library/windows/desktop/ms644902(v=vs.85).aspx">WM_TIMER</a> messages there is a symbol containing “Timer” in this dll:</p><pre>0:000> <strong>x filemgmt!*timer*</strong><br />00007ffc`7c05b5b4 filemgmt!CServiceControlProgress::M_OnTimer (<no parameter info>)<br />00007ffc`7c082aa8 filemgmt!_imp_KillTimer = <no type information><br />00007ffc`7c0389cc filemgmt!MakeElapsedTimeResult (<no parameter info>)<br />00007ffc`7c082aa0 filemgmt!_imp_SetTimer = <no type information><br /></pre><p><em>filemgmt!CServiceControlProgress::M_OnTimer<strong> </strong></em>seems easily the best canditate. </p><br /><blockquote><br /><p>If this function didn’t contain the word “timer” and you couldn’t guess it otherwise by dumping the members of <em>CServiceControlProgress (x filemgmt!CServiceControlProgress::*</em>) you could still deductively find it by setting a breakpoint at the default <a href="https://msdn.microsoft.com/en-us/library/windows/desktop/ms645469%28v=vs.85%29.aspx">DialogProc</a> (<em>user32!<a href="https://msdn.microsoft.com/en-us/library/windows/desktop/ms645450%28v=vs.85%29.aspx">DefDlgProcW</a></em>) then tracing to find the <em>DialogProc</em> of the progress bar dialog (<em>filemgmt!CServiceControlProgress::S_DlgProcControlService</em>), then setting a <a href="https://msdn.microsoft.com/en-us/library/windows/hardware/ff556853%28v=vs.85%29.aspx">conditional breakpoint</a> waiting for WM_TIMER messages (0x113) with <em>bp filemgmt!CServiceControlProgress::S_DlgProcControlService ".if @rdx=113 {} .else {gc}" </em>and then quickly tracing to the timer handler.</p></blockquote><br /><p>Fortunately, the relevant control flow is right at the start of the <em>filemgmt!CServiceControlProgress::M_OnTimer </em>function (I removed some error checking code):</p><pre>filemgmt!CServiceControlProgress::M_OnTimer:<br />00007ffc`7c05b5b4 48895c2418 mov qword ptr [rsp+18h],rbx<br />00007ffc`7c05b5b9 57 push rdi<br />00007ffc`7c05b5ba 4883ec50 sub rsp,50h<br />00007ffc`7c05b5cd 81413890010000 <strong>add dword ptr [rcx+38h],190h</strong><br />00007ffc`7c05b5db 8b4138 <strong>mov eax,dword ptr [rcx+38h]</strong><br />00007ffc`7c05b5de 488bfa mov rdi,rdx<br />00007ffc`7c05b5e1 488bd9 mov rbx,rcx<br />00007ffc`7c05b600 3b01 <strong>cmp eax,dword ptr [rcx]</strong><br />00007ffc`7c05b602 761e jbe filemgmt!CServiceControlProgress::M_OnTimer+0x6e (00007ffc`7c05b622)<br />00007ffc`7c05b604 488b5130 mov rdx,qword ptr [rcx+30h]<br />00007ffc`7c05b608 488bcf mov rcx,rdi<br />00007ffc`7c05b60b ff1597740200 call qword ptr [filemgmt!_imp_KillTimer (00007ffc`7c082aa8)]<br />00007ffc`7c05b611 4883633000 and qword ptr [rbx+30h],0<br />00007ffc`7c05b616 c783a00600001d040000 <strong>mov dword ptr [rbx+6A0h],41Dh<br /></strong></pre><p>The first parameter of the function, the <em>this </em>pointer (of <em>CServiceControlProgress</em>) that is passed at the <em>rcx</em> register (<a href="https://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_calling_convention">x64 calling convention</a>) has some interesting fields:</p><pre>0:000> dps rcx<br />00000000`03a17b80 <strong>00000005`0001e848<br /></strong>00000000`03a17b88 00000000`002b063a<br />00000000`03a17b90 00000000`00500e0e<br />00000000`03a17b98 00000000`003c0e96<br />00000000`03a17ba0 00000000`02440d9e<br />00000000`03a17ba8 00000000`00000000<br />00000000`03a17bb0 00000000`00000001<br />00000000`03a17bb8 <strong>00000000`00000960</strong><br /></pre><p>We can see in the code that the [rcx+38] offset is incremented by 0x190 and then compared to [rcx] (both values are highlighted in the memory dump above). When [rcx+38] is bigger than [rcx], <a href="https://msdn.microsoft.com/en-us/library/windows/desktop/ms644903%28v=vs.85%29.aspx">KillTimer</a><em> </em>is called and [rbx+0x6A0], which is equal to the [rcx+0x6A0] of the start of the function (reminder: rcx was the <em>this </em>pointer), gets assigned the value of decimal <strong>1053 </strong>(0x41D), which is our displayed error code, and if we disassemble <em>CServiceControlProgress::M_ProcessErrorCode </em>we would see that it reads the same pointer and passes the value to the message box with the description of this error code, which pretty much confirms that perpetrator is the progress bar dialog and that we shouldn’t worry about the error message box, as the actual interaction with the service happens on another thread, and is not affected by this, below was the call stack during all of this:</p><pre>0:000> ~9k<br />Child-SP RetAddr Call Site<br />00000000`04cef0d8 00007ffc`9b5e1199 ntdll!NtAlpcSendWaitReceivePort+0xa<br />00000000`04cef0e0 00007ffc`9b5d3f2d RPCRT4!LRPC_CCALL::SendReceive+0x169<br />00000000`04cef1a0 00007ffc`9b5dea0f RPCRT4!I_RpcSendReceive+0x59<br />00000000`04cef1d0 00007ffc`9b6df750 RPCRT4!NdrSendReceive+0x2b<br />00000000`04cef200 00007ffc`9b6dfc1c RPCRT4!NdrpClientCall2+0x363<br />00000000`04cef820 00007ffc`9aeb62a3 RPCRT4!NdrClientCall2+0x1c<br /><strong>00000000`04cef850 00007ffc`7c05be40 sechost!StartServiceW+0x23<br />00000000`04cef8a0 00007ffc`9b2713d2 filemgmt!CServiceControlProgress::S_ThreadProcStartService+0x80</strong><br />00000000`04cef8d0 00007ffc`9d525444 KERNEL32!BaseThreadInitThunk+0x22<br />00000000`04cef900 00000000`00000000 ntdll!RtlUserThreadStart+0x34<br /></pre><br /><blockquote><br /><p><strong>Trivia and a sanity check: </strong>if we set a breakpoint at the user32!SetTimer and get the interval parameter that was passed by our dialog, we would see that it’s 0x190, which equals to the increment at the timer handler function we saw, meaning that the values we saw are in time units and that the stop condition which is 0x1e848, or 125000 in decimal, is 125 seconds, pretty close to the 2 minutes that we observed.<strong></p></strong></blockquote> Anonymoushttp://www.blogger.com/profile/11316621936237390502noreply@blogger.com0tag:blogger.com,1999:blog-3713810121431770793.post-9057505114873654192015-04-24T15:12:00.001-07:002015-04-24T15:13:01.262-07:00Diagnosing which process is consuming commit charge with pagefile-backed sections<h5><br>introduction</h5> <p>Most of the time when there is memory pressure on the system it’s easy to find the offending process by simply checking the Task Manager. However, there is one kind of memory usage that can consume <em>Commit Charge </em>but won’t show up on any Task Manager (including <a href="http://en.wikipedia.org/wiki/Process_Explorer">Process Explorer</a>, <a href="http://processhacker.sourceforge.net/">Process Hacker</a> and even opening the correct process with <a href="https://technet.microsoft.com/en-us/library/dd535533.aspx">VMMap</a>), it is <a href="https://msdn.microsoft.com/en-us/library/windows/hardware/ff545754%28v=vs.85%29.aspx">Pagefile-Backed Sections</a>.</p> <h5>Pagefile-backed sections</h5> <p><em>Sections </em>are the underlying objects of <a href="https://msdn.microsoft.com/en-us/library/windows/desktop/aa366556%28v=vs.85%29.aspx">Memory-Mapped Files</a> and <em>pagefile-backed sections</em> mean that the backing store behind the memory is the <em>Pagefile</em>, and thus they consume <a href="http://en.wikipedia.org/wiki/Commit_charge">Commit Charge</a>. It makes sense to use those objects when you want to store temporary data that you don’t want constantly in memory (by creating the sections, filling them with data and then <a href="https://msdn.microsoft.com/en-us/library/.../aa366882(v=vs.85).aspx">unmapping</a> them from the process address space, that’s why <em>VMMap</em> doesn’t help here as well – if the sections are unmapped), an advantage of this method over simple file I/O is that you don’t leave unneeded files in case the process or the system crashes.</p> <p>An example of extensive pagefile-backed sections usage is <a href="https://technet.microsoft.com/en-us/library/bb896645.aspx">Process Monitor</a>, that tool can capture a very large amount (many millions) of system events without pressuring physical memory using pagefile-backed sections as the event store. I once forgot that I left it open and ran out of <em>Commit Charge </em>and got the <em>“your computer is low on memory. close programs to prevent information loss” </em>error. Process Explorer couldn’t help finding the guilty process and that’s how this post was born.</p> <h5>Looking for pagefile-backed sections</h5> <p>In <a href="http://blogs.technet.com/b/markrussinovich/archive/2008/11/17/3155406.aspx">this great post</a> (suggested reading for more details about Windows virtual memory management), <a href="https://technet.microsoft.com/en-us/sysinternals/bb896655">Sysinternals’ handle.exe</a> with the –l<em> </em>flag is suggested to display the size of the pagefile-backed sections that all processes has handles to, however currently that flag seems broken (crashes), so I’ll suggest alternative methods for tracking pagefile-backed sections.<br><br>Both Process Explorer and Process Hacker are capable of displaying the size of the pagefile-backed sections that a process has handles to, with this method you would have to go over suspect processes one by one.</p> <h6>Process explorer</h6> <p>First we should check <em>Show Unnamed Handles and Mappings</em>:<br><a href="http://lh3.googleusercontent.com/-X0bxFbYY0fQ/VTq_p8tRdyI/AAAAAAAAAIk/OYhx3hp_PHM/s1600-h/image%25255B2%25255D.png"><img title="image" style="border-left-width: 0px; border-right-width: 0px; border-bottom-width: 0px; display: inline; border-top-width: 0px" border="0" alt="image" src="http://lh3.googleusercontent.com/-CDsRRUg-Jy4/VTq_qny7O5I/AAAAAAAAAIs/qEu1t-ZM3CU/image_thumb.png?imgmax=800" width="244" height="126"></a> </p> <p>Now in the handles pane we can see unnamed pagefile-backed sections and by double-clicking them we can see their size (in hex bytes):<br> <a href="http://lh3.googleusercontent.com/-U-nYF1jtdiI/VTq_rcVaBgI/AAAAAAAAAI0/VWxSpQ9GgRE/s1600-h/image%25255B11%25255D.png"><img title="image" style="border-left-width: 0px; border-right-width: 0px; border-bottom-width: 0px; display: inline; border-top-width: 0px" border="0" alt="image" src="http://lh3.googleusercontent.com/-2zu57AHWu-I/VTq_sL0OVlI/AAAAAAAAAI8/w2sb59vJk8k/image_thumb%25255B5%25255D.png?imgmax=800" width="430" height="455"></a> </p> <p></p> <h6>Process hacker</h6> <p>After choosing and double-clicking on a process, in the handles tab uncheck <em>hide unnamed handles </em>and similarly to Process Explorer you can view the section size:<br><a href="http://lh3.googleusercontent.com/-DLI2dBHS2dU/VTq_s2slEMI/AAAAAAAAAJA/yB-yMQj-wHQ/s1600-h/image%25255B15%25255D.png"><img title="image" style="border-left-width: 0px; border-right-width: 0px; border-bottom-width: 0px; display: inline; border-top-width: 0px" border="0" alt="image" src="http://lh3.googleusercontent.com/--yjZ4UKlkFU/VTq_tbPiiRI/AAAAAAAAAJM/1XS_sGMcV9Y/image_thumb%25255B7%25255D.png?imgmax=800" width="510" height="234"></a> </p> <p>Note that in both applications in this case you can see that the type of the section is “<em>Reserve</em>”<em> </em>which means that the memory specified is reserved and not necessarily committed (if nothing was committed there is zero impact on <em>Commit Charge</em>).</p> <h5>Checking the Committed memory</h5> <p>In order to see the committed memory by the sections we can do local kernel debugging with <a href="https://technet.microsoft.com/en-us/sysinternals/bb897415.aspx">LiveKD</a>. <br>We can take the address of the Section object from either application and dump its <em>_SECTION_OBJECT </em>structure:</p><pre>0: kd> dt nt!_SECTION_OBJECT 0xFFFFC00065CB95C0<br /> +0x000 StartingVa : 0xffffd000`2213d8e8 Void<br /> +0x008 EndingVa : 0xfffff802`4e4a8f75 Void<br /> +0x010 Parent : 0x00000000`00000001 Void<br /> +0x018 LeftChild : (null) <br /> +0x020 RightChild : (null) <br /> +0x028 Segment : 0xffffc000`5c0f66b0 _SEGMENT_OBJECT<br /></pre><br /><p>The <em>Segment </em>structure contains the committed memory size:</p><pre>0: kd> dt nt!_SEGMENT 0xffffc000`5c0f66b0<br /> +0x000 ControlArea : 0xffffe001`43f15880 _CONTROL_AREA<br /> +0x008 TotalNumberOfPtes : 0x17d79<br /> +0x00c SegmentFlags : _SEGMENT_FLAGS<br /> +0x010 <font color="#ff0000"><strong>NumberOfCommittedPages : 0x9c00</strong></font><br /> +0x018 SizeOfSegment : 0x17d79000<br /> +0x020 ExtendInfo : (null) <br /> +0x020 BasedAddress : (null) <br /> +0x028 SegmentLock : _EX_PUSH_LOCK<br /> +0x030 u1 : <unnamed-tag><br /> +0x038 u2 : <unnamed-tag><br /> +0x040 PrototypePte : (null) </pre><br /><p>I Used _SEGMENT instead of _SEGMENT_OBJECT (that is contained in _SECTION_OBJECT’s symbols) because _SEGMENT_OBJECT’s output didn’t make sense (for example NonExtendedPtes can’t be the same size as the section in bytes, as a <a href="http://en.wikipedia.org/wiki/Page_table">PTE</a> is used for each page, which is 0x1000 bytes of memory): </p><pre><br />0: kd> dt nt!_SEGMENT_OBJECT 0xffffc000`5c0f66b0<br /> +0x000 BaseAddress : 0xffffe001`43f15880 Void<br /> +0x008 TotalNumberOfPtes : 0x17d79<br /> +0x010 SizeOfSegment : _LARGE_INTEGER 0x9c00<br /> +0x018 <font color="#ff0000"><strong>NonExtendedPtes : 0x17d79000</strong></font><br /> +0x01c ImageCommitment : 0<br /> +0x020 ControlArea : (null) <br /> +0x028 Subsection : (null) <br /> +0x030 MmSectionFlags : 0xffffe001`45e7a8c0 _MMSECTION_FLAGS<br /> +0x038 MmSubSectionFlags : 0x00000000`3fde0000 _MMSUBSECTION_FLAGS<br /><br /></pre><br /><p>So the committed memory is NumberOfCommittedPages * 0x1000 bytes, which in this case is 0x9c00000 bytes, or 156MBs.</p><br /><h5>other methods</h5><p>Possible alternative methods that would not require checking each process are based on kernel debugger commands:</p><ol><li><a href="https://msdn.microsoft.com/en-us/library/windows/hardware/ff562176(v=vs.85).aspx">!ca 0 21 or !ca 0 28</a> – that command displays all system control areas related to pagefile-backed sections, control areas are structures related to file mappings, and they are pointing to <em>Segment</em> structures that we’ve seen above. However the 0 parameter seems currently broken (checked both with LiveKD on Windows 8.1 and live debugging on Windows 10).</li><br /><li><a href="https://msdn.microsoft.com/en-us/library/windows/hardware/ff563187(v=vs.85).aspx">!handle 0 1 Section</a> – that command displays all handles in all processes pointing to section objects and it can be scripted to dump the size of the committed memory using the structures displayed above.</li></ol> Anonymoushttp://www.blogger.com/profile/11316621936237390502noreply@blogger.com0tag:blogger.com,1999:blog-3713810121431770793.post-54933382286925892762015-04-18T11:29:00.001-07:002015-04-18T11:31:11.874-07:00Debugging Assemblies that weren’t built with debug information<br> <h5>introduction</h5> <p>Using <a href="http://hmemcpy.com/2014/07/how-to-debug-anything-with-visual-studio-and-jetbrains-dotpeek-v1-2/">this great dotPeek feature</a> we can debug any third party managed assembly we want (it gets even better when we <a href="http://debugandconquer.blogspot.co.il/2015/03/skipping-over-last-statement-of.html">prevent JIT optimizations</a>), unless it was built without debug information. This can be seen during debug in the <em>Modules</em> window:<a href="http://lh3.googleusercontent.com/-67X0YDdCxb8/VTKiaxRP9zI/AAAAAAAAAH4/hScRws-yZpM/s1600-h/image%25255B3%25255D.png"><img title="image" style="border-left-width: 0px; border-right-width: 0px; border-bottom-width: 0px; display: inline; border-top-width: 0px" border="0" alt="image" src="http://lh3.googleusercontent.com/-TQNyd6wXAGw/VTKibcOlPDI/AAAAAAAAAIA/aqI0Q_miipU/image_thumb%25255B1%25255D.png?imgmax=800" width="566" height="23"></a> <br>Such assemblies were created without a PDB file using that setting:<a href="http://lh3.googleusercontent.com/-5i7DTZNWXVk/VTKicOZVsVI/AAAAAAAAAII/aGwPTwvY2I8/s1600-h/image%25255B8%25255D.png"><img title="image" style="border-left-width: 0px; border-right-width: 0px; border-bottom-width: 0px; display: inline; border-top-width: 0px" border="0" alt="image" src="http://lh3.googleusercontent.com/-iQ3DHqd6qyM/VTKic_RaxuI/AAAAAAAAAIQ/wQxxcEOwHmc/image_thumb%25255B4%25255D.png?imgmax=800" width="625" height="392"></a> <br>The debugger sees that the assembly was created without a <a href="http://www.wintellect.com/devcenter/jrobbins/pdb-files-what-every-developer-must-know">PDB file</a>, so it will refuse loading the “fake” <em>PDB </em>that <em>dotPeek</em> creates.</p> <blockquote> <p><font color="#6f6f6f">Note that there is no reason to build assemblies with this setting, the fact that the assembly points to a PDB file is mostly relevant during debug time and <a href="http://www.wintellect.com/devcenter/jrobbins/do-pdb-files-affect-performance">has no impact on performance</a>. Thus it’s rare to find such assemblies (all Microsoft’s <em>.NET Framework </em>assemblies and even Windows’ native DLLs were built with PDBs for example) but they exist.</font></p></blockquote> <h5>Where is that information stored?</h5> <p>This information is stored in the <a href="http://www.debuginfo.com/articles/debuginfomatch.html">PE header</a>, and can be viewed with <a href="https://support.microsoft.com/en-us/kb/177429">dumbin /headers</a>:</p><pre>C:\> dumpbin /headers Test.dll<br />...<br /> Debug Directories<br /><br /> Time Type Size RVA Pointer<br /> -------- ------ -------- -------- --------<br /> 55324F94 cv 24 00125D90 123F90 Format: RSDS, {C2B3677B-EE83-4<br />1DA-8CA2-C16D74BB6C87}, 1, Test.pdb<br />...<br /></pre><br /><p>The output above contains the GUID that is matched by the debugger in the loaded PDB file along with <a href="http://www.debuginfo.com/articles/debuginfomatch.html#pdbfiles">few other things</a>. When <em>Debug Info </em>is set to <em>none </em>no <em>Debug directories</em> are emitted and thus no PDB file can be matched.</p><br /><h5>What can we do?</h5><p>Theoretically it is possible to directly add <em>Debug Directories </em>to the assembly but no common tool does it, so we’ll use <em>ildasm</em> and <em>ilasm:</em></p><pre>C:\> ildasm NoDebugInfo.dll /out=Test.il<br />C:\> ilasm /dll /pdb /Out:Test.dll Test.il<br /><br /></pre><br /><p>Those pair of commands create an assembly with a PDB file, thus the assembly has Debug Directories that point to the PDB. You now may be asking the following:</p><ol><br /><li>What if the assembly is strong name signed? <br>This will break the signature, but for <a href="https://msdn.microsoft.com/en-us/library/cc679069%28v=vs.110%29.aspx">some cases it isn’t validated</a> and when it is you can disable validation for this assembly using <a href="http://blogs.msdn.com/b/securitytools/archive/2009/12/30/how-to-turn-off-strong-name-validation.aspx">sn –Vr <AssemblyFile></a> (don’t forget to restore the setting later using <em>sn –Vu</em> or <em>sn -Vx</em>). Note that you must run the correct edition (32 bit or 64 bit) for the program you are running, the <em>Visual Studio Developer Command Prompt </em>on my machine references the 32 bit one so for 64 bit application I must run the one located in <em>C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\x64 </em>on my machine.</li><br /><li>What does the created <em>PDB</em> contain?<br><a href="http://blogs.msdn.com/b/jmstall/archive/2005/08/25/pdb2xml.aspx">.NET PDBs point between IL offsets and source code lines</a>, in this case instead of <em>C#</em> our source is <em>IL, </em>which isn’t really useful because the same <em>IL </em>instructions are embedded in the assembly, However for our purpose it doesn’t matter, we just wanted to add <em>Debug Directories </em>and we’ll use the <em>dotPeek </em>provided PDB that is “faking” the PDB signature to actually debug C# code.</li></ol> Anonymoushttp://www.blogger.com/profile/11316621936237390502noreply@blogger.com0tag:blogger.com,1999:blog-3713810121431770793.post-32383909368114150862015-04-11T14:02:00.001-07:002015-04-18T06:40:31.933-07:00The Relationship between .NET and the Windows Kernel<h4> </h4> <h4>Introduction</h4> <p>A question that one may ask is "Is the <em>Windows</em> kernel aware of the <em>.Net Framework</em>?". <br>Assuming "No" here is very sensible because the Windows kernel should expose all of the necessary services for any software framework in the <em>Windows API</em>, and any kernel changes made for a software framework would hurt encapsulation.<br>Indeed, the entire <em>.NET CLR</em> is made of <em>DLL’s</em> that are using the <em>Windows API</em>, However there are few features in .<em>NET</em> that involve kernel modifications and I will discuss them in this post. <h4> </h4> <h4>How .NET executables launch</h4> <p><em>.NET executables</em> (and <em>.NET DLLs</em> as well) are like other exe files on <em>Windows</em>, they use the<em> </em><a href="http://en.wikipedia.org/wiki/Portable_Executable"><em>Portable Executable</em></a><em> (PE)</em> file format, and are usually launched with a <a href="https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx">CreateProcess</a> <em>Windows API</em> call. <br>When Windows launches a native process the last step of the process startup is passing the execution control to the <em>entry point</em> of the <em>executable </em>(can be viewed with <a href="https://support.microsoft.com/en-us/kb/177429">dumpbin /headers</a> command). With <em>.NET executables</em>, since <em>Windows XP</em>, the system passes the execution to <a href="https://msdn.microsoft.com/en-us/library/xh0859k0.aspx">_CorExeMain</a> function of the <em>mscoree.dll </em>(ignoring the <em>entry point</em>), which initializes the <em>CLR</em> and passes the control to it (On older versions of Windows the system did pass execution to the executables’s entry point which contained short code to jump to<em> _CorExeMain</em>).</p> <blockquote> <p>The component that runs at the start of the process, and is responsible for initialization tasks like calling <em>_CorExeMain,</em> is called the <em>NTDLL Loader</em>, you can note that its functions start with ntdll!Ldr*.</p></blockquote> <p>How does windows recognize<em> .NET executables</em>? They contain <em>.NET</em> specific metadata, the part that is relevant to this post can be viewed (and modified) with the <a href="https://msdn.microsoft.com/en-us/library/ms164699(v=vs.110).aspx">CorFlags</a> utility.<br>This is the first demonstration of Windows' knowledge of .NET, but the next features are bigger. </p><br></br> <h4>AnyCPU Executables</h4> <h6>The interesting feature of .NET executables that run as 64-bit on 64-bit Windows, and as 32-bit on 32-bit windows. </h6> <blockquote> <p>The newer<em> Prefer 32</em>-<em>bit </em>option<em> </em>isn’t very interesting for this post, as on 64-bit windows it makes the executable behave like a <em>32-bit only </em>executable when launched, thus we will refer to <em>AnyCPU </em>as an executable built without this flag.<br></p></blockquote> <h6>How does it work?</h6><p><a href="https://msdn.microsoft.com/en-us/library/4ce9k7xb(v=vs.110).aspx">The documentation of mscoree’s _CorValidateImage</a> refers to changing <em>32-bit (PE32)</em> executable image to <em>64-bit (PE32+)</em> executable image in memory (an executable in memory is called an <em>Image</em>) on 64-bit Windows, and you might think that it's all to it, <strong>However</strong> that's a <em>user mode function </em>that is supposed to be called in the newly created process by the NTDLL <em>Loader</em>, the decision about the architecture of a process happens earlier, and in <em>kernel mode </em>(kernel structures like <em><a href="https://msdn.microsoft.com/en-us/library/windows/hardware/ff544273(v=vs.85).aspx">EPROCESS</a> </em>depend on it), so there has to be some <em>kernel mode</em> code knowing about .NET which decides which architecture to use. <blockquote> <p>Note: I debugged and _<em>CorValidateImage</em> isn't getting called on <em>Windows 8.1</em> (on <em>Windows 7</em> it does), its responsibility seems to have moved to the <em>Loader's</em> <em>LdrpCorValidateImage</em> and <em>LdrpCorFixupImage</em> functions. </p></blockquote> <h6>Entering kernel mode</h6><p>I attached a kernel debugger to a <em>Windows 10 VM</em>, I wanted to inspect the data structures related to executables in memory. </p> <p>I started with finding the process (I chose ILSpy, an AnyCPU executable):<pre>0: kd> !process 0 1 ILSpy.exe<br /><br />PROCESS ffffe0001e7e57c0<br /> SessionId: 1 Cid: 533c Peb: 7ff5ffb86000 ParentCid: 1808<br />FreezeCount 1<br /> DirBase: 23540f000 ObjectTable: ffffc00158aded80 HandleCount: <Data Not Accessible><br /> Image: ILSpy.exe<br /> <strong><font color="#ff0000" size="2">VadRoot ffffe0001d03dac0</font></strong> Vads 12 Clone 0 Private 44. Modified 5. Locked 0.<br /> DeviceMap 0000000000000000<br /> Token ffffc0015c62c930<br /> ElapsedTime 09:02:01.350<br /> UserTime 00:00:00.000<br /> KernelTime 00:00:00.000<br /> QuotaPoolUsage[PagedPool] 17352<br /> QuotaPoolUsage[NonPagedPool] 1408<br /> Working Set Sizes (now,min,max) (161, 50, 345) (644KB, 200KB, 1380KB)<br /> PeakWorkingSetSize 148<br /> VirtualSize 3 Mb<br /> PeakVirtualSize 3 Mb<br /> PageFaultCount 199<br /> MemoryPriority BACKGROUND<br /> BasePriority 8<br /> CommitCharge 70<br /> DebugPort ffffe0000e433cf0<br /> Job ffffe0001f724430</pre><p><em>VAD's</em> are structures that windows uses to track the virtual address space of a process, each process has a <em>VAD root</em> (highlighted in the output above) and it points to other <em>VAD's</em> (and so on) forming a tree structure that represents the virtual address space of a process. The <a href="https://msdn.microsoft.com/en-us/library/windows/hardware/ff565574(v=vs.85).aspx">!VAD debugger extenstion command</a> helps analyze VAD's. By passing the VAD Root of the process, the command displays the virtual memory layout of the process: <pre><font size="1">0: kd> !vad ffffe0001d03dac0<br />VAD level start end commit<br /><font color="#ff0000"><strong>ffffe000127bd430</strong></font> ( 3) b90 c15 1 Mapped Exe EXECUTE_WRITECOPY \path\ILSpy.exe<br />ffffe00012993010 ( 2) c20 c3f 32 Private READWRITE <br />ffffe0001e92e320 ( 3) c40 c4e 0 Mapped READONLY Pagefile-backed section<br />ffffe00018be7dc0 ( 1) c50 d4f 5 Private READWRITE <br />ffffe00019f154c0 ( 3) d50 d53 0 Mapped READONLY Pagefile-backed section<br />ffffe0001dc9a090 ( 2) d60 d60 0 Mapped READONLY Pagefile-backed section<br />ffffe00019057120 ( 3) d70 d71 2 Private READWRITE <br />ffffe0001d03dac0 ( 0) 7ffe0 7ffef -1 Private READONLY <br />ffffe0000f121ca0 ( 2) 7ff5ffb60 7ff5ffb82 0 Mapped READONLY Pagefile-backed section<br />ffffe0000db3a5a0 ( 1) 7ff5ffb86 7ff5ffb86 1 Private READWRITE <br />ffffe00019a990f0 ( 3) 7ff5ffb8e 7ff5ffb8f 2 Private READWRITE <br />ffffe00019c043d0 ( 2) 7ffb3c5e0 7ffb3c78b 17 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\ntdll.dll<br /><br />Total VADs: 12, average level: 3, maximum depth: 3</font></pre><p>We can see above the VAD describing our <em>executable image</em> (highlighted), now when we pass it to the !VAD command with the extra parameter <em><strong>1</strong>,</em><strong> </strong>we’ll get extra details about that specific image:<pre>0: kd> !vad ffffe000127bd430 1<br /><br />VAD @ ffffe000127bd430<br /> Start VPN b90 End VPN c15 Control Area ffffe000196e5d80<br /> FirstProtoPte ffffc00146cbfbd0 LastPte ffffc00146cbfff8 Commit Charge 1 (1.)<br /> Secured.Flink 0 Blink 0 Banked/Extend 0<br /> File Offset 0 <br /> ImageMap ViewShare EXECUTE_WRITECOPY <br /><br />ControlArea @ ffffe000196e5d80<br /> Segment ffffc001584de880 Flink ffffe000127bd490 Blink ffffe000126fe150<br /> Section Ref 2 Pfn Ref 83 Mapped Views 2<br /> User Ref 4 WaitForDel 0 Flush Count 5ed8<br /> File Object ffffe0000f1f3c80 ModWriteCount 0 System Views ffff<br /> WritableRefs 0 <br /> Flags (a0) Image File <br /><br /> \path\ILSpy.exe<br /><br />Segment @ ffffc001584de880<br /> ControlArea ffffe000196e5d80 BasedAddress 0000000000400000<br /> Total Ptes 86<br /> Segment Size 86000 Committed 0<br /> Image Commit 0 <strong><font color="#ff0000">Image Info ffffc001584de8c8</font></strong><br /> ProtoPtes ffffc00146cbfbd0<br /> Flags (1c20000) ProtectionMask <br><br></pre><p>The output contains a property named <em>Image Info</em> (highlighted), that seems to contain the address of some kind of a structure (addresses starting with <em>ffff</em> are kernel space). Now the goal is to figure out which one, unfortunately the debug symbols of the object containing it - _<em>SEGMENT</em>, give no info about its type: <pre>0: kd> dt nt!_SEGMENT ffffc001584de880<br /> +0x000 ControlArea : 0xffffe000`196e5d80 _CONTROL_AREA<br /> +0x008 TotalNumberOfPtes : 0x86<br /> +0x00c SegmentFlags : _SEGMENT_FLAGS<br /> +0x010 NumberOfCommittedPages : 0<br /> +0x018 SizeOfSegment : 0x86000<br /> +0x020 ExtendInfo : 0x00000000`00400000 _MMEXTEND_INFO<br /> +0x020 BasedAddress : 0x00000000`00400000 Void<br /> +0x028 SegmentLock : _EX_PUSH_LOCK<br /> +0x030 u1 : <unnamed-tag><br /><font color="#ff0000"><strong> +0x038 u2 : <unnamed-tag></strong></font><br /> +0x040 PrototypePte : 0xffffc001`46cbfbd0 _MMPTE<br />0: kd> dps ffffc001584de880<br />ffffc001`584de880 ffffe000`196e5d80<br />ffffc001`584de888 01c20000`00000086<br />ffffc001`584de890 00000000`00000000<br />ffffc001`584de898 00000000`00086000<br />ffffc001`584de8a0 00000000`00400000<br />ffffc001`584de8a8 00000000`00000000<br />ffffc001`584de8b0 00000000`00000000<br /><font color="#ff0000"><strong>ffffc001`584de8b8 ffffc001`584de8c8</strong></font><br />ffffc001`584de8c0 ffffc001`46cbfbd0</pre><p>The above commands show the missing symbol information (first command) and the actual raw memory (second command) containing our pointer at the same offset (0x38). <br /><p>The next option is guessing the type by searching for existing symbols: <pre>0: kd> dt nt!*image*info*<br /> ntkrnlmp!_MI_SECTION_IMAGE_INFORMATION<br /> <strong><font color="#ff0000">ntkrnlmp!_SECTION_IMAGE_INFORMATION</font></strong><br /> ntkrnlmp!_MI_EXTRA_IMAGE_INFORMATION</pre><br /><p>Trying <em>dt </em>with <em>_SECTION_IMAGE_INFORMATION</em>, and bingo, it fits (data like stack sizes makes sense):<pre>0: kd> dt nt!_SECTION_IMAGE_INFORMATION ffffc001584de8c8<br /> +0x000 TransferAddress : 0x00000000`004734be Void<br /> +0x008 ZeroBits : 0<br /> +0x010 MaximumStackSize : 0x100000<br /> +0x018 CommittedStackSize : 0x1000<br /> +0x020 SubSystemType : 2<br /> +0x024 SubSystemMinorVersion : 0<br /> +0x026 SubSystemMajorVersion : 4<br /> +0x024 SubSystemVersion : 0x40000<br /> +0x028 GpValue : 0<br /> +0x02c ImageCharacteristics : 0x102<br /> +0x02e DllCharacteristics : 0x8540<br /> +0x030 Machine : 0x14c<br /> +0x032 ImageContainsCode : 0x1 ''<br /><strong> +0x033 ImageFlags : 0x3 ''<br /><font color="#ff0000"> +0x033 ComPlusNativeReady : 0y1<br /> +0x033 ComPlusILOnly : 0y1</font></strong><br /> +0x033 ImageDynamicallyRelocated : 0y0<br /> +0x033 ImageMappedFlat : 0y0<br /> +0x033 BaseBelow4gb : 0y0<br /> +0x033 Reserved : 0y000<br /> +0x034 LoaderFlags : 1<br /> +0x038 ImageFileSize : 0x83000<br /> +0x03c CheckSum : 0x8859c</pre><p>Immediatly it looks like it contains 2 interesting flags: <em>ComPlusILOnly</em> and <em>ComPlusNativeReady</em>.<br><em>ComPlusILOnly</em> seems helpful, and it actually is: it simply tells us if the PE contains only IL instructions (CorFlags ILONLY flag) or it's a mixed mode (or native) executable. Obviously an executable that contains any amount of machine code (mixed or native) can't be AnyCPU, thus this flag must be set for it to work.</p><p>I couldn't really make sense of the name of ComPlusNativeReady flag but from testing it with different executables it is turned on (value is 1) when the executable is <em>AnyCPU</em>, the relevant CorFlags flags for that - <em>32BITREQ (only 32-bit) </em>and<em> 32BITPREF (prefer 32-bit</em>) should be turned off, and the <em>ILONLY </em>flag must be turned on. </p><p>By changing these value in the debugger with eb <ImageFlagsAddres> <0,1,2,3> I observed how new processes of the same executable spawn differently (it worked because the PE headers aren't parsed each time a new process is launched, they are cached). <br><br>As for the kernel execution flow, the parsing of the executable seem to happen at the <em>nt!MiParseImageSectionHeaders</em> and <em>nt!MiParseComImage</em> functions, and the branching based on the <em>Image Flags </em>at <em>nt!PspAllocateProcess</em> and <em>nt!PspDetectComplusILImage </em>(checked using <a href="https://msdn.microsoft.com/en-us/library/windows/hardware/ff538165%28v=vs.85%29.aspx">memory access breakpoints</a> and some tracing). <br /><h4>Repositioning the image in memory</h4><br /><p>For increased security, since <em>Windows Vista, </em>a feature called <a href="http://security.stackexchange.com/questions/18556/how-do-aslr-and-dep-work">ASLR</a> is repositioning images in memory between boots, the reason that it happens only between boots and not for every process launch is because images should be shared between processes for best performance (think of images like <em>ntdll.dll</em> that every process contains and the memory that would have been wasted if they weren’t shared), and because of the fact that they contain pointers to absolute addresses, those addresses should be the same for every process. Thus all images are <a href="http://en.wikipedia.org/wiki/Relocation_%28computing%29">relocated</a> only once per boot and otherwise every image has its own constant <a href="https://msdn.microsoft.com/en-us/library/f7f5138s.aspx">base address</a> for all processes.</p><p>However, <em>IL Only </em>images contain no native code and thus no pointers to absolute addresses, so unlike native images there is no reason not to relocate them per process without compromising the sharing, and it actually is implemented in the kernel. Based on the <em>ComPlusILOnly </em>flag, the kernel decides whether to relocate the image every time the image is loaded to a process. <br>Below is a screen capture of <em>Process Explorer’s DLL’s</em> <em>view </em>of two processes of the same executable, note how the <em>Base </em>value changes. Similar relocations happen with managed IL only referenced DLL’s, unlike the <em>Base </em>of <em>ntdll </em>which stays the same.<br> <a href="http://lh5.ggpht.com/-ett6QZYbcdE/VSmL0cVOByI/AAAAAAAAAHc/NNdj0p3wMgM/s1600-h/image%25255B19%25255D.png"><img title="image" style="border-left-width: 0px; border-right-width: 0px; border-bottom-width: 0px; display: inline; border-top-width: 0px" border="0" alt="image" src="http://lh6.ggpht.com/-SzD54Zan4yg/VSmL1OegqEI/AAAAAAAAAHk/_6BFRrLlvxk/image_thumb%25255B11%25255D.png?imgmax=800" width="654" height="268"></a> </p><br /><h4>Conclusion</h4><br /><p>In this post we have seen how few features in .NET required Windows kernel modifications and inspected their high level implementation with some debugging techniques, This list of features wasn’t meant to be exhaustive but those are the features that I’m currently aware of, I’ll be happy to find more such features in the feature.</p> Anonymoushttp://www.blogger.com/profile/11316621936237390502noreply@blogger.com0tag:blogger.com,1999:blog-3713810121431770793.post-43722900166908608182015-03-27T14:11:00.001-07:002015-03-28T01:34:15.051-07:00Skipping over the last statement Of a function of an optimized Assembly in the visual studio debugger<p>Let’s imagine that we are debugging a third party module (<a href="http://hmemcpy.com/2014/07/how-to-debug-anything-with-visual-studio-and-jetbrains-dotpeek-v1-2/">possibly using this cool dotPeek feature</a>), and want to skip the last line of the executing function. While it’s well known that it’s <a href="https://msdn.microsoft.com/en-us/library/y740d9d3.aspx#sectionToggle13">possible to skip over lines of code in the debugger</a>, and it’s easily done in an unoptimized assembly by simply setting the closing curly bracket “}” as the next statement. That method doesn't work with an optimized build because because the compiler doesn’t emit <a href="https://msdn.microsoft.com/en-us/library/system.reflection.emit.opcodes.nop%28v=vs.110%29.aspx">IL NOP instruction</a> at the end of the function whose debugging information can be pointing to the closing curly bracket (that’s how it works with an unoptimized build).</p><h6>JIT optimization</h6><p>Before we can set the next instruction to any instruction, we need to prevent <em>JIT optimization</em>: <br>When an assembly is compiled with optimizations it also usually means that it’s going to be <em>JIT optimized</em> as well, which would make the debugging experience really bad with messages like <em>“Cannot evaluate expression because the code of the current method is optimized” </em>and also <strong>prevent changing the next instruction</strong>.</p> <h6>Preventing JIT optimization</h6><p>The information on reliably preventing <em>JIT optimization </em>exists on the internet but it’s scattered across a few sources so It took me a while to find it. I’ll sum it up here: </p> <ol> <li>In case where a <a href="https://msdn.microsoft.com/en-us/library/vstudio/6t9t5wcf%28v=vs.110%29.aspx">native image of the assembly</a> is installed on the machine (as most framework assemblies like <em>mscorlib.dll </em>and<em> System.dll </em>are) the optimized native image would be loaded by default and we can prevent that by setting the <em>environment variable COMPLUS_ZapDisable</em> to 1. <li>For each assembly that we want to prevent <em>JIT optimization </em>we should create an <em>.ini file</em> with the same name as the dll containing: <pre>[.NET Framework Debugging Control]<br />GenerateTrackingInfo=1<br />AllowOptimize=0 <br /><br /></pre><p>note that the <em>.ini file </em>should be placed at the <strong>same directory as the assembly that it refers to loaded from</strong> (including the <em>GAC</em> and <em>Temporary ASP.Net Files </em>if needed).</p></li></ol><p>The final result can be verified by seeing the assembly not optimized in the <em>modules </em>window during debug:<br><a href="http://lh5.ggpht.com/-dSAEmwtVZN0/VRXHakJtkNI/AAAAAAAAAGw/CipLJoiC8KY/s1600-h/image%25255B5%25255D.png"><img title="image" style="border-left-width: 0px; border-right-width: 0px; border-bottom-width: 0px; display: inline; border-top-width: 0px" border="0" alt="image" src="http://lh5.ggpht.com/-B0e9_38Vq3s/VRXHbS6iwzI/AAAAAAAAAG4/gxX1ZGhRc_Y/image_thumb%25255B3%25255D.png?imgmax=800" width="361" height="84"></a> </p><h6>Skipping the last statement of a function</h6><p>Let’s assume that our function is the following (now it would be obvious why I wanted to skip the last line).</p><pre class="brush: csharp;">private static void FailFast(string message, string detailMessage)<br />{<br /> if (Invariant.IsDialogOverrideEnabled)<br /> Debugger.Break();<br /> Environment.FailFast(MS.Internal.WindowsBase.SR.Get("InvariantFailure"));<br />}</pre><p>While preventing <em>JIT Optimization </em>allows us setting the next instruction, we still can’t skip the last source code line (because there is still no <em>IL NOP</em> that can be pointing to the closing curly bracket as it’s a <em>C#</em> compiler optimization) </p><p>The trick is using the <em>disassembly</em> window to control the execution:<br><a href="http://lh3.ggpht.com/-1vwl2gUGTOA/VRXHcBFNJYI/AAAAAAAAAHA/dK9pelw61PA/s1600-h/image%25255B11%25255D.png"><img title="image" style="border-left-width: 0px; border-right-width: 0px; border-bottom-width: 0px; display: inline; border-top-width: 0px" border="0" alt="image" src="http://lh5.ggpht.com/-4VUDg1ILIFI/VRXHcxTQbHI/AAAAAAAAAHI/ZwLMgKuosSY/image_thumb%25255B7%25255D.png?imgmax=800" width="511" height="387"></a> <br>The image contains the <em>disassembly</em> window when execution is broken at the first line of our function. </p><p>What we can do in this case is as with source code, set the next statement to be the beginning of the function epilogue (<em>mov esp, ebp</em>) thus skipping the instruction that causes the application to terminate (<em>Environment.FailFast</em>).<br><br>Obviously as with source code, we should be careful of where we directing the execution to prevent corruption (for example not skipping the function epilogue and corrupting the stack, supplying return value when needed). Also preventing the application from crashing when it wants to, like I did, is probably not a good idea but I wanted to check something quickly and it did the job.</p> Anonymoushttp://www.blogger.com/profile/11316621936237390502noreply@blogger.com0tag:blogger.com,1999:blog-3713810121431770793.post-51728033048361020682014-11-15T08:50:00.001-08:002014-12-06T11:57:08.918-08:00Taking a memory dump of a Protected process on windows 8.1<p><font face="">Let’s imagine we’d like to inspect the memory of the <a href="http://en.wikipedia.org/wiki/Service_Control_Manager">SCM</a> (<em>services.exe</em>) process for <a href="http://www.moonsols.com/2011/03/06/retrieving-windows-services-via-windbg/">some reason</a>, the best option would be taking a memory dump. However, since <em>Windows 8.1</em>, a hindrance was added in doing this and most other actions that touch that process, and a few other system processes. That hindrance is called <strong><em>Protected processes.</em></strong></font></p> <h5>Introduction to protected processes</h5> <p>The goal of protected processes is adding another layer of protection between regular user processes (even those running as administrator) and some system processes. It started for mostly <a href="http://msdn.microsoft.com/en-us/library/windows/desktop/aa376846%28v=vs.85%29.aspx">DRM related processes at Windows Vista</a> and at Windows 8.1 it extended to other system processes. Probably the most important one is <a href="http://www.petri.com/enable-lsa-protection-windows-8-1-server-2012-r2.htm">the security related process lsass.exe</a> because <a href="http://blogs.dirteam.com/blogs/sanderberkouwer/archive/2014/06/24/security-thoughts-lsass-protection-in-windows-8-1-and-windows-server-2012-r2.aspx">its compromise may lead to the compromise of a domain network</a>. The protection is manifested by the fact that regular (not protected) processes are unable to perform most actions on protected processes, and that includes taking a memory dump. </p> <p>That system isn’t completely sealed yet: for obvious reasons the protection isn’t enforced in kernel mode and there exist <a href="http://processhacker.sourceforge.net/">few</a> <a href="http://blog.gentilkiwi.com/mimikatz">signed drivers</a> who can help regular processes to bypass some of the protection, since regular processes running as an administrator can launch drivers.</p> <p>What makes a process protected during its runtime is a field in the <em>EPROCESS</em> kernel structure: it used to be a bit field named <em>ProtectedProcess </em>since <em>Vista</em>, and as a few protection options were added in <em>8.1</em> it changed to a byte sized structure field named <em>Protection.</em> You can strip the protection of a protected process or turn a regular process into a protected one by modifying this field, which would also allow it to access a protected process.</p> <p>For more in depth info on protected processes you can read <a href="http://www.alex-ionescu.com/?p=97">this series</a>, and <a href="http://www.gentlesecurity.com/blog/blog5.php/2008/03/04/protected-processes">this post</a> (updated to <em>Vista</em>) which also displays the method of taking a memory dump of a protected process in Vista. I’ll use a similar method but adjusted to the <em>8.1</em> <em>EPROCESS</em> structure changes. </p> <h5>Taking a memory dump of a protected process</h5> <p>We start with <a href="http://msdn.microsoft.com/en-us/library/windows/hardware/ff553382%28v=vs.85%29.aspx">local kernel debugging</a>, let’s assume we want to take the memory dump of <em>services.exe</em> with Task Manager (<em>TaskMgr.exe</em>).</p> <p>We first need to get the offset of the <em>Protection </em>field:</p><pre>0: kd> dt _EPROCESS -y Protection<br />nt!_EPROCESS<br /> <strong>+0x67a</strong> Protection : <strong>_PS_PROTECTION</strong><br /><br /></pre><br /><p>Next we want to check the protection of <em>services.exe</em> to adjust Task Manager’s protection to it (simply setting its protection field to a non-zero value may not be enough as there is some isolation between different types of protected processes, more on this in the series I linked above), so we’ll find its <em>EPROCESS</em> address:</p><pre>0: kd> !process 0 0 services.exe <br />PROCESS <strong>ffffe0001a644900</strong><br /> SessionId: 0 Cid: 0304 Peb: 7ff65bf4c000 ParentCid: 0298<br /> DirBase: 1520e1000 ObjectTable: ffffc00088b4ad80 HandleCount: <Data Not Accessible><br /> Image: services.exe<br><br /></pre><br /><p>Now we can dump its <em>Protection </em>field:</p><pre>0: kd> dt _PS_PROTECTION ffffe0001a644900+0x67a<br />nt!_PS_PROTECTION<br /> +0x000 Level : <strong>0x61</strong> 'a'<br /> +0x000 Type : 0y001<br /> +0x000 Audit : 0y0<br /> +0x000 Signer : 0y0110<br /><br /></pre><br /><p>Now let’s find Task Manager’s <em>EPROCESS</em> location:</p><pre>0: kd> !process 0 0 TaskMgr.exe <br />PROCESS <strong>ffffe0001d489080</strong><br /> SessionId: 1 Cid: 1b20 Peb: 7ff65480f000 ParentCid: 0418<br /> DirBase: 17ad18000 ObjectTable: ffffc0009f0a9380 HandleCount: <Data Not Accessible><br /> Image: Taskmgr.exe<br /><br /></pre><br /><p>Before we change its protection let’s check its current value:</p><pre>0: kd> dt _PS_PROTECTION ffffe0001d489080+0x67a<br />nt!_PS_PROTECTION<br /> +0x000 Level : 0 ''<br /> +0x000 Type : 0y000<br /> +0x000 Audit : 0y0<br /> +0x000 Signer : 0y0000<br /><br /></pre><br /><p>So there’s no protection, Now we can adjust it to the protection of services.exe:</p><pre>0: kd> eb ffffe0001d489080+0x67a 0x61<br /><br /></pre><br /><p>Finally we can use the right click menu to create a dump of services.exe:<a href="http://lh5.ggpht.com/-t8yMqf_NC3E/VGeEXCnl-zI/AAAAAAAAACw/Efsevoj1uk0/s1600-h/image%25255B3%25255D.png"><img title="image" style="border-left-width: 0px; border-right-width: 0px; border-bottom-width: 0px; display: inline; border-top-width: 0px" border="0" alt="image" src="http://lh6.ggpht.com/-HPuLaoJF1M4/VGeEXzP74zI/AAAAAAAAAC4/26SbmSM6vwQ/image_thumb%25255B1%25255D.png?imgmax=800" width="376" height="350"></a></p> Anonymoushttp://www.blogger.com/profile/11316621936237390502noreply@blogger.com0