2010-05-28 26 views
3

PrésentationOù est l'appel de méthode dans le fichier EXE?

Après avoir regardé cette vidéo de LIDNUG, sur la protection de code .NET http://secureteam.net/lidnug_recording/Untitled.swf (en particulier de 46:30 à 57:30), je localiser l'appel à un MessageBox.Show dans un EXE J'ai crée.

La seule logique dans mon "TrialApp.exe" est:

public partial class Form1 : Form 
{ 
    public Form1() 
    { 
     InitializeComponent(); 
    } 

    private void Form1_Load(object sender, EventArgs e) 
    { 
     MessageBox.Show("This is trial app"); 
    } 
} 

Compilé sur la configuration de sortie: http://rapidshare.com/files/392503054/TrialApp.exe.html

Ce que je fais pour localiser l'appel

Run l'application dans WinDBG et pause après la boîte de message apparaît.

Obtenir la pile de CLR avec !clrstack:

0040e840 5e21350b [InlinedCallFrame: 0040e840] System.Windows.Forms.SafeNativeMethods.MessageBox(System.Runtime.InteropServices.HandleRef, System.String, System.String, Int32) 
0040e894 5e21350b System.Windows.Forms.MessageBox.ShowCore(System.Windows.Forms.IWin32Window, System.String, System.String, System.Windows.Forms.MessageBoxButtons, System.Windows.Forms.MessageBoxIcon, System.Windows.Forms.MessageBoxDefaultButton, System.Windows.Forms.MessageBoxOptions, Boolean) 
0040e898 002701f0 [InlinedCallFrame: 0040e898] 
0040e934 002701f0 TrialApp.Form1.Form1_Load(System.Object, System.EventArgs) 

Obtenir la structure MethodDesc (en utilisant l'adresse de Form1_Load) !ip2md 002701f0

MethodDesc: 001762f8 
Method Name: TrialApp.Form1.Form1_Load(System.Object, System.EventArgs) 
Class:  00171678 
MethodTable: 00176354 
mdToken:  06000005 
Module:  00172e9c 
IsJitted:  yes 
CodeAddr:  002701d0 
Transparency: Critical 
Source file: D:\temp\TrialApp\TrialApp\Form1.cs @ 22 

Dump de l'IL de ce procédé (par MethodDesc) !dumpil 001762f8

IL_0000: ldstr "This is trial app" 
IL_0005: call System.Windows.Forms.MessageBox::Show 
IL_000a: pop 
IL_000b: ret 

Ainsi, comme le vidéo mentionnée, l'appel à Show est de 5 octets depuis le début de la mise en œuvre de la méthode.

Maintenant j'ouvre CFFExplorer (comme dans la vidéo) et j'obtiens le RVA de la méthode Form1_Load: 00002083. Après cela, je vais à Address Converter (encore une fois dans CFF Explorer) et naviguez pour compenser 00002083. Il nous:

32 72 01 00 00 70 28 16 00 00 0A 26 2A 7A 03 2C 
13 02 7B 02 00 00 04 2C 0B 02 7B 02 00 00 04 6F 
17 00 00 0A 02 03 28 18 00 00 0A 2A 00 03 30 04 
00 67 00 00 00 00 00 00 00 02 28 19 00 00 0A 02 

Dans la vidéo est mentionné que les 12 premiers octets sont l'en-tête de la méthode alors je les ai sauter

        2A 7A 03 2C 
13 02 7B 02 00 00 04 2C 0B 02 7B 02 00 00 04 6F 
17 00 00 0A 02 03 28 18 00 00 0A 2A 00 03 30 04 
00 67 00 00 00 00 00 00 00 02 28 19 00 00 0A 02 

5 octets depuis le début de la mise en œuvre devrait être le opcode pour appel de méthode (28). Malheureusement, n'est pas là.

02 7B 02 00 00 04 2C 0B 02 7B 02 00 00 04 6F 
17 00 00 0A 02 03 28 18 00 00 0A 2A 00 03 30 04 
00 67 00 00 00 00 00 00 00 02 28 19 00 00 0A 02 

Questions:

  1. Qu'est-ce que je fais mal?
  2. Pourquoi il n'y a pas d'appel de méthode à cette position dans le fichier? Ou peut-être la vidéo manque-t-elle quelques informations ...
  3. Pourquoi le gars de cette vidéo remplace-t-il l'appel par 9 zéros?

Répondre

2

Lorsque j'utilise Ildasm.exe et regarder l'IL avec Afficher Bytes activés Je vois ceci:

.method private hidebysig instance void Form1_Load(object sender, 
                class [mscorlib]System.EventArgs e) cil managed 
// SIG: 20 02 01 1C 12 15 
{ 
    // Method begins at RVA 0x20f1 
    // Code size  12 (0xc) 
    .maxstack 8 
    IL_0000: /* 72 | (70)00000D  */ ldstr  "This is trial app" 
    IL_0005: /* 28 | (0A)00001E  */ call  valuetype [System.Windows.Forms]System.Windows.Forms.DialogResult [System.Windows.Forms]System.Windows.Forms.MessageBox::Show(string) 
    IL_000a: /* 26 |     */ pop 
    IL_000b: /* 2A |     */ ret 
} // end of method Form1::Form1_Load 

Les valeurs de jeton dans votre décharge ne sont pas les mêmes, vous semblez avoir un programme beaucoup plus vaste. Mais l'IL dans votre vidage commence au décalage 1, pas 12. Pas sûr pourquoi il est éteint.

+0

Hey! Merci pour votre réponse. Vous avez compilé le code avec le compilateur que vous avez, non? Parce que je vois que vous avez un RVA différent. Le problème pourrait-il être causé par le fait que j'ai utilisé le compilateur de VS2010 (la plate-forme cible est .NET 4.0)? –

+0

Bien sûr, la structure interne a peut-être complètement changé dans la version 4 du CLR. Vous piratez les structures de données CLR non documentées, tout est possible. La seule raison pour laquelle on en sait quelque chose est à cause du code source de SSCLI 2.0. Il a déjà plus de 5 ans. –

+0

Trouvé (l'appel)! Était dans les 12 octets j'ai enlevé. (6 octets depuis le début: 28 16 00 00 0A). Hans Passant, merci beaucoup pour votre réponse utile! –