cours/content/secu_systeme/3_compilation_obfiscation_llvm/index.md at a0d73353e68c16b228c66c6687aac83b51bec4f5

ephase/cours

Fork 0

Yorick Barbanneau d129c59be2 Add obfuscation lesson

2023-10-24 01:19:10 +02:00

10 KiB

Raw Blame History

title

date

compilation en trois étapes

Il est possible de découper la compilation en 3 étapes avec LLVM:

Le code source passe par un frontend avec l'analyse syntaxique et sémantique;
Le résultat passe par un middle-end qui va procéder aux optimisations;
Et enfin par un backend qui va transformer le code optimisé en code assembleur et réaliser des optimisations spécifique à l'architecture cible.

L'obfuscation du code se fait au niveau du middle-end.

Dans le cadre de la suite d'outils autour de LLVM nous avons plusieurs backends (clang, flang, RetDec) qui transforme le code en entrée en code LLVM (middle-end) sur lequel seront réalisées les optimisations. Et enfin le résultat passe dans un compilateur qui le transforme en code binaire (ARM. x86_64, Webassembly,...).

Nous avons déjà vu cette partie lors [de l'introcution]({{<ref "secu_systeme/1_introduction/index.md#la-compilation">}})

Vie d'un hello world

Voyons maintenant ce qu'il se passe dans le cadre du code suivant:

#include <stdio.h>
int main(int argc, char** argv) {
  puts("Hello, world!\n");
  return 0;
}

l'AST (Frontend)

Voyons l'AST produit avec clang grâce à la commande suivante avec la commande:

clang -Xclang -ast-dump -fsyntax-only main.c

le voici donc:

`-FunctionDecl 0x56028bd93cc0 <main.c:3:1, line:6:1> line:3:5 main 'int (int, char **)'
  |-ParmVarDecl 0x56028bd93b68 <col:10, col:14> col:14 argc 'int'
  |-ParmVarDecl 0x56028bd93be8 <col:20, col:27> col:27 argv 'char **'
  `-CompoundStmt 0x56028bd93e88 <col:33, line:6:1>
    |-CallExpr 0x56028bd93e00 <line:4:3, col:25> 'int'
    | |-ImplicitCastExpr 0x56028bd93de8 <col:3> 'int (*)(const char *)' <FunctionToPointerDecay>
    | | `-DeclRefExpr 0x56028bd93d70 <col:3> 'int (const char *)' Function 0x56028bd8f730 'puts' 'int (const char *)'
    | `-ImplicitCastExpr 0x56028bd93e40 <col:8> 'const char *' <NoOp>
    |   `-ImplicitCastExpr 0x56028bd93e28 <col:8> 'char *' <ArrayToPointerDecay>
    |     `-StringLiteral 0x56028bd93d90 <col:8> 'char[15]' lvalue "Hello, world!\n"
    `-ReturnStmt 0x56028bd93e78 <line:5:3, col:10>
      `-IntegerLiteral 0x56028bd93e58 <col:10> 'int' 0

Langage intermédiaire (Middle-end)

Maintenant, regardons le code LLVM produit par clang:

clang -S -emit-llvm -Xclang -disable-O0-optnone main.c -o

À ce niveau, le code obtenu n'est pas optimisé:

; ModuleID = '/home/user/code/main.c'
source_filename = "/home/user/code/main.c"
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-pc-linux-gnu"
@.str = private unnamed_addr constant [15 x i8] c"Hello, world!\0A\00", align 1
; Function Attrs: noinline nounwind uwtable
define dso_local i32 @main(i32 noundef %0, ptr noundef %1) #0 {
  %3 = alloca i32, align 4
  %4 = alloca i32, align 4
  %5 = alloca ptr, align 8
  store i32 0, ptr %3, align 4
  store i32 %0, ptr %4, align 4
  store ptr %1, ptr %5, align 8
  %6 = call i32 @puts(ptr noundef @.str)
  ret i32 0
}
declare i32 @puts(ptr noundef) #1

Optimisation (Middle-end)

Voici la commande permettant de lancer les optimisations sur le code intermediaire LLVM:

opt -S -O2 main.ll

Le code produit contient plus les élements jugés inutiles comme ici argv et argc :

; ModuleID = '<stdin>'
source_filename = "/home/user/code/main.c"
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-pc-linux-gnu"
@.str = private unnamed_addr constant [15 x i8] c"Hello, world!\0A\00", align 1
; Function Attrs: nofree noinline nounwind uwtable
define dso_local i32 @main(i32 noundef %0, ptr nocapture noundef readnone %1) local_unnamed_addr #0 {
  %3 = tail call i32 @puts(ptr noundef nonnull @.str)
  ret i32 0
}
; Function Attrs: nofree nounwind
declare noundef i32 @puts(ptr nocapture noundef readonly) local_unnamed_addr #1

Transformation en assembleur (Backend)

Voici la commande qui permet de transformer le code intermédiaire optimisé en code assembleur:

llc main.ll -o main.s

Le code obtenu sera cette-fois dépendant de l'architecture cible. Une fois trasformé en code machine, il se sera pas directement exécutable, il manque l'édition de lien.

LLVM

LLVM signifie Low Level Virtual Machine est une spécification d'une représentation intermédiaire (LLVM-IR) accompagnée d'un ensemble d'outils qui communiquent autour de rette réprésentation.

LLVM se compose de modules, son langage est de type RISC fortement typé et non signé - certaine opération le sont par contre comme div et sdiv.

Prenons comme exemple le code C suivant :

double polynome(float x) {
  return 2*x*x*x + 7*x*x + 9*x + 1234;
}

Voici la représenation LLVM :

; Function Attrs: mustprogress nofree nosync nounwind readnone willreturn uwtable
define dso_local double @polynome(float noundef %0) local_unnamed_addr #0 {
  %2 = fmul float %0, 2.000000e+00
  %3 = fmul float %2, %0
  %4 = fmul float %0, 7.000000e+00
  %5 = fmul float %4, %0
  %6 = tail call float @llvm.fmuladd.f32(float %3, float %0, float %5)
  %7 = tail call float @llvm.fmuladd.f32(float %0, float 9.000000e+00, float %6)
  %8 = fadd float %7, 1.234000e+03
  %9 = fpext float %8 to double
  ret double %9

Branchements

Il n'y a pas de structure de contrôle comme dans les langages de plus haut niveau, mais certaines instructions permettent des branchements (conditionnels ou non) comme br, ret, switch, invoke, resume ...

Prenons comme exemple :

void then_(int);
void else_(int);
void if_then_else(int a, int b, int c) {
  if(a) then_(b);
  else else_(c);
}

le code correspondant en représentation intermediaire:

  %4 = icmp eq i32 %0, 0
  br i1 %4, label %6, label %5

5:                                                ; preds = %3
  tail call void @then_(i32 noundef %1) #2
  br label %7

6:                                                ; preds = %3
  tail call void @else_(i32 noundef %2) #2

Static Single Assignement et PHI-Node

Les instructions LLVM prennent la forme de SSA ce qui signifie principalement qu'une variable peut être assignée une seule fois. C'est ici que les PHI-Nodes entrent en jeu.

Prenons le code C suivant:

a = 1;
if (v < 10)
    a = 2;
b = a;

Le code LLVM-IR coorespondant est le suivant:

a1 = 1;
if (v < 10)
    a2 = 2;
b = PHI(a1, a2);

L'instruction b = PHI(a1, a2) permet de faire une affectation conditionnelle de b. Le fonctionement de phi est le suivant:

%10 = PHI i32 [valeur, label] [valeur, label]

PHI peut faire référence à des variables non déclarées.

Memoire

LLVM-IR dispose de quelques instructions pour l'accès à la mémoire comme load, store, cmpxchg,

Types complexe

LLVM-IR dispose de plusieurs rypes complexe comme:

les vecteurs sour la forme <4 x i32> représentant 4 entiers de 32 bits;
les tableaux sous la forme i32[10]
les structures sous la forme my_struct = type { i32, i32}

Les exceptions

LLVM-IR permet la gestion des exceptions, mais nous n;utiliserons pas ces mécanismes das le cadre de ce cours. LLVM dispose de fonction intrinsèques pour la gestion des exceptions préfixée par llvm.eh. Toutes les fonctions disponibles sont référencées sur cette page

L'obfuscation

L'obfuscation a pour but principal de ralentir au maximum l'opération de reverse engineering. Il est souvent question de protéger les parties les plus sensibles, celle contenant des clés de chiffrement, des algorithmes etc.

Cette protection sera de toutes manières éphemère et elle a un prix, voire même plusieurs:

exécution plus lente
consommation mémoire alourdie
binaire plus volumineux

Il faut alors trouver un compromis. nous allons voir les techniques utilisées.

Obfusquer les instructions

Il est question de remplacer les instructions élémentaires par des équivalent par exemple:

A + B == (A & B)<<1 + (A ^ B)
A - B == (A & -B)<<1 + (A ^ -B)
A ^ B == A + B - (A & B)<<1

Prédicat opaques

Il existe plusiers façon d'opacifier certaines partie du code. Il est pas exemple possible d'ajouter du code mort : une condition toujours vérifiée mène au code "correct" :

int predicat = F(x); // F(x) est toujours vrai
if ( predicat ) {
    // donc on exécutera toujours le bon code
    good_code();
}
else {
    // et ça c'est pour perdre le 'reverser'
    useless_insanely_complex_code();
}

Il est aussi possible de remplacer certaines fonctions mathematiques par certaines autres par exemple:

log2(x) == log10(x) - log10(2)

Il est aussi possible des constantes opaque, trouver par exemple pi avec la formule suivante:

pi = 4 * (1 - 1/3 + 1/5 - 1/7 + ... + 1/N);

Après suffisement d'itération, la marge d'erreur est en dessous de 0,2.

Tester ses obfuscations

Il est très important de tester les obfuscations déjà pour ne pas introduire de bugs, mais aussi pour vérifier qu'elles survivent aux optimisations. Il est possible de faires des tests unitaires, des tests par fuzzing, test de reproductibilité.

Il faut savoir que certaines optimisations effectuées par les compilateurs peuvent faire penser à des obfuscations. La division etant très couteuses, elle est remplacée par une série d'opérations plus rapide.

Premiers TP

Il est question ici de modifier le code intermédiaire LLVM en utilisant son API. Nous allons manipuler l'IR. LLVM est capable de faire de l'instrospection par exemple:

// est ce que I est une fonction
isa<CAllInst>(I);

10 KiB Raw Blame History