tag:blogger.com,1999:blog-5036198523690297182Wed, 13 Dec 2017 19:45:08 +0000svchostanti-attachinternalsollydbg bugreversingsecretsecretsdetect Virtual PCvulnerabilitywow64EnumProcessModulesGetModuleFileNameExAIDAIDA ProNtCreateThreadExalgorithmanti-attachingantidumpdetect VirtualPCDbgBreakpointDbgUiIssueRemoteBreakinDbgUiRemoteBreakinDbgkMapViewOfSectionDebugActiveProcessEFLAGSHideFromDebuggerKiFastSystemCallLoaderDataNB10PAGE_GUARDPspAllocateThreadRtlCreateUserThreadSeIncreaseBasePriorityPrivilegeVirtual PCVirtualBox_KUSER_SHARED_DATAanti-OllyDumpanti-debuganti-dumpantiattachdetect VPCdetect VirtualBoxdynamic TLSlpStartAddresswow64.dll.lib file.sym olly.sym olly exploit.udd.udd bug0x12B0x2A425E190x800000030x9e9e9e9e0xCDCDCDCD0xFFFFFFF70xbaadf00d0xe9e9e9e90xfeeefeee2A425E197ffe030096 sections9e9e9e9eAdjustTokenPrivilegesAnti-IDAAnti-WindbgBad Dos SignatureBaseCreateStackBreak on new threadBreakOnDllLoadBreakonnewthreadCOFFCONTEXTCPUID sepCREATE_THREAD_DEBUG_EVENTCheckAppHelpCodeViewCoff debug infoCpuThreadInitCpupReturnFromSimulatedCodeCreateRemoteThreadDbgPromptDbgkForwardExceptionDbgkSuppressDbgMsgDebugActiveProcessStopDebugPromptDetachDetachMeDisableHeapLookAsideERROR_PARTIAL_COPYEXCEPTION_BREAKPOINTFFFFFFF7FileAlignmentGetSystemInfoICanCatchIDA 6.2IMAGEHLP_MODULEIMAGE_COFF_SYMBOLS_HEADERIMAGE_DEBUG_DIRECTORYIMAGE_DEBUG_TYPE_CODEVIEWIMAGE_DEBUG_TYPE_COFFIMAGE_DEBUG_TYPE_UNKNOWNIMAGE_EXPORT_DIRECTORYINT 2DKiFastSystemCallRetKiIntSystemCallLDR_MODULELOAD_DLL_DEBUG_EVENTLOAD_DLL_DEBUG_INFOLdrQueryImageFileExecutionOptionsLordPeMajorSubsystemVersionMinorSubsystemVersionNB02NB11NeedsWorkingSetAgingNtContinueNtMajorVersionNtMinorVersionNtQueryInformationThreadNtQuerySectionNtQuerySystemInformationNtSetInformationProcessNtSetInformationThreadNumberOfSectionsNumberOfSymbolsOlly 2OllyDbg v2.0OllydumpPAGE_EXECUTE_WRITECOPYPAGE_NOACCESSPAGE_WRITECOPYPDB2.0PE ExplorerPE TimeDateStampPE headerPE/CoffPE/Coff.COFFPEBPEB_LDR_DATAPEExplorerPointerToRawDataPointerToSymbolTableProcessInitProcessIoPriorityProcessSelfDeleteProcessThreadStackAllocationPspCreateThreadRSDSRaiseExceptionReadmemoryResEditResTunerResource hackerResume flagRtlCreateUserStackRtlImageDirectoryEntryToDataRtlIsCurrentThreadAttachExemptRtlSetProcessIsCriticalRundownFailSTATUS_WX86_BREAKPOINTSYSENTERSYSEXITSYSTEM_THREAD_INFORMATIONSeDebugPrivilegeSectionAlignmentServiceDllServiceMainSetTimerResolutionLinkSizeOfDataSizeOfImageSizeOfStackCommitSizeOfStackReserveSkipThreadAttachStackRandomizationDisabledStartAddressStud_PEStude PESuppressDebugMsgSvchostPushServiceGlobalsSymGetModuleInfoSymLoadModuleSymTypeTEBTFTLSThreadHideFromDebuggerThreadIoPriorityThreadPagePriorityThunRTMainTime Date StampTimeDateStampTimeDateStampsUnmapViewOfFileVB MalwareVPCVS2010VSDVirtualAllocVirtualAllocExVirtualProtectexVirtualQueryVirtualbox DetectionWQLWQL QueryWaitForDebugEventWow64 antidebugWow64CommittedStackSizeWow64ExecuteFlagsWow64GetWow64ImageOptionsWow64LogWow64LogInitializeWow64LogMessageArgListWow64LogSystemServiceWow64LogTerminateWow64MaximumStackSizeWow64ProcessX86SwitchTo64BitModeZeroMemoryZwContinueZwCreateThreadExZwMapViewOfSectionZwSetInformationProcessZwSetInformationThread_FindModule_LdrpImageHasTls_NO_DEBUG_HEAP_Readmemoryanti software breakpointsanti sw bpsanti-dumpinganti-memory breakpointsantiattachingantidebugantidumpingantimemory breakpointsantiollydumpbinary resourcebrute forcebrute-forcebsodbuffer overflowcallwindowprocwcode sectioncoff symbolscpuiddbg.ldwdebug control registerdetect OllyDbgdetect vboxdevc++dllfunctioncalldr7dwShareModedwg.ldwe9e9e9e9embed executableerase peexport tablehardwarehardware breakpointimport libraryinfinite loopinternal namekernelbugkill %s%slib filelink.exeloaders\dbg.ldwloopmalwarememory breakpointmovsbmsvbvm60.dllnamed entrynativenative x86 hookntdllnumberoffunctionsolly bugolly win7ollybugsollydbgollydbg .uddollydbg 2ollydbg exploitollydbg format stringollydbg uddollyvbollywowollywow64os loaderp-codepcodepe header erasionpermutationpidpop ssprocess heappsapipsapi.dllrandomnessrdtscrdtsc algorithmrep movsbresource entryresource sizeresource tableresource tunerresourcehackerresourcetunersection nameshared globals tablesingle stepsingle steppingsizeofcodesnapshotsnapshotsstep intostep overstud_pe TLSsym exploitsym ollysym ollydbgt_hardbpointtls callbacktlscallbacktlscallbackstoo many sectionstrap flagudd buguser-mode hookvb decomilervisual basic malwarevpc 2007whNtSetInformationProcesswin2000win7 kernelwindows 2000wow64 anti-debugwow64cpu.dllwow64win.dllzombie_addrefzombie_releasewaliedassarhttp://waleedassar.blogspot.com/noreply@blogger.com (Walied Assar)Blogger74125tag:blogger.com,1999:blog-5036198523690297182.post-1155128012354100377Sat, 04 Apr 2015 23:53:00 +00002015-12-11T16:37:36.372-08:00detect VirtualBoxVirtualBoxVirtualbox DetectionWQLWQL QueryVirtualBox Detection Via WQL Queries<div dir="ltr" style="text-align: left;" trbidi="on">Here i have tried to group most of the WMI classes that can be used to detect VirtualBox Virtual Machine. They are as follows:<br /><br />1) Win32_NetworkAdapterConfiguration (Alias: NICCONFIG)<br />2) Win32_SystemDriver (Alias: sysdriver)<br />3) Win32_NTEventLog (Alias: NTEventLog)<br />4) Win32_BIOS (Alias: bios)<br />5) Win32_DiskDrive (Alias: diskdrive)<br />6) Win32_StartupCommand (Alias: Startup)<br />7) Win32_ComputerSystem (Alias: ComputerSystem)<br />8) Win32_Service (Alias: service)<br />9) Win32_LogicalDisk (Alias: LogicalDisk)<br />10) Win32_LocalProgramGroup)<br />11) Win32_NetworkAdapter (Alias: NIC)<br />12) Win32_Process (Alias: process)<br />13) Win32_BaseBoard (Alias: BaseBoard)<br />14) Win32_SystemEnclosure (Alias: SystemEnclosure)<br />15) Win32_CDROMDrive (Alias: cdrom)<br />16) WIN32_NetworkClient (Alias: netclient)<br />17) Win32_ComputerSystemProduct (Alias: csproduct)<br />18) Win32_VideoController<br />19) Win32_PnPEntity<br />20) Win32_NetworkConnection (Alias: NetUse) <br /><br />I wrote some simple VBScript code for these WQL queries. <a href="http://pastebin.com/667SREHM" target="_blank">Here</a> you can find it. It is very self-explanatory.<br /><br />You can find it on GitHub <a href="https://github.com/waleedassar/vbDetectVirtualBox" target="_blank">here</a>.</div>http://waleedassar.blogspot.com/2015/04/virtualbox-detection-via-wql-queries.htmlnoreply@blogger.com (Walied Assar)2tag:blogger.com,1999:blog-5036198523690297182.post-4862633854817127952Tue, 24 Jun 2014 21:04:00 +00002014-06-24T14:04:38.843-07:00ShareCount As Anti-Debugging Trick<div dir="ltr" style="text-align: left;" trbidi="on">In this post i will share with you an Anti-Debugging trick that is very similar to the "<a href="http://msdn.microsoft.com/en-us/library/windows/desktop/aa366786%28v=vs.85%29.aspx" target="_blank">PAGE_EXECUTE_WRITECOPY</a>" trick mentioned <a href="http://waleedassar.blogspot.com/2012/09/pageexecutewritecopy-as-anti-debug-trick.html" target="_blank"><b>here</b></a>, where we had to flag code section as <a href="http://msdn.microsoft.com/en-us/library/windows/desktop/ms680341%28v=vs.85%29.aspx" target="_blank">writeable</a> such that any memory write to its page(s) would force OS to change the page protection from <i><b>PAGE_EXECUTE_WRITECOPY</b></i> to <i><b>PAGE_EXECUTE_READWRITE</b></i>. But in this case we don't have to make any modifications to the code section's page protection. We will just query the process for its current <a href="http://msdn.microsoft.com/en-us/library/windows/desktop/cc441804%28v=vs.85%29.aspx" target="_blank">working set info</a>. Among the stuff we receive querying the working set of a process are two fields, "<a href="http://msdn.microsoft.com/en-us/library/windows/desktop/ms684902%28v=vs.85%29.aspx" target="_blank">Shared</a>" and "<a href="http://msdn.microsoft.com/en-us/library/windows/desktop/ms684902%28v=vs.85%29.aspx" target="_blank">ShareCount</a>".<br /><br />By default the OS assumes the memory pages of code section (<i><b>Non-writable</b></i> sections) should share physical memory across all process instances. This is true till one process instance commits a memory-write to the shared page. At this point the page becomes no longer shared. Thus, querying the working set of the process and inspecting the "<i><b>Shared</b></i>" and/or "<i><b>ShareCount</b></i>" fields for our Code section pages would reveal the presence&nbsp; of&nbsp; debugger, only if the debugger uses <i><b>INT3</b></i> for breakpoints.<br /><br /><br />To implement the trick, all you have to do is call the "<a href="http://msdn.microsoft.com/en-us/library/windows/desktop/ms684946%28v=vs.85%29.aspx" target="_blank"><i><b>QueryWorkingSet</b></i></a>" or "<a href="http://msdn.microsoft.com/en-us/library/windows/desktop/ms684949%28v=vs.85%29.aspx" target="_blank">QueryWorkingSetEx</a>" functions.<br /><br /><i><b>N.B.</b></i> You can also use the "<i><b>ZwQueryVirtualMemory</b></i>" function with the "<i><b>MemoryInformationClass</b></i>" parameter set to <i><b>MemoryWorkingSetList</b></i> for more portable code.<br /><br />Code from <a href="https://www.dropbox.com/s/7a4231rzn57zkh2/xAntix.cpp" target="_blank">here</a> and demo from <a href="https://www.dropbox.com/s/eopcih9vlgy47dg/xAntix.exe?dl=1" target="_blank">here</a>. Tested on Windows 7.<br /><br />For any suggestions, leave me a comment or drop me a mail <i><b>waliedassar@gmail.com</b></i>.<br /><br />You can also follow me on Twitter <i><b><a href="https://twitter.com/waleedassar" target="_blank">@waleedassar</a></b></i><br /><br /></div>http://waleedassar.blogspot.com/2014/06/sharecount-as-anti-debugging-trick.htmlnoreply@blogger.com (Walied Assar)2tag:blogger.com,1999:blog-5036198523690297182.post-3701970894668405177Sun, 23 Feb 2014 19:49:00 +00002015-12-11T18:21:22.246-08:000x2A425E192A425E19IMAGE_DEBUG_TYPE_CODEVIEWNB10PDB2.0PE TimeDateStampPointerToRawDataTime Date StampTimeDateStampTimeDateStampsPE TimeDateStamp Viewer<div dir="ltr" style="text-align: left;" trbidi="on">In this this post, i will share with you a tiny tool that i wrote to discover all occurrences of <i><b>TimeDateStamps</b></i> in a PE executable. The tool simply traverses the <i><b>PE header </b></i>and specifically the following structures/fields:<br /><br /><i><b>1)</b></i> The "<i><b>TimeDateStamp</b></i>" field of the "<i><b>_IMAGE_FILE_HEADER</b></i>" structure. <br /><br />This is the most notorious field that is always a target for both malware authors and forensic guys.<br /><br /><i><b>N.B.</b></i> Certain versions of <i><b>Delphi </b></i>linkers always emit a fixed <i><b>TimeDateStamp</b></i> of <i><b>0x2A425E19</b></i>, <i><b>Sat Jun 20 01:22:17 1992</b></i>. In this case you should not rely on this field and continue looking in other fields.<br /><br /><i><b>2)</b></i> The "<i><b>TimeDateStamp</b></i>" field of the "<i><b>_IMAGE_EXPORT_DIRECTORY</b></i>" structure.<br /><br />It is usually the same as or very close to the "<i><b>TimeDateStamp</b></i>" field of the the "<i><b>_IMAGE_FILE_HEADER</b></i>" structure".<br /><br /><i><b>N.B.</b></i> Not all linkers fill this field, but Microsoft Visual Studio linkers do fill it for both <i><b>DLL's</b></i> and <i><b>EXE's</b></i>.<br /><br /><i><b>3)</b></i> The "<i><b>TimeDateStamp</b></i>" field of the "<i><b>_IMAGE_IMPORT_DESCRIPTOR</b></i>" structure.<br /><br />Unlike what the name implies, this field is a bit useless if you are trying to determine when the executable was built. It is <i><b>-1</b></i> if the executable/dll is bound (see #8) and zero if not. So, it is not implemented in my tool.<br /><br /><i><b>4)</b></i> The "<i><b>TimeDateStamp</b></i>" field of the "<i><b>_IMAGE_RESOURCE_DIRECTORY</b></i>" structure.<br /><br />Usually <i><b>Microsoft Visual Studio linkers</b></i> don't set it (I have tested with linker versions of <i><b>6.0</b></i>, <b><i>8.0</i></b>, <i><b>9.0</b></i>,&nbsp; and <i><b>10.0</b></i>).<br /><br /><i><b>Borland C</b></i> and <b><i>Delphi</i></b> set this field for the main <i><b>_IMAGE_RESOURCE_DIRECTORY</b></i> and its <i><b>subdirectories</b></i>.<br /><br />Sometimes spoofers forget to forge this field for <i><b>subdirectories.</b></i><br /><br /><i><b>5)</b></i> The "<i><b>TimeDateStamp</b></i>" of the "<i><b>_IMAGE_DEBUG_DIRECTORY</b></i>" structures.<br /><br /><i><b>Microsoft Visual Studio linkers</b></i> emitting debug info. in the final PE always set this field. Spoofers may forge the field in the first "<i><b>_IMAGE_DEBUG_DIRECTORY</b></i>" structure and forget the following ones.<br /><br /><i><b>N.B.</b></i> Debug info as pointed to by Debug Data Directory is an array of&nbsp; "<i><b>_IMAGE_DEBUG_DIRECTORY</b></i>" structures, each representing debug info of different type e.g. <i><b>COFF</b></i>, <i><b>CodeView</b></i>, etc.<br /><br /><i><b>6)</b></i> If&nbsp; "<i><b>_IMAGE_DEBUG_DIRECTORY"</b></i> has the "<i><b>Type</b></i>" field set to <i><b>0x2</b></i> (<i><b>IMAGE_DEBUG_TYPE_CODEVIEW</b></i>), then by following the "<i><b>PointerToRawData</b></i>" field we can find another occurrence of <i><b>TimeDateStamp</b></i> ( only if the <i><b>PDB format</b></i> is <i><b>PDB 2.0</b></i> i.e when "<i><b>Signature</b></i>" field is set to "<i><b>NB10</b></i>" )<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-Hc7OUuAhSxw/UwpPoCUvieI/AAAAAAAAB6k/IFyoStcAUY8/s1600/NB10.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="182" src="http://2.bp.blogspot.com/-Hc7OUuAhSxw/UwpPoCUvieI/AAAAAAAAB6k/IFyoStcAUY8/s1600/NB10.png" width="400" /></a></div><br /><br /><b>7)</b> The "<i><b>TimeDateStamp</b></i>" field of the "<i><b>_IMAGE_LOAD_CONFIG_DIRECTORY</b></i>" structure.<br /><br />I have not seen it being used before. However, it is&nbsp; implemented in the tool.<br /><br /><i><b>8)</b></i> The "<i><b>TimeDateStamp</b></i>" field of the "<i><b>_IMAGE_BOUND_IMPORT_DESCRIPTOR</b></i>" structures.<br /><br />It is the <i><b>TimeDateStamp</b></i> of the <i><b>DLL</b></i> that the executable is bound to. We can't use this field to know when the executable was build, but we can use it to determine on which Windows version/Service pack the file was built/bound. It is not implemented in the tool.<br /><br />The tool has a very simple command line. See below.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-uqby_1HkKCI/UwThd_QTPGI/AAAAAAAAB6U/Q9lDTgo8wrw/s1600/TimeData.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="161" src="http://2.bp.blogspot.com/-uqby_1HkKCI/UwThd_QTPGI/AAAAAAAAB6U/Q9lDTgo8wrw/s1600/TimeData.png" width="320" /></a></div><br />You download the tool from <a href="https://www.dropbox.com/s/xld3ha5rdst1174/TimeDateStamp.exe" target="_blank">here</a>. For any bugs or suggestions, please don't hesitate to leave me a comment or contant me <a href="https://twitter.com/waleedassar" target="_blank">@waleedassar</a>.<br /><br />GitHub Project <a href="https://github.com/waleedassar/TimeDateStamp/" target="_blank">here</a>.</div>http://waleedassar.blogspot.com/2014/02/pe-timedatestamp-viewer.htmlnoreply@blogger.com (Walied Assar)1tag:blogger.com,1999:blog-5036198523690297182.post-5143274187804741338Tue, 12 Feb 2013 19:29:00 +00002014-03-15T10:31:49.594-07:00NtSetInformationProcessProcessIoPriorityProcessSelfDeleteSeIncreaseBasePriorityPrivilegeSetTimerResolutionLinkKernel Bug #1 ProcessIoPriority<div dir="ltr" style="text-align: left;" trbidi="on">In this post i will show you the second kernel bug that i found in the<i><b>&nbsp; Kernel</b></i> of <i><b>Windows 7 SP1 (64-bit)</b></i>. This one is in the "<a href="http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/NT%20Objects/Process/NtSetInformationProcess.html" target="_blank"><i><b>nt!NtSetInformationProcess</b></i></a>" function.<br /><br /><i><b>Description:</b></i><br />With the "<i><b>ProcessInformationClass</b></i>" parameter set to <i><b>ProcessIoPriority 0x21</b></i>, passing certain <i><b>signed</b></i> values <i><b>e.g.</b></i>&nbsp; <i><b>0xFFFFFFFF</b></i> or<i><b> 0x8000F129</b></i> in the variable pointed to by the "<i><b>ProcessInformation</b></i>" parameter to the <i><b>ntdll "<a href="http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/NT%20Objects/Process/NtSetInformationProcess.html" target="_blank">ZwSetInformationProcess</a>"</b></i> function can be abused to arbitrarily set certain bit flags of the corresponding "<i><b>_EPROCESS</b></i>" structure<i><b> e.g.</b></i> <i><b><i><b>DefaultIoPriority: Pos 27, ProcessSelfDelete : Pos 30</b></i>, or SetTimerResolutionLink: Pos 31.</b></i><br /><br /><i><b>Bug Type</b></i>:<br />This is due to a <i><b>signedness</b></i> error in the <i><b>"</b><b>nt!NtSetInformationProcess"</b></i> function.<br /><br /><br /><i><b>32-Bit kernel</b></i>:<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-LD6ltcERaMc/URMHXibBiZI/AAAAAAAAByc/ETsvOt2gdWU/s1600/Kernel_32_bit_bug.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://3.bp.blogspot.com/-LD6ltcERaMc/URMHXibBiZI/AAAAAAAAByc/ETsvOt2gdWU/s400/Kernel_32_bit_bug.png" height="162" width="400" /></a></div><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-ramrgpH3j7k/URMHdhfS_-I/AAAAAAAAByk/tWAR77YspVU/s1600/kernel32_bug_loopx.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://1.bp.blogspot.com/-ramrgpH3j7k/URMHdhfS_-I/AAAAAAAAByk/tWAR77YspVU/s400/kernel32_bug_loopx.png" height="111" width="400" /></a></div><br /><i><b>64-bit kernel:</b></i><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-zPkWItI8y-M/URMKEeda15I/AAAAAAAABzU/Pm3YlhPpaMU/s1600/kernel64_bug.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://2.bp.blogspot.com/-zPkWItI8y-M/URMKEeda15I/AAAAAAAABzU/Pm3YlhPpaMU/s400/kernel64_bug.png" height="205" width="400" /></a></div><br /><i><b>&nbsp;Impact:</b></i><br /><i><b><i><b>1)</b></i> </b></i>The signed value leads to bypassing the check for the "<i><b>SeIncreaseBasePriorityPrivile</b></i><wbr></wbr><i><b>ge</b></i>" privilege that is required to set the process's <i><b>IO priority</b></i> to <i><b>HIGH</b></i>.<i><b><br /></b></i><br /><br /><i><b><i><b>2)</b></i> </b></i>The signed value leads to bypassing the check for disallowed values for the process's <i><b>IO priority e.g.</b></i> the bug can be abused to set the process's<i><b> IO priority </b></i>to<i><b> CRITICAL.</b></i><br /><br /><i><b>3) </b></i>Setting the "<i><b>ProcessSelfDelete</b></i>" flag, which makes the target process non-killable by conventional methods.<br /><br /><i><b>4) </b></i>Setting the "<i><b>SetTimerResolutionLink</b></i>" flag, which causes a <i><b>BSOD</b></i> (<i><b>Bug check code of 0x3B</b></i>)&nbsp; if we terminate the process due to a null pointer dereference bug.<i><b> </b></i><br /><br /><i><b>Poc:</b></i><br /><br /><i><b><a href="https://www.dropbox.com/s/t6g5v8defb13itx/KillMe.exe" target="_blank">Non-Killable Process</a></b></i><br /><br /><a href="https://www.dropbox.com/s/k8g9dcr5at9kemu/NtSetInformationProcess_BSOD.exe" target="_blank"><i><b>BSOD </b></i></a><br /><br /><i><b>Code: </b></i><br /><a href="http://pastebin.com/QejGQXib" target="_blank">http://pastebin.com/QejGQXib</a><br /><br /><i><b>Status</b></i>:<br />Reported to the vendor.<br /><br />Any comments or ideas are very welcome. You can also follow me on Twitter <a href="http://www.twitter.com/waleedassar" target="_blank">@waleedassar</a></div>http://waleedassar.blogspot.com/2013/02/kernel-bug-1-processiopriority.htmlnoreply@blogger.com (Walied Assar)8tag:blogger.com,1999:blog-5036198523690297182.post-4714896335605053698Tue, 12 Feb 2013 19:24:00 +00002014-03-15T10:36:17.869-07:00kernelbugNeedsWorkingSetAgingNtSetInformationThreadRundownFailSeIncreaseBasePriorityPrivilegeThreadIoPriorityThreadPagePrioritywin7 kernelZwSetInformationThreadKernel Bug #0 ThreadIoPriority<div dir="ltr" style="text-align: left;" trbidi="on">This post is the first in a series of posts that will discuss several kernel bugs that i find in <i><b>Windows Kernel</b></i>. This post is about a bug found in the kernel of <i><b>Windows 7 SP1 (64-bit)</b></i>.<br /><br /><i><b>Description:</b></i><br />With the "<i><b>ThreadInformationClass</b></i>" parameter set to <i><b>ThreadIoPriority 0x16</b></i>, passing certain <i><b>signed</b></i> values <i><b>e.g.</b></i>&nbsp; <i><b>0xFF3FFF3C</b></i> or&nbsp; <i><b>0xFF3FFFFC</b></i> in the variable pointed to by the "<i><b>ThreadInformation</b></i>" parameter to the <i><b>ntdll "<a href="http://msdn.microsoft.com/en-us/library/windows/hardware/ff567101%28v=vs.85%29.aspx" target="_blank">ZwSetInformationThread</a>"</b></i> function can be abused to arbitrarily set certain bit flags of the corresponding "<i><b>_ETHREAD</b></i>" structure <i><b>e.g.</b></i> <i><b>ThreadIoPriority:3, ThreadPagePriority:3, RundownFail:1, or NeedsWorkingSetAging:1</b></i>.<br /><br /><i><b>Bug Type</b></i>:<br />This is due to a <i><b>signedness</b></i> error in the <i><b>"</b><b>nt!NtSetInformationThread"</b></i> function.<br /><br /><i><b>32-Bit kernel</b></i>:<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-t60PTgl_dPY/UMsMZRc_XTI/AAAAAAAABgI/mdisGYHLM5M/s1600/fixhere.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://3.bp.blogspot.com/-t60PTgl_dPY/UMsMZRc_XTI/AAAAAAAABgI/mdisGYHLM5M/s400/fixhere.png" height="131" width="400" /></a></div><i><b>64-bit kernel:</b></i><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-93Phrtp3F_4/UQCXwJjEMiI/AAAAAAAABqI/KSiP0LZzsYI/s1600/64_bit_IO_PRIOIR_BUG.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://1.bp.blogspot.com/-93Phrtp3F_4/UQCXwJjEMiI/AAAAAAAABqI/KSiP0LZzsYI/s400/64_bit_IO_PRIOIR_BUG.png" height="218" width="400" /></a></div><br /><br /><i><b>Impact</b></i>:<br /><i><b>1)</b></i> The signed value leads to bypassing the check for the "<i><b>SeIncreaseBasePriorityPrivile<wbr></wbr>ge</b></i>" privilege that is required to set the thread's IO priority to <i><b>HIGH</b></i>.<br /><br /><i><b>2)</b></i> An unprivileged thread can use certain calculated signed values to escalate its<i><b> IO priority and memory priority</b></i> to maximum values <i><b>e.g.</b></i> <i><b>Raise IO</b></i> priority to <i><b>CRITICAL</b></i> or Page priority to <i><b>7</b></i>.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-Abmayd41d28/UMsJB79GZjI/AAAAAAAABfc/ha5U-Za5qcs/s1600/POC__.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://1.bp.blogspot.com/-Abmayd41d28/UMsJB79GZjI/AAAAAAAABfc/ha5U-Za5qcs/s400/POC__.png" height="400" width="328" /></a></div><br /><i><b>3)</b></i> Also, certain bit flags of the corresponding "<i><b>_ETHREAD</b></i>" structure can be set <i><b>e.g.</b></i> <i><b>RundownFail</b></i> and <i><b>NeedsWorkingSetAging</b></i>. <br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-pNveK8JGsOI/UQCT2oiOqXI/AAAAAAAABpc/0WhWdTFiznA/s1600/Irr_Flags.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://1.bp.blogspot.com/-pNveK8JGsOI/UQCT2oiOqXI/AAAAAAAABpc/0WhWdTFiznA/s400/Irr_Flags.png" height="218" width="400" /></a></div><br /><br /><i><b>POC:</b></i><br /><a href="https://www.dropbox.com/s/x7zzx5r62h0k4uz/PriorityCheckBypass.exe"><i><b>https://www.dropbox.com/s/x7zzx5r62h0k4uz/PriorityCheckBypass.exe</b></i></a><br /><br /><i><b>Code:</b></i><br /><a href="http://pastebin.com/TanNzkn9" target="_blank">http://pastebin.com/TanNzkn9</a><br /><br /><i><b>Status</b></i>:<br />Reported to the vendor and rejected for not being a security issue.<br /><br />Any comments or ideas are very welcome. You can also follow me on Twitter <a href="http://www.twitter.com/waleedassar" target="_blank">@waleedassar</a></div>http://waleedassar.blogspot.com/2013/02/kernel-bug-0-threadiopriority.htmlnoreply@blogger.com (Walied Assar)0tag:blogger.com,1999:blog-5036198523690297182.post-3166865134261600Tue, 29 Jan 2013 07:17:00 +00002013-01-29T02:04:02.124-08:00DbgPromptDebugPromptINT 2Dwow64 anti-debugWow64 antidebugWow64-Specific Anti-Debug Trick<div dir="ltr" style="text-align: left;" trbidi="on">In this post i will show you an anti-debug trick that i have recently found. The trick is specific to<i><b> Wow64</b></i> processes. It rely on the fact that <i><b>32-bit</b></i> debuggers <i><b>e.g.</b></i> <i><b>OllyDbg, IDA Pro Debugger</b></i>, and <i><b>WinDbg_x86</b></i> don't receive debug events for<b> </b>certain exceptions originating from <i><b>64-bit</b></i> code. One example of these exceptions is <i><b>EXCEPTION_BREAKPOINT</b></i> <b><i>0x80000003</i></b>.<br /><br /><div class="separator" style="clear: both; text-align: left;"><i><b>N.B.</b></i> In <i><b>a Wow64</b></i> process in <i><b>Windows 7</b></i>, <i><b>its 32-bit</b></i> code is executing in <i><b>CS=0x23</b></i>, while <i><b>its 64-bit</b></i> code is executing in <i><b>CS=0x33</b></i>.</div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: left;">Let's take for example the <i><b>ntdll</b></i> "<i><b>DbgPrompt</b></i>" function in <i><b>Windows 7 64-bit</b></i>.&nbsp; I chose <i><b>DbgPrompt</b></i> for two reasons:</div><div class="separator" style="clear: both; text-align: left;">1) Calls to it end up with executing the <i><b>INT 0x2D</b></i> instruction, which raises an <i><b>EXCEPTION_BREAKPOINT</b></i>.</div><div class="separator" style="clear: both; text-align: left;">2) The <i><b>32-bit</b></i> version of it (in <i><b>32-bit</b></i> version of <i><b>ntdll.dll</b></i>) calls the <i><b>64-bit</b></i> version of it (in <i><b>64-bit</b></i> version of <i><b>ntdll.dll</b></i>).</div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: left;"><i><b>N.B.</b></i> The <i><b>ntdll</b></i> "<i><b>DbgPrompt</b></i>" function wraps up calls to the non-exported "<i><b>DebugPrompt</b></i>" function.</div><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-Q9s5s1VHuOo/UQdxSPIprDI/AAAAAAAABw0/fMz29tC1-yo/s1600/DebugPrompt.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="206" src="http://2.bp.blogspot.com/-Q9s5s1VHuOo/UQdxSPIprDI/AAAAAAAABw0/fMz29tC1-yo/s400/DebugPrompt.png" width="400" /></a></div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: left;">So, now if we call the "<i><b>DbgPrompt</b></i>" function from within our <b><i>32-bit</i></b> code, we know that the call will end up with an <i><b>EXCEPTION_BREAKPOINT </b></i>raised from <b><i>64-bit</i></b> mode.</div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: left;">The interesting thing here is that if you call the function without a debugger, the exception will be raised and its exception handler will be called. One the other hand, if a debugger is present, no exceptions are raised and the instruction following <i><b>INT 2D </b></i>will be executed.</div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: left;">Given the above knowledge, i wrote a simple demo for that <i><b>Wow64-specific anti-debug</b></i> trick. You can download the demo from <a href="http://code.google.com/p/ollytlscatch/downloads/detail?name=Wow64AntiDbg.exe" target="_blank">here</a> and its source code from <a href="http://pastebin.com/kMrGisCj" target="_blank">here</a>.</div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-GtIiX4evzCQ/UQd28VQQjBI/AAAAAAAABxs/ALocZRwPGIg/s1600/Src.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="201" src="http://4.bp.blogspot.com/-GtIiX4evzCQ/UQd28VQQjBI/AAAAAAAABxs/ALocZRwPGIg/s400/Src.png" width="400" /></a></div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-fAjG3wI6fOE/UQd2nzi9HKI/AAAAAAAABxk/7CxQIZoZGTk/s1600/OllySpec.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="172" src="http://4.bp.blogspot.com/-fAjG3wI6fOE/UQd2nzi9HKI/AAAAAAAABxk/7CxQIZoZGTk/s400/OllySpec.png" width="400" /></a></div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: left;">To bypass this trick, you have to use a <i><b>64-bit</b></i> debugger where the exception will be raised and seen by the debugger.</div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: left;">Any comments or ideas are very welcome.</div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: left;">You can follow me on Twitter <i><b><a href="http://www.twitter.com/waleedassar" target="_blank">@waleedassar</a></b></i> </div></div>http://waleedassar.blogspot.com/2013/01/wow64-specific-anti-debug-trick.htmlnoreply@blogger.com (Walied Assar)6tag:blogger.com,1999:blog-5036198523690297182.post-103571303455924456Sat, 26 Jan 2013 21:38:00 +00002013-10-07T20:09:13.314-07:00ProcessInitWow64CommittedStackSizeWow64ExecuteFlagsWow64GetWow64ImageOptionsWow64LogWow64LogInitializeWow64LogMessageArgListWow64LogSystemServiceWow64LogTerminateWow64MaximumStackSizeWow64Log<div dir="ltr" style="text-align: left;" trbidi="on"><div class="separator" style="clear: both; text-align: center;"></div>In this post i will discuss an interesting functionality that i discovered while reversing <i><b>Wow64.dll</b></i> and specifically the "<i><b>wow64!ProcessInit</b></i>" function. Now let's take the function into assembly and see how it looks like.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-a3wlhW-As-Y/UQM5wfF2pVI/AAAAAAAABq0/FIqkzNaIELs/s1600/Wow64_NtOpenKey.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="128" src="http://3.bp.blogspot.com/-a3wlhW-As-Y/UQM5wfF2pVI/AAAAAAAABq0/FIqkzNaIELs/s400/Wow64_NtOpenKey.png" width="400" /></a></div><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-uJmJ1vmD37I/UQM9hSmQubI/AAAAAAAABrs/b3HGI9sZllk/s1600/ObjectAttributes.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="251" src="http://4.bp.blogspot.com/-uJmJ1vmD37I/UQM9hSmQubI/AAAAAAAABrs/b3HGI9sZllk/s400/ObjectAttributes.png" width="400" /></a></div><br />The first thing the function does is open a registry key by calling the "<i><b><a href="http://msdn.microsoft.com/en-us/library/windows/hardware/ff567014%28v=vs.85%29.aspx" target="_blank">ZwOpenKey</a></b></i>" function with the "<i><b>ObjectAttributes</b></i>" parameter having the "<i><b>ObjectName</b></i>" member set to "<i><b>REGISTRY\MACHINE\SOFTWARE\Microsoft\WOW64</b></i>". So our first conclusion here is that the function tries to open the registry key "<i><b>HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Wow64</b></i>" to retrieve specific information that may affect the <i><b>Wow64</b></i> process throughout its lifetime. Usually, the key does not exist, at least on my machine (<i><b>Windows 7 SP1 64-bit</b></i>).<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-I_rnKn4uaC4/UQM8vfSvniI/AAAAAAAABrg/DXxw26rEyuM/s1600/Wow64ExecuteFLags.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="45" src="http://1.bp.blogspot.com/-I_rnKn4uaC4/UQM8vfSvniI/AAAAAAAABrg/DXxw26rEyuM/s400/Wow64ExecuteFLags.png" width="400" /></a></div><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-0ICFczF_3nE/UQM-N7uHCwI/AAAAAAAABsU/h5uWg844NNw/s1600/Wow64ExecuteFLags.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="85" src="http://3.bp.blogspot.com/-0ICFczF_3nE/UQM-N7uHCwI/AAAAAAAABsU/h5uWg844NNw/s400/Wow64ExecuteFLags.png" width="400" /></a></div><br />Next, if the key was successfully opened, the "<i><b>Wow64GetWow64ImageOption</b></i>" function is then called with the <i><b>first</b></i> parameter set to the opened key handle, the <i><b>second</b></i> parameter pointing at the wide string "<i><b>Wow64ExecuteFlags</b></i>", the <i><b>third</b></i> parameter set to <i><b>0x4</b></i> (<i><b>REG_DWORD</b></i>), the <i><b>fourth</b></i> parameter pointing at the variable that will receive the returned value, and the <i><b>fifth</b></i> parameter set to <i><b>0x4</b></i> (output size).<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-7195rz9iDU0/UQNG5s4RTWI/AAAAAAAABtE/IenJi1X1V-c/s1600/Wow64GetImageOption.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="248" src="http://4.bp.blogspot.com/-7195rz9iDU0/UQNG5s4RTWI/AAAAAAAABtE/IenJi1X1V-c/s400/Wow64GetImageOption.png" width="400" /></a></div><br />The "<i><b>Wow64GetWow64ImageOption"</b></i> function opens the <i><b>IFEO</b></i> registry key and queries the registry value whose name is the string pointed to by the <i><b>second</b></i> parameter and on error, it queries the same registry value under the registry key whose handle was given in the <i><b>first</b></i> parameter.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-GxunEOq3aLY/UQRFWOLeNWI/AAAAAAAABt0/l3pQCHVwJZU/s1600/ffffffffffff.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="81" src="http://3.bp.blogspot.com/-GxunEOq3aLY/UQRFWOLeNWI/AAAAAAAABt0/l3pQCHVwJZU/s400/ffffffffffff.png" width="400" /></a></div><br />The extracted flags are then used to initialize three <i><b>Wow64</b></i> global variables, <i><b>Wow64!Wow64CommittedStackSize, Wow64!Wow64MaximumStackSize, </b></i>and <i><b>Wow64InfoPtr.</b></i><br /><i><b><br /></b></i><i><b><br /></b></i>Whether the registry key was successfully opened or not and whether the "<i><b>Wow64ExecuteFlags</b></i>" value was successfully extracted or not, the "<i><b>ProcessInit</b></i>" function then directly jumps to the code you see in the image below.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-CSjDGps_bIU/UQRGcLmXvZI/AAAAAAAABuk/vu5vLCWcHv4/s1600/LdrLoadDll.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="108" src="http://2.bp.blogspot.com/-CSjDGps_bIU/UQRGcLmXvZI/AAAAAAAABuk/vu5vLCWcHv4/s400/LdrLoadDll.png" width="400" /></a></div><br /><br />As you can see it is trying to load a library called "<i><b>Wow64Log.dll</b></i>" residing in the "<i><b>System32</b></i>" directory by calling the ntdll "<i><b>LdrLoadDll</b></i>" function. Usually, this module does not exist.<br /><br /><i><b>N.B.</b></i> Since this code is <i><b>x64</b></i>, the library <i><b>Wow64Log.dll </b></i>must be<i><b> 64-bit.</b></i><br /><br />Then comes some code that tries to resolve certain function addresses from <i><b>Wow64Log.Dll </b></i>by calling the "<i><b>LdrGetProcedureAddress</b></i>" function.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-g6wn7NI8vyU/UQRIukQtrNI/AAAAAAAABvU/bRaDSwX5S0M/s1600/Resolution.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="212" src="http://4.bp.blogspot.com/-g6wn7NI8vyU/UQRIukQtrNI/AAAAAAAABvU/bRaDSwX5S0M/s400/Resolution.png" width="400" /></a></div><i><b><br /></b></i><i><b>N.B. </b></i>The<i><b> kernel32 "GetProcAddress" </b></i>function is just a wrap up of the<i><b> ntdll "LdrGetProcedureAddress" </b></i>function<i><b>.</b></i><br /><i><b><br /></b></i>The code we see in the image above tries to resolve addresses of the<i><b> "Wow64LogInitialize", "Wow64LogSystemService", "Wow64LogMessageArgList", and "Wow64LogTerminate"&nbsp; </b></i>function<i><b>s </b></i>from the <i><b>Wow64Log.dll.&nbsp; </b></i>If any of the functions' addresses could not be resolved, the function fails and <i><b>Wow64Log.dll i</b></i>s unloaded from the address space by calling the <i><b>ntdll "LdrUnloadDll"</b></i> function.<br /><br />Assuming <i><b>Wow64Log.dll</b></i> was found in <b><i>NtSystemRoot\\System32</i></b> and the above mentioned functions were found to be exported from it, we will have the global <i><b>wow64.dll </b></i>function pointers, "<i><b>pfnWow64LogInitialize</b></i>", "<i><b>pfnWow64LogSystemService</b></i>", "<i><b>pfnWow64LogMessageArgList</b></i>", and "<i><b>pfnWow64LogTerminate</b></i>" holding the address of the "<i><b>Wow64LogInitialize</b></i>", "<i><b>Wow64LogSystemService</b></i>", "<i><b>Wow64LogMessageArgList</b></i>", and "<i><b>Wow64LogTerminate</b></i>" functions respectively. The "<i><b>Wow64LogInitialize"</b></i> function will then be immediately called.<br /><i><b><br /></b></i>The "<i><b>Wow64LogSystemService</b></i>" function will be called every time the "<i><b>Wow64!Wow64SystemServiceEx</b></i>" function is called <i><b>i.e.</b></i> called with every system call being issued. This can be used for system call logging.<br /><i><b><br /></b></i>The "<i><b>Wow64LogMessageArgList</b></i>" function is called by the "<i><b>Wow64!Wow64LogPrint</b></i>" function to log certain events, more likely errors.<br /><i><b><br /></b></i>The "<i><b>Wow64LogTerminate</b></i>" function is called upon process termination by the "<i><b>Wow64!whNtTerminateProcess</b></i>" function.<br /><i><b><br /></b></i><i><b><br /></b></i><i><b>The above mentioned topic can be used as a simple method for injecting 64-bit Dll's into Wow64 (32-Bit) processes by dropping Wow64Log.dll into system32.</b></i><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-iNogBSHOg5o/UQRN32OVQCI/AAAAAAAABwE/oXIm_np_RJ4/s1600/BBglBH8CQAAV6yh.png+large.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="205" src="http://2.bp.blogspot.com/-iNogBSHOg5o/UQRN32OVQCI/AAAAAAAABwE/oXIm_np_RJ4/s400/BBglBH8CQAAV6yh.png+large.png" width="400" /></a></div><i><b><br /></b></i><i><b>Here is a simple <a href="http://goo.gl/yU8Ea" target="_blank">Wow64Log.dll</a> that i wrote as a demo.</b></i><br /><i><b><br /></b></i><i><b><br /></b></i><i><b>You can follow me on Twitter <a href="http://www.twitter.com/waleedassar" target="_blank">@waleedassar</a></b></i></div>http://waleedassar.blogspot.com/2013/01/wow64logdll.htmlnoreply@blogger.com (Walied Assar)0tag:blogger.com,1999:blog-5036198523690297182.post-876277777875726076Fri, 18 Jan 2013 00:26:00 +00002013-01-17T22:48:35.173-08:00ProcessThreadStackAllocationrandomnessRtlCreateUserStackStackRandomizationDisabledVirtualAllocVirtualAllocExA Real Random VirtualAlloc<div dir="ltr" style="text-align: left;" trbidi="on">In this post i will discuss one disadvantage of using the "<a href="http://msdn.microsoft.com/en-us/library/windows/desktop/aa366887%28v=vs.85%29.aspx" target="_blank">VirtualAlloc</a>" function to allocate memory and also suggest a trick to play around this disadvantage.<br /><br />If you ever used the "<i><b>VirtualAlloc</b></i>" function&nbsp; to allocate memory, you must have noticed that addresses returned are almost the same over instances of the same process. This is due to the "<i><b>ZwAllocateVirtualMemory</b></i>" function doing nothing to ensure the randomness of the base address returned, at least in <i><b>Windows 7</b></i>.<br /><br /><i><b>N.B.</b></i> <a href="http://msdn.microsoft.com/en-us/library/windows/desktop/aa366887%28v=vs.85%29.aspx" target="_blank">VirtualAlloc</a> is just a wrap up of the "<a href="http://msdn.microsoft.com/en-us/library/windows/desktop/aa366890%28v=vs.85%29.aspx" target="_blank">VirtualAllocEx</a>" function which is a wrap up of the ntdll "<a href="http://msdn.microsoft.com/en-us/library/windows/hardware/ff566416%28v=vs.85%29.aspx" target="_blank">ZwAllocateVirtualMemory</a>" function.<br /><br />To test that fact, we will create a small application that does almost nothing but calling the "<i><b>ZwAllocateVirtualMemory</b></i>" function and printing the base address at which memory has been allocated.<br />The source code looks like below.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-hjIIwRQA-dQ/UPiEgiWEHSI/AAAAAAAABkk/sdvNk3R6Ix4/s1600/NoRan.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="163" src="http://1.bp.blogspot.com/-hjIIwRQA-dQ/UPiEgiWEHSI/AAAAAAAABkk/sdvNk3R6Ix4/s400/NoRan.png" width="400" /></a></div><br /><div class="separator" style="clear: both; text-align: center;"></div><i><b>N.B.</b></i> Even though the <i><b>ASLR </b></i>has nothing to do with randomizing the base address of memory returned by ZwAllocateVirtualMemory, we just set the "<b>IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE</b>" bit field for testing purposes.<br /><br />Compile the above source code and run the application several times. See image below.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-HlPJtqMFPSo/UPiHopk3q4I/AAAAAAAABl4/jz4KxUZFabA/s1600/NoRanAction.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="201" src="http://3.bp.blogspot.com/-HlPJtqMFPSo/UPiHopk3q4I/AAAAAAAABl4/jz4KxUZFabA/s400/NoRanAction.png" width="400" /></a></div><br /><div class="separator" style="clear: both; text-align: center;"></div>As you can see in the image above, the base address is the same (<i><b>0x30000</b></i>) across all instances of the process and this poses a security issue.<br /><br />It seems that Microsoft has taken care of this issue while allocating stack memory for threads. Now in later versions of Windows e.g. <i><b>Windows 7</b></i>, the "<i><b>RtlCreateUserStack</b></i>" function which is responsible for reserving and committing the memory for threads is calling the "<i><b>NtSetInformationProcess</b></i>" function with a new information class to <i><b>reserve</b></i> the stack memory at a random address. The new process information class is <i><b>ProcessThreadStackAllocation 0x29</b></i>.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-l1oRa_D_o0Q/UPiJOfBBpyI/AAAAAAAABmk/CzqmTeAUbZ0/s1600/RtlCreateUserStack.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="218" src="http://2.bp.blogspot.com/-l1oRa_D_o0Q/UPiJOfBBpyI/AAAAAAAABmk/CzqmTeAUbZ0/s400/RtlCreateUserStack.png" width="400" /></a></div><br />Now let's see how this new information class reserves memory.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-o_Kbzz0--B0/UPiMupDw1cI/AAAAAAAABnQ/CqBaVrN3Atk/s1600/StackRandomizationDisabled.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="218" src="http://4.bp.blogspot.com/-o_Kbzz0--B0/UPiMupDw1cI/AAAAAAAABnQ/CqBaVrN3Atk/s400/StackRandomizationDisabled.png" width="400" /></a></div><br />Looking at the disassembly we can see that the function checks the "<i><b>StackRandomizationDisabled</b></i>" flag of the "<i><b>_EPROCESS</b></i>" structure. We can also see the function trying to randomize some variable by using the "<i><b>SystemTime</b></i>" field of the "<i><b>SharedUserData</b></i>" page, and the "<i><b>RDTSC</b></i>" instruction.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-NqukGLkFS2Q/UPiN43aISFI/AAAAAAAABnc/Wy3VgvZJcSo/s1600/Action.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="218" src="http://4.bp.blogspot.com/-NqukGLkFS2Q/UPiN43aISFI/AAAAAAAABnc/Wy3VgvZJcSo/s400/Action.png" width="400" /></a></div><br />The function then calls the "<i><b>MiScanUserAddressSpace</b></i>" and "<i><b>ZwAllocateVirtualMemory</b></i>" functions to reserve memory at a random base address.<br /><br /><br />Now let's try to test the "<i><b>ZwSetInformationProcess</b></i>" function and see if addresses returned are really random. So, we compile the code in the image below and see.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-6ZkY23evMA0/UPiVGn6cmsI/AAAAAAAABoo/hthJKnHNKfY/s1600/TestOkay.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="217" src="http://1.bp.blogspot.com/-6ZkY23evMA0/UPiVGn6cmsI/AAAAAAAABoo/hthJKnHNKfY/s400/TestOkay.png" width="400" /></a></div><b>N.B. </b>Setting the "<i><b>IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE"</b></i> bit field is <b>necessary</b> for the "<i><b>StackRandomizationDisabled</b></i>" bit flag of the "<i><b>_EPROCESS"</b></i> structure to be unset.<br /><br /><br /><div class="separator" style="clear: both; text-align: center;"></div><div class="separator" style="clear: both; text-align: center;"></div><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-1kISQp7lp_s/UPiVMEFGcTI/AAAAAAAABow/6cS-yh7X_dw/s1600/Wow.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="201" src="http://4.bp.blogspot.com/-1kISQp7lp_s/UPiVMEFGcTI/AAAAAAAABow/6cS-yh7X_dw/s400/Wow.png" width="400" /></a></div><br />As you can see in the two images above, in each time we invoked the application we got a random address for the memory allocated.<br /><br /><br /><i><b>Conclusion:</b></i><br />using the "<i><b>ProcessThreadStackAllocation</b></i>" class of the "<i><b>ZwSetInformationProcess</b></i>" function, we can guarantee a random address for memory we allocate which can be considered a security enhancement.<br /><br />Code and examples for this post can be found <a href="http://code.google.com/p/ollytlscatch/downloads/detail?name=Random.rar" target="_blank">here</a><a href="http://www.blogger.com/blogger.g?blogID=5036198523690297182" target="_blank"></a>.<br /><br />You can follow me on Twitter <a href="https://twitter.com/waleedassar" target="_blank">@waleedassar</a></div>http://waleedassar.blogspot.com/2013/01/a-real-random-virtualalloc.htmlnoreply@blogger.com (Walied Assar)9tag:blogger.com,1999:blog-5036198523690297182.post-1675588226318200235Mon, 14 Jan 2013 12:48:00 +00002015-12-11T20:33:05.655-08:00whNtSetInformationProcesswow64wow64.dllCall64, Bypassing Wow64 Emulation Layer<div dir="ltr" style="text-align: left;" trbidi="on">In this post i will discuss a piece of code that i wrote to ease the process of issuing<i><b> 64-bit system calls</b></i> without passing through the <i><b>Wow64</b></i> emulation layer implemented in <i><b>Wow64cpu.dll</b></i>, <i><b>Wow64.dll</b></i>, and <i><b>Wow64win.dll</b></i>.<br /><br /><br />I implemented it in a function called "<i><b>Call64()</b></i>". Since some arguments in <i><b>64-bit</b></i> system calls are <i><b>64 bits</b></i> long, the "<i><b>Call64()</b></i>" function expects its arguments in the form of pointers to <i><b>LARGE_INTEGER </b></i>structures. Also, the return value is in the form of a pointer to a <i><b>LARGE_INTEGER </b></i>structure.<br /><br /><br />Let's take the implementation of this function step by step.<br /><br />The first argument <i><b>Call64</b></i> takes is a pointer to a <i><b>LARGE_INTEGER</b></i> structure which will receive the return value (<i>RAX</i>) of this system call. It is the caller's responsibility to allocate this structure. Also, it is the caller's responsibility to <i><b>type-cast</b></i> the value returned in it.<br /><br />The second argument the function takes is the system call number or ordinal <i><b>e.g.</b></i> The "<i><b>ZwWaitForSingleObject</b></i>" function in <i><b>Windows 7</b></i> has a system call number of <i><b>0x1</b></i>.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-znoK2f0q8wc/UPFcdZPPgOI/AAAAAAAABho/qGx_WV8iGQU/s1600/ZwWaitForSingleObject.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="40" src="http://1.bp.blogspot.com/-znoK2f0q8wc/UPFcdZPPgOI/AAAAAAAABho/qGx_WV8iGQU/s400/ZwWaitForSingleObject.png" width="400" /></a></div><br />This argument is later used to formulate the <i><b>shellcode </b></i>used to issue the <i><b>64-bit</b></i> system call.<br /><br /><br />Since this function is supposed to make<i><b> 64-bit</b></i> system calls with different number of arguments, the function is implemented as <i><b>variadic (A function with </b><b>an indefinite number of arguments</b></i>) with the third argument being the number of arguments the system call expects. The next arguments are all in the form of<i><b> pointers to</b></i> <i><b>LARGE_INTEGER </b></i>structures.<br /><br />The function prototype is like below:<br /><div class="separator" style="clear: both; text-align: center;"></div><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-TShIxvEr-JA/UPFZp0iC3ZI/AAAAAAAABg8/s7mJxAIsppQ/s1600/Prototype.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="60" src="http://1.bp.blogspot.com/-TShIxvEr-JA/UPFZp0iC3ZI/AAAAAAAABg8/s7mJxAIsppQ/s400/Prototype.png" width="400" /></a></div><br />After we have looked at how the arguments look like, let's see how the function works.<br /><br />First, given the number of arguments, it calculated the stack space needed and commits it using the "<i><b>_alloca</b></i>" function. The newly-allocated stack space is initialized to <i><b>zero</b></i>. <br /><br />The function takes the first<i><b> four </b></i>arguments and stores them in <i><b>RCX, RDX, R8, and R9</b></i> respectively. Extra arguments are stored on stack. Also, <i><b>shadow space</b></i> is taken care of<i><b>.</b></i> <br /><br />Using the value of the <i><b>64-bit mode Code Segment selector</b></i>, the function makes a <i><b>Far Call </b></i>to a <i><b>64-bit</b></i> shellcode responsible for issuing the system call.<br /><br /><br />Suppose that we want to make a call to the <i><b>"ZwClose"</b></i> function using the "<i><b>Call64</b></i>" function, what you should do is allocate two <i><b>LARGE_INTEGER</b></i> structure, one to hold the value of the "<i><b>Handle</b></i>" parameter and the other to receive the return value (RAX). It looks like below.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-Dh3HuuChFdw/UPP6rS7wsQI/AAAAAAAABiU/QOamBIBbnng/s1600/ZwClose.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="62" src="http://2.bp.blogspot.com/-Dh3HuuChFdw/UPP6rS7wsQI/AAAAAAAABiU/QOamBIBbnng/s400/ZwClose.png" width="400" /></a></div><br />Other example is the "<i><b>ProcessConsoleHostProcess</b></i>" class of the "<i><b>ZwSetInformationProcess</b></i>" function. If we trace into this call, we will find that the <i><b>Wow64</b></i> emulation layer implemented in <i><b>Wow64.dll </b></i>prevents <i><b>Wow64 </b></i>processes from making such call and thus preventing them from changing their console host processes. See implementation of the<b> "wow64!whNtSetInformationProcess"</b> function<b>.</b><br /><b><br /></b>The sole solution to this is to directly make the system call without passing through the <i><b>Wow64</b></i> emulation layer. The call using the "<i><b>Call64</b></i>" function is like below.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-VwJsZ1GHVsY/UPQiBBXoi4I/AAAAAAAABjs/DNcgTLn5xyA/s1600/fix.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="155" src="http://4.bp.blogspot.com/-VwJsZ1GHVsY/UPQiBBXoi4I/AAAAAAAABjs/DNcgTLn5xyA/s400/fix.png" width="400" /></a></div><div class="separator" style="clear: both; text-align: center;"></div><br /><br /><i><b>N.B. </b></i>You should bear in mind that some system calls expect pointer arguments to be aligned by <i><b>8</b></i> and this is why we should align them by using <i><b>e.g.</b></i> the "<i><b>_aligned_malloc</b></i>" function.<br /><br /><br />Source code and examples can be found <a href="http://pastebin.com/LmZsuyha" target="_blank">here</a>. The function has also been implemented in a Dynamic Link Library, you can find it and its header and .lib files <a href="http://code.google.com/p/ollytlscatch/downloads/detail?name=Call64.zip" target="_blank">here</a>.<br /><br />GitHub project from <a href="https://github.com/waleedassar/Call64" target="_blank">here</a>.<br /><br />Any comments, ideas, or bug reports are more than welcome.<br /><br />You can follow me on Twitter <a href="http://www.twitter.com/waleedassar" target="_blank">@waleedassar </a></div>http://waleedassar.blogspot.com/2013/01/call64-no-wow64-emulation-layer.htmlnoreply@blogger.com (Walied Assar)0tag:blogger.com,1999:blog-5036198523690297182.post-4268643921494252018Fri, 07 Dec 2012 14:32:00 +00002012-12-08T00:31:03.295-08:00DbgUiIssueRemoteBreakinDebugActiveProcessNtCreateThreadExRtlIsCurrentThreadAttachExemptSkipThreadAttachZwCreateThreadExWindows Internals: SkipThreadAttach<div dir="ltr" style="text-align: left;" trbidi="on">In this post i will not present any new tricks but i will instead discuss a new issue introduced in later versions of Windows regarding thread creation.<br />In a <a href="http://waleedassar.blogspot.com/2012/11/hidding-threads-from-debuggers.html" target="_blank">previous post</a>, i quickly explained the <i><b>ntdll</b></i> "<i><b>NtCreateThreadEx</b></i>" function and its flag <i><b>HideFromDebugger 0x4</b></i> that when passed to the function causes the new thread to be created hidden from debuggers.<br /><br />In this post we will see another interesting flag<b> </b>that i prefer to call it <i><b>SuppressDllMains 0x2</b></i>. Let's see this in disassembly.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-yzw8ByghiMo/UMHdaHeeNTI/AAAAAAAABbk/RHoVc9DBpBA/s1600/32_0.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="197" src="http://2.bp.blogspot.com/-yzw8ByghiMo/UMHdaHeeNTI/AAAAAAAABbk/RHoVc9DBpBA/s400/32_0.png" width="400" /></a></div><br />As we can see in the image above, the "<i><b>PspAllocateThread</b></i>" function inspects the "<i><b>Flags</b></i>" parameter. If the <i><b>SuppressDllMains </b><b>0x2</b></i> flag is set, then the function sets the "<i><b>SkipThreadAttach 0x8</b></i>" bit flag in the new thread's <i><b>TEB</b></i>.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-ZmSIma_RcOk/UMHiMRk7_YI/AAAAAAAABcQ/dsrDx-uRYm4/s1600/64_0.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="217" src="http://4.bp.blogspot.com/-ZmSIma_RcOk/UMHiMRk7_YI/AAAAAAAABcQ/dsrDx-uRYm4/s400/64_0.png" width="400" /></a></div><br />Similarly for the<i><b> 64-bit </b></i>version of the function. If the "<i><b>SuppressDllMains</b></i>" flag is passed, then the "<i><b>SkipThreadAttach 0x8</b></i>" bit flag is set in both the <i><b>32-bit TEB</b></i> and <i><b>64-bit TEB</b></i> of the new thread.<br /><br /><i><b>N.B.</b></i> The bit flags are at offset <i><b>0xFCA</b></i> in<i><b> 32-bit TEB's</b></i> and at offset <i><b>0x17EE</b></i> in <i><b>64-bit TEB's</b></i>.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-0z3E55eD1Xo/UMHj6YHdc0I/AAAAAAAABcY/V_u8B9fURFM/s1600/struct.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="336" src="http://2.bp.blogspot.com/-0z3E55eD1Xo/UMHj6YHdc0I/AAAAAAAABcY/V_u8B9fURFM/s400/struct.png" width="400" /></a></div><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-RPKeyE3Ciy8/UMHkc_hwOyI/AAAAAAAABcg/WCzWxLOTHVk/s1600/strcr.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="256" src="http://1.bp.blogspot.com/-RPKeyE3Ciy8/UMHkc_hwOyI/AAAAAAAABcg/WCzWxLOTHVk/s400/strcr.png" width="400" /></a></div><br />Now let's see what the "<i><b>SkipThreadAttach</b></i>" bit flag does. To track this, we will have to shift to user-mode.<br /><br />In <i><b>OllyDbg</b></i>, search for the "<i><b>\xCA\x0F</b></i>" (<i><b>0xFCA</b></i>) in <i><b>ntdll.dll</b></i> and see which functions make use of the "<i><b>SkipThreadAttach 0x8</b></i>" bit flag.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-d030ZTB9IXc/UMHnHos9zdI/AAAAAAAABdM/nmguouD_-cQ/s1600/ggggg.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="207" src="http://4.bp.blogspot.com/-d030ZTB9IXc/UMHnHos9zdI/AAAAAAAABdM/nmguouD_-cQ/s400/ggggg.png" width="400" /></a></div><br />The <i><b>ntdll </b></i>"<b><i>RtlIsCurrentThreadAttachExempt</i></b>" function was among the results i found.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-Rw36zffBeyE/UMHni16XqjI/AAAAAAAABdU/pj63ybxkdXg/s1600/RtlIsExempt.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="35" src="http://3.bp.blogspot.com/-Rw36zffBeyE/UMHni16XqjI/AAAAAAAABdU/pj63ybxkdXg/s400/RtlIsExempt.png" width="400" /></a></div>This function returns <i><b>false</b></i> if the "<i><b>SkipThreadAttach</b></i>" bit flag is not set.<br />If the "<i><b>SkipThreadAttach</b></i>" bit flag is set, another bit flag "<i><b>RanProcessInit 0x20</b></i>" is tested. If not set, the function returns<i><b> true</b></i>. Otherwise, the function returns <i><b>false</b></i>. In C code it looks something like below.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-LnmAfBCND5A/UMHvNc4NzPI/AAAAAAAABeA/kA_E088566g/s1600/pseudo.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="35" src="http://1.bp.blogspot.com/-LnmAfBCND5A/UMHvNc4NzPI/AAAAAAAABeA/kA_E088566g/s400/pseudo.png" width="400" /></a></div><br />Searching for all references to the "<b><i>RtlIsCurrentThreadAttachExempt</i></b>" function, i found one interesting place in <i><b>ntdll.dll </b></i>where this function is called, that is <i><b>LdrpInitializeThread.&nbsp;</b></i><br /><br />The "<i><b>LdrpInitializeThread</b></i>" function is for calling the <i><b><a href="http://msdn.microsoft.com/en-us/library/windows/desktop/ms682583%28v=vs.85%29.aspx" target="_blank">DllMain</a></b></i>'s of loaded dlls ( and <i><b>TLS callbacks</b></i> as well) each time a thread is initializing (with the "<i><b>fdwReason</b></i>" parameter set to <i><b>DLL_THREAD_ATTACH</b></i>) or is exiting (with the "<i><b>fdwReason</b></i>" parameter set to <i><b>DLL_THREAD_DETACH</b></i>).<br /><i><b><br /></b></i>Taking the "<i><b>LdrpInitializeThread</b></i>" function in disassembly, we can see that if&nbsp; the<i><b> ntdll</b></i> "<b><i>RtlIsCurrentThreadAttachExempt</i></b>" function returns <i><b>true</b></i> <b><i>e.g.</i></b> due to the "<b>NtCreateThreadEx</b>" function being called with the "<i><b>Flags</b></i>" parameter set to <i><b>SuppressDllMains 0x2</b></i>, the <i><b>DllMains</b></i> and <b><i>TLS callbacks</i></b> of loaded modules will not be called in the context of the new thread. See image below.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-e5SNrwT9zkk/UMH3Qod1lnI/AAAAAAAABes/XvlJXPNW2L0/s1600/LdrpIniThreads.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="218" src="http://1.bp.blogspot.com/-e5SNrwT9zkk/UMH3Qod1lnI/AAAAAAAABes/XvlJXPNW2L0/s400/LdrpIniThreads.png" width="400" /></a></div><i><b><br /></b></i><i><b><br /></b></i>A good example for this is the "<i><b>DbgUiIssueRemoteBreakin</b></i>" function in <b><i>ntdll.dll</i></b> of <i><b>Windows 7</b></i>. This function is called by the "<i><b>DebugActiveProcess</b></i>" function to create the attaching thread in the context of the process to be debugged.<br />In <i><b>Windows XP</b></i>, the thread created by the "<i><b>DbgUiIssueRemoteBreakin</b></i>" function caused the <i><b>DllMains</b></i> and <i><b>TLS callbacks</b></i> of loaded modules to be called, presenting another layer of protection against attaching.<br />In <i><b>Windows 7</b></i>, since the "<i><b>DbgUiIssueRemoteBreakin</b></i>" function ends up calling the "<i><b>NtCreateThreadEx</b></i>" function with the "<i><b>Flags</b></i>" parameter set to <i><b>0x2 (SuppressDllMains)</b></i>, no <i><b>DllMain'</b></i>s or <i><b>TLS callbacks</b></i> are called for the debugger thread.<br /><br />You can download the demo of this post from <a href="http://code.google.com/p/ollytlscatch/downloads/detail?name=SkipThreadAttach.zip" target="_blank">here</a> and source code from <a href="http://pastebin.com/9z9pvUFn" target="_blank">here</a>.<br /><br />You can follow me on Twitter <a href="http://www.twitter.com/waleedassar" target="_blank">@waleedassar</a><br /><br />Any comments or ideas are very welcome.</div>http://waleedassar.blogspot.com/2012/12/skipthreadattach.htmlnoreply@blogger.com (Walied Assar)6tag:blogger.com,1999:blog-5036198523690297182.post-8390241787316131377Sat, 24 Nov 2012 22:06:00 +00002012-11-24T18:22:50.384-08:00Anti-IDAAnti-WindbgDbgkMapViewOfSectionDbgkSuppressDbgMsgHideFromDebuggerLOAD_DLL_DEBUG_EVENTLOAD_DLL_DEBUG_INFOSuppressDebugMsgwow64Wow64ProcessSuppressDebugMsg As Anti-Debug Trick<div dir="ltr" style="text-align: left;" trbidi="on">In this post i will show you a new anti-debug trick that affects many debuggers e.g. <i><b>WinDbg</b></i> and <i><b>IDA Debugger.</b></i><br /><br />When you load a module into the address space of a process usually via calling e.g.&nbsp; the <i><b>kernel32</b></i> "<i><b>LoadLibrary</b></i>" function, the debugger is notified of this through the <i><b>LOAD_DLL_DEBUG_EVENT</b></i> event. This occurs at the point the "<i><b>NtMapViewOfSection</b></i>" function calls the "<i><b>DbgkMapViewOfSection</b></i>" function.<br /><br />As we saw in the <a href="http://waleedassar.blogspot.com/2012/11/hidding-threads-from-debuggers.html" target="_blank">previous</a> post, the "<i><b>HideFromDebugger</b></i>" flag of the "<i><b>_ETHREAD</b></i>" structure and the "<b><i>DebugPort</i></b>" field of the "<i><b>_EPROCESS</b></i>" structure are queried. If the "<b><i>HideFromDebugger</i></b>" flag is not set and the "<i><b>DebugPort</b></i>" field is set, the debug event is delivered to the debugger but only after the return value of the "<i><b>DbgkpSuppressDbgMsg</b></i>" function is checked.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-CGcpGB7M1fg/ULBG81z1AiI/AAAAAAAABYQ/7GKpJRmt0vc/s1600/call_suppress.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="217" src="http://1.bp.blogspot.com/-CGcpGB7M1fg/ULBG81z1AiI/AAAAAAAABYQ/7GKpJRmt0vc/s400/call_suppress.png" width="400" /></a></div><br />If the "<i><b>DbgkpSuppressDbgMsg" </b></i>function returns <i><b>false</b></i>, the debug event is delivered to the debugger and vice versa. Now let's see the "<i><b>DbgkpSuppressDbgMsg" </b></i>function in disassembly.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-3EM8UtJWP6U/ULEgmvfymPI/AAAAAAAABZg/Y9Hce8fP1V0/s1600/SUppress.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="217" src="http://2.bp.blogspot.com/-3EM8UtJWP6U/ULEgmvfymPI/AAAAAAAABZg/Y9Hce8fP1V0/s400/SUppress.png" width="400" /></a></div><br /><br />As you can see in the image below, it checks the "<i><b>SuppressDebugMsg</b></i>" flag of the <i><b>64-bit TEB</b></i> of the thread. If it is set, the function returns true and the debug event is not delivered to the debugger.<br /><br />Also, the "<i><b>SuppressDebugMsg</b></i>" field of the <i><b>32-bit TEB</b></i> is queried, if the "<i><b>Wow64Process</b></i>" field of the "<b><i>_EPROCESS</i></b>" structure is set.<br /><br />Notes:<br /><i><b>1)</b></i> Each <i><b>Wow64</b></i> process has two<i><b> Process Environment Blocks</b></i> (<i><b>PEBs</b></i>), a <i><b>64-bit</b></i> one and a <i><b>32-bit</b></i> one.<br /><br /><i><b>2) </b></i>Each thread in a <i><b>Wow64</b></i> process has two <i><b>Thread Information Blocks</b></i> (<i><b>TEBs</b></i>), a <i><b>64-bit</b></i> one and a <i><b>32-bit</b></i> one. The <i><b>64-bit TEB</b></i> is of size <i><b>2</b></i> pages and the <i><b>32-bit TEB</b></i> is of size <i><b>1</b></i> page. The <i><b>32-bit TEB</b></i> always follows the <i><b>64-bit TEB</b></i>.<br /><br /><i><b>3)</b></i> If the "<i><b>Wow64Process</b></i>" field of the "<i><b>_EPROCESS</b></i>" structure is set, then it is a <i><b>Wow64</b></i> process (<i><b>32-bit</b></i> process running on <b><i>64-bit</i></b> system). This field holds the address of the process's <i><b>32-bit PEB</b></i>.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-iSFH7PfRg_E/ULBtJWncqKI/AAAAAAAABY4/hvzNQXRaIhg/s1600/PEB.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="217" src="http://4.bp.blogspot.com/-iSFH7PfRg_E/ULBtJWncqKI/AAAAAAAABY4/hvzNQXRaIhg/s400/PEB.png" width="400" /></a></div>In <i><b>WinDbg</b></i> and <i><b>IDA debugger</b></i>, if our process loads a module e.g. <i><b>walied.dll</b></i> via calling e.g. the<i><b> "LoadLibrary" </b></i>function, the debugger receives the <i><b>LOAD_DLL_DEBUG_EVENT</b></i> event and caches the "<i><b>hFile</b></i>" field of the <i><b>"LOAD_DLL_DEBUG_INFO</b></i>" structure. It uses the "<i><b>hFile</b></i>" field to <i><b>ReadFile</b></i> info. <i><b>e.g.</b></i> debug info. from <i><b>walied.dll</b></i><br /><br />The problem here is that <i><b>WinDbg</b></i> and <i><b>IDA debugger</b></i> don't <i><b>CloseHandle(hFile)</b></i> until the <i><b>UNLOAD_DLL_DEBUG_EVENT</b></i> event for <i><b>walied.dll</b></i> is received. So, if we set the "<i><b>SuppressDebugMsg</b></i>" bit of <i><b>TEB</b></i> and then call <i><b>FreeLibrary("walied.dll")</b></i>, then the debugger will not receive the <i><b>UNLOAD_DLL_DEBUG_EVENT</b></i> for <i><b>walied.dll</b></i>. Any subsequent attempt to acquire an exclusive access to <i><b>walied.dll</b></i> via calling the "<i><b>CreateFile</b></i>" function will definitely fail which is a very sign of debugger existence.<br /><br />A demo can be found <a href="http://code.google.com/p/ollytlscatch/downloads/detail?name=SuppressDebugMsg.exe" target="_blank">here</a> and its source code from<a href="http://pastebin.com/mg6kUSFx" target="_blank"> here</a>.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-xlJ_9ESIICY/ULEyrmy8oRI/AAAAAAAABaI/tUgAU26aU_A/s1600/source.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="390" src="http://4.bp.blogspot.com/-xlJ_9ESIICY/ULEyrmy8oRI/AAAAAAAABaI/tUgAU26aU_A/s400/source.png" width="400" /></a></div><br />The trick mentioned above affects <i><b>WinDbg</b></i> and <i><b>IDA debugger</b></i>. <i><b>OllyDbg v1.10</b></i> is affected but in a slightly different way. <i><b>OllyDbg v1.10</b></i> does not<i><b> CloseHandle(hFile)</b></i> even if the corresponding <i><b>UNLOAD_DLL_DEBUG_EVENT</b></i> event is received.<br /><br /><i><b>N.B.</b></i> <i><b>OllyDbg v2.x</b></i> is not affected since it immediately <i><b>CloseHandle</b></i> the "<i><b>hFile</b></i>" field of the "<i><b>LOAD_DLL_DEBUG_INFO</b></i>" structure once it receives the <i><b>LOAD_DLL_DEBUG_EVENT </b></i>event. <br /><br /><i><b>Conclusion:</b></i><br />Setting the "<i><b>SuppressDebugMsg</b></i>" bit of thread's <i><b>TEB</b></i> prevents the attached debugger from receiving <i><b>UN/LOAD_DLL_DEBUG_EVENT</b></i>'s from this thread.<br /><br />For debuggers to be immune to this trick, they should use the "<i><b>hFile</b></i>" field to read info. and close this handle immediately.<br /><br />Any comments or ideas are very welcome.<br /><br />You can follow me on Twitter <a href="http://www.twitter.com/waleedassar" target="_blank">@waleedassar</a></div>http://waleedassar.blogspot.com/2012/11/suppressdebugmsg-as-anti-debug-trick.htmlnoreply@blogger.com (Walied Assar)9tag:blogger.com,1999:blog-5036198523690297182.post-6232530107313845668Fri, 23 Nov 2012 05:05:00 +00002012-11-22T22:21:25.614-08:00DbgkForwardExceptionDbgkMapViewOfSectionHideFromDebuggerNtCreateThreadExPspAllocateThreadThreadHideFromDebuggerZwMapViewOfSectionHidding Threads From Debuggers<div dir="ltr" style="text-align: left;" trbidi="on">In this post i will take into discussion an old anti-debug trick that many of us know well. The trick is the ability of our code to hide specific threads from debuggers. This is usually achieved by calling the <i><b>ntdll </b></i>"<a href="http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/NT%20Objects/Thread/NtSetInformationThread.html" target="_blank"><i><b>ZwSetInformationThread</b></i></a>" function with the "<i><b>ThreadInformationClass</b></i>" parameter set to <i><b>ThreadHideFromDebugger</b></i> <i><b>0x11</b></i>. Sample code for this trick can be found <a href="http://pastebin.com/sArnNGBN" target="_blank">here</a>.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-W8Vek5jlubU/UK7BxY8EdZI/AAAAAAAABRQ/4SOWAq-oOEg/s1600/fffff.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="70" src="http://3.bp.blogspot.com/-W8Vek5jlubU/UK7BxY8EdZI/AAAAAAAABRQ/4SOWAq-oOEg/s400/fffff.png" width="400" /></a></div><br />If we take the "<i><b>ZwSetInformationThread</b></i>" function into disassembly, we can easily see that the "<i><b>ThreadInformationLength</b></i>" parameter must be <i><b>zero</b></i> for the function call to succeed, otherwise <b><i>ERROR_BAD_LENGTH</i> </b>is returned<b>.</b> See image below.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-fahnzSTLwks/UK7Hsa_rU2I/AAAAAAAABR4/V9cV73ud7CU/s1600/32.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="138" src="http://1.bp.blogspot.com/-fahnzSTLwks/UK7Hsa_rU2I/AAAAAAAABR4/V9cV73ud7CU/s400/32.png" width="400" /></a></div><br />&nbsp;And here is the <i><b>64-bit</b></i> version<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-upPaNuvur5o/UK7RvpuneRI/AAAAAAAABSg/tBAxZwc6TIE/s1600/64.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="205" src="http://3.bp.blogspot.com/-upPaNuvur5o/UK7RvpuneRI/AAAAAAAABSg/tBAxZwc6TIE/s400/64.png" width="400" /></a></div><br />As you can see from the two images above, the whole function call ends up setting the "<i><b>HideFromDebugger</b></i>" bit of the "<i><b>_ETHREAD</b></i>" structure. Once this flag has been set, the kernel guarantees that the debugger will never receive any debug events from the corresponding thread.<br /><br />For example, let's take the <a href="http://msdn.microsoft.com/en-us/library/windows/desktop/ms680351%28v=vs.85%29.aspx" target="_blank"><i><b>LOAD_DLL_DEBUG_EVENT</b></i></a> events. As you know, any time a module is loaded into the address space of specific process, the debugger is notified of this action through the <i><b>LOAD_DLL_DEBUG_EVENT</b></i> events.The debugger then inspects various interesting fields in the "<i><b>LOAD_DLL_DEBUG_INFO</b></i>" structure e.g. <i><b>ImageBase</b></i>. Depending on the debugger configuration, the debugger notifies you of that or not. You can see this if you instruct <i><b>OllyDbg</b></i> to break on new module.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-BE34azThwng/UK7S4oxc54I/AAAAAAAABSo/M5GbB1d0BZI/s1600/OllyShit.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="323" src="http://1.bp.blogspot.com/-BE34azThwng/UK7S4oxc54I/AAAAAAAABSo/M5GbB1d0BZI/s400/OllyShit.png" width="400" /></a></div><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-sDfsivXpjsQ/UK7ULvsAwZI/AAAAAAAABSw/-9eqezTu7gE/s1600/shitx2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="307" src="http://3.bp.blogspot.com/-sDfsivXpjsQ/UK7ULvsAwZI/AAAAAAAABSw/-9eqezTu7gE/s400/shitx2.png" width="400" /></a></div><br />The two images above show how <i><b>OllyDbg</b></i> acts if a normal (not hidden) thread loads a new <i><b>DLL</b></i>. It is as follows:<br /><i><b>1)</b></i> Thread Loads a new DLL via calling e.g. the "<i><b>LoadLibrary</b></i>" function.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-FD9AYPLaOb0/UK7W5xCiFxI/AAAAAAAABTY/H07DgK4Bpnk/s1600/LoadLibrary.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="58" src="http://1.bp.blogspot.com/-FD9AYPLaOb0/UK7W5xCiFxI/AAAAAAAABTY/H07DgK4Bpnk/s400/LoadLibrary.png" width="400" /></a></div><br /><i><b>2)</b></i> The "<i><b>LoadLibrary</b></i>" function wraps up a call to the <i><b>ntdll "ZwMapViewOfSection"</b></i> function.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-xNBdh33xFz4/UK7XfHLEF6I/AAAAAAAABTg/nmqy0iNj_TA/s1600/ZwMapViewOfSection.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="102" src="http://1.bp.blogspot.com/-xNBdh33xFz4/UK7XfHLEF6I/AAAAAAAABTg/nmqy0iNj_TA/s400/ZwMapViewOfSection.png" width="400" /></a></div><br /><i><b>3)</b></i> The kernel mode part of <i><b>ZwMapViewOfSection</b></i> calls the "<i><b>DbgkMapViewOfSection</b></i>" function.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-zj4Sbh9Vt0g/UK7ZX-HpjGI/AAAAAAAABTo/ntH2ozlNssA/s1600/ZwMapViewOfSection_k.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="205" src="http://1.bp.blogspot.com/-zj4Sbh9Vt0g/UK7ZX-HpjGI/AAAAAAAABTo/ntH2ozlNssA/s400/ZwMapViewOfSection_k.png" width="400" /></a></div><br /><i><b>4) </b></i>The "<i><b>DbgkMapViewOfSection" </b></i>function<i><b> </b></i>queries both the "<i><b>HideFromDebugger</b></i>" bit of the "<i><b>_ETHREAD</b></i>" structure and the value of the "<i><b>DebugPort</b></i>" field of the "<i><b>_EPROCESS</b></i>" structure. If the "<i><b>HideFromDebugger</b></i>" bit is <i><b>not set</b></i> and the "<i><b>DebugPort</b></i>" field is <i><b>set</b></i>, then the function builds the "<i><b>LOAD_DLL_DEBUG_INFO</b></i>" structure and calls the "<i><b>DbgkpSendApiMessage</b></i>" function which is responsible for delivering the debug event to the attached debugger.<br />On the other side, if the "<i><b>HideFromDebugger</b></i>" bit is set, <i><b>DbgkMapViewOfSection</b></i> returns immediately without delivering the debug event. See images below.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-wcdmJuFLKFM/UK7cM_sp_VI/AAAAAAAABUQ/JDNG4b9yTpY/s1600/DbgkMap.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="205" src="http://2.bp.blogspot.com/-wcdmJuFLKFM/UK7cM_sp_VI/AAAAAAAABUQ/JDNG4b9yTpY/s400/DbgkMap.png" width="400" /></a></div><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-czKDVfrc4vw/UK7dICxYGFI/AAAAAAAABUY/K5Bt86-J30s/s1600/SendApi.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="205" src="http://4.bp.blogspot.com/-czKDVfrc4vw/UK7dICxYGFI/AAAAAAAABUY/K5Bt86-J30s/s400/SendApi.png" width="400" /></a></div><br /><br /><i><b>N.B.</b></i> Regarding the <i><b>UN/LOAD_DLL_DEBUG_EVENT</b></i>'s, there are other factors that determine whether or not the debug event is going to be delivered to debugger e.g. the "<i><b>SuppressDebugMsg</b></i>" bit of the <i><b>Thread Environment Block</b></i> (<i><b>TEB</b></i>).<br /><br /><i><b>5)&nbsp; </b></i>In the debugger, the "<i><b>WaitForDebugEvent</b></i>" function returns with the "<i><b>dwDebugEventCode</b></i>" field set to <i><b>LOAD_DLL_DEBUG_EVENT 0x6. </b></i>Given this, the debugger figures out that a new module has just been loaded and that it should inspect the "<i><b>LOAD_DLL_DEBUG_INFO</b></i>" structure to extract the new image base, file handle, etc.<br /><br /><i><b>6)</b></i> After extracting info. from the "<i><b>LOAD_DLL_DEBUG_INFO</b></i>" structure, the debugger calls the "<i><b>ContinueDebugEvent</b></i>" function to continue executing the thread. <br /><i><b><br /></b></i>Similar to <i><b>LOAD_DLL_DEBUG_EVENT</b></i>'s, debuggers never get notified of exceptions raised in the scope of hidden threads. To ensure that let's have a look at the "<i><b>DbgkForwardException</b></i>" function.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-3DMJICKte5g/UK7j3GFxZSI/AAAAAAAABVA/DUbi-BJSLf8/s1600/DbgkFor.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="205" src="http://3.bp.blogspot.com/-3DMJICKte5g/UK7j3GFxZSI/AAAAAAAABVA/DUbi-BJSLf8/s400/DbgkFor.png" width="400" /></a></div><i><b><br /></b></i>As you can see in the image above, the "<i><b>HideFromDebugger</b></i>" bit of the "<b><i>_ETHREAD</i></b>" structure is queried here as well.<br /><i><b><br /></b></i><i><b>Conclusion: When the "HideFromDebugger" bit flag of the "_ETHREAD" structure is set, the thread will not receive any debug events.</b></i><br /><i><b><br /></b></i>If we look again at the "<i><b>NtSetInformationThread</b></i>" function in disassembly, we will see that the function call is one-way i.e. you can make this function call to hide the thread from debugger but you can not make this call to un-hide the thread from debuggers.<i><b></b></i><br /><i><b><br /></b></i>Let's have a look at the "<i><b>ZwQueryInformationThread</b></i>" function. As the name implies, we can use<i><b> </b></i>this<i><b> </b></i>function to determine if a specific thread is hidden from debuggers. See below.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-vaYeX0EgVWo/UK7uOwkArHI/AAAAAAAABVo/GNh9ZEvkhk4/s1600/Query_7.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="181" src="http://4.bp.blogspot.com/-vaYeX0EgVWo/UK7uOwkArHI/AAAAAAAABVo/GNh9ZEvkhk4/s400/Query_7.png" width="400" /></a></div><i><b><br /></b></i>And here is the <i><b>64-bit</b></i> version.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-z-Mm47CN0Wo/UK7yTcE_8ZI/AAAAAAAABWQ/yRJStVR5iZ8/s1600/Query64.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="217" src="http://4.bp.blogspot.com/-z-Mm47CN0Wo/UK7yTcE_8ZI/AAAAAAAABWQ/yRJStVR5iZ8/s400/Query64.png" width="400" /></a></div><i><b><br /></b></i>As you can see from the two images above, the "<i><b>ThreadInformationLength</b></i>" parameter must be <i><b>one</b></i> for this function call to succeed. If it is <i><b>one</b></i> as expected, nothing surprising is seen, the function just sets the first byte pointed to by the "<b><i>ThreadInformation</i></b>" parameter to <i><b>one</b></i> if the "<i><b>HideFromDebugger</b></i>" bit of the "<i><b>_ETHREAD</b></i>" structure<b> </b>is set. Given this knowledge, i have created a small <i><b>OllyDbg v1.10</b></i> plugin to detect any hidden thread in the process being debugged esp. if we are attaching to an active process. The plugin is called <i><b>HiddenThreads</b></i>. You download it from <a href="http://code.google.com/p/myollyplugins/downloads/detail?name=HiddenThreads.dll" target="_blank">here</a> and its source code from <a href="http://code.google.com/p/myollyplugins/downloads/detail?name=HiddenThreads.cpp" target="_blank">here</a>.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-bLK8dUQnYUs/UK73XW2PPtI/AAAAAAAABW4/vBQZTt5o63A/s1600/plugin.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="155" src="http://2.bp.blogspot.com/-bLK8dUQnYUs/UK73XW2PPtI/AAAAAAAABW4/vBQZTt5o63A/s400/plugin.png" width="400" /></a></div><i><b><br /></b></i>Unfortunately, in older versions of Windows e.g. <i><b>XP</b></i>, the "<b><i>ZwQueryInformationThread</i></b>" function can't be used to detect if a thread is hidden from debuggers as the <i><b>ThreadHideFromDebugger</b></i><i><b></b></i> information class <i><b>0x11</b></i> is simply not implemented. The function call returns <i><b>ERROR_INVALID_PARAMETER</b></i>.<br /><br />Now that we have seen how to hide a thread from debuggers, how this works under the hood, and how to detect if a thread is hidden from debuggers, let's try to find another way to hide the thread other than calling the "<i><b>ZwSetInformationThread</b></i>" function.<br /><i><b><br /></b></i>With the introduction of the "<i><b>ZwCreateThreadEx</b></i>" function e.g. <b><i>Windows Vista and 7</i></b>, a new flags parameter is present. This flag causes new threads to be created hidden from debuggers i.e. you don't need to call the "<i><b>ZwSetInformationThread</b></i>" function. If we set this parameter (the <b><i>7th</i></b> parameter) to <i><b>0x4</b></i>, then the new thread will be hidden from debuggers. In this case, setting the "<i><b>HideFromDebugger</b></i>" bit occurs in the "<i><b>PspAllocateThread</b></i>" function. See image below.<i><b> </b></i><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-bUm88wYqHTk/UK8B8jqHjFI/AAAAAAAABXg/WYt6NnOgExg/s1600/PspAllocateThread.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="118" src="http://2.bp.blogspot.com/-bUm88wYqHTk/UK8B8jqHjFI/AAAAAAAABXg/WYt6NnOgExg/s400/PspAllocateThread.png" width="400" /></a></div><i><b><br /></b></i><i><b><br /></b></i>You can find a demo <a href="http://code.google.com/p/ollytlscatch/downloads/detail?name=HiddenThreads.exe" target="_blank">here</a> and its source code from <a href="http://pastebin.com/jAv5GYUd" target="_blank">here</a><i><b>.</b></i><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-wBiH7Ccm8TQ/UK8DkPYwFYI/AAAAAAAABXo/BLiiSDQDSH4/s1600/coooo.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="158" src="http://3.bp.blogspot.com/-wBiH7Ccm8TQ/UK8DkPYwFYI/AAAAAAAABXo/BLiiSDQDSH4/s400/coooo.png" width="400" /></a></div><br /><i><b><br /></b></i><i><b>This post was written based on debugging sessions on Windows 7 64-bit. This is why you see me switching from x86 to x64.</b></i><br /><i><b><br /></b></i><i><b>Any comments or ideas are very welcome.</b></i><br /><i><b><br /></b></i><i><b>You can follow me on Twitter <a href="http://www.twitter.com/waleedassar" target="_blank">@waleedassar</a></b></i></div>http://waleedassar.blogspot.com/2012/11/hidding-threads-from-debuggers.htmlnoreply@blogger.com (Walied Assar)5tag:blogger.com,1999:blog-5036198523690297182.post-685408260098974525Mon, 12 Nov 2012 23:53:00 +00002012-11-12T15:57:55.986-08:00CPUID sepdetect vboxdetect VirtualBoxSYSENTERSYSEXITVirtualBoxVirtualBox CPUID Discrepancy<div dir="ltr" style="text-align: left;" trbidi="on">In this post i will show you a weird issue i have lately found in <i><b>VirtualBox</b></i>. This issue is seen only if <i><b>VirtualBox</b></i> is running without hardware virtualization support (<i><b>VT-x/AMD-V</b></i>).<br /><br />For example, when <i><b>Windows XP</b></i> is running in <i><b>VirtualBox</b></i> with no hardware virtualization support, it is forced to use <i><b>INT 2E</b></i> to make system calls instead of <i><b>SYSENTER</b></i>. This is because <i><b>SYSENTER</b></i> is apparently not supported by <i><b>VirtualBox</b></i>. The problem here is that in this case the <i><b>CPUID</b></i> instruction still detects supported <i><b>SYSENTER/SYSEXIT</b></i> instructions.<br /><br />We can use this discrepancy to detect VirtualBox (only if running with no hardware virtualization). All we have to do is execute <i><b>CPUID</b></i> (<i><b>Leaf 1</b></i>) and if we have bit <i><b>0x800</b></i> of <i><b>EDX</b></i> set, then execute <i><b>SYSENTER</b></i> in the form of any system call e.g. <i><b>ZwDelayExecution</b></i>. If an <i><b>EXCEPTION_ILLEGAL_INSTRUCTION <span class="nu12">0xC000001D </span></b></i><span class="nu12">is raised</span><i><b><span class="nu12">, then VirtualBox is present.</span></b></i><br /><i><b><span class="nu12"></span></b></i><br /><br />You can find a demo <a href="http://code.google.com/p/ollytlscatch/downloads/detail?name=vbox_cpuid_sep.exe" target="_blank">here</a> and source code from <a href="http://pastebin.com/FiY3fzRA" target="_blank">here</a>.<br /><br />Any comments or ideas are very welcome.<br /><br />You can follow me on Twitter <a href="http://www.twitter.com/waleedassar" target="_blank">@waleedassar</a></div>http://waleedassar.blogspot.com/2012/11/virtualbox-cpuid-discrepancy.htmlnoreply@blogger.com (Walied Assar)1tag:blogger.com,1999:blog-5036198523690297182.post-7573598028618699798Mon, 12 Nov 2012 22:48:00 +00002012-11-12T15:09:12.963-08:000x80000003detect OllyDbgEXCEPTION_BREAKPOINTollydbg bugRaiseExceptionOllyDbg RaiseException Bug<div dir="ltr" style="text-align: left;" trbidi="on">In this post i will show you a bug in <i><b>OllyDbg</b></i> that can be used to detect its presence<i><b></b></i>. The trick is so easy that all you have to do is call the "<a href="http://msdn.microsoft.com/en-us/library/windows/desktop/ms680552%28v=vs.85%29.aspx" target="_blank"><i><b>RaiseException</b></i></a>" function with the "<i><b>dwExceptionCode</b></i>" parameter set to <i><b>EXCEPTION_BREAKPOINT</b></i> <i><b>0x80000003</b></i>. The response depends on the <i><b>OllyDbg</b></i> version used. If it is <i><b>v1.10</b></i>, then the exception is going to be silently swallowed by the debugger and the registered exception handler is not called. <span class="co1">In <i><b>v2.01 (alpha 4)</b></i>, several message boxes pop up and the exception handler is not called either. Only <i><b>v2.01 (beta 2)</b></i> is immune to this bug.</span><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-sJ5VANw_9wg/UKF8Wy0bagI/AAAAAAAABQY/TF3uXCae-SU/s1600/errv2.0.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="206" src="http://4.bp.blogspot.com/-sJ5VANw_9wg/UKF8Wy0bagI/AAAAAAAABQY/TF3uXCae-SU/s400/errv2.0.png" width="400" /></a></div><span class="co1"><br /></span><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-s-u_OOfKE0g/UKF8cUu905I/AAAAAAAABQg/yeD3A49eJiU/s1600/errxxxx.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="88" src="http://2.bp.blogspot.com/-s-u_OOfKE0g/UKF8cUu905I/AAAAAAAABQg/yeD3A49eJiU/s400/errxxxx.png" width="400" /></a></div><span class="co1"><br /></span><span class="co1">The reason behind this bug is <i><b>OllyDbg</b></i> trying to read the <b>x86</b> instruction pointed to by the "<i><b>ExceptionAddress</b></i>" field of the "<a href="http://msdn.microsoft.com/en-us/library/windows/desktop/aa363082%28v=vs.85%29.aspx" target="_blank"><i><b>EXCEPTION_RECORD</b></i></a>" structure to ensure it is <i><b>0xCC</b></i> or <i><b>0x03</b></i>. In case of <i><b>EXCEPTION_BREAKPOINT</b></i> exceptions raised by explicitly calling the "<i><b>RaiseException</b></i>" function, the instructions at <i><b>ExceptionAddress</b></i> is definitely not <i><b>0xCC</b></i> or <i><b>0x03</b></i>.</span><br /><span class="co1"><br /></span><span class="co1"><br /></span><span class="co1">You can find a demo <a href="http://code.google.com/p/ollytlscatch/downloads/detail?name=olly_raiseexception.exe" target="_blank">here</a> and its source code from <a href="http://pastebin.com/XVhzkNkM" target="_blank">here</a>.</span><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-zfyLfbEN3WA/UKF9Ljt5WsI/AAAAAAAABQo/hU-yDnbtYqg/s1600/errrt.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="312" src="http://2.bp.blogspot.com/-zfyLfbEN3WA/UKF9Ljt5WsI/AAAAAAAABQo/hU-yDnbtYqg/s400/errrt.png" width="400" /></a></div><span class="co1"><br /></span><span class="co1">Any comments or ideas are very welcome.</span><br /><span class="co1"><br /></span><span class="co1">You can follow me on Twitter <a href="http://www.twitter.com/waleedassar" target="_blank">@waleedassar</a></span></div>http://waleedassar.blogspot.com/2012/11/ollydbg-raiseexception-bug.htmlnoreply@blogger.com (Walied Assar)0tag:blogger.com,1999:blog-5036198523690297182.post-8178621234443553732Mon, 12 Nov 2012 21:20:00 +00002012-11-12T21:54:10.403-08:00anti-memory breakpointsantimemory breakpointsmemory breakpointPAGE_GUARDPAGE_NOACCESSTEBwow64Defeating Memory Breakpoints<div dir="ltr" style="text-align: left;" trbidi="on">In this post i will show you a couple of tricks that can be used to defeat <i><b>memory breakpoints</b></i>. First i should explain what <i><b>memory breakpoints </b></i>are and how they work.<br /><br />Anyone who has spent some time in the field of software protection and debuggers must have heard of <i><b>Memory breakpoints</b></i>. Actually, <i><b>memory breakpoints</b></i> were not extensively used in the past but since more and more protection schemes implement <i><b>anti-INT3</b></i> and <i><b>anti-Hardware</b></i> breakpoints tricks, reverse engineers started to use <i><b>memory breakpoints</b></i> to avoid detection.<br /><br />The idea of memory breakpoints is so simple. Imagine that we want to place a memory breakpoint at address <i><b>0x402005</b></i> (<i><b>On-Execution</b></i>), what the debugger theoretically does is as follows:<br /><br /><i><b>1)</b></i> Marks the memory page which the address <i><b>0x402005</b></i> belongs to (page<i><b> 0x402000)</b></i> as <i><b>guarded</b></i> via calling the "<i><b>VirtualProtectEx</b></i>" or "<i><b>ZwProtectVirtualMemory</b></i>" function with the "<i><b>flNewProtect</b></i>" parameter having the <i><b>"PAGE_GUARD"</b></i> protection attribute set. In this case page <i><b>0x402000</b></i> is originally <b>PAGE_EXECUTE_READ <i>0x20</i></b> and after placing the memory breakpoint it becomes <i><b>PAGE_EXECUTE_RE</b><b>AD|PAG</b><b>E_GUARD</b></i> <i><b>0x120</b></i>.<br /><br /><i><b>2)</b></i> Each time the guarded page is touched whether read from, written to, or executes, then an exception <i><b>STATUS_GUARD_PAGE_VIOLATION</b><b> 0x80000001</b></i> is raised and the debugger receives a <a href="http://msdn.microsoft.com/en-us/library/windows/desktop/ms679308%28v=vs.85%29.aspx" target="_blank">debug event</a> of type&nbsp; <b><i>EXCEPTION_DEBUG_EVENT</i>.</b><br /><br /><b>3) </b>The debugger then inspects various fields in the "<i><b>EXCEPTION_RECORD</b></i>" structure of the "<i><b>DEBUG_EVENT</b></i>" structure to determine the reason why the exception was raised.<br />If the following conditions are met, then the debugger figures out that instruction at <i><b>0x402005</b></i> is about to execute<i><b> i.e.</b></i> breakpoint reached and that it should break accordingly. <br /><i><b>a)</b></i> The "<i><b>ExceptionCode</b></i>" field is set to<i><b> STATUS_GUARD_PAGE_VIOLATION</b></i> <i><b>0x80000001</b></i>. <i><b>b)</b></i> The "<i><b>NumberParameters</b></i>" field is greater than or equal to<i><b> 2</b></i>. <i><b>c)</b></i> The "<i><b>ExceptionInformation[0]</b></i>" field is <i><b>set to 8. d) </b></i>The <i><b>"ExceptionInformation[1]"</b></i> field is set to <i><b>0x402005</b></i>. The image below represents something very similar.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-3i77N8L31kU/UJ-SfU_94iI/AAAAAAAABPw/CzRq869WCEQ/s1600/pseudo.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="90" src="http://2.bp.blogspot.com/-3i77N8L31kU/UJ-SfU_94iI/AAAAAAAABPw/CzRq869WCEQ/s400/pseudo.png" width="400" /></a></div><br /><br />If any of the above mentioned conditions is not met, then the debugger figures out it is not the breakpoint. Whether the breakpoint is hit or not, the debugger resets the "<i><b>PAGE_GUARD</b></i>" protection attribute.<br /><br />Surprisingly, even though this is the typical way debuggers should implement memory breakpoints, <i><b>OllyDbg</b></i> and many other user-mode debuggers implement memory breakpoints in a slightly different way.<br /><br />Let's first take OllyDbg v1.10 and see how it implements memory breakpoints.<br /><br />If you already use <i><b>OllyDbg v1.10</b></i>, you should already know that it has only two kinds of memory breakpoints, <i><b>On-Access</b></i> and <i><b>On-Write</b></i>. <i><b>On-Access </b></i>memory breakpoints trigger anytime the page is touched and <i><b>On-Write </b></i>memory breakpoints trigger anytime the page is written to.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-1KFZyIZm9r0/UJ98WOL_2eI/AAAAAAAABPI/w7QNCLPOvcM/s1600/OllyDbg110_mem.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="155" src="http://3.bp.blogspot.com/-1KFZyIZm9r0/UJ98WOL_2eI/AAAAAAAABPI/w7QNCLPOvcM/s400/OllyDbg110_mem.png" width="400" /></a></div><br />Trying to reverse <i><b>OllyDbg v1.10</b></i> to see how it implements each type, i found out that:<br /><br /><b><i>1) </i></b>For<b><i> On-Access</i></b> memory breakpoints, they are implemented by marking the page that the breakpoint address belongs to as <i><b>PAGE_NOACESS</b></i>. <i><b>PAGE_NOACCESS</b></i> means that anytime the page is touched, an exception <i><b>STATUS_ACCESS_VIOLATION</b></i> is raised. The debugger then receives the debug event and inspects fields in the <i><b>"EXCEPTION_RECORD</b></i>" structure in a similar way to the conventional method mentioned above.<br /><br /><b><i>2) </i></b>For<b><i> On-Write </i></b>memory breakpoints, they are implemented by depriving the page which the breakpoint address belongs to of the write access right via setting the "<b>flNewProtect</b>" parameter passed to the "<i><b>VirtualProtectEx</b></i>" function to <i><b>PAGE_EXECUTE_READ</b></i>. Every time the page is written to, an exception <i><b>STATUS_ACCESS_VIOLATION</b></i> is received. The debugger then receives the debug event and inspects fields in the <i><b>"EXCEPTION_RECORD</b></i>" structure in a similar way to the conventional method mentioned above. Here lies a bug in <i><b>OllyDbg v1.10</b></i> since it assumes that the memory protection of any single page in the process address space can be turned into <i><b>PAGE_EXECUTE_READ</b></i> while this is not true for example memory page at <i><b>0x10000</b></i> can never be executable (<i><b>Windows 7</b></i>).<br /><br />After we have seen how memory breakpoints are implemented, i will show you two tricks that can be used as <i><b>anti-memory-breakpoints</b></i>.<br /><br /><i><b>Trick 1)</b></i><br /><br />Given the knowledge above, we can conclude that in order to defeat memory breakpoints <i><b>esp.</b></i> those of type <i><b>On-Execution</b></i>, we should cause the "<i><b>VirtualProtectEx</b></i>" function to fail. <i><b>How is that possible?</b></i><br />By copying our code to a dynamically-allocated memory page whose page protection attributes can be executable and in the same time can not be <i><b>guarded</b></i> or <i><b>no-access</b></i>. This type of memory pages does really exist. For every thread you create, the kernel allocates one page (three pages in case of <i><b>Wow64</b></i> processes) for the <i><b>TEB</b></i>. <i><b>The TEB page(s) can't be non-writable and can't be assigned the "PAGE_GUARD" protection attribute</b></i>. <i><b>How can this be implemented?</b></i><br />All you have to do to implement this trick is call the "<i><b>CreateThread</b></i>" function with the "<i><b>dwCreationFlags</b></i>" parameter set to <i><b>CREATE_SUSPENDED</b></i>. At this point, we have the new thread's <i><b>TEB</b></i> with the page protection attributes set to <i><b>PAGE_READWRITE</b></i>. The next thing we should do is make the <i><b>TEB </b></i>page executable by calling the "<i><b>VirtualProtect</b></i>" function with the "<i><b>flNewProtect</b></i>" parameter set to <i><b>PAGE_EXECUTE_READWRITE</b></i>.<br /><br />You can use this <a href="http://pastebin.com/Y5aJC13M" target="_blank">demo</a> to test this trick.<br /><br /><i><b>N.B.</b></i> For more stealthy way to conceal the point at which the page protection is changed to executable, use the "<i><b>VirtualAlloc</b></i>" function instead of "<i><b>VirtualProtect</b></i>". The allocation type in this case must be <i><b>MEM_COMMIT</b></i> only.<br /><br /><i><b>Trick 2)</b></i><br /><br />This trick can easily detect memory breakpoints. It relies on the fact that the "<i><b>ReadProcessMemory</b></i>" function returns false if you try to read <i><b>guarded</b></i> or <i><b>no-access</b></i> memory. To use this trick, all you have to do is call the "<i><b>ReadProcessMemory</b></i>" function with the "<i><b>Handle</b></i>" parameter set to <b><i>0xFFFFFFFF</i></b>, the "<i><b>lpBaseAddress</b></i>" parameter set to the image base, and the "<i><b>nSize</b></i>" parameter set to the size of image. If it returns false, then at least one memory breakpoint is present.<br /><br />You can use this <a href="http://pastebin.com/RCkVDNXJ" target="_blank">demo</a> to test this trick.<br /><br /><i><b>N.B.</b></i> Certain executables have gap inaccessible pages e.g. those pages intended for <i><b>anti-dumping</b></i> described in a <a href="http://waleedassar.blogspot.com/2012/03/anti-dumping-part-2.html" target="_blank">previous post.</a> So you have to take care of that if implementing this trick.<br /><br /><i><b>N.B. ReadProcessMemory</b></i> has also been used as a stealthy way to read memory without triggering <i><b>Hardware Breakpoints</b></i>.<br /><br /><br />Any comments or ideas are very welcome.<br /><br />You can follow me on Twitter <a href="http://www.twitter.com/waleedassar" target="_blank">@waleedassar</a><br /><br /><br /><br /><br /><br /></div>http://waleedassar.blogspot.com/2012/11/defeating-memory-breakpoints.htmlnoreply@blogger.com (Walied Assar)7tag:blogger.com,1999:blog-5036198523690297182.post-1911079722808320333Tue, 06 Nov 2012 01:08:00 +00002013-03-12T17:08:17.511-07:00BaseCreateStackNtCreateThreadExPspAllocateThreadPspCreateThreadSizeOfStackCommitSizeOfStackReserveSizeOfStackReserve As Anti-Attaching Trick<div dir="ltr" style="text-align: left;" trbidi="on">In this post i will show you a new <i><b>anti-attaching</b></i> trick that has been tested on <i><b>Windows 7</b></i>. It does not work on <i><b>Windows XP</b></i> due to the changes <i><b>Microsoft</b></i> introduced in the way threads are created.<br /><br />Let's first see how thread creation in <i><b>Windows 7</b></i> is different from that of <i><b>Windows XP</b></i>.<br /><br />In <b>Windows XP</b>, whenever you call the <i><b>kernel32</b></i> "<a href="http://msdn.microsoft.com/en-us/library/windows/desktop/ms682437%28v=vs.85%29.aspx" target="_blank"><i><b>CreateRemoteThread</b></i></a>" or the <i><b>ntdll </b></i>"<a href="http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/Executable%20Images/RtlCreateUserThread.html" target="_blank"><i><b>RtlCreateUserThread</b></i></a>" function to create a new thread, the following occurs underneath:<br /><br />The <i><b>kernel32</b></i> "<i><b>BaseCreateStack</b></i>" or <i><b>ntdll</b></i> "<i><b>RtlpCreateStack</b></i>" function is called in case of&nbsp; "<i><b>CreateRemoteThread</b></i>" or "<i><b>RtlCreateUserThread</b></i>" successively<i><b> to allocate space for the new thread's stack in the address space of the target process.</b></i><br /><i><b><br /></b></i><i><b>N.B. </b></i>The <i><b>kernel32</b></i> "<i><b>CreateThread</b></i>" function is only a call to the<i><b> kernel32</b></i> "<i><b>CreateRemoteThread</b></i>" function with the "<i><b>hProcess</b></i>" parameter set to<i><b> -1.</b></i><br /><i><b><br /></b></i>Since there is no big difference between the "<i><b>BaseCreateStack</b></i>" and "<i><b>RtlpCreateStack</b></i>" functions, it is enough for us to take the "<i><b>BaseCreateStack</b></i>" function in disassembly in this post.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-wOzAz6135ls/UJgjIdRCK9I/AAAAAAAABBA/b9QUKiIZyb4/s1600/begin.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="173" src="http://1.bp.blogspot.com/-wOzAz6135ls/UJgjIdRCK9I/AAAAAAAABBA/b9QUKiIZyb4/s400/begin.JPG" width="400" /></a></div><br />The "<i><b>BaseCreateStack</b></i>" function takes four parameters, only three of them are of interest. The <i><b>first</b></i> parameter is the <i><b>handle</b></i> to the process in which we are about to allocate user stack memory. The <i><b>second</b></i> parameter is the size in bytes of user stack memory to <i><b>COMMIT</b></i> into the target process's address space. The <i><b>third</b></i> parameter is the size in bytes of user stack memory to <i><b>RESERVE</b></i> into the target process's address space. Hereafter, i will refer to them as <i><b>hProcess</b></i>, <i><b>CommitSize</b></i>, and <i><b>ReserveSize</b></i>.<br /><br /><i><b>N.B.</b></i> If you call the "<i><b>CreateRemoteThread</b></i>" function with the "<i><b>dwStackSize</b></i>" parameter set to e.g. <i><b>0x10000</b></i>, then <i><b>BaseCreateStack </b></i>commits <i><b>0x10000</b></i> bytes. On the other side, if the "<i><b>CreateRemoteThread</b></i>" function is called with the "<i><b>dwCreationFlags</b></i>" parameter having the "<b>STACK_SIZE_PARAM_IS_A_RESERVATION" </b>flag<b> </b>set, then <i><b>BaseCreateStack</b></i> Reserves <i><b>0x10000</b></i>.<b></b><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-7U8KtKWWceI/UJbdb8VO56I/AAAAAAAABAc/IfIEHAXmCiw/s1600/shit_rev.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="132" src="http://1.bp.blogspot.com/-7U8KtKWWceI/UJbdb8VO56I/AAAAAAAABAc/IfIEHAXmCiw/s400/shit_rev.png" width="400" /></a></div><b><br /></b>Now, let's dive into the "<i><b>BaseCreateStack</b></i>" function and see what is going on inside.<br /><br /><b>1)</b> It extracts the value of <i><b>ImageBase</b></i> from the <i><b>PEB</b></i> of the process in which it is called, the value is then passed to the "<i><b>RtlImageNtHeader</b></i>" function. If the "<i><b>RtlImageNtHeader</b></i>" function fails an error <i><b>ERROR_BAD_EXE_FORMAT</b></i> is returned.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-bu2wJkIY77M/UJgkyzubW9I/AAAAAAAABBI/wZLs55LaThM/s1600/RTlImageNt.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="88" src="http://3.bp.blogspot.com/-bu2wJkIY77M/UJgkyzubW9I/AAAAAAAABBI/wZLs55LaThM/s400/RTlImageNt.JPG" width="400" /></a></div><br /><b><br />2)</b> If the "<i><b>ReserveSize</b></i>" parameter passed to it is zero, it uses the value of the "<b>SizeOfStackReserve</b>" field of the <a href="http://msdn.microsoft.com/en-us/library/windows/desktop/ms680339%28v=vs.85%29.aspx" target="_blank"><b><i>IMAGE_OPTIONAL_HEADER</i></b></a> structure. <b><br /></b><br /><br /><br /><b>3)</b> Similarly, If the "<i><b>CommitSize</b></i>" parameter passed to it is zero, it uses the value of the "<b>SizeOfStackCommit</b>" field of the <a href="http://msdn.microsoft.com/en-us/library/windows/desktop/ms680339%28v=vs.85%29.aspx" target="_blank"><b><i>IMAGE_OPTIONAL_HEADER</i></b></a> structure. Please remember that the values are extracted from the PE header of the main executable of the process that is calling the "<i><b>CreateRemoteThread</b></i>" function, not the target process.<b><br /></b><br /><b></b><br /><b></b><br /><b>4) </b>It then makes some sanitization checks on the <i><b>ReserveSize</b></i> and <i><b>CommitSize</b></i>, for example to ensure that the commit size is never greater than the reserve size. It also checks to ensure that the commit size is never lower than the value of the "<i><b>MinimumStackCommit</b></i>" field of <a href="http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/NT%20Objects/Process/PEB.html" target="_blank"><i><b>PEB</b></i></a>.<br /><b></b><br /><b></b><br /><b></b><br /><b></b><br /><b>5) </b>It calls the "<i><b>ZwAllocateVirtualMemory</b></i>" function to reserve memory of size <i><b>ReserveSize</b></i> into the address space of the target process with the <i><b>PAGE_READWRITE</b></i> protection attribute.<br /><b></b><br /><b></b><br /><b>6) </b>It calls the "<i><b>ZwAllocateVirtualMemory</b></i>" function to commit <i><b>CommitSize+0x1000</b></i> of the memory reserved in the previous step.<b></b><br /><b></b><br /><b></b><br /><b></b><br /><i><b>7)</b></i> The extra page committed in the previous step is then given the <i><b>PAGE_GUARD</b></i> protection attribute.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-s7xjTdPjJWM/UJhERJ2TYwI/AAAAAAAABCQ/irLtUFzSAIY/s1600/dddd.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="142" src="http://3.bp.blogspot.com/-s7xjTdPjJWM/UJhERJ2TYwI/AAAAAAAABCQ/irLtUFzSAIY/s400/dddd.png" width="400" /></a></div><br /><br />Here is a similar reversed code of the "<i><b>BaseCreateStack</b></i>" function. From <a href="http://pastebin.com/79ZRpB6X" target="_blank">here</a>.<br /><br /><br />The reason why a <i><b>PAGE_GUARD</b></i> page always exists at the end of committed stack is for the kernel to be notified each time the stack needs to be expanded. For example, if a thread tries to touch its stack's <i><b>PAGE_GUARD</b></i> page, an <i><b>STATUS_GUARD_PAGE_VIOLATION</b></i> exception is raised and swallowed by the kernel and it automatically commits one more page.<br /><br /><i><b>N.B.</b></i> If a thread tries to touch the <i><b>PAGE_GUARD</b></i> page of another thread's stack, the exception is passed to the application or the debugger.<br /><br />After the stack has been allocated in the target process's address space, the "<i><b>CreateRemoteThread</b></i>" function formulates a <i><b>CONTEXT</b></i> structure for the new thread. After the previous steps have completed successfully, the "<b>ZwCreateThread</b>" function is called to initiate the new remote thread.<br /><br />Now let's see how threads are created in <i><b>Windows 7</b></i>.<br /><br />In <i><b>Windows 7</b></i>, if we take the "<i><b>CreateRemoteThread</b></i>" or "<i><b>RtlCreateUserThread</b></i>" function into disassembly, we will see that the "<i><b>dwStackSize</b></i>" is directly passed to the "<i><b>ZwCreateThreadEx</b></i>" function.<br />So, our first assumption here is that stack allocation is now forwarded to the kernel. Also, we can note that now in later versions of <i><b>Windows</b></i> than <i><b>XP</b></i>, the "<i><b>ZwCreateThreadEx</b></i>" function is by default used for thread creation instead of the "<i><b>ZwCreateThread</b></i>" function.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-Lb_Flrj8iZc/UJgyOS8TbZI/AAAAAAAABBs/FxFLsF4Cu8A/s1600/shi.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="111" src="http://1.bp.blogspot.com/-Lb_Flrj8iZc/UJgyOS8TbZI/AAAAAAAABBs/FxFLsF4Cu8A/s400/shi.png" width="400" /></a></div><br />Now let's check the "<i><b>NtCreateThreadEx</b></i>" function in <i><b>ntoskrnl.exe</b></i>.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-F9U3Zg6YJf8/UJhLiWPbOII/AAAAAAAABC8/PMLPbqwfjv8/s1600/Untitled_.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="143" src="http://2.bp.blogspot.com/-F9U3Zg6YJf8/UJhLiWPbOII/AAAAAAAABC8/PMLPbqwfjv8/s400/Untitled_.png" width="400" /></a></div><br />We can easily see in "<i><b>NtCreateThreadEx</b></i>" a call to the "<i><b>PspCreateThread</b></i>" function.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-ZR5rPL6A8lU/UJhLL4SS_oI/AAAAAAAABC0/JMiVv479jBQ/s1600/Untitled.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="153" src="http://2.bp.blogspot.com/-ZR5rPL6A8lU/UJhLL4SS_oI/AAAAAAAABC0/JMiVv479jBQ/s400/Untitled.png" width="400" /></a></div>The <i><b>"PspCreateThread"</b></i> function calls the "<i><b>PspAllocateThread</b></i>" function which calls "<i><b>RtlCreateUserStack</b></i>" function.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-P1ziG2X5xjs/UJhM5JiQKHI/AAAAAAAABDE/DPZuSm9XgWI/s1600/xxxxs.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="86" src="http://4.bp.blogspot.com/-P1ziG2X5xjs/UJhM5JiQKHI/AAAAAAAABDE/DPZuSm9XgWI/s400/xxxxs.png" width="400" /></a></div><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-K_cpT9QAiFI/UJhNlcB636I/AAAAAAAABDM/EO0u4Fvsanc/s1600/zzzzzz.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="81" src="http://3.bp.blogspot.com/-K_cpT9QAiFI/UJhNlcB636I/AAAAAAAABDM/EO0u4Fvsanc/s400/zzzzzz.png" width="400" /></a></div><br />The "<i><b>RtlCreateUserStack</b></i>" function is called after attaching to the target process's address space. Now let's look at the "<i><b>RtlCreateUserStack</b></i>" function in disassembly.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-CJbyV9XnP1M/UJhPyddf-FI/AAAAAAAABDU/LOrGoQx1-3g/s1600/imp.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="93" src="http://3.bp.blogspot.com/-CJbyV9XnP1M/UJhPyddf-FI/AAAAAAAABDU/LOrGoQx1-3g/s400/imp.png" width="400" /></a></div><br />Now it is easy to see that it reads the <i><b>PE header</b></i> from the main executable of the process in which the remote thread is being created unlike <i><b>XP</b></i> where information was extracted from the main executable of the process that creates the thread. Yeah, it seems <i><b>Microsoft</b></i> fixed a very minor issue.<br /><br /><br />From the image above, it is also easy to conclude that if we forced the "<i><b>RtlImageNtHeader</b></i>" function to fail, we can prevent any foreign process including the debugger from attaching to our process. The easiest way to accomplish that is by erasing the <i><b>PE header</b></i> at runtime.&nbsp; Any call to <i><b>ZwCreateThreadEx</b></i> as part of calling the "<i><b>DebugActiveprocess</b></i>" function (Used for attaching to a running process) would fail. For more information and examples, please refer to my <a href="http://waleedassar.blogspot.com/2012/02/debuggers-anti-attaching-techniques_15.html" target="_blank">previous post</a>.<br /><br /><i><b>N.B.</b></i> <i><b>DebugActiveProcess</b></i> calls <i><b>DbgUiIssueRemoteBreakin</b></i> which calls <i><b>~RtlCreateUserThread</b></i> which calls "<i><b>ZwCreateThreadEx</b></i>".<br /><br />One may say, "Erasing the whole <i><b>PE header</b></i> may render many <i><b>APIs</b></i> which read from the <i><b>PE header</b></i> useless e.g. <i><b>FindResource</b></i> or <i><b>GetProcAddress</b></i>". My answer will be "Yes, you are right".<br /><br />So, we should find a smarter way to do it.<br /><br />Okay, let's continue disassembling the "<i><b>RtlCreateUserStack</b></i>" function.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-YRuL5zDj_GA/UJhVk2NxhZI/AAAAAAAABD4/P6QnFcEK6NQ/s1600/shhshshs.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="101" src="http://1.bp.blogspot.com/-YRuL5zDj_GA/UJhVk2NxhZI/AAAAAAAABD4/P6QnFcEK6NQ/s400/shhshshs.png" width="400" />&nbsp;</a></div><div class="separator" style="clear: both; text-align: center;"><br /></div><div class="separator" style="clear: both; text-align: left;">As you can see in the image above if the size of stack commit argument passed to it is zero, it takes the value of the "<i><b>SizeOfStackCommit</b></i>" field from the PE header. The same measure is taken if the size of stack reserve passed is zero. It is also noteworthy that if both the size of stack commit argument passed and "<i><b>SizeOfStackCommit"</b></i> of the PE header are zero, the commit size becomes <i><b>0x4000</b></i> (The default commit size is <i><b>0x4000</b></i>).</div><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-sDh9RVmuQ-Y/UJhXSdBsgwI/AAAAAAAABEA/2kDBDDoD9yc/s1600/d.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="46" src="http://4.bp.blogspot.com/-sDh9RVmuQ-Y/UJhXSdBsgwI/AAAAAAAABEA/2kDBDDoD9yc/s400/d.png" width="400" /></a></div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: left;">The function then checks the size of stack commit against the size of stack reserve. If the size of stack commit happens to be greater, then the size of stack reserve is adjusted to be greater.</div><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-01XX_iLLysM/UJhZTi0240I/AAAAAAAABEI/Ccyel0PcbIM/s1600/shshsh.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="111" src="http://4.bp.blogspot.com/-01XX_iLLysM/UJhZTi0240I/AAAAAAAABEI/Ccyel0PcbIM/s400/shshsh.png" width="400" />&nbsp;</a></div><div class="separator" style="clear: both; text-align: center;"><br /></div><div class="separator" style="clear: both; text-align: left;">The function then ensures that the size to be committed is not less than the "<i><b>MinimumStackCommit</b></i>" field of&nbsp; the process's<i><b> PEB</b></i>. If it is less, the size to be committed is adjusted.</div><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-bJM0z9EUbok/UJhcj9NDb7I/AAAAAAAABEs/f153uuOVdi8/s1600/wut.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="96" src="http://1.bp.blogspot.com/-bJM0z9EUbok/UJhcj9NDb7I/AAAAAAAABEs/f153uuOVdi8/s400/wut.png" width="400" /></a></div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: left;"><br /></div>The function then calls the "<i><b>ZwSetInformationProcess</b></i>" function with the "<i><b>ProcessInformationClass</b></i>" parameter set to <i><b>0x29</b></i> (<i><b>ProcessThreadStackAllocation</b></i>). The size to be reserved is passed in the <i><b>4th</b></i> member of the structure passed in the "<i><b>ProcessInformation</b></i>" parameter.<br /><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: left;">Now let's quickly have a look at the "<i><b>NtSetInformationProcess</b></i>" function.</div><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-b3wQLHj6458/UJhg10FB9_I/AAAAAAAABFQ/GCvw9ciZwrM/s1600/SHIT1.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="152" src="http://3.bp.blogspot.com/-b3wQLHj6458/UJhg10FB9_I/AAAAAAAABFQ/GCvw9ciZwrM/s400/SHIT1.png" width="400" /></a></div><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-MjhJMsq9z50/UJhg6dJUkgI/AAAAAAAABFY/d1hdiNg-E28/s1600/SHIT2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="126" src="http://4.bp.blogspot.com/-MjhJMsq9z50/UJhg6dJUkgI/AAAAAAAABFY/d1hdiNg-E28/s400/SHIT2.png" width="400" /></a></div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: left;">As you can see in the two images above, the value of the <i><b>4th</b></i> member of the structure passed to the "<i><b>ZwSetInformationProcess</b></i>" function is used as the "<i><b>RegionSize</b></i>" parameter passed to the "<i><b>ZwAllocateVirtualMemory</b></i>" function.</div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: left;">Given this knowledge, if we at runtime change the value of the "<i><b>SizeOfStackReserve</b></i>" field of the PE header to a huge value, then we can cause the <i><b>"ZwAllocateVirtualMemory", "ZwSetInformationProcess", "RtlCreateUserThread", "PspAllocateThread", "PspCreateThread", and "NtCreateThreadEx"</b></i> functions to successively fail preventing any foreign processes including debuggers from creating any thread in our process.</div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: left;">A demo can be found <a href="http://code.google.com/p/ollytlscatch/downloads/detail?name=SizeOfStackReserve.exe" target="_blank">here</a> and its source code from <a href="http://pastebin.com/yUsjVbzL" target="_blank">here</a>.</div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: left;">Any comments or ideas are more than welcome.</div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: left;">You can follow me on Twitter <a href="http://www.twitter.com/waleedassar" target="_blank">@waleedassar </a></div></div>http://waleedassar.blogspot.com/2012/11/sizeofstackreserve-as-anti-attaching.htmlnoreply@blogger.com (Walied Assar)4tag:blogger.com,1999:blog-5036198523690297182.post-1825210064449503204Tue, 30 Oct 2012 18:14:00 +00002012-10-31T04:13:17.011-07:00cpuiddetect Virtual PCdetect VirtualPCdetect VPCEFLAGSpop ssTFtrap flagVirtual PC vs. CPUID<div dir="ltr" style="text-align: left;" trbidi="on">In this post i will show another weird behavior of <i><b>Virtual PC 2007</b></i>. This time it is about the <i><b><a href="http://en.wikipedia.org/wiki/CPUID" target="_blank">CPUID</a> </b></i>instruction. As most of you already know well what the <i><b>CPUID</b></i> is for and how it works, i will directly jump into the main topic.<br /><br />In <i><b>Virtual PC</b></i>, executing <i><b>CPUID</b></i> disables interrupts for one instruction. Oh, wait, how is that?<br /><br />Imagine we want to trace a sequence of <i><b>x86</b></i> instruction. What the debugger does in that situation is as follows:<br />1) Calls the "<i><b>GetThreadContext</b></i>" function to extract the current context of the thread executing this sequence of instructions.<br />2) Modifies the "<a href="http://en.wikipedia.org/wiki/FLAGS_register" target="_blank"><i><b>EFLAGS</b></i></a>" register of the "<i><b>CONTEXT</b></i>" structure such that the <i><b>Trap flag (TF)</b></i> is set. <a href="http://en.wikipedia.org/wiki/FLAGS_register" target="_blank"><i><b>EFLAGS</b></i></a> is situated at offset <i><b>0xC0</b></i> from the start of the structure for the <i><b>x86</b></i> version.<i><b> TF</b></i> is bit number <i><b>8 (0x100).</b></i><br />3) Calls the "<i><b>SetThreadContext</b></i>" and "<b>ContinueDebugEvent</b>" functions to continue execution.<br /><br />When the trap flag is set, after executing an<i><b> x86</b></i> instruction, an exception <i><b>EXCEPTION_SINGLE_STEP</b></i> is raised and trap flag is cleared.<br /><br />The debugger receives the exception and resets the trap flag as shown above and so on.<br /><br />Disable interrupts, what does that mean?<br />Executing certain instructions when the trap flag is set, no <i><b>EXCEPTION_SINGLE_STEP</b></i> exception is raised. The exception is raised after executing the instruction following them. One example instruction that disables interrupts is <i><b>POP SS</b></i>. <i><b>POP SS</b></i> has been used for a long time as an<i><b> anti-tracing</b></i> trick. Since it disables interrupts for one instruction, dumping the <i><b>EFLAGS</b></i> register to stack via . <i><b>PUSHFD</b></i> reveals the <b><i>Trap Flag</i></b>.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-VEEhtcorWtk/UJAU-fYO13I/AAAAAAAAA-M/4wra8-IkzCU/s1600/pic1.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="296" src="http://2.bp.blogspot.com/-VEEhtcorWtk/UJAU-fYO13I/AAAAAAAAA-M/4wra8-IkzCU/s400/pic1.png" width="400" /></a></div><br /><br />Executing <i><b>CPUID</b></i> in <i><b>Virtual PC 2007</b></i>, i found out that it has the same effect as <i><b>POP SS</b></i>. <b>CPUID</b> disables interrupts for one instruction.<br /><br />I created a simple demo that exploits this bug to detect whether it is running inside <i><b>Virtual PC 2007</b></i>. It has been tested on <i><b>Windows XP SP2</b></i> running inside <i><b>Virtual PC 2007</b></i>.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-oOaC9kZBEeY/UJAY-f4taAI/AAAAAAAAA-w/jWpvizpC5c4/s1600/pic2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="221" src="http://1.bp.blogspot.com/-oOaC9kZBEeY/UJAY-f4taAI/AAAAAAAAA-w/jWpvizpC5c4/s400/pic2.png" width="400" /></a></div><br />Reason for that is still under research but it seems to be due to the <i><b>Virtualized CPUID</b></i> (<i><b>Intel FlexMigration</b></i>) hardware support since the trick only works if Hardware Virtualization is enabled.<br /><br />You can download the demo from <a href="http://code.google.com/p/ollytlscatch/downloads/detail?name=VPC_CPUID.exe" target="_blank">here</a> and its source code from <a href="http://pastebin.com/HVActZMC" target="_blank">here</a>.<br /><br />N.B. <i><b>VirtualBox v4.1.22 r80657</b></i> is also affected by this bug.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-ROwhgCyypUM/UJD6oQLdyBI/AAAAAAAAA_U/IkzgLnaFIL0/s1600/vvvv.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="210" src="http://4.bp.blogspot.com/-ROwhgCyypUM/UJD6oQLdyBI/AAAAAAAAA_U/IkzgLnaFIL0/s400/vvvv.png" width="400" /></a></div><br />N.B. <b>Parallels Desktop</b> is reportedly affected by this bug.<br /><br />You can follow me on Twitter <a href="https://www.twitter.com/waleedassar" target="_blank"><i><b>@waleedassar</b></i></a>.</div>http://waleedassar.blogspot.com/2012/10/virtual-pc-vs-cpuid.htmlnoreply@blogger.com (Walied Assar)2tag:blogger.com,1999:blog-5036198523690297182.post-5371825008831600317Mon, 29 Oct 2012 17:07:00 +00002016-12-03T13:32:08.518-08:00debug control registerdetect Virtual PCdetect VirtualPCdr7vpc 2007Virtual PC vs. DR7<div dir="ltr" style="text-align: left;" trbidi="on">In this post i will show you another weird behavior of <i><b>Virtual PC 2007.</b></i> This time the trick is about how <i><b>Virtual PC</b></i> handles the debug register <i><b>DR7</b></i> known as <i><b>Debug Control</b></i> register.<br /><br />For those who don't know,<i><b> DR7</b></i> is used to specify the conditions under which the <i><b>EXCEPTION_SINGLE_STEP</b></i> exception is triggered for addresses held in <i><b>DR0-DR3</b></i>.<br />If we want to dissect <i><b>DR7</b></i>, it would be as follows:<br />Bit 0&nbsp;&nbsp;&nbsp;&nbsp; ---&gt; <i><b>DR0</b></i> is locally enabled.<br />Bit 1&nbsp;&nbsp;&nbsp;&nbsp; ---&gt; <i><b>DR0</b></i> is globally enabled.<br />Bit 2 &nbsp; &nbsp; ---&gt; <i><b>DR1</b></i> is locally enabled.<br />Bit 3&nbsp;&nbsp;&nbsp;&nbsp; ---&gt; <i><b>DR1</b></i> is globally enabled.<br />Bit 4&nbsp;&nbsp;&nbsp;&nbsp; ---&gt; <i><b>DR2</b></i> is locally enabled.<br />Bit 5&nbsp;&nbsp;&nbsp;&nbsp; ---&gt; <i><b>DR2</b></i> is globally enabled.<br />Bit 6 &nbsp; &nbsp; ---&gt; <i><b>DR3</b></i> is locally enabled.<br />Bit 7&nbsp;&nbsp;&nbsp;&nbsp; ---&gt; <i><b>DR3</b></i> is globally enabled.<br /><br />Bit 8 &nbsp; &nbsp; ---&gt; The "<i><b>Local Enable Bit</b></i>". Also for "<b><i>Last Branch</i></b>" tracing.<br />Bit 9 &nbsp; &nbsp; ---&gt; The "<i><b>Global Enable Bit</b></i>". Also for "<b><i>Last Branch</i></b>" tracing.<br />Bit 10 &nbsp; ---&gt; Reserved.<br />Bit 11&nbsp; ----&gt; Reserved.<br />Bit 12 -----&gt; IR<br />Bit 13 -----&gt; GD<br />Bit 14 -----&gt; TB<br />Bit 15 -----&gt; TT<br /><br />Bit 16 -----<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | ----&gt; When <i><b>DR0</b></i> is triggered. <br />Bit 17 -----<br />Bit 18 -----<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | ----&gt; Size of <i><b>DR0's trigger condition.</b></i><br />Bit 19 -----<br />Bit 20 -----<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | ----&gt; When <i><b>DR1</b></i> is triggered. <br />Bit 21 -----<br />Bit 22 -----<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | ----&gt; Size of <i><b>DR1's trigger condition.</b></i><i><b></b></i><br />Bit 23 -----<br /><br />Bit 24 -----<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | ----&gt; When <i><b>DR2</b></i> is triggered. <br />Bit 25 -----<br />Bit 26 -----<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | ----&gt; Size of <i><b>DR2's trigger condition.</b></i><i><b></b></i><br />Bit 27 -----<br />Bit 28 -----<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | ----&gt; When <i><b>DR3</b></i> is triggered. <br />Bit 29 -----<br />Bit 30 -----<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | ----&gt; Size of <i><b>DR3's trigger condition.</b></i><i><b></b></i><br />Bit 31 -----<br /><br />For example:<br />Imagine we want to place a <i><b>Hardware-Breakpoint-On-Execution</b></i> for an instruction at <i><b>0x401000</b></i>. See image below.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-Pki2bEH5pEc/UI6aSehi_QI/AAAAAAAAA9g/t8DssXs1tlk/s1600/pic1.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="257" src="https://2.bp.blogspot.com/-Pki2bEH5pEc/UI6aSehi_QI/AAAAAAAAA9g/t8DssXs1tlk/s400/pic1.png" width="400" /></a></div><br />What the debugger does in this case is:<br />1) Sets <i><b>DR0</b></i> to <i><b>0x401000</b></i>.<br />2) Sets bit 0 of <i><b>DR7</b></i> to 1.<br />3) Sets bit 8 of <i><b>DR7</b></i> to 1 (for <i><b>backward compatibility</b></i>).<br />4) Sets bits 16 and 17 of <i><b>DR7</b></i> to 00 (00 means <i><b>On-Execution</b></i>).<br /><br />And if we then want to place a <i><b>Hardware-Breakpoint-On-Write-Four</b></i> for memory at <i><b>0x10000</b></i>. See image below.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-SOrZ_NUwt_Y/UI6bS7k4aWI/AAAAAAAAA9o/KaY7Uk-T9eQ/s1600/pic2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="143" src="https://4.bp.blogspot.com/-SOrZ_NUwt_Y/UI6bS7k4aWI/AAAAAAAAA9o/KaY7Uk-T9eQ/s400/pic2.png" width="400" /></a></div>What the debugger does in this case is:<br />1) Sets <i><b>DR1</b></i> to <i><b>0x10000</b></i>.<br />2) Sets bit 2 of <i><b>DR7</b></i> to 1.<br />3) Sets bit 8 of <i><b>DR7</b></i> to 1 (for <i><b>backward compatibility</b></i>).<br />4) Sets bits&nbsp; 20 and 21 of <i><b>DR7</b></i> to 01 (01 means <i><b>On-Write</b></i>).<br />5) Sets bits&nbsp; 22 and 23 of <i><b>DR7</b></i> to 11 (11 for the size of trigger condition means to watch four bytes).<br /><br />Now let's try to get back to the main topic of this post.<br /><br />Hereafter, i will call the second byte of <i><b>DR7</b></i> (byte <i><b>0xBB</b></i> of <i><b>0xDDCCBBAA</b></i>) the <i><b>flags byte</b></i>, just for brevity. <br /><br />On <i><b>Windows XP</b></i>, if we set the <i><b>flags byte</b></i> to any value ranging from <i><b>0x00</b></i> to <i><b>0xFF</b></i>, the breakpoint is always active and the exception is always raised whenever the trigger condition is met e.g. if we set <i><b>DR7</b></i> to <i><b>0x0000FF01</b></i> (a hardware breakpoint <i><b>On-Execution</b></i> with <i><b>Local enable, global enable, reserved, reserved, IR, GD, TB, </b></i>and<i><b> TT</b></i> bits set), the exception is raised whenever the address in <i><b>DR0</b></i> executes.<br />The same applies for <i><b>Windows 7</b></i>.<br /><br /><i><b>What about Virtual PC 2007?&nbsp;</b></i><br /><i><b><br /></b></i>In <i><b>Virtual PC 2007</b></i> with <i><b>Windows XP</b></i> installed inside, with certain flags set in <i><b>DR7</b></i> e.g. <i><b>0x00003F01</b></i>, the breakpoint is <b>sometimes </b>not activated.<br /><br />So, i created simple executable that brute-forces the<i><b> DR7's flag byte</b></i> and based on the number of times the exception is raised it determines whether it is running inside <i><b>Virtual PC 2007</b><b>.</b></i><br /><br />You can download the <a href="http://code.google.com/p/ollytlscatch/downloads/detail?name=VPC_DR7.exe" target="_blank">demo</a> from here and its source code from <a href="http://pastebin.com/cy3axkKj" target="_blank">here</a>.<br /><i><b><i><b>&nbsp;</b></i> </b></i><br /><i><b>N.B. It has been tested with Windows XP SP2 and SP3.</b></i><br /><i><b>N.B. VirtualBox</b></i> is also affected, but i will leave this for a future post.<i><b><br /></b></i><br /><i><b><br /></b></i>Any comments or ideas are very welcome. You can also follow me on Twitter <a href="http://www.twitter.com/waleedassar" target="_blank">@waleedassar</a></div>http://waleedassar.blogspot.com/2012/10/virtual-pc-vs-dr7.htmlnoreply@blogger.com (Walied Assar)0tag:blogger.com,1999:blog-5036198523690297182.post-7987546556295023209Sat, 27 Oct 2012 19:17:00 +00002012-10-27T12:40:28.445-07:00detect Virtual PCdetect VirtualPCEFLAGSResume flagVirtual PCVirtual PC vs. Resume Flag<div dir="ltr" style="text-align: left;" trbidi="on">In this post i will show you another weird behavior of <i><b>Virtual PC 2007</b></i>. I encountered this weird behavior while playing with <i><b>Virtual PC 2007</b></i> with <i><b>Windows XP SP3</b></i> installed inside. The behavior is all about how a <i><b>Windows XP</b></i> <i><b>Virtual PC</b></i> virtual machine handles the <i><b>Resume Flag</b></i>.<br /><br />For those who don't know, the <i><b>Resume Flag</b></i> (Flag no. <i><b>16</b></i> in the <a href="http://en.wikipedia.org/wiki/FLAGS_register" target="_blank"><b><i>EFLAGS</i></b></a> register) is used to temporarily disable <i><b>Hardware Breakpoints</b></i> exceptions for one instruction. Without it, a <i><b>Hardware-Breakpoint-On-Execution</b></i> would infinitely trigger an <i><b>EXCEPTION_SINGLE_STEP</b></i> exception.<br /><br />According to <a href="https://twitter.com/osxreverser" target="_blank">@osxreverser</a>, <i><b>Windows XP</b></i> does not support the <i><b>Resume Flag</b></i> (<i>RF</i>). I was also amazed to see that also <i><b>WinDbg</b></i> and <i><b>OllyDbg v1.10</b></i> don't use the resume flag. They use the <i><b>Trap Flag </b></i>(<i><b>TF</b></i>) instead.<br /><br />Running a simple executable that on purpose makes use of the <i><b>Resume Flag</b></i> inside an <i><b>XP </b></i>Virtual PC Virtual Machine, i found out that<i><b> </b></i>execution flows normally as if XP supports the resume flag.<br /><br />Given the finding above, i created a small executable that tries to detect if it is running inside Virtual PC 2007.<br />You can find it <a href="http://code.google.com/p/ollytlscatch/downloads/detail?name=VPC_RF_Trick.exe" target="_blank">here</a> and its source code from <a href="http://pastebin.com/Nsv5B1yk" target="_blank">here</a>. <br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-qsv-GVOwgCg/UIw4n3HCmjI/AAAAAAAAA9A/8R5jS5zxH9Y/s1600/print.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="135" src="http://3.bp.blogspot.com/-qsv-GVOwgCg/UIw4n3HCmjI/AAAAAAAAA9A/8R5jS5zxH9Y/s400/print.png" width="400" /></a></div><br />I guess the finding above only applies if the host operating system itself supports the<i><b> resume flag </b></i>e.g. <i><b>Windows 7</b></i> or later.<br /><br /><i><b>N.B. This topic is still under research. </b></i><br /><br />Please don't hesitate to leave a comment.<br />You can also follow me on Twitter <a href="http://www.twitter.com/waleedassar" target="_blank">@waleedassar </a><br /><br /></div>http://waleedassar.blogspot.com/2012/10/virtual-pc-vs-resume-flag.htmlnoreply@blogger.com (Walied Assar)2tag:blogger.com,1999:blog-5036198523690297182.post-6465339603068161029Fri, 26 Oct 2012 00:58:00 +00002012-10-27T23:36:33.756-07:00detect Virtual PCdetect VPCVirtual PCVPCVirtual PC Machine Reset<div dir="ltr" style="text-align: left;" trbidi="on">While playing with <i><b>Virtual PC 2007</b></i>, i came up with an interesting trick not only to detect <i><b>Virtual PC 2007</b></i> but also to reset (restart) the Virtual Machine.<br /><br />The trick is so simple that all you need to do in your code is execute <span class="co1"><i><b>"\x0F\xC7\xC8\x05\x00"</b></i>.&nbsp;</span><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-WrJrRAEBrI4/UInf2DJY_-I/AAAAAAAAA8Y/8nk5UwJ1rlw/s1600/mmm.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="70" src="http://1.bp.blogspot.com/-WrJrRAEBrI4/UInf2DJY_-I/AAAAAAAAA8Y/8nk5UwJ1rlw/s400/mmm.jpg" width="400" /></a></div><br /><span class="co1">Executing that x86 instruction sequence causes the following message to pop up.</span><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-2OLAHE9dyI4/UInePREe5EI/AAAAAAAAA8Q/Zk-UJ6NQ3YE/s1600/A4tAsQuCQAATKB9.jpg+large.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="225" src="http://4.bp.blogspot.com/-2OLAHE9dyI4/UInePREe5EI/AAAAAAAAA8Q/Zk-UJ6NQ3YE/s400/A4tAsQuCQAATKB9.jpg+large.jpg" width="400" /></a></div><span class="co1">A POC can be found <a href="http://code.google.com/p/ollytlscatch/downloads/detail?name=VirtualPC_IntError.exe" target="_blank">here</a> and its source from <a href="http://pastebin.com/exAK5XQx" target="_blank">here</a>.</span><br /><span class="co1"><br /></span><span class="co1">N.B. Other x86 instruction sequences can cause the same result.</span><br /><span class="co1"><br /></span><span class="co1">Any comments or ideas are welcome.</span><br /><span class="co1">You can follow me on Twitter <a href="http://www.twitter.com/waleedassar" target="_blank">@waleedassar</a></span></div>http://waleedassar.blogspot.com/2012/10/virtual-pc-machine-reset.htmlnoreply@blogger.com (Walied Assar)1tag:blogger.com,1999:blog-5036198523690297182.post-238890052288860752Fri, 28 Sep 2012 14:48:00 +00002012-10-25T16:01:18.702-07:00PAGE_EXECUTE_WRITECOPYPAGE_WRITECOPYVirtualQueryPAGE_EXECUTE_WRITECOPY As Anti-Debug Trick<div dir="ltr" style="text-align: left;" trbidi="on">In this post, i will share with you a poorly discussed anti-debug trick that i <span style="font-size: large;"><i><b>may be the first one to discover or disclose</b></i></span>. <br /><br />Now let's start with a quick introduction. If a memory page with the "<i><b>PAGE_EXECUTE_READWRITE</b></i>" access protection attributes is requested from the OS, then a page with the "<i><b>PAGE_EXECUTE_WRITECOPY</b></i>" attributes, not the "<i><b>PAGE_EXECUTE_READWRITE</b></i>" attributes is given.&nbsp;&nbsp;&nbsp; <br /><br />The reason for that behavior is so simple, that is, the OS memory manager wants to physically share the page between all the process instances (since it is guaranteed to be the same in all the process instances before any write).<br /><br />Once you make the first write to the new page, the OS assigns a private copy of the page to the process in which the write occurrs and the page attributes change to <i><b>PAGE_EXECUTE_READWRITE</b></i>.<br /><br /><b><i>N.B.</i></b> The same applies to pages requested with the <i><b>PAGE_READWRITE</b></i> attributes. They are initially given the "<b><i>PAGE_WRITECOPY</i></b>" attributes and after the first write, they turn into <i><b>PAGE_READWRITE</b></i>.<br /><br />N.B. <i><b>PAGE_EXECUTE_WRITECOPY</b></i> and <b><i>PAGE_WRITECOPY</i></b> are not valid parameters to the "<i><b>VirtualAlloc</b></i>" or "<b><i>VirtualAllocEx</i></b>" function.<br /><br />Now if you have a section in your executable with the <b><i>read, write, and execute</i></b> access attributes (See section <i><b>xyz</b></i> in the image below), then the abovementioned applies to it.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-793dSW4aJoA/UGWfVyZxzGI/AAAAAAAAA3s/8jGhkjRe9CE/s1600/sections.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="352" src="http://3.bp.blogspot.com/-793dSW4aJoA/UGWfVyZxzGI/AAAAAAAAA3s/8jGhkjRe9CE/s400/sections.jpg" width="400" /></a></div>The access protection attributes given to section <i><b>xyz</b></i> causes its memory page to be mapped with the "<b><i>PAGE_EXECUTE_WRITECOPY</i></b>" attributes. See image below.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-618vTv0eUoc/UGWhbC5SqAI/AAAAAAAAA30/VvLrv31-AKI/s1600/access_init.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="250" src="http://1.bp.blogspot.com/-618vTv0eUoc/UGWhbC5SqAI/AAAAAAAAA30/VvLrv31-AKI/s400/access_init.jpg" width="400" /></a></div>If we design section <i><b>xyz</b></i> in a way that it is never written to (e.g. does not contain self-modifying code) throughout the whole lifetime of the process, then the page will always be <i><b>PAGE_EXECUTE_WRITECOPY</b></i> even at process exit.<br /><br />If the attributes change to <i><b>PAGE_EXECUTE_READWRITE, </b></i>that means the page must have been written to e.g. when another process, mostly a debugger, had called the "<i><b>WriteProcessMemory</b></i>" function while <i><b>stepping-over</b></i>, <b><i>tracing-over</i></b>, or <i><b>placing</b></i> <i><b>software breakpoints</b></i>. That definitely means the process is being debugged. See images below.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-bvP3wKODGRk/UGWnjGmReLI/AAAAAAAAA4Y/xneo3Vvwf3g/s1600/after.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="93" src="http://4.bp.blogspot.com/-bvP3wKODGRk/UGWnjGmReLI/AAAAAAAAA4Y/xneo3Vvwf3g/s400/after.jpg" width="400" /></a></div><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/--4-1B4s9CtA/UGWzkD00r2I/AAAAAAAAA48/8ol4_gqjVTg/s1600/after_.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="248" src="http://3.bp.blogspot.com/--4-1B4s9CtA/UGWzkD00r2I/AAAAAAAAA48/8ol4_gqjVTg/s400/after_.jpg" width="400" /></a></div><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-JjYyxUanHZM/UGWz6kM8QjI/AAAAAAAAA5E/rJuWK2jX7zw/s1600/after1.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="78" src="http://3.bp.blogspot.com/-JjYyxUanHZM/UGWz6kM8QjI/AAAAAAAAA5E/rJuWK2jX7zw/s400/after1.jpg" width="400" /></a></div><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-2bMAZiIfG5o/UGW0QpVJFKI/AAAAAAAAA5U/gGn9wfraSbg/s1600/after1_.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="250" src="http://4.bp.blogspot.com/-2bMAZiIfG5o/UGW0QpVJFKI/AAAAAAAAA5U/gGn9wfraSbg/s400/after1_.jpg" width="400" /></a></div><br />Now our executable of question can call the "<i><b>VirtualQuery</b></i>" function to check the page protection attributes of section <b><i>xyz</i></b>. If it is something other than <i><b>PAGE_EXECUTE_WRITECOPY</b></i>, then a debugger is present and the process should quit.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-u-JPmGt11hg/UGW1pdYX4TI/AAAAAAAAA5c/zHU9hwtNezE/s1600/vq.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="86" src="http://4.bp.blogspot.com/-u-JPmGt11hg/UGW1pdYX4TI/AAAAAAAAA5c/zHU9hwtNezE/s400/vq.jpg" width="400" /></a></div><i><b><br /></b></i>The good thing about this trick is that, unlike the <b><i>0xCC-scanning</i></b> trick, it can detect software breakpoints even if there are no longer active (removed by the debugger).<br /><br />Also, most debuggers in their default settings are used to place software breakpoints on modules' entry points, which means the page protection attributes change even before the reverse engineer starts to debug the module.<br /><br />A common way to bypass this trick for <i><b>stepping-over</b></i> and <i><b>tracing-over</b></i> is to use hardware breakpoints which is an available option in <i><b>OllyDbg v1.10</b></i> and <b>OllyDbg v2.01 (alpha 4)</b>.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-Cq4ym0_n1dk/UGW315TTfYI/AAAAAAAAA5k/YQI82dkxzVI/s1600/olly2.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="350" src="http://1.bp.blogspot.com/-Cq4ym0_n1dk/UGW315TTfYI/AAAAAAAAA5k/YQI82dkxzVI/s400/olly2.jpg" width="400" /></a></div><br />A simple <a href="http://code.google.com/p/ollytlscatch/downloads/detail?name=WriteCopy_Trick_.exe" target="_blank">demo</a> can be found here and its source code from <a href="http://pastebin.com/62De887S" target="_blank">here</a>.<br /><br />Any ideas or comments are very welcome.<br /><br />You can follow me on Twitter <i><b><a href="https://twitter.com/waleedassar" target="_blank">@waleedassar</a></b></i></div>http://waleedassar.blogspot.com/2012/09/pageexecutewritecopy-as-anti-debug-trick.htmlnoreply@blogger.com (Walied Assar)13tag:blogger.com,1999:blog-5036198523690297182.post-4329380136697982203Sat, 08 Sep 2012 13:46:00 +00002012-09-08T08:41:45.471-07:000x12Banti-dumpantidumpERROR_PARTIAL_COPYPAGE_GUARDSizeOfImageVirtualProtectexAnti-Dumping - Part 3<div dir="ltr" style="text-align: left;" trbidi="on">In this post i will share with you a couple of small tricks that can be deployed to harden or defeat memory dumping attempts. As i have just mentioned they are small tricks, so don't flame at me.<br /><br />The first trick briefly involves appending a special <i><b><a href="http://msdn.microsoft.com/en-us/library/windows/desktop/ms680341%28v=vs.85%29.aspx" target="_blank">section header</a></b></i> to the <i><b>section table</b></i> of your executable. The new section header is to be set with a huge <b><i>virtual size</i></b>. Don't worry, this is not going to affect the file size (on disk) since we can set the <i><b>raw size</b></i> of the new section to zero (<b><i>completely virtual section</i></b>).<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-T25dIYMKjm8/UEs_gkbd_WI/AAAAAAAAA10/5fE9BY2YsXg/s1600/Untitled.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="287" src="http://4.bp.blogspot.com/-T25dIYMKjm8/UEs_gkbd_WI/AAAAAAAAA10/5fE9BY2YsXg/s400/Untitled.jpg" width="400" /></a></div><br />This results in the the "<i><b>SizeOfImage</b></i>" field of the <a href="http://msdn.microsoft.com/en-us/library/windows/desktop/ms680339%28v=vs.85%29.aspx" target="_blank"><i><b>IMAGE_OPTIONAL_HEADER</b></i></a> structure being huge as well.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-TbTjtpnCJ6Q/UEtO1MajwAI/AAAAAAAAA3E/NjSaQ-wdfmI/s1600/sadasd.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="290" src="http://2.bp.blogspot.com/-TbTjtpnCJ6Q/UEtO1MajwAI/AAAAAAAAA3E/NjSaQ-wdfmI/s400/sadasd.jpg" width="400" /></a></div><br />Unlike old anti-dumping tricks, we don't have to forge the "<i><b>SizeOfImage</b></i>" field of <a href="http://undocumented.ntinternals.net/UserMode/Structures/LDR_MODULE.html" target="_blank"><i><b>PEB.LoaderData</b></i></a> or that in the PE Header memory page. Here, we give the dumping tools a huge value that they are very likely to fail to allocate using e.g. the "<i><b>VirtualAlloc</b></i>" function or its likes. Of course, this trick does not defeat dumping tools that read the memory of processes page by page.<br /><br />Since the raw size of this huge section is zero, then the new section will be zero-initialized and the OS memory manager will throw it away making the memory usage of such process as smooth as possible.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-oRnoJvFr8io/UEtDirxDdWI/AAAAAAAAA2Y/zMYaVE7BxDo/s1600/untdd.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="122" src="http://3.bp.blogspot.com/-oRnoJvFr8io/UEtDirxDdWI/AAAAAAAAA2Y/zMYaVE7BxDo/s400/untdd.jpg" width="400" /></a></div><br />It is now obvious that the new section should be left as it is. Your code should never read, write, or execute it. As any attempt to e.g. write to it results in the OS memory manager restoring the whole section into memory.<br /><br />Here you can find a <a href="http://code.google.com/p/ollytlscatch/downloads/detail?name=MMM.exe" target="_blank">demo</a>. <br /><br />The second trick was first mentioned by <a href="https://twitter.com/kris_kaspersky" target="_blank">Kris Kaspersky</a>. The trick is very nice and simple. If we set the memory protection of one section as <i><b>PAGE_GUARD</b></i>, then the "<i><b>ReadProcessMemory</b></i>" function will fail usually with the system error code<b> </b><i>ERROR_PARTIAL_COPY</i>, 0x12B. To defeat this trick, dumping tools are now using the "<a href="http://msdn.microsoft.com/en-us/library/windows/desktop/aa366899%28v=vs.85%29.aspx" target="_blank"><i><b>VirtualProtectEx</b></i></a>" function to remove the <i><b>PAGE_GUARD</b></i> attribute, then read the section, and finally restore the <i><b>PAGE_GUARD</b></i> attribute.<br /><br />To enhance this trick, i have created a watching thread that infinitely calls the "<i><b>VirtualQuery</b></i>" function and once it detects that <i><b>PAGE_GUARD</b></i> is removed from the section's memory protection attributes, it just terminates the process. Here is the <a href="http://pastebin.com/QYMTTkXc" target="_blank">code</a> and here is a <a href="http://code.google.com/p/ollytlscatch/downloads/detail?name=antidump_guard.exe" target="_blank">demo</a>.<br /><br /><b><i>N.B.</i></b> For the second trick to be effective, you should place the sections you want to protect after the <i><b>PAGE_GUARD </b></i>section so that the process terminates before them being dumped.<br /><br /><i><b>N.B.</b></i> The second trick theoretically has better chances to work on multi-processor systems than on single-processor ones.<br /><br />Any comments or ideas are very welcome.<br /><br />You can follow me on Twitter <a href="http://twitter.com/waleedassar" target="_blank">@waleedassar</a></div>http://waleedassar.blogspot.com/2012/09/anti-dumping-part-3.htmlnoreply@blogger.com (Walied Assar)5tag:blogger.com,1999:blog-5036198523690297182.post-750725646246474626Sun, 05 Aug 2012 21:00:00 +00002012-09-07T11:53:33.768-07:00MajorSubsystemVersionMinorSubsystemVersionNtMajorVersionNtMinorVersionNtQuerySectionVS2010win2000windows 2000Major / MinorSubsystemVersion<div dir="ltr" style="text-align: left;" trbidi="on">If you are still using <i><b>Windows 2000</b></i>, you must have noticed that certain executables refuse to run. Actually, this is due to the executables being built with <i><b>Microsoft Visual Studio</b></i> <b><i>2010</i></b> which sets the <i><b>MajorSubSystemVersion</b></i> and <b><i>MinorSubsystemVersion</i></b> in the <i><b>PE header</b></i> to <b><i>5</i></b> and <i><b>1</b></i>. In other words, it creates executables to run on <b><i>Windows XP</i></b> (<i><b>5.1</b></i>) and above. This causes <b><i>Windows 2000</i></b> (<i><b>5.0</b></i>) to refuse to load these executables.<br /><br />Now, let's see where the check occurs and how to bypass it. The first place to check must be the <b><i>kernel32 "CreateProcess"</i></b> function.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-kLfbzC0U9_I/UBs4JJJDrYI/AAAAAAAAAx4/BcYHlpEM_D0/s1600/untitled.bmp" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="50" src="http://2.bp.blogspot.com/-kLfbzC0U9_I/UBs4JJJDrYI/AAAAAAAAAx4/BcYHlpEM_D0/s400/untitled.bmp" width="400" /></a></div><br />If we start at address <i><b>0x7C4F1ECE</b></i>, we can see a call to the <b><i>ntdll "<a href="http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/NT%20Objects/Section/NtQuerySection.html" target="_blank">ZwQuerySection</a>"</i></b> function with the "<i><b>InformationClass</b></i>" parameter set to 1 (<i><b>SectionImageInformation</b></i>). After the "ZwQuerySection" function has returned successfully, the "<a href="http://undocumented.ntinternals.net/UserMode/Structures/SECTION_IMAGE_INFORMATION.html" target="_blank"><i><b>SECTION_IMAGE_INFORMATION</b></i></a>" structure should be filled with some useful data. Among the data returned are the executable's subsystem type and minor and major versions.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-QtF8aya0ToM/UBs_JJK-7NI/AAAAAAAAAyc/blXGvO2QXrU/s1600/next.bmp" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="60" src="http://3.bp.blogspot.com/-QtF8aya0ToM/UBs_JJK-7NI/AAAAAAAAAyc/blXGvO2QXrU/s400/next.bmp" width="400" /></a></div><br />Then comes a check for the subsystem type. The subsystem type must be either GUI (<i><b>IMAGE_SUBSYSTEM_WINDOWS_GUI</b></i>) or console (<b><i>IMAGE_SUBSYSTEM_WINDOWS_CUI</i></b>). If it is not any of these two types, the "<i><b>CreateProcess</b></i>" function fails.<br /><br /><br />As you can see in the image above, at address <i><b>0x7C4F1F91, </b></i>the major and minor subsystem versions extracted from the PE header via the "<i><b>ZwQuerySection</b></i>" function are passed to the "<b><i>CheckSubSystem</i></b>" function. If the "<b><i>CheckSubSystem</i></b>" function returns <i><b>TRUE</b></i>, the "<i><b>CreateProcess</b></i>" function proceeds and if it returns <i><b>FALSE</b></i>, the "<i><b>CreateProcess</b></i>" function fails as such. Now, let's check this function.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-2ZEjOtxMpgw/UBtCovYMVnI/AAAAAAAAAzA/F6b4bbfbwVk/s1600/checkf1.bmp" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="57" src="http://2.bp.blogspot.com/-2ZEjOtxMpgw/UBtCovYMVnI/AAAAAAAAAzA/F6b4bbfbwVk/s400/checkf1.bmp" width="400" /></a></div><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-TBtFF_WooJo/UBtCvJMTJ9I/AAAAAAAAAzI/n1wF_yOm1Sw/s1600/checkf2.bmp" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="21" src="http://2.bp.blogspot.com/-TBtFF_WooJo/UBtCvJMTJ9I/AAAAAAAAAzI/n1wF_yOm1Sw/s400/checkf2.bmp" width="400" /></a></div><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-77qsiRvnSX8/UBtLgUOSGVI/AAAAAAAAAz0/XqeUcCIqSAQ/s1600/reversed.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="143" src="http://1.bp.blogspot.com/-77qsiRvnSX8/UBtLgUOSGVI/AAAAAAAAAz0/XqeUcCIqSAQ/s400/reversed.jpg" width="400" /></a></div><br /><div class="separator" style="clear: both; text-align: center;"></div>As you can see in the disassembly and C-code in the three images above, if the subsystem versions extracted from the PE header are less than <i><b>3.10</b></i>, the "<b><i>CheckSubsystem</i></b>" function returns <i><b>FALSE</b></i>. Then comes the important part, if the "<i><b>MajorSubsystemVersion"</b></i> extracted from the PE header is greater than the value of the "<i><b>NtMajorVersion</b></i>" field (The field is at offset <i><b>0x26C</b></i> from the <a href="http://www.nirsoft.net/kernel_struct/vista/KUSER_SHARED_DATA.html" target="_blank"><i><b>_KUSER_SHARED_DATA</b></i></a> page), the function fails. The same applies for "<b><i>MinorSubSystemVersion</i></b>" if "<i><b>MajorSubsystemVersion</b></i>" and "<b><i>NtMajorVersion</i></b>" are equal.<br /><br />N.B. <i><b>NtMajorVersion</b></i> and <b><i>NtMinorVersion</i></b> are usually the same as the OS version info. returned by the <i><b>kernel32 "GetVersion" or "GetVersionEx"</b></i> functions. <br /><br />As a developer, bypassing the check can easily be done by using <i><b>Platform Toolset v9</b></i> in <b><i>microsoft visual studio</i></b> (thanks <a href="https://twitter.com/skier_t" target="_blank">@skier_t</a>) or by directly editing the PE header of the executable using any <i><b>PE Editor</b></i>.<b><i>&nbsp;</i></b> <br /><br />Imagine the scenario where the executable in question has CRC check upon its PE header as part of the implemented protection scheme. In this case, as a user, you won't be able to run the executable since any attempt to edit the PE header will cause the CRC check to fail. This leads us to find a system-wide solution. Yes, <i><b>patching</b></i>.<br /><br />Speaking of patching, we have two options:<br /><br /><i><b>1)</b></i> The first is to patch a couple of addresses inside the "<i><b>CheckSubSystem</b></i>" function (Actually, i don't recommend patching the return value check).<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-haPqRL0xqeI/UBtbHbRP4EI/AAAAAAAAA0Y/E7n2SDngHyk/s1600/a7a.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="91" src="http://1.bp.blogspot.com/-haPqRL0xqeI/UBtbHbRP4EI/AAAAAAAAA0Y/E7n2SDngHyk/s400/a7a.jpg" width="400" /></a></div><br />To implement the check bypass, i created&nbsp; a dynamic link library, <i><b>hooksubsystem.dll</b></i> that once injected into a process bypasses the subsystem version check.<br /><br />You can find the source code of <i><b>hooksubsystem.dll</b></i> <a href="http://code.google.com/p/ollytlscatch/downloads/detail?name=HookSubSystem.rar" target="_blank">here</a>.<br />You can find <b><i>hooksubsystem.dll</i></b> <a href="http://code.google.com/p/ollytlscatch/downloads/detail?name=HookSubSystem.dll" target="_blank">here</a>.<br /><br />One drawback of this method is that it is <i><b>Service pack-specific</b></i> since the "<b><i>CheckSubSystem</i></b>" function is not exported by <i><b>kernel32.dll</b></i>.<br /><br /><i><b>2) </b></i>The second is to patch the "<i><b>ZwQuerySection</b></i>" function such that we can manipulate the data returned in the "<i><b>SECTION_IMAGE_INFORMATION</b></i>" structure before being used by "<b><i>CheckSubSystem</i></b>" function.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-xQnj2-CPiYI/UByaVkLByoI/AAAAAAAAA08/r00pF7nas7c/s1600/shitty.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="158" src="http://4.bp.blogspot.com/-xQnj2-CPiYI/UByaVkLByoI/AAAAAAAAA08/r00pF7nas7c/s400/shitty.jpg" width="400" /></a></div><i><b><br /></b></i>To implement this method, i created another version of <i><b>hooksubsystem.dll. </b></i>You can find it <a href="http://code.google.com/p/ollytlscatch/downloads/detail?name=HookSubSystem_0.2.dll" target="_blank">here</a> and its source code from <a href="http://code.google.com/p/ollytlscatch/downloads/detail?name=HookSubSystem_0.2.rar" target="_blank">here</a><i><b>.</b></i><br /><br /><i><b>I also created a small application, BypassSubSystem.exe, which installs a system-wide hook of the type provided in the command line arguments. It can be used in the way you see in the image below.</b></i><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-23ErtiM3GHs/UBybfGr5ntI/AAAAAAAAA1E/bEn0CegKFX8/s1600/wwwww.bmp" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="197" src="http://3.bp.blogspot.com/-23ErtiM3GHs/UBybfGr5ntI/AAAAAAAAA1E/bEn0CegKFX8/s400/wwwww.bmp" width="400" /></a></div><i><b>BypassSubSystem.exe can be downloaded from <a href="http://code.google.com/p/ollytlscatch/downloads/detail?name=BypassSubSystem.exe" target="_blank">here</a> and its source code from <a href="http://code.google.com/p/ollytlscatch/downloads/detail?name=BypassSubSystem.rar" target="_blank">here</a>.</b></i><br /><br /><i><b>In a future post i will go deeper into this topic.&nbsp;</b></i><br /><br /><br /><i><b>You can follow me on Twitter <a href="http://twitter.com/waleedassar" target="_blank">@waleedassar</a> </b></i></div>http://waleedassar.blogspot.com/2012/08/major-minorsubsystemversion.htmlnoreply@blogger.com (Walied Assar)2tag:blogger.com,1999:blog-5036198523690297182.post-8667732752273306365Fri, 27 Jul 2012 20:41:00 +00002012-07-28T16:58:19.996-07:00_KUSER_SHARED_DATAKiFastSystemCallKiFastSystemCallRetKiIntSystemCallnative x86 hookuser-mode hookNative x86 User-mode System Calls Hooking<div dir="ltr" style="text-align: left;" trbidi="on">In this post i am going to explain how to implement system call hooking from user-mode for <i><b>native x86</b></i> processes (i here refer to<i><b> 32-bit</b></i> processes running in <b><i>32-bit</i></b> versions of <i><b>Windows XP SP2</b></i> and <i><b>SP3</b></i>).<br /><br />Let's have a look at the "<i><b>ZwOpenProcess</b></i>" function of <b><i>Windows XP SP2</i></b> and of <i><b>Windows XP SP3</b></i>.<br /><br />1) <b><i>XP SP2</i></b><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-q46UDr3nUro/UBLyWtul-eI/AAAAAAAAAwE/IICRIsdEvwY/s1600/ZwOpenProcess.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="35" src="http://1.bp.blogspot.com/-q46UDr3nUro/UBLyWtul-eI/AAAAAAAAAwE/IICRIsdEvwY/s400/ZwOpenProcess.JPG" width="400" /></a></div><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/--dV54HwHbo0/UBLy34WX_OI/AAAAAAAAAwM/LjRmsscgIAc/s1600/Shared.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="312" src="http://4.bp.blogspot.com/--dV54HwHbo0/UBLy34WX_OI/AAAAAAAAAwM/LjRmsscgIAc/s400/Shared.JPG" width="400" /></a></div><br /><div class="separator" style="clear: both; text-align: center;"></div><br />2) XP SP3<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-37GKDtA64Ew/T_9lzv12LtI/AAAAAAAAArw/6SO8IiZUH_g/s1600/ZwOpenProcess_XP.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="48" src="http://3.bp.blogspot.com/-37GKDtA64Ew/T_9lzv12LtI/AAAAAAAAArw/6SO8IiZUH_g/s400/ZwOpenProcess_XP.JPG" width="400" /></a></div><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-yJHpZW6K8iI/UAq_kINjBxI/AAAAAAAAAuo/-JZkv03hmx0/s1600/xpxp.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="300" src="http://3.bp.blogspot.com/-yJHpZW6K8iI/UAq_kINjBxI/AAAAAAAAAuo/-JZkv03hmx0/s400/xpxp.jpg" width="400" /></a></div><br />As you can see in the images above, <i><b>EAX</b></i> is set to <i><b>0x7A</b></i>, the system call ordinal and <i><b>EDX</b></i> is made to point at <b><i>0x7FFE0300</i></b> in the <b><i><a href="http://www.nirsoft.net/kernel_struct/vista/KUSER_SHARED_DATA.html">_KUSER_SHARED_DATA</a> </i></b>page. Then comes a <i><b>CALL</b></i> instruction which jumps to the "<b><i>KiFastSystemCall</i></b>" function whose address is stored in <i><b>0x7FFE0300 (<a href="http://www.nirsoft.net/kernel_struct/vista/KUSER_SHARED_DATA.html">_KUSER_SHARED_DATA</a></b><a href="http://www.nirsoft.net/kernel_struct/vista/KUSER_SHARED_DATA.html" target="_blank"><b>::SystemCall</b></a></i>).<br /><br />One difference we can see is that <i><b>SYSENTER</b></i> of <b><i>XP SP2</i></b> is followed by <i><b>5 NOPs</b></i> while in <b><i>XP SP3</i></b> <b><i>SYSENTER</i></b> is directly followed by the <i><b>RET</b></i> of the "<b><i>KiFastSystemCallRet</i></b>" function.<br />&nbsp; <br />The first thing one may think of to implement the user-mode system call hook in <b><i>Windows XP SP3/SP2</i></b> is to overwrite the "<a href="http://www.nirsoft.net/kernel_struct/vista/KUSER_SHARED_DATA.html" target="_blank">_KUSER_SHARED_DATA::SystemCall</a>" and "<a href="http://www.nirsoft.net/kernel_struct/vista/KUSER_SHARED_DATA.html" target="_blank">_KUSER_SHARED_DATA::SystemCallRet</a>" fields. Unfortunately, this is not possible since the page is not writable and any attempt to change its memory protection constant always fails.<br /><br />So, we should now turn to the "<i><b>KiFastSystemCall</b></i>" function and try to overwrite its very first instruction with a <i><b>JMP</b></i> instruction. Is this all? Let's see.<br /><br />For <i><b>XP SP2</b></i>, it is okay to write a <i><b>near jmp</b></i> instruction (<b><i>5-byte long</i></b>) since we have enough space (filled with 5 <b><i>NOP</i></b>s) and this does not hurt the <b><i>RET</i></b> instruction of the "<i><b>KiFastSystemCallRet</b></i>" function. But for <i><b>XP SP3</b></i>, any attempt to write the <b><i>near jmp</i></b> instruction will hurt the "<i><b>KiFastSystemCallRet</b></i>" function. Any common method for both <b><i>XP SP2</i></b> and <i><b>SP3</b></i>?<br /><br />I thought about that and came up with something that worked for both service packs. If we allocate a memory page at an address which when converted from <i><b>absolute</b></i> to <b><i>relative</i></b> gives <i><b>0xC3</b></i> as the fifth byte of the new <b><i>JMP</i></b> instruction. For example, if we allocate a memory page at <i><b>0x3F910000</b></i>, given that the "<b><i>KiFastSystemCall</i></b>" function is at <i><b>0x7C90E510</b></i>, we get the new <i><b>JMP</b></i> instruction as a sequence of <br />&nbsp;"<i><b>\xE9\xEB\x1A\x00\xC3</b></i>". You can check the source code of <a href="http://code.google.com/p/injecthooklib/downloads/detail?name=InjectHookLib.rar" target="_blank"><i><b>InjectHookLib</b></i></a> for more information.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-Wrlq90W5xHA/UBL5l-E9YPI/AAAAAAAAAww/y_ga6iTEfUE/s1600/final.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="127" src="http://1.bp.blogspot.com/-Wrlq90W5xHA/UBL5l-E9YPI/AAAAAAAAAww/y_ga6iTEfUE/s400/final.jpg" width="400" /></a></div><br />N.B. We can still use a <i><b>short JMP</b></i> by searching for any vacant <b><i>5 bytes</i></b> in the range of <b><i>-128</i></b> to <i><b>+127</b></i> from the address of the "<i><b>KiFastSystemCall</b></i>" function. <i><b>LEA ESP,[ESP]</b></i> seems to be okay for both service packs.<br /><br />N.B. With certain processors or under certain conditions e.g. disabled <i><b>VT-x/AMD-V</b></i> if using <i><b>VirtualBox</b></i>, the "<i><b>KiFastSystemCall</b></i>" function is not used at all and the "<b><i>KiIntSystemCall</i></b>" is used instead. In these cases, you can safely overwrite the first instructions of "<i><b>KiIntSystemCall</b></i>" function with a <b><i>near JMP</i></b> instruction as long as the code you hook to takes care of that.<br /><br /><br />Any ideas or suggestions are always very welcome.<br /><br />You can follow me <a href="https://twitter.com/waleedassar" target="_blank">@waleedassar</a> </div>http://waleedassar.blogspot.com/2012/07/native-x86-user-mode-system-calls.htmlnoreply@blogger.com (Walied Assar)2tag:blogger.com,1999:blog-5036198523690297182.post-5811159836122972170Thu, 26 Jul 2012 22:35:00 +00002012-08-02T10:25:59.059-07:007ffe0300_KUSER_SHARED_DATACpupReturnFromSimulatedCodeCpuThreadInitKiFastSystemCallSTATUS_WX86_BREAKPOINTwow64.dllwow64cpu.dllwow64win.dllX86SwitchTo64BitModeWow64 User-mode System Calls Hooking<div dir="ltr" style="text-align: left;" trbidi="on">The idea started as an attempt to implement "<i><b>System Calls Hooking</b></i>" from <i><b>user-mode</b></i> under <i><b>Wow64</b></i> processes (<i><b>32-bit</b></i> processes running on<i><b> </b><b>64-bit versions of Windows</b></i>). I later extended it to include <i><b>native</b></i> <b><i>32-bit</i></b> processes. The whole thing ended up as an <i><b>OllyDbg</b></i> plugin which you may find useful for many purposes e.g. malware analysis and unpacking. <br /><br />Now let's quickly see how <i><b>32-bit</b></i> code issues system calls in <b><i>Wow64</i></b> processes and in <b><i>native 32-bit</i></b> processes.<br /><br />1) <i><b>In Wow64 Processes:</b></i><br />If we take the "<i><b>ZwOpenProcess</b></i>" function of the <b><i>64-bit</i></b> version of <i><b>Windows 7</b></i>, we can see that <b><i>EAX</i></b> holds <b><i>0x23</i></b>, the system call ordinal and <i><b>EDX</b></i> points at the stack arguments.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-qTeXhCXr_nw/UAnrYJ_df6I/AAAAAAAAAtk/Fq9q6wqL5NM/s1600/111.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="38" src="http://3.bp.blogspot.com/-qTeXhCXr_nw/UAnrYJ_df6I/AAAAAAAAAtk/Fq9q6wqL5NM/s400/111.jpg" width="400" /></a></div><br />Then comes a <i><b>CALL</b></i> instruction, neither <b><i>SYSENTER</i></b>, nor <i><b>SYSCALL</b></i>, nor <i><b>INT 2E</b></i>. The <i><b>Call DWORD PTR FS:[C0] </b></i>instruction jumps to the address stored at <i><b>TEB+0xC0</b></i>, <b><i>0x74DE2320</i></b>, see the image below.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-iNy-jU5wypw/UAnrPTZowJI/AAAAAAAAAtc/nulXl3StMho/s1600/CO.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="188" src="http://3.bp.blogspot.com/-iNy-jU5wypw/UAnrPTZowJI/AAAAAAAAAtc/nulXl3StMho/s400/CO.jpg" width="400" /></a></div><div class="separator" style="clear: both; text-align: center;"><br /></div>If we move to this address, we see a <i><b>FAR</b></i> jump. It jumps to <i><b>0x74DE271E </b></i>setting the <i><b>code segment</b></i> to<i><b> 0x33 </b></i>and this is where <i><b>32-bit</b></i> debuggers can't go any further.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-DktsEGwtpvU/UAnrvXXJZJI/AAAAAAAAAts/mzL5orLiTyk/s1600/wow64cpu.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="63" src="http://4.bp.blogspot.com/-DktsEGwtpvU/UAnrvXXJZJI/AAAAAAAAAts/mzL5orLiTyk/s400/wow64cpu.jpg" width="400" /></a></div><br />So, we can now conclude that by changing the <i><b>CS, code segment</b></i> to <b><i>0x33</i></b>, transition from <i><b>32-bit mode</b></i> to <b><i>64-bit mode</i></b> occurs and this is where system calls are taken care of.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-VmANlEut4jM/UAn7x6smV5I/AAAAAAAAAuQ/2903WTAmiRs/s1600/windbg.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="120" src="http://4.bp.blogspot.com/-VmANlEut4jM/UAn7x6smV5I/AAAAAAAAAuQ/2903WTAmiRs/s400/windbg.jpg" width="400" /></a></div><br /><i><b>0x74DE271E </b></i>does not exist in the "<i><b>Executable modules</b></i>" list that you see if you press<i><b> ALT+E </b></i>in<i><b> OllyDbg. </b></i>But if we try to dump the memory that this address belongs to<i><b>, </b></i>we can see that the module name is <i><b>wow64cpu.dll</b></i>.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-2BT1Gf7rdgs/UAntB73RqhI/AAAAAAAAAt0/nQeyH14yQI0/s1600/dump.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="185" src="http://1.bp.blogspot.com/-2BT1Gf7rdgs/UAntB73RqhI/AAAAAAAAAt0/nQeyH14yQI0/s400/dump.jpg" width="400" /></a></div><i><b><br /></b></i><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-lm_3YcDpnRE/UAntL33FYhI/AAAAAAAAAt8/FC8hyABznLk/s1600/saveas.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="305" src="http://4.bp.blogspot.com/-lm_3YcDpnRE/UAntL33FYhI/AAAAAAAAAt8/FC8hyABznLk/s400/saveas.jpg" width="400" /></a></div><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-puf4fseJfM0/UAnt4gCIfmI/AAAAAAAAAuE/GbiD_M8u-S8/s1600/stp.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="290" src="http://4.bp.blogspot.com/-puf4fseJfM0/UAnt4gCIfmI/AAAAAAAAAuE/GbiD_M8u-S8/s400/stp.jpg" width="400" /></a></div>N.B.<b><i> wow64cpu.dll</i></b> is a <i><b>64-bit</b></i> dynamic link library that resides in the "<i><b>system32</b></i>" directory and is always loaded into the address space of<i><b> Wow64</b></i> processes along with other<i><b> 64-bit </b></i><b>libraries</b>. The other <i><b>64-bit</b></i> libraries are <i><b>wow64.dll</b></i>, <i><b>wow64win.dll</b></i>, and the <i><b>64-bit</b></i> version of <i><b>ntdll.dll</b></i>. They are hidden by depriving them of having entries into the doubly linked lists of <i><b>PEB.<a href="http://undocumented.ntinternals.net/UserMode/Structures/PEB_LDR_DATA.html" target="_blank">LoaderData</a></b></i> (i here refer to the <i><b>32-bit PEB</b></i>, we will see this later).<br /><br />N.B. If we apply symbols to <i><b>wow64cpu.dll</b></i>, we find that <b><i>0x74DE2320</i></b> is the address of the non-exported symbol of&nbsp; "<i><b>X86SwitchTo64BitMode</b></i>" and <b><i>0x74DE271E</i></b> is the address of the non-exported symbol of "<i><b>CpupReturnFromSimulatedCode</b></i>".<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-EQQ0b7TJgxo/UAqfjlSuJmI/AAAAAAAAAuc/7ApCUnYVheg/s1600/swi.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="91" src="http://1.bp.blogspot.com/-EQQ0b7TJgxo/UAqfjlSuJmI/AAAAAAAAAuc/7ApCUnYVheg/s400/swi.jpg" width="400" /></a></div><br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-VmANlEut4jM/UAn7x6smV5I/AAAAAAAAAuQ/2903WTAmiRs/s1600/windbg.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="120" src="http://4.bp.blogspot.com/-VmANlEut4jM/UAn7x6smV5I/AAAAAAAAAuQ/2903WTAmiRs/s400/windbg.jpg" width="400" /></a></div><br /><i><b></b></i>2) In Native 32-bit Processes:<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-37GKDtA64Ew/T_9lzv12LtI/AAAAAAAAArw/6SO8IiZUH_g/s1600/ZwOpenProcess_XP.JPG" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="48" src="http://3.bp.blogspot.com/-37GKDtA64Ew/T_9lzv12LtI/AAAAAAAAArw/6SO8IiZUH_g/s400/ZwOpenProcess_XP.JPG" width="400" /></a></div><br />The image above is the "<i><b>ZwOpenProcess</b></i>" function of Windows XP SP3. <i><b>EAX</b></i> is <i><b>0x7A</b></i>, the system call ordinal and <i><b>EDX</b></i> points at <b><i>0x7FFE0300</i></b> in the <b><i><a href="http://www.nirsoft.net/kernel_struct/vista/KUSER_SHARED_DATA.html">_KUSER_SHARED_DATA</a> </i></b>page. Then comes a <i><b>CALL</b></i> instruction which jumps to the "<b><i>KiFastSystemCall</i></b>" function whose address is stored in <i><b>0x7FFE0300 (<a href="http://www.nirsoft.net/kernel_struct/vista/KUSER_SHARED_DATA.html">_KUSER_SHARED_DATA</a></b><a href="http://www.nirsoft.net/kernel_struct/vista/KUSER_SHARED_DATA.html" target="_blank"><b>::SystemCall</b></a></i>)<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-yJHpZW6K8iI/UAq_kINjBxI/AAAAAAAAAuo/-JZkv03hmx0/s1600/xpxp.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="300" src="http://3.bp.blogspot.com/-yJHpZW6K8iI/UAq_kINjBxI/AAAAAAAAAuo/-JZkv03hmx0/s400/xpxp.jpg" width="400" /></a></div><br />Actually, depending on the underlying processor architecture, that <i><b>CALL</b></i> instruction may jump to the "<i><b>KiIntSystemCall</b></i>" function. In this post, i will just focus on the "<i><b>KiFastSystemCall</b></i>" function.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-qmf_Ivt5K6Y/T_9uX30ZmLI/AAAAAAAAAsE/UNnGOBOpFDU/s1600/KiFast.JPG" style="margin-left: 1em; margin-right: 1em;"><br /></a></div><br />Looking at the "<i><b>KiFastSystemCall</b></i>" function, we can see it is as simple as pointing <b><i>EDX</i></b> at the stack and issuing <i><b>SYSENTER</b></i> to enter <i><b>kernel-mode</b></i>. Then comes <i><b>a RET </b></i>instruction which represents the<i><b> "KiFastSystemCallRet" </b></i>function.<br /><br /><br />Now, let's see how we can implement a user-mode system calls hook in <i><b>Windows 7 64-bit</b></i> (<b><i>Wow64</i></b> processes).<br /><br />1) <i><b>Wow64 processes</b></i><br /><br />To implement a hook, the first method one may think of is replacing the address stored at <i><b>FS:[0xC0]</b></i>&nbsp; (<b><i>0x74DE2320, </i></b>as seen above) with the address of our own hooking code. While this seems to be very easy, it has one drawback, that is, this field is per-thread i.e. we have to keep track of all new threads and for each new thread, we have to replace the address at <i><b>FS:[0xC0]</b></i> with the address to our own hooking code.<br /><br />Imagine the scenario where we <i><b>CreateProcess</b></i> our target process in&nbsp; <b><i>suspended</i></b> state, overwrite the address stored at <i><b>FS:[0xC0]</b></i>, and finally <i><b>ResumeThread</b></i>. In this scenario, we can't keep track of any new tread created after we call the "<i><b>ResumeThread</b></i>" function and hence all its system calls will be lost.<br /><br />Imagine the second scenario where we call the "<i><b>CreateProcess</b></i>" function on our target process with the "<b><i>dwCreationFlags</i></b>" parameter set to <b><i>DEBUG_ONLY_THIS_PROCESS</i> </b>a.k.a we are debugging our target process<b>. </b>In this scenario we can see all new threads as we intercept the "<i><b>CREATE_THREAD_DEBUG_EVENT</b></i>" events. Once we receive the "<i><b>CREATE_THREAD_DEBUG_EVENT</b></i>" event, <i><b>FS:[0xC0]</b></i> should contain the address of the <i><b>FAR</b></i> jump, but this does not always occur. To explore this fact, let's use the <b><i>64bit</i></b> version of <i><b>Debugging Tools for Windows</b></i> to debug a demo <i><b>32-bit</b></i> executable that does nothing but creates a new thread.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-q6mrugoLzbU/UAm9UeY9FRI/AAAAAAAAAsc/PJIw_xzYsP8/s1600/xxx.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="242" src="http://1.bp.blogspot.com/-q6mrugoLzbU/UAm9UeY9FRI/AAAAAAAAAsc/PJIw_xzYsP8/s400/xxx.jpg" width="400" /></a></div><br />We instruct <i><b>WinDbg</b></i> to break on new threads and then place a software breakpoint on the "<i><b>Wow64cpu!CpuThreadInit</b></i>" function, the function responsible for storing the address of the <i><b>FAR</b></i> jump into <i><b>FS:[0xC0]</b></i>. <br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-NPizuETH-_o/UAnHZs34lyI/AAAAAAAAAso/nq7N-K3g_aI/s1600/xyx.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="141" src="http://1.bp.blogspot.com/-NPizuETH-_o/UAnHZs34lyI/AAAAAAAAAso/nq7N-K3g_aI/s400/xyx.jpg" width="400" /></a></div><br /><br />After repeating the abovementioned step few times, you can see that the "<b><i>Wow64cpu!CpuThreadInit</i></b>" function does not always precede the thread entry point.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-Jgyuaj3PSEY/UAnJqw40hAI/AAAAAAAAAsw/wNcZBlHt_5Y/s1600/xyuu.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="61" src="http://4.bp.blogspot.com/-Jgyuaj3PSEY/UAnJqw40hAI/AAAAAAAAAsw/wNcZBlHt_5Y/s400/xyuu.jpg" width="400" /></a></div>Now we have seen that overwriting the pointer at <i><b>FS:[0xC0]</b></i> is not the best way to implement the user-mode system call hook.<br /><br />Let's try the second method. Actually it is the one i prefer. By overwriting the <b><i>FAR</i></b> jump instruction itself in <i><b>wow64cpu.dll</b></i>, we can get rid of the new threads' annoyance. All we have to to in this method is set the proper <i>memory protection</i> of the <i><b>wow64cpu.dll</b></i> page that contains the <b><i>FAR</i></b> jump, write a near&nbsp; <i><b>JMP</b></i> instruction into your hook code, and finally restore the original memory protection. This method has been implemented in my open source <i><b>OllyDbg</b></i> plugin. A link to the source code is found at the end of this blog post.<br /><br />One more method would be manipulating the "<i><b>Wow64cpu!CpuThreadInit</b></i>" function to force it to store the address of our own code at offset <b>0xC0</b> instead of storing the address of the <i><b>FAR</b></i> jump.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-Xz1uYRI9rw4/UAs29ioLqxI/AAAAAAAAAvA/s47Wcdo6abY/s1600/last.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="65" src="http://2.bp.blogspot.com/-Xz1uYRI9rw4/UAs29ioLqxI/AAAAAAAAAvA/s47Wcdo6abY/s400/last.jpg" width="400" /></a></div><br /><br />Side notes:<br />1) As you can see in the "<i><b>Wow64cpu!CpuThreadInit</b></i>" function code, each <i><b>Wow64</b></i> thread has two <i><b>TEB</b></i>'s, <b><i>32bit TEB</i></b> and <b><i>64bit TEB</i></b>. The <i><b>64bit TEB</b></i> always precedes the <b><i>32bit TEB</i></b> by two pages.<br /><br />2) I have also noticed that <i><b>32bit PEB</b></i> always precedes the <b><i>64bit PEB</i></b> by one page. So, in a single-threaded application, the sequence is <i><b>64bit TEB</b></i>--&gt;<b><i>32bit TEB</i></b>---&gt;<i><b>32bit PEB</b></i> --&gt; <b><i>64bit PEB</i></b>.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-B27M-hHeYwI/UAr9QQTcj9I/AAAAAAAAAu0/ucTgoEgEUOE/s1600/peb_teb_wow.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="41" src="http://2.bp.blogspot.com/-B27M-hHeYwI/UAr9QQTcj9I/AAAAAAAAAu0/ucTgoEgEUOE/s400/peb_teb_wow.jpg" width="400" /></a></div><br />3) Wow64 processes, at their startup, always raise a special exception called<b> "STATUS_WX86_BREAKPOINT"</b> with exception code <i><b>0x4000001f</b></i>. This is something that <i><b>64bit</b></i> debuggers are supposed to be aware of.<br /><br />4) I have also noticed that <b><i>Wow64</i></b> threads seem to have two stacks, 64bit stack and 32bit one. <br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-66Q0AxiPV8U/UAnSipFRv5I/AAAAAAAAAtI/x9BGhnihmAI/s1600/hshshs_.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="101" src="http://1.bp.blogspot.com/-66Q0AxiPV8U/UAnSipFRv5I/AAAAAAAAAtI/x9BGhnihmAI/s400/hshshs_.jpg" width="400" /></a></div>In later posts, i will show how we implement the user-mode system call in Windows XP SP3. Don't worry it is even easier.<br /><br />Let's see how we can implement the system call hook for OllyDbg v1.10.<br /><br />First, i designed the hook into two <i><b>DLLs</b></i>. The first is the <b><i>OllyDbg</i></b> plugin or the <i><b>injector DLL</b></i>, i named it <i><b>InjectHookLib.dll</b></i>. The second is the <b><i>injected DLL</i></b> which has your own code for logging or manipulating system calls. I will show you the steps i have taken to write <b><i>InjectHookLib.dll</i></b>. I will also show you how to write a simple library to inject.<br /><br />1) <i><b>Injector DLL</b></i> <br />Once you choose to inject a library, a common dialog box is opened for you to choose the library. One memory page is allocated into the address space of the target process (the debuggee) and a few x86 instructions are copied into it.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-4EtluaegDmI/UBA4REjZGMI/AAAAAAAAAvQ/NMsknXTNvPA/s1600/shellcode.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="157" src="http://4.bp.blogspot.com/-4EtluaegDmI/UBA4REjZGMI/AAAAAAAAAvQ/NMsknXTNvPA/s400/shellcode.jpg" width="400" /></a></div><br /><br />In the image above you can see the code cave copied into the target process address space. <br /><br />If it is the first system call issued by the target process, this code cave injects the library you chose into the address space. After the library has successfully been injected, the code then jumps to its "<i><b>DllMain</b></i>" function where you can manipulate intercepted system calls.<br /><br /><br />One difficulty that i met was filtering the calls originating from the "<i><b>LoadLibraryA</b></i>" function and from inside the "<b><i>DllMain</i></b>" function. That was overcome by having global variables which are to be checked upon any call to the "<i><b>DllMain</b></i>" function.<br /><br />Calling the "<b><i>DllMain</i></b>" function of the injected library, the "<i><b>fdwReason</b></i>" is always set to <b><i>0x4</i></b> to tell the "<i><b>DllMain</b></i>" function that a system call is being passed and "<i><b>lpvReserved</b></i>" is made to point to the stack where the registers are saved (those registers are the ones of <b><i>PUSHAD</i></b> and <i><b>PUSHFD</b></i>).<br /><br /><br />Now let's see how we write the "<i><b>DllMain</b></i>" function of the library to be injected. I will take my dumpSysCalls.dll to be my first example. More examples will be released soon.<br /><br />I will rename the third parameter from <i><b>void* lpvReserved</b></i> to <i><b>MyContext* pContext</b></i> so that the "DllMain" function prototype looks like below.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-FTFzY1K16GE/UBBPE--_7TI/AAAAAAAAAvc/tfRyhnKXUEs/s1600/proto.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="53" src="http://1.bp.blogspot.com/-FTFzY1K16GE/UBBPE--_7TI/AAAAAAAAAvc/tfRyhnKXUEs/s400/proto.jpg" width="400" /></a></div><br /><br />If the "<i><b>fdwReason</b></i>" parameter is <b><i>DLL_PROCESS_ATTACH</i></b>, i recommend you to call the "<i><b>DisableThreadLibraryCalls</b></i>" function.<br /><br />The "<i><b>MyContext</b></i>" structure as its name implies has all registers passed via the code cave mentioned above and its definition looks like below.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-EHd5c2o5p-o/UBBQDUBcS_I/AAAAAAAAAvk/6Pc1SUnnOiw/s1600/defin.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="224" src="http://1.bp.blogspot.com/-EHd5c2o5p-o/UBBQDUBcS_I/AAAAAAAAAvk/6Pc1SUnnOiw/s400/defin.png" width="400" /></a></div>If the "<i><b>fdwReason</b></i>" parameter is <b><i>0x4</i></b>, this means that a system call is being passed and we should start playing with it. Given the "<b><i>pContext</i></b>" pointer and the platform-specific info. discussed earlier in the post, we can easily play with system calls. For example, in <i><b>Windows 7 64-bit</b></i>, the <b><i>Eax</i></b> (<i><b>pContext-&gt;Eax</b></i>) always holds the system call ordinal. We can look up this ordinal to determine the system call string. According to the system call ordinal we can use <i><b>(pContext-&gt;Esp)&nbsp; </b></i>to get the return address and the system call arguments<i><b>.</b></i> See the image below.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-alrqsuQ3FLA/UBGY0nhBHnI/AAAAAAAAAvw/GJBzc8XmRdk/s1600/src.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="207" src="http://2.bp.blogspot.com/-alrqsuQ3FLA/UBGY0nhBHnI/AAAAAAAAAvw/GJBzc8XmRdk/s400/src.jpg" width="400" /></a></div><br />N.B. The library entry point must be "DllMain" (not "DllMainCRTStartup"). This is accomplished by ignoring all default libraries and setting the "/entry" to "DllMain".<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-Wsaq2uyn_Pg/UBq4GcaRPaI/AAAAAAAAAxU/jDXwTtr1P5U/s1600/xxx.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="261" src="http://2.bp.blogspot.com/-Wsaq2uyn_Pg/UBq4GcaRPaI/AAAAAAAAAxU/jDXwTtr1P5U/s400/xxx.jpg" width="400" /></a></div><br />Example libraries:<br /><br />1) <a href="http://code.google.com/p/injecthooklib/downloads/detail?name=dumpSysCalls.dll" target="_blank">dumpSysCalls.dll</a> <br /><br />Function: It logs all system calls to <b><i>c:\syscall_log.txt</i></b><i><b></b></i>&nbsp; <br />Source code: <br />VC6.0-compatible source code from <a href="http://code.google.com/p/injecthooklib/downloads/detail?name=dumpSysCalls.rar" target="_blank">here</a>.<br />VC8.0-compatible source code from <a href="http://code.google.com/p/injecthooklib/downloads/detail?name=dumpSysCalls_vc8.rar" target="_blank">here</a>.<br /><br />2) <a href="http://code.google.com/p/injecthooklib/downloads/detail?name=FindWindow.dll" target="_blank">FindWindow.dll</a><br /><br />Function: It logs calls to the "FindWindow", "FindWindowA", "FindWindowExA", and "FindWindowExW" functions and their parameters to "c:\FindWindow.txt"<br /><br />Source code: <br />VC6.0-compatible source code from <a href="http://code.google.com/p/injecthooklib/downloads/detail?name=FindWindow.rar" target="_blank">here</a>.<br />VC8.0-compatible source code from <a href="http://code.google.com/p/injecthooklib/downloads/detail?name=FindWindow_vc8.rar" target="_blank">here</a>.<br /><br /><br /><br />For list of system calls per OSes, you can refer to the following links:<br /><a href="http://j00ru.vexillium.org/ntapi/">http://j00ru.vexillium.org/ntapi/</a><br /><a href="http://j00ru.vexillium.org/ntapi_64/">http://j00ru.vexillium.org/ntapi_64/</a><br /><a href="http://j00ru.vexillium.org/win32k_syscalls/">http://j00ru.vexillium.org/win32k_syscalls/</a><br /><br />You can find the the "<i><b>InjectHookLib</b></i>" plugin <a href="http://code.google.com/p/injecthooklib/downloads/detail?name=InjectHookLib.dll" target="_blank">here</a> and its source code <a href="http://code.google.com/p/injecthooklib/downloads/detail?name=InjectHookLib.rar" target="_blank">here</a>. It has been tested with Windows 7 SP0 <i><b>64-bit</b></i> and Windows XP SP2/SP3.<br /><br />You can follow me on Twitter <a href="https://twitter.com/waleedassar" target="_blank">@waleedassar</a></div>http://waleedassar.blogspot.com/2012/07/wow64-user-mode-system-calls-hooking.htmlnoreply@blogger.com (Walied Assar)5