A customer reported that their employees were randomly getting “memory write errors”.<\/p>\n
This was their way of interpreting the error message<\/a><\/p>\n The instruction at “XX” referenced memory at “YY”. The memory could not be “written”.<\/p><\/blockquote>\n Okay, so what we have here is an access violation.<\/p>\n The strange thing was that this access violation was happening across multiple unrelated programs, rather than all occurring in a single program or family of programs. So there is some sort of broader problem here, rather than just a single buggy program.<\/p>\n Opening one of the crash dumps shows this:<\/p>\n That All of the crash dumps look like this, just with different process names.<\/p>\n Let’s disassemble from the start of the function to see how we got here.<\/p>\n This doesn’t look like the proper start of a function.<\/p>\n I mean, one clue is that it starts with a single-byte And then of course there is the chunk of four What I thought was interesting is that if you take out those four This looks to me like a failed attempt to detour the function. The next step is to try to figure out what they were trying to do.<\/p>\n Well, it looks like it’s trying to detour to a function at So this is a mystery 4KB allocation of executable memory.<\/p>\n Maybe there are some interesting strings in that memory block.<\/p>\n Okay, well, that path to a DLL kind of catches them red-handed. I bet the “inj” stands for “injection”. But what were they trying to do?<\/p>\n I figured, “Hm, the extra four zero bytes come right after the constant they were trying to load, so if I change the Now, this is a 32-bit process (evidenced by the 32-bit instruction pointer), so there is no But wait, what if they got confused and thought<\/i> it was a 64-bit process?<\/p>\n Let’s disassemble these bytes as if they had been injected into a 64-bit process.<\/p>\n The way I do this is to load up a sacrificial 64-bit debug session and just patch into it the bytes that I want to study. For poetic irony, I will load the 64-bit WerFault.exe<\/tt> into the debugger as a dump file.<\/p>\n Okay, now it makes much more sense. This is a 64-bit detour that loads an absolute jump target into a 64-bit register ( They injected 64-bit code into a 32-bit process!<\/p>\n This also explains why the crashes are sporadic: The customer’s employees run 64-bit processes most of the time, but on occasion, something will run a 32-bit process, and those are the ones that are crashing.<\/p>\n Upon further discussion with the customer, we learned that Contoso is an anti-malware program that they use. We advised them to disable it temporarily<\/a> to confirm that it was the source of the problem, but they didn’t want to disable their anti-malware software.<\/p>\n Okay, so we advised them to check with the vendor to see if an update is available. They were resistant to changing their anti-malware software without first putting it through their internal validation. They considered this a Windows problem, and they demanded a Windows solution.<\/p>\n We are still working to convince the customer that they need to re-evaluate their anti-malware software.\u00b2<\/p>\neax=0013d354 ebx=0049a000 ecx=009e9a9f edx=03111160 esi=009e9aa0 edi=009e9aa0\r\neip=009e9aa7 esp=003cfda4 ebp=003cfdb0 iopl=0 nv up ei pl nz ac pe cy\r\ncs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010217\r\nWerFault!wmainCRTStartup+0x7:\r\n009e9aa7 0000 add byte ptr [eax],al ds:002b:0013d354=??\r\n0:000>\r\n<\/pre>\n
add byte ptr [eax], al<\/code> should immediately tell you that we are not executing valid code: It is the instruction that you get if you try to execute zeroes<\/a>. You can see the zeroes in the second column.<\/p>\n0:000> u .-7\r\nWerFault!wmainCRTStartup:\r\n009e9aa0 90 nop\r\n009e9aa1 49 dec ecx\r\n009e9aa2 ba6011f102 mov edx,2F11160h\r\n009e9aa7 0000 add byte ptr [eax],al \u2190 died here\r\n009e9aa9 0000 add byte ptr [eax],al\r\n009e9aab 41 inc ecx\r\n009e9aac ffe2 jmp edx\r\n009e9aae cc int 3\r\n<\/pre>\n
nop<\/code>, rather than a mov edi, edi<\/code>, as is customary for x86-32 code<\/a>.\u00b9<\/p>\n00<\/code> bytes in the middle of the instruction stream.<\/p>\n00<\/code> bytes, then the dec ecx<\/code> and inc ecx<\/code> cancel out, and what’s left looks like a detour: It loads an absolute address into edx<\/code> and then jumps to it.<\/p>\n0x02f11160<\/code>, so let’s see what the debugger can tell us about that.<\/p>\n0:000> !address 0x2f11160\r\n\r\nUsage: <unknown>\r\nBase address: 02f11000\r\nEnd address: 02f12000\r\nRegion Size: 00001000 (4.000 kB)\r\nState: 00001000 MEM_COMMIT\r\nProtect: 00000020 PAGE_EXECUTE_READ\r\nType: 00020000 MEM_PRIVATE\r\nAllocation Base: 02f10000\r\nAllocation Protect: 00000004 PAGE_READWRITE\r\n<\/pre>\n
0:000> !strings 02f11000 02f12000\r\n02f11080 --------\r\n02f11148 ----------------\r\n02f11472 C:\\Program Files\\Common Files\\Contoso\\injcore.dll\r\n02f11545 IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII\r\n<\/pre>\n
mov edx<\/code> to a mov rdx<\/code>, it would be the upper half of a 64-bit constant, and then this would look okay again.<\/p>\nmov rdx<\/code> instruction. That instruction requires a 64-bit process.<\/p>\nC:\\> windbgx -z C:\\Windows\\System32\\WerFault.exe\r\n\r\nExecutable search path is: \r\nModLoad: 00000001`40000000 00000001`400a1000 C:\\Windows\\System32\\WerFault.exe\r\nWerFault!wmainCRTStartup:\r\n00000001`40002480 sub rsp,28h\r\n0:000> eb . 90 49 ba 60 11 f1 02 00 00 00 00 41 ff e2 cc\r\n0:000> u .\r\nWerFault!wmainCRTStartup\r\n00000001`40002480 nop\r\n00000001`40002481 mov r10,2F11160h\r\n00000001`4000248b jmp r10\r\n00000001`4000248e int 3\r\n<\/pre>\n
r10<\/code>) and then jumps to it.<\/p>\n