Discussion :

[mat.M]

Bonjour,
je voudrais développer un programme en assembleur jusque-là rien d'extraordinaire puisque c'est le forum adéquat.
En fait je voudrais plus précisément créer mon propre assembleur x86 qui serait appelé le cas échéant plus tard par mon propre language de programmation ;
je veux développer à la base un assembleur qui puisse créer des .exe puis développer un compilateur ( par exemple une sorte de basic ).
Le problème est : comment appeler une API comme MessageBox ou SetPixel contenues dans les dll de Windows SANS AUCUNE LIAISON avec des librairies externes.

Je m'explique : vous développez un programme en assembleur vous faites cela avec TASM , MASM , FASM il ya des librairies de codes qui contiennent les références des imports à ces API .
Moi je veux partir de rien du tout , à la limite avec Debug sous DOS ( quoique pas possible puisque debug =16 bits ) ou bien avec A86/D86 si ça existe encore, pour créer mes propres librairies de codes .
Puis développer mon propre éditeur de lien.
Pour développer le language assembleur / compilateur ce sera fait en C++...

Alors comment faire pour appeler une API win32 SANS extern ?

Sinon autre petite question , qui dit appli win 32 en assembleur dit utilisation d'instructions pour passer en mode protégé ??? Je ne pense pas que cela soit vraiment utile voir risqué.

Merci pour les idées.

[Smortex]

Ta question est paradoxale : appeler des API sans utiliser de librairies... Le code des API etant justement dans des dll... Donc soit DLL et API soit ni DLL ni API...

Dans ces conditions, peut tu preciser ce que tu demande ?

[Neitsa]

Bonjour,

J'ai 'pondu' une lib la-dessus il y a qque temps (une sorte de GetProcAddress personnel).

Solution assez complexe:

a) Retrouver l'Image_Base de Kernel32.dll
b) Retrouver la table d'export de Kernel32.dll
c) Faire un parsing de la table d'export
-Retrouve le nom de (des) API recherchées (LoadLibrary et GetProcAddress)
-Retrouver la localisation de leur procédures dans la DLL (dans la table d'export on trouve les RVA)
d) Une fois obtenu l'adresse d'une API, on peut l'appeler avec la méthode des push/call (grâce à LoadLibrary et GetProcaddress on peut ensuite appeler n'importe quel API du système).

Il me semble que MASM interdit de faire un exe sans imports [un import au minimum] (je ne sais pas pour les autres compilos), je ne sais même pas si le loader de windows apprécie cela.

Cette technique est souvent employé pour le low-level sous windows ,aussi bien pour les shellcodes que pour les virii (je précise que je n'écris ni l'un ni l'autre). C'est aussi un moyen de protection contre les débuggeur Ring3 (qui pose des BP sur les JMP de l'IAT).

je tiens à préciser que c'est plus un "truc" ou du bricolage qu'autre chose, certainement pas une manière propre de coder...

La voie normal ce fait normalement par les champs de l'IAT (Import Adress Table) et de la combinaison FirstThunk/OriginalFirstThunk avec l'IMAGE_IMPORT_BY_NAME, le sytème résovant le cas échéant les problèmes...Les DLL systèmes et les programmes ont été concus pour cela (norme PE/COFF).

qui dit appli win 32 en assembleur dit utilisation d'instructions pour passer en mode protégé ???

Effectivement, Windows ne cohabite absolument pas avec le mode réel. Je ne comprend pas très bien ce que tu veux faire exactement. Un prog en mode réel qui appelle les DLL systèmes de windows??? c'est complètement impossible... Les DLL sont chargées au démarrage de windows par son loader et mappées dans l'espace d'adressage du système, de manière a ce qu'elle soient vues globalement par les process/threads.

[Morgatte]

Sur le site d'Iczelion il y a un petit essai de Yoda en page 3 (1234) si je me souvien bien appelé (Kernel.zip), qui parle exactement de ça.

C'est très proche de ce qu'a expliqué Neitsa.

On peut donc effectivement appeler n'importe quelle API sans passer par l'IAT. (Je m'en sert régulièrement pour mes packers dans la section .loader)

[TangiX]

Je veux pas etre mechant mais j'ai comme l'impression que vous tous a coté de la plaque par rapport au message de mat.M. son but n'est pas de conterner le role de l'IAT par plaisir ou par défi... amon avis mat.M veux construire cet IAT ainsi que le reste du fichier PE en compilant de maniere binaire afin de realiser son propre linker.

je me trompe peut etre....

[Morgatte]

On dirait bien oui. Mais franchement je vois pas comment il va s'en sortir sur ce coup là.

[mat.M]

Merci à tous pour les réponses

Effectivement, Windows ne cohabite absolument pas avec le mode réel. Je ne comprend pas très bien ce que tu veux faire exactement. Un prog en mode réel qui appelle les DLL systèmes de windows??? c'est complètement impossible...

Merci pour la réponse
non je ne veux pas faire un programme particuilièrement en mode réel ce que je veux savoir c'est si on développe une appli win32 en assembleur d'assurer une compatibilité mode protégé.
Est-ce qu'on écrit un programme win32 comme on écrit un programme pour le 8086 ???
Je crois que c'est totalement transparent exception faite de la possibilité d'utiliser les registres étendus ( EAX , ECX )
Mais je crois que c'est totalement inutile

Je veux pas etre mechant mais j'ai comme l'impression que vous tous a coté de la plaque par rapport au message de mat.M. son but n'est pas de conterner le role de l'IAT par plaisir ou par défi... amon avis mat.M veux construire cet IAT ainsi que le reste du fichier PE en compilant de maniere binaire afin de realiser son propre linker.

Non les autres personnes ne sont pas forcément à côté de la plaque et la réponse de Neitsa est assez satisfaisante mais effectivement je veux combiner entête PE + code exécutable.
Je veux réaliser mon propre compilateur ou assembleur code machine pour win32 tout bêtement sans passer par TASM ou MASM car ces outils rajoutent leurs propres librairies

[mat.M]

Pour résumer : tout ce que je veux faire c'est comme si j'utilisais comme seul outil debug sous Dos et dans mon code source appeler par exemple SetPixel du GDI.
(mais ce n'est pas possible avec Debug car code 16 bits et pas possible de créer un exe )
Comment faire pour appeler SetPixel alors ?

[mat.M]

Ta question est paradoxale : appeler des API sans utiliser de librairies... Le code des API etant justement dans des dll... Donc soit DLL et API soit ni DLL ni API...

Dans ces conditions, peut tu preciser ce que tu demande ?

En fait ce que je voulais dire c'est si on développe un programme en assembleur win32 il faut utiliser le fichier windows.inc.
Le programme assembleur va lier le code objet généré à un fichier d'imports ( que j'ai qualifié peut-être à travers de "librairies") .
Prenez TASM : il y a un dossier "librairies" qui sont liées au code objet.

Et moi je ne veux pas de cela je veux faire mes propres librairies mon propre assembleur

[Smortex]

Je suis pas sur que c'est ce que tu cherche, mais j'avais fait ca avec FASM (Le programme dessinait sur le bureau l'etat de charge de la batterie du portable) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
section '.code' code readable executable
 
[...]
 
    ;-----------------------------;
    ; Restauration des paramètres ;
    ; de bordure                  ;
    ;-----------------------------;
 
    push [hOldPen]
    push [DesktopDC]
    call [SelectObject]
 
    push [hForePen]
    call [DeleteObject]
 
[...]
section '.idata' import data readable writeable
 
  dd 0,0,0,RVA kernel_name,RVA kernel_table
  dd 0,0,0,RVA gdi_name, RVA gdi_table
  dd 0,0,0,RVA user_name,RVA user_table
  dd 0,0,0,0,0
 
  kernel_table:
    Beep dd RVA _Beep
    ExitProcess dd RVA _ExitProcess
    GetSystemPowerStatus dd RVA _GetSystemPowerStatus
    Sleep dd RVA _Sleep
    dd 0
  gdi_table:
    CreatePen dd RVA _CreatePen
    CreateSolidBrush dd RVA _CreateSolidBrush
    DeleteObject dd RVA _DeleteObject
    Rectangle dd RVA _Rectangle
    SelectObject dd RVA _SelectObject
    dd 0
  user_table:
    GetDesktopWindow dd RVA _GetDesktopWindow
    GetWindowDC dd RVA _GetWindowDC
    GetSystemMetrics dd RVA _GetSystemMetrics
    MessageBoxA dd RVA _MessageBoxA
    ReleaseDC dd RVA _ReleaseDC
    dd 0
 
  kernel_name db 'KERNEL32.DLL',0
  gdi_name db 'GDI32.DLL',0
  user_name db 'USER32.DLL',0
 
  _Beep dw 0
    db 'Beep',0
  _ExitProcess dw 0
    db 'ExitProcess',0
  _GetSystemPowerStatus dw 0
    db 'GetSystemPowerStatus'
  _Sleep dw 0
    db 'Sleep',0
 
  _CreatePen dw 0
    db 'CreatePen', 0
  _CreateSolidBrush dw 0
    db 'CreateSolidBrush', 0
  _DeleteObject dw 0
    db 'DeleteObject', 0
  _Rectangle dw 0
    db 'Rectangle',0
  _SelectObject dw 0
    db 'SelectObject', 0
 
  _GetDesktopWindow dw 0
    db 'GetDesktopWindow', 0
  _GetSystemMetrics dw 0
    db 'GetSystemMetrics', 0
  _GetWindowDC dw 0
    db 'GetWindowDC', 0
  _MessageBoxA dw 0
    db 'MessageBoxA',0
  _ReleaseDC dw 0
    db 'ReleaseDC',0

Si ca t'inspire

[mat.M]

Ok Merci Smortex je vais étudier cela