Skip to content
Reverse Engineering
Anti-analysebeginner

Hardware Fingerprint Sandbox Check

Le malware interroge le nombre de cœurs CPU, la taille de la RAM et la capacité du disque ; les ressources anormalement faibles typiques des sandboxes automatisées trahissent l'environnement d'analyse et suppriment le déclenchement.

Les sandboxes de malware automatisées sont généralement provisionnées avec des ressources minimales pour maximiser le débit : un ou deux cœurs CPU, quelques gigaoctets de RAM et un petit disque virtuel. Le malware empreinte la machine en interrogeant ces valeurs et les compare à des seuils que le poste de travail d'un vrai utilisateur dépasserait facilement. Si la machine semble trop petite, l'échantillon suppose qu'il est dans une sandbox et se termine ou reste dormant.

C'est une évasion de niveau débutant qui n'utilise que des API documentées et aucune opération privilégiée, ce qui la rend peu coûteuse à greffer sur n'importe quel échantillon.

Fonctionnement

Le malware lit le nombre de processeurs, la mémoire physique et la taille du disque, puis rejette tout ce qui est en dessous de minimums réalistes.

c
#include <windows.h>

BOOL LooksLikeSandbox(void)
{
    SYSTEM_INFO si;
    GetSystemInfo(&si);
    if (si.dwNumberOfProcessors <= 2)            // too few cores
        return TRUE;

    MEMORYSTATUSEX ms = { sizeof(ms) };
    GlobalMemoryStatusEx(&ms);
    if (ms.ullTotalPhys < (4ULL << 30))          // < 4 GB RAM
        return TRUE;

    ULARGE_INTEGER freeBytes, totalBytes, totalFree;
    GetDiskFreeSpaceExW(L"C:\\", &freeBytes, &totalBytes, &totalFree);
    if (totalBytes.QuadPart < (60ULL << 30))     // < 60 GB disk
        return TRUE;

    return FALSE;
}

La taille du disque est aussi fréquemment interrogée avec DeviceIoControl(IOCTL_DISK_GET_LENGTH_INFO), et le nombre de cœurs via GetNativeSystemInfo ou le champ NumberOfProcessors du PEB.

Détection & contournement

  • Statique — Recherchez dans IDA/Ghidra les imports de GetSystemInfo/GetNativeSystemInfo, GlobalMemoryStatusEx, GetDiskFreeSpaceExW, et DeviceIoControl avec le code de contrôle IOCTL_DISK_GET_LENGTH_INFO. Cherchez les champs renvoyés comparés à des seuils ronds (2, 0x100000000 pour 4 Go, etc.).
  • Dynamique — Dans x64dbg, posez un point d'arrêt sur kernel32!GlobalMemoryStatusEx, kernel32!GetSystemInfo et kernel32!GetDiskFreeSpaceExW ; inspectez les structures qu'ils remplissent au retour et les comparaisons qui suivent pour découvrir les seuils exacts utilisés par l'échantillon.
  • Patch / contournement — Provisionnez une VM d'analyse réaliste (4+ cœurs, 8 Go+ de RAM, 200 Go+ de disque) pour que chaque vérification passe naturellement. Sinon, hookez les API d'interrogation pour renvoyer de grandes valeurs, ou patchez les constantes de seuil / inversez les sauts conditionnels qui branchent vers le chemin de sortie.
  • Outils — Un modèle de VM bien doté en ressources ; des hooks d'API de type Frida/ScyllaHide pour gonfler les valeurs rapportées ; le patch de sauts conditionnels dans x64dbg ; des outils comme Pafish pour vérifier que votre environnement ne déclenche plus les vérifications de ressources courantes.
Votes

Commentaires(0)