I have been reversing a popular Windows application and ended up in a very interesting place while debugging. What I can clearly see as valid x86 instructions that eventually lead to some sort of "trap." In the disassembly below there are some checks for sign (integer overflow?) and then less than (max bounds check?) and if those fall through then we encounter a
mov byte ptr , 0 instruction at 0x037D22A9. I'm curious if this has any purpose other than to signal the structure error handler something went wrong and what kind of source code would cause a compiler to emit such an instruction.
Sorry for not including the opcodes in the disassembly. The opcode in question has been added inline below.
Below is a larger code snip with more context.
.text:037D2292 jle short loc_37D22D2 .text:037D2294 mov esi, [ebp+0Ch] .text:037D2297 mov ecx, eax .text:037D2299 mov edx, ebx .text:037D229B nop dword ptr [eax+eax+00h] .text:037D22A0 .text:037D22A0 loc_37D22A0: ; CODE XREF: .text:037D22CD↓j .text:037D22A0 test ecx, ecx .text:037D22A2 js short loc_37D22A9 .text:037D22A4 cmp ecx, [esi+8] .text:037D22A7 jl short loc_37D22B5 .text:037D22A9 .text:037D22A9 loc_37D22A9: ; CODE XREF: .text:037D22A2↑j .text:037D22A9 c6050000000000 mov large byte ptr ds:0, 0 ; Why was a null pointer assignment compiled here .text:037D22B0 movss xmm1, dword ptr [ebp-10h] .text:037D22B5 .text:037D22B5 loc_37D22B5: ; CODE XREF: .text:037D22A7↑j .text:037D22B5 mov eax, [esi+4] .text:037D22B8 movss xmm0, dword ptr [eax+ecx*4] .text:037D22BD inc ecx .text:037D22BE addss xmm1, xmm0 .text:037D22C2 movss dword ptr [ebp-10h], xmm1 .text:037D22C7 movaps xmm0, xmm1 .text:037D22CA sub edx, 1 .text:037D22CD jnz short loc_37D22A0 .text:037D22CF mov esi, [ebp-8] .text:037D22D2 .text:037D22D2 loc_37D22D2: ; CODE XREF: .text:037D2292↑j .text:037D22D2 cmp ebx, esi