Needless to say that this way is completely convenient for the developer as he does not need to patch the monstrous application all around in order to compare access addresses against read-only fragment. Instead, a block defined as read-only will be immediately available as such for the whole process almost without any performance overhead.<\/p>\n
As ATL provides a set of memory allocator templates (CHeapPtr<\/a> for heap backed memory blocks, allocated with CCRTAllocator<\/em>, alternate options include CComHeapPtr<\/a> with CComAllocator<\/em> wrapping CoTaskMemAlloc<\/a>\/CoTaskMemFree<\/em> API), let us make an alternate allocator option that mimic well-known class interface and would facilitate corruption detection.<\/p>\n Because virtual memory allocation unit is a page, and protection mode is defined for the whole page, this would be the allocation granularity. For a single allocated byte we would need to request SYSTEM_INFO::dwPageSize<\/a> bytes of virtual memory. Unlike normal memory heap manager, we have no way to share pages between allocations as we would be unable to effectively apply protection modes. This would definitely increase application pressure onto virtual memory, but is still acceptable for the sacred task of troubleshooting.<\/p>\n We define a CVirtualAllocator<\/em> class to be compatible with ATL’s CCRTAllocator<\/em>, however based on VirtualAlloc<\/a>\/VirtualFree<\/em> API. The smart pointer class over memory pointer would be defined as follows:<\/p>\n The SetProtection<\/em> method is to define memory protection for the memory block. Full code for the classes is available on Trac here<\/a> (lines 9-132):<\/p>\n Use case code will be as follows. “SetProtection(PAGE_READONLY)” enables protection on memory block and turns on exception generation at the moment memory block modification attempt. “SetProtection(PAGE_READWRITE)” would restore normal mode of memory operation.<\/p>\n Given the information what data gets corrupt, the pointer allocator provides an efficient opportunity to detect the violation attempt. The only thing remained is to keep memory read-only, and temporarily revert to write access when the “legal” memory modification code is about to be executed.<\/p>\n <\/p>\n Another option granted by memory protection modes is brought by PAGE_GUARD flag. MSDN says:<\/p>\n A guard page provides a one-shot alarm for memory page access. This can be useful for an application that needs to monitor the growth of large dynamic data structures. For example, there are operating systems that use guard pages to implement automatic stack checking.<\/p><\/blockquote>\n Setting a guard page mode provides an additional option to trigger an exception with even read access to a protected memory block.<\/p>\n While setting memory protection attributes on a memory block of interest provides unique troubleshooting opportunities, it still does not cover important typical problems with memory misuse scenarios. Those are writing immediately before the allocated block, and writing immediately after. Having array of N items, this would be writing to indices -1 and N respectively.<\/p>\n To address this scenarios of misuse we can extend CVirtualHeapPtr class so that it could additionally provide “sanity pages” with PAGE_NOACCESS protection at the boundary of allocation. Because virtual memory allocation is granular, we will have to have padding bytes that extend our block to the page boundary, however we have an option to put the padding bytes before or after the payload data block in order to capture after or before memory block writes respectively.<\/p>\n The figure below shows memory layout for the data:<\/p>\n Source code for the CDebugHeapPtr<\/em> class is available on Trac<\/a> (lines 155-). The sanity pages create a block of inaccessible addresses which immediately cause access violation exception on either read of write access attempt. Under debugger, those are shows with question marks:<\/p>\n The padding space is pre-initialized with hardcoded value 0x77, and the space is checked for integrity at release of memory block call.<\/p>\n Having the exceptions generated on run-time, they immediately alter application execution code path and are easy to track and catch. There is no need to bring the feature rich debugger, such as Visual Studio to the production site in order to catch the exception and environment, instead a way simpler tool such as LogProcessExceptions<\/a> would be able to create a minidump file and write the state of the application. The minidump can be transferred into debugger-enabled environment for detailed check.<\/p>\ntemplate<\/span> <<\/span>typename<\/span> T><\/span>\r\nclass<\/span> CVirtualHeapPtr :<\/span>\r\n public<\/span> CHeapPtr<<\/span>T,<\/span> CVirtualAllocator><\/span>\r\n{<\/span>\r\npublic<\/span>:<\/span>\r\n\/\/ CVirtualHeapPtr<\/span>\r\n CVirtualHeapPtr(<\/span>)<\/span> throw<\/span>(<\/span>)<\/span>;<\/span>\r\n explicit<\/span> CVirtualHeapPtr(<\/span>_In_ T*<\/span> pData)<\/span> throw<\/span>(<\/span>)<\/span>;<\/span>\r\n VOID<\/span> SetProtection(<\/span>DWORD<\/span> nProtection)<\/span>\r\n {<\/span>\r\n \/\/ <\/span>TODO: ...<\/span>\r\n }<\/span>\r\n}<\/span>;<\/span><\/pre>\n\n
CVirtualHeapPtr<<\/span>BYTE<\/span>><\/span> p;<\/span>\r\np.<\/span>Allocate(<\/span>2<\/span>)<\/span>;<\/span>\r\np[<\/span>1<\/span>]<\/span> =<\/span> 0x01<\/span>;<\/span>\r\np.<\/span>SetProtection(<\/span>PAGE_READONLY)<\/span>;<\/span>\r\n\/\/ NOTE: Compile with \/EHa on order to catch the exception<\/span>\r\n_ATLTRY\r\n{<\/span>\r\n p[<\/span>1<\/span>]<\/span> =<\/span> 0x02<\/span>;<\/span>\r\n \/\/ NOTE: We never reach here due to exception<\/span>\r\n}<\/span>\r\n_ATLCATCHALL(<\/span>)<\/span>\r\n{<\/span>\r\n \/\/ NOTE: Catching the access violation for now to be able to continue execution<\/span>\r\n}<\/span>\r\np.<\/span>SetProtection(<\/span>PAGE_READWRITE)<\/span>;<\/span>\r\np[<\/span>1<\/span>]<\/span> =<\/span> 0x03<\/span>;<\/span><\/pre>\nOne-shot Read\/Write Protection with Guard Pages<\/h5>\n
p.<\/span>SetProtection(<\/span>PAGE_READWRITE |<\/span> PAGE_GUARD)<\/span>;<\/span>\r\nBYTE<\/span> n =<\/span> p[<\/span>0<\/span>]<\/span>;<\/span><\/pre>\nCDebugHeapPtr Class: More Options to Catch Memory Corruption Conditions<\/h4>\n
![\"\"](\"https:\/\/alax.info\/blog\/wp-content\/uploads\/2011\/11\/image.png\" "\\"CDebugHeapPtr")
<\/p>\n![\"\"](\"https:\/\/alax.info\/blog\/wp-content\/uploads\/2011\/11\/Image0011.png\" "\\"PAGE_NOACCESS")
<\/p>\nCatching the Exceptions<\/h4>\n