ArrayLocalVariable.c — arrays on the stack

ArrayLocalVariable.c takeaways

• Local variables need not be stored on the stack in the same order they are defined in the high-level language. (Here: declared a, b, c; laid out a, c, b.)
• (In VS unoptimized code) array access is typically done by multiplying the size of the array element (4 bytes for an int) times the index desired — hence mov eax,4 + imul rax,rax,index, even for index 1.
• Moving a small value to a large register results in a zero extend. Addition using signed values can involve a sign extend, when the arithmetic is done in a larger register (here: movsxd widened b[1] to 64 bits to add it to long long c).

Variant 2 — change short a → int a, add a (short)c cast

The takeaways slide steps a modified version. Two tiny C edits, and the compiler's choice of extension instructions changes completely (differences highlighted):

short main(){
    short a;
    int b[6];
    long long c;
    a = 0xbabe;
    c = 0xba1b0ab1edb100d;
    b[1] = a;
    b[4] = b[1] + c;
    return b[4];
}

mov   eax, 0FFFFBABEh
mov   word ptr [rsp], ax
…
movsx ecx, word ptr [rsp]      ; load short a
mov   dword ptr [rsp+rax+10h], ecx
…
movsxd rax, dword ptr [rsp+rax+10h]
add   rax, qword ptr [rsp+8]   ; 64-bit add
…
b[4] = 1EDACACB  →  returns AX = CACB

short main(){
    int a;
    int b[6];
    long long c;
    a = 0xbabe;
    c = 0xba1b0ab1edb100d;
    b[1] = a;
    b[4] = b[1] + (short)c;
    return b[4];
}

mov   dword ptr [rsp], 0BABEh  ; int a: plain dword store
…
mov   ecx, dword ptr [rsp]     ; plain load, no movsx
mov   dword ptr [rsp+rax+10h], ecx
…
movsx ecx, word ptr [rsp+8]    ; (short)c = low word 100Dh
add   ecx, dword ptr [rsp+rax+10h] ; 32-bit add
…
b[4] = 0000CACB  →  returns AX = CACB

• int a → the store is a full dword 0BABEh = 0x0000BABE. As an int, 0xbabe stays the positive 47,806 — no sign-extended 0FFFFBABEh constant, and b[1] = a becomes a plain int-to-int mov instead of movsx. So variant 2's b[1] is 0000BABE, not FFFFBABE.
• (short)c → take only c's low word: movsx ecx, word ptr [rsp+8] grabs 0x100D (positive → sign-extends to 0000100D) and the addition happens in 32-bit ecx, not 64-bit rax. b[4] = 0x0000BABE + 0x0000100D = 0x0000CACB.
• Punchline: both variants return AX = 0xCACB — but for different reasons, with different b[4] values (0x1EDACACB vs 0x0000CACB). Same bits, different stories: exactly why you read the types before trusting the numbers.

IMUL — Signed Multiplyinstruction ⭐ #9 · book p.65

FYI: Visual Studio seems to have a predilection for imul over mul (unsigned multiply). You'll see it showing up in places you expect mul — Xeno reports never getting MSVC to emit plain mul for simple examples. (That's a fingerprint, by the way.)

Three forms — one, two, or three operands. Three operands? Possibly the only "basic" (non-added-on-instruction-set: MMX/AVX/VMX/etc.) instruction of its kind — and note the destination doesn't have to be one of the sources.

Group 1 — single operand (widening: full product kept)

The result register is twice the operand width, so nothing is lost. The other groups aren't so lucky:

Group 2 — two operands

Group 3 — three operands, 8-bit immediate

(Group 4 is the same idea with a 16-bit immediate: IMUL r16, r/m16, imm16.)

Group 5 — three operands, 32-bit immediate

IMUL worked examples — with the math spelled out

All three start from the same registers: r12 = 0x84, rax = 0x609966C1A977E177. (In the video these run live in a Visual Studio myasm.asm scratchpad — comment/uncomment one imul, breakpoint on ret, watch the Registers window.)

MOVZX / MOVSX — move with zero / sign extendinstructions ⭐ #10 & #11 · book p.53

• Used to move small values (from smaller types) into larger registers (holding larger types).
• Support the same r→r, m→r forms as normal MOV.
• Zero extend: the CPU unconditionally fills the high-order bits of the larger register with zeros.
• Sign extend: the CPU fills the high-order bits of the destination with whatever the sign bit (most significant bit) of the small value is.

Encoding nuance (the slide glosses this): there is no movzx r64, r/m32 — a plain mov ebx, eax already zero-extends (§3.4.1.1, as ever). That's why only the sign-extending 32→64 form needs its own mnemonic: movsxd. movzx/movsx exist for 8-bit and 16-bit sources.

All three appear in this lecture's listing: movsx ecx, word ptr [rsp] (short → int, signed), movsxd rax, dword ptr […] (int → long long, signed), movzx eax, word ptr […] (16 defined bits are all a short-returning function owes its caller).

Curiosity corner — compiler fingerprinting 🔍

"Visual Studio likes imul" is more than trivia: compilers have styles, and with practice you can often name the compiler (sometimes the version and flags) from a page of disassembly. Reverse engineers use this to pick the right FLIRT/type signatures, date a binary, or cluster malware families. Some tells:

• Try it live: Compiler Explorer (godbolt.org) — one C snippet, MSVC vs GCC vs Clang side by side; and dogbolt.org for the reverse direction (decompilers compared).
• Automated ID: Detect It Easy (signature-based compiler/packer detection); IDA and Ghidra both guess the compiler on load.
• Cheap tricks: readelf -p .comment ./binary on ELF; strings | grep -i "GCC:"; on PE, parse the Rich header — see "The devil's in the Rich header" (used to attribute OlympicDestroyer's false flag).
• Rabbit hole: academic "compiler provenance" work (e.g. BinComp, origin-ID papers) recovers compiler family, version, and optimization level from stripped binaries with >90% accuracy — all from idiom statistics like the ones above.