forentfraps/pe-signgenGénération universelle de signatures pour toute fonction système de toutes les builds Windows à l'aide de Winbindex
Signatures binaires multi-versions et offsets RVA pour les fonctions Windows PE
pe-signgen est un outil destiné aux ingénieurs en rétro-ingénierie et aux chercheurs en sécurité qui génère automatiquement :
L'idée centrale est de fournir un moyen systématique et robuste d'accéder aux fonctions non exportées sur les builds Windows 10/11. L'outil s'appuie sur :
⚠️ Prise en charge des versions Windows
pe-signgenprend en charge uniquement Windows 10 et Windows 11. Il s'agit d'un choix de conception délibéré : Winbindex ne fournit pas de données complètes pour les versions plus anciennes.
Internes Windows non exportés
Générer des signatures pour des fonctions comme LdrpInitializeTls, RtlpInsertInvertedFunctionTableEntry, etc.
Recherche sur le game hacking / l'anti-triche Générer des signatures stables qui survivent aux mises à jour des jeux
Recherche en sécurité Localiser les routines critiques pour la sécurité sur différents builds Windows
Automatisation Génération scriptable de signatures et d'offsets pour des ensembles entiers d'API internes
pe-signgen fournit trois formats de sortie distincts pour différents cas d'usage :
Données structurées pour l'automatisation, les scripts et l'intégration avec d'autres outils.```bash pe-signgen --signature ntdll!NtCreateFile -o ntcreatefile.json --output-format json
**Structure de sortie :**```json
{
"dll_name": "ntdll",
"function_name": "NtCreateFile",
"architecture": "x64",
"generated": "2024-12-11T15:30:00.123456",
"total_builds": 1247,
"unique_signatures": 3,
"signature_groups": [
{
"matched_symbol": "NtCreateFile",
"signature": "4C 8B DC 49 89 5B 08 49 89 6B 10 49 89 73 18 ...",
"length": 48,
"build_count": 845,
"versions": [
{ "major": 10240, "minor": 16384, "build": "10240.16384" },
{ "major": 10586, "minor": 0, "build": "10586.0" }
]
}
]
}
Notes :
major et minor sont dérivés de la chaîne de build en la divisant au premier ..
Exemple : "10240.16384" → major = 10240, minor = 16384.build est la chaîne de build d’origine utilisée comme clé interne.Formats binaires compacts, prêts à l’exécution, optimisés pour les systèmes embarqués et l’analyse à faible surcharge.
Ils correspondent à la disposition sur disque implémentée dans write_wsig() et write_woff().
Magic : WSO\0 (0x57 0x53 0x4F 0x00)
Version actuelle : 1
Objectif : stocker des signatures binaires avec masques génériques (wildcards) et les versions de build Windows associées
┌─────────────────────────────────────┐ │ Header (36 bytes) │ ├─────────────────────────────────────┤ │ DLL Name (variable) │ ├─────────────────────────────────────┤ │ Function Name (variable) │ ├─────────────────────────────────────┤ │ Signature / Mask / Build blobs │ ← Arbitrary order, see notes ├─────────────────────────────────────┤ ← Aligned to 4 bytes │ Groups Table (24 × N bytes) │ └─────────────────────────────────────┘
**Notes importantes sur la disposition (correspond à `write_wsig`)**
* Après l'en-tête, les noms de DLL et de fonction sont écrits sous forme d'octets UTF‑8.
* Pour chaque groupe de signatures, les octets de motif et les octets de masque sont écrits, suivis du tableau de build pour ce groupe.
* Ces régions par groupe ne sont **pas** regroupées globalement par type : les motifs, les masques et les tableaux de build peuvent être entrelacés.
* Le builder s'aligne sur **4 octets** avant chaque tableau de build et avant la table des groupes. Cela peut introduire du remplissage.
* Les consommateurs doivent **toujours** suivre les décalages dans l'en-tête et les entrées de groupe ; ne **pas** se fier au diagramme conceptuel pour la contiguïté physique.
##### Disposition de l'en-tête (36 octets)```c
// Packed as: "<4sIIIIIIII" (little-endian)
typedef struct {
char magic[4]; // "WSO\0" (WSIG_MAGIC)
uint32_t version; // FORMAT_VERSION (currently 1)
uint32_t arch; // Architecture code (1=x64, 2=ARM64, 3=WoW64)
uint32_t dll_off; // Offset to DLL name string
uint32_t dll_len; // Length of DLL name in bytes
uint32_t func_off; // Offset to function name string
uint32_t func_len; // Length of function name in bytes
uint32_t group_count;// Number of signature groups
uint32_t groups_off; // Offset to groups table
} wsig_header_t; // 36 bytes
Chaque groupe de signatures représente un motif unique qui s'applique à une ou plusieurs builds Windows.```c // Packed as: "<IIIIII" (little-endian)
typedef struct { uint32_t sig_off; // Offset to signature pattern bytes uint32_t sig_len; // Length of signature pattern (in bytes) uint32_t mask_off; // Offset to wildcard mask bytes uint32_t mask_len; // Length of wildcard mask (≈ ceil(sig_len/8)) uint32_t builds_off; // Offset to build version array uint32_t build_cnt; // Number of builds using this signature } wsig_group_t; // 24 bytes
##### Entrée de version de build (8 octets)
Chaque entrée de version de build identifie une version Windows spécifique qui utilise cette signature.```c
typedef struct {
uint32_t major; // e.g. 19041
uint32_t minor; // e.g. 1234
} wsig_build_t; // 8 bytes
major et minor proviennent de la décomposition de la chaîne de build (« A.B » → A, B). La chaîne de build d'origine n'est pas stockée dans le format binaire ; si vous en avez besoin, conservez-la en externe (elle est présente dans la sortie JSON).
Le masque est un masque de bits (bitmask) où chaque bit correspond à un octet du motif de signature :
Exemple :``` Signature: 4C 8B DC 49 89 ?? 08 49 Mask bits: 1 1 1 1 1 0 1 1 (MSB first within each byte) Mask byte: 0xBF (binary: 10111111)
Les octets de masque sont stockés et interprétés selon **l'ordre des bits little-endian** au sein de chaque octet (exactement comme dans les helpers C et `parse_signature`) :```c
uint8_t bit = (mask_bytes[byte_index >> 3] >> (byte_index & 7)) & 1u;
*_len pour déterminer la longueur ; ne lisez pas au-delà.Magic : WOF\0 (0x57 0x4F 0x46 0x00)
Version actuelle : 1
Objectif : Stocker les RVA directes et les offsets de fichier pour les fonctions à travers les builds Windows