Code complètement relogeable en C ?

Signaler
Messages postés
37
Date d'inscription
jeudi 22 octobre 2009
Statut
Membre
Dernière intervention
10 décembre 2011
-
Messages postés
3983
Date d'inscription
jeudi 14 juillet 2005
Statut
Membre
Dernière intervention
30 juin 2013
-
Bonjour,

J'aurais souhaité savoir s'il était possible d'écrire du code en C et de le compiler de façon à ce qu'il soit complètement relogeable sans l'aide de la section reloc et du loader système.

Je sais qu'en assembleur il existe la technique simple du calcul du delta à l'aide d'un "faux" call, mais mes connaissance en assembleur étant trop limitées pour écrire une grosse portion de code je cherche à trouver une alternative.
J'ai bien pensé à compiler en dll ou simplement en non fixé, mais si je ne dis pas de bêtise la section reloc deviendrait obligatoire et le code ne pourrait pas être relogé à souhait, surtout en court d'execution.

Alors bien sûr il serait envisageable de faire du bricolage mais dans ce cas bonjour la maintenance du code... :S

Merci d'avance :)

8 réponses

Messages postés
6535
Date d'inscription
lundi 16 décembre 2002
Statut
Modérateur
Dernière intervention
22 août 2010
7
Salut,

Je n'ai malheureusement pas la réponse à ta question. Je ne connaissais pas la notion de relogeage (ou bien je l'avais oubliée), j'ai donc profité de ton message pour faire quelques recherches sur le sujet.
Je vois a peu près de quoi il s'agit pour les dll, mais du coup je ne comprends pas bien ta question. Tu cherches à faire quoi exactement?


_____________________________________
Messages postés
37
Date d'inscription
jeudi 22 octobre 2009
Statut
Membre
Dernière intervention
10 décembre 2011
15
Salut vecchio,

Merci de ta réponse.

En fait dans le but de sécuriser un minimum nos applis critiques, je cherchais en l'occurrence à décrypter du code en mémoire (code contenu dans l'exe original) pour ensuite l'executer directement. Sans rentrer dans les détails, peut-être le sais tu déjà mais les exe standards sont systématiquement chargés à l'imagebase 0x400000. Les dll également la plupart du temps sauf quelques fois auquel cas intervient le loader OS qui, à l'aide de la section reloc de l'exe, va se charger (entre autre) de fixer toutes les adresses absolues (globales, fonctions, etc) lors du lancement.

Or dans mon cas pas de loader, donc il va falloir que je me débrouille pour faire le boulot du loader apparemment.
Apparemment c'est une technique très employée dans le monde des virus donc je vais chercher de ce côté là. Je verrai bien si c'est faisable en C.

Merci en tous cas.
Messages postés
37
Date d'inscription
jeudi 22 octobre 2009
Statut
Membre
Dernière intervention
10 décembre 2011
15
Pour préciser (sinon effectivement on ne comprend pas trop l'intérêt) :

En fait il faut voir ça comme une "enveloppe" de l'executable hôte dont le code serait parasite en quelque sorte.
Messages postés
3983
Date d'inscription
jeudi 14 juillet 2005
Statut
Membre
Dernière intervention
30 juin 2013
12
Ca ne devrait pas être difficile : il te suffit d'ajouter un segment de code où tu placeras ta routine de décryption et de changer le point d'entrée de l'exécutable.

VB.NET is good ... VB6 is better
Utilise Réponse acceptée quand un post répond à ta question
Messages postés
37
Date d'inscription
jeudi 22 octobre 2009
Statut
Membre
Dernière intervention
10 décembre 2011
15
Salut ghuysmans,

C'est déjà ce que j'ai l'intention de faire mais le problème et le suivant :
Comme il ne s'agira que d'une "enveloppe", le but et que ça s'applique après compilation de l'appli à protéger.
Donc celle dernière doit retrouver son environnement exacte avant de s'éxécuter.
Donc le code parasite doit se trouver ailleurs que dans l'espace originalement occupée par les sections de l'appli à protéger (soit dans une section -virtuelle ou physique- ajoutée en fin, soit en mémoire allouée s'il y a eu compression).
Or lorsque je vais compiler le code parasite il le sera pour une adresse fixée ou bien accompagné d'une section reloc si compilé en non fixé.

On en arrive à mon soucis, il faudrait que ce code puisse s'éxécuter depuis n'importe qu'elle emplacement.

PS: Je sais bien qu'avec cette technique je me fais dumper en moins d'une minute, mais c'est un début.

Merci en tous cas :)
Messages postés
3983
Date d'inscription
jeudi 14 juillet 2005
Statut
Membre
Dernière intervention
30 juin 2013
12
soit dans une section -virtuelle ou physique-
C'est quoi ça ?
ou bien accompagné d'une section reloc si compilé en non fixé
On s'en fout de la reloc, de toutes façons personne s'en sert ...
avec cette technique je me fais dumper en moins d'une minute
Donc ça n'a pas beaucoup d'intérêt : dès que le cracker verra qu'il a sauté à une adresse normale (40xxxx), il saura qu'il se trouve dans le vrai code. Il lui suffira alors de modifier le point d'entrée dans l'EXE et de l'exécuter.

Pour savoir où placer le parasite, il suffit d'énumérer toutes les sections de ton exécutable et d'en trouver une de libre (le code en lui-même est portable : ce sont les données qui ne le sont pas toujours).

VB.NET is good ... VB6 is better
Utilise Réponse acceptée quand un post répond à ta question
Messages postés
37
Date d'inscription
jeudi 22 octobre 2009
Statut
Membre
Dernière intervention
10 décembre 2011
15
C'est quoi ça ?

Chui allé un peu vite, je voulais dire soit une section physique dans le sens ou je la rajoute en dur à l'exe d'origine, soit une section virtuelle dans le sens ou je compresse et je fais un gros pavé dans l'exe d'origine (ou en tous cas je refais mes propres sections) pour ensuite reconstruire tout ça proprement en mémoire.

On s'en fout de la reloc, de toutes façons personne s'en sert ...

Bah justement si, on s'en sert même très souvent. Sauf que c'est transparent car accompli par le loader de windows avant que le point d'entré ne soit atteint. Piste à oublier car il ne me sera d'aucune aide dans le cas présent.

Il lui suffira alors de modifier le point d'entrée dans l'EXE et de l'exécuter.

Ah bah non j'vais quand même pas laisser l'exe non altéré avec ma petite section ajoutée à la fin.

Donc ça n'a pas beaucoup d'intérêt : dès que le cracker verra qu'il a sauté à une adresse normale (40xxxx), il saura qu'il se trouve dans le vrai code.

L'objectif c'est justement de retourner l'exe de façon à ce que s'il (l'attaquant) veut dumper, il faudra qu'il passe par le code parasite. Or il sera truffé d'anti-debbug et le point d'entré originel sera caché et faussé jusqu'au dernier jump.

le code en lui-même est portable : ce sont les données qui ne le sont pas toujours

Sauf les fonctions (codées par moi je parle hein, les autres sont dans la table d'import dont l'alteration anti reconstruction est d'ailleurs l'objectif suivant parmi beaucoup d'autres), ainsi que les variables.
Mais bon je vais attaquer en partant du fait que la troisième appli, qui fera justement le mixe, calcule le delta en fonction de où elle place le code pour qu'ensuite le code parasite puisse s'en resservir lors d'appel de fonction ou d'accès aux variables.
Je verrai bien en cours de route ce que ça donne.

Merci beaucoup de t'être penché sur le sujet en tous cas. Je débute dans ce domaine donc je fais une reconnaissance accélérée des techniques employées par l'"ennemi". ennemi entre guillemets parce qu'en étudiant le sujet on se prend vite au jeu du challenge.
En tous cas c'est très intéressant et surtout très instructif.
Je me suis d'ailleurs aperçu que nos méthodes d'auto hashage du fichier et autres étaient réellement contournables en beaucoup moins de temps qu'il ne faut pour les coder. Comme quoi on ne se protège pas sans savoir comment on va se faire attaquer !
Messages postés
3983
Date d'inscription
jeudi 14 juillet 2005
Statut
Membre
Dernière intervention
30 juin 2013
12
On s'en fout de la reloc, de toutes façons personne s'en sert ...
C'est quand même utilisé mais pas systématiquement. Je ne pourrai pas t'aider sur le sujet, je n'y connais rien.

Ah bah non j'vais quand même pas laisser l'exe non altéré avec ma petite section ajoutée à la fin.
Non je parlais du côté cracker. Lui il s'en fout de laisser ton bout de code à la fin du programme : il ne sera quand même jamais exécuté. Il faut évidemment obfusquer ton code ...

L'objectif c'est justement de retourner l'exe de façon à ce que s'il (l'attaquant) veut dumper, il faudra qu'il passe par le code parasite. Or il sera truffé d'anti-debug et le point d'entré originel sera caché et faussé jusqu'au dernier jump.
On n'est pas dans Harry Potter : ton anti-debug à la gomme, on saura lui faire la peau et tu n'y pourras rien. Et tout ce qu'attend le cracker, c'est bien le dernier jump

Mais bon je vais attaquer en partant du fait que la troisième appli, qui fera justement le mixe, calcule le delta en fonction de où elle place le code pour qu'ensuite le code parasite puisse s'en resservir lors d'appel de fonction ou d'accès aux variables.
Pas trop pigé là : tu veux que le programme principal fasse appel au parasite pour l'accès au variables et aux fonctions ? C'est irréalisable (sauf en travaillant sur l'ASM produit par VC++ mais là ça devient du masochisme ) vu que l'accès à une variable et l'appel de la fonction dans le parasite n'ont pas la même taille (et même si c'était le cas, ton programme serait lent à se suicider).


Pour résumer, ne perds pas ton temps à ça : tout ce qui pourrait être utile c'est de compacter le code histoire de gagner un peu de place. Cela existe déjà avec des programmes tels qu'UPX.

VB.NET is good ... VB6 is better
Utilise Réponse acceptée quand un post répond à ta question