Discussion :

[klakman]

Bonjour,

Je sais que cette question a été posé plusieurs fois sur ce forum, pour avoir pris le temps de lire les réponses que j'ai trouvé.

Cependant l'assembleur n'est pas du tout ma spécialité. Je programme en C/C++ et Java habituellement. ( J'ai néanmoins quelques base en assembleur, plus ce que j'ai appris ces derniers jours durant mes recherches. )

Mais pour les besoins d'une application que je développe, il faudrait que je puisse ajouter une fonction à une DLL.

Cette fonction serait chargée d'ouvrir puis écrire un code dans un fichier .txt, et enfin refermer le fichier.

D'après ce que j'ai pu lire ici et là, mon code doit ressembler à ceci :

Code :

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

1
2
3
4
5
6
7
8
 
mov AH, 3Dh ; pour la fonction "ouvrir fichier"
mov AL, 2     ; mode d'ouverture "lecture/écriture"
 
; ici l'instruction qui me pose problème
mov DX, ????
 
INT 21 ; interruption logiciel

Alors il me semble bien avoir compris que dans DX je dois mettre l'offset de ma chaine de caractère.
Mais avant je dois avoir dans DS, le segment où est stoqué ma chaine.

Et là je ne sais pas comment récupérer cette info ( le segment ). Je sais que j'ai stoqué la chaine dans .rdata, mais comment y accéder.

Avant compilation en assembleur j'ai vu des choses de la sorte :

Code :

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

1
2
3
 
mov ax, @rdata
mov ds, ax

Mais la première instruction ne fonctionne pas lorsque je le fais dans le débugueur.

J'espère avoir été clair, si ce n'est pas le cas demandez moi des précisions.

Merci par avance.

PS: je suis sur un système 32 bits.

[Neitsa]

Bonjour,

Il est important de comprendre qu'on ne peut plus du tout utiliser d'interruptions sous Windows 32 ou 64 bits, sauf à de rares exceptions qui entrent dans un cadre très particulier.

L'appel à une interruption (via l'instruction INT) ou la manipulation des registres de segment depuis l'espace utilisateur (ring3) est donc prohibé sous Windows. Cela reste possible uniquement si l'on dispose du niveau de privilège kernel (ring0).

Pour demander un (ou des) service(s) à Windows on doit alors obligatoirement passer par son API.

Si tu souhaites créer un fichier, il faut donc passer par CreateFile puis WriteFile pour y écrire.

[klakman]

Ok, merci beaucoup.

Je suis habitué à l'utilisation de l'API windows en C/C++, mais là va falloir que j'apprenne pour le faire en assembleur.

[Rémi Coquet]

C'est exactement pareil pourquoi voudrais-tu qu'il y ait une différence ?

[Noteworthy]

Salut,

Les fichiers d'entrée-sortie sous Win32 ressemblent étonnement à ceux sous DOS (en utilisant les interruptions). Les étapes nécessaires sont les mêmes. Tu as seulement besoin de changer les appels d'INT aux API, c'est tout. Les étapes exigées sont les suivantes :

• Ouvrez ou créez le fichier en appelant la fonction CreateFile.
• Déplacez le pointer dans le fichier à l'emplacement désiré en appelant SetFilePointer.
• Exécutez, lisez ou écrivez l'opération en appelant ReadFile ou WriteFile. Ces fonctions transfèrent des données d'un bloc de mémoire vers un fichier et inversement. Donc tu devra allouer un bloc de mémoire assez grand pour qu'il puisse contenir les données.
• Fermez le fichier en appelant CloseHandle. Cette fonction reçoit l'Handle du fichier.

Pour allouer de la mémoire, on procède ainsi:

• On réserve un bloc de mémoire en appelant GlobalAlloc. Cette fonction renvoie l'handle du bloc de mémoire demandé.
• On ferme le bloc de mémoire en appelant GlobalLock. Cette fonction reçoit l'handle du bloc de mémoire et renvoie le pointer du bloc de mémoire.
• Tu peux employer le pointer pour lire ou écrire dans cette mémoire.
• On ouvre le bloc de mémoire en appelant GlobalUnlock. Cette fonction rend nul et sans effet le pointer du bloc de mémoire.
• Et enfin on libére le bloc de mémoire en appelant GlobalFree. Cette fonction reçoit l'handle du bloc de mémoire.

PS: Si tu appelles GlobalAlloc ou LocalAlloc, tu obtiendra exactement le même résultat puisque le modèle mémoire utilisé sous Win32 est le modèle flat.

Pourtant, cette méthode a un défaut sérieux : que se passe-t-il si la taille du fichier que tu veux lire est plus grande que le bloc de mémoire allouée ? Ou que la chaîne de caractère que tu veux chercher est coupée en deux à la fin du bloc de mémoire ? Il y aura toujours des répences à ces problèmes mais c'est pas pratique. Pour remédier à ce problème, on fait appel au 'File Mapping'.

• Tu appelles CreateFile pour ouvrir le fichier quetu veux mapper.
• Après CreateFileMapping avec l'Handle du fichier renvoyé par CreateFile comme un de ses paramètres.
• Tu Appeles MapViewOfFile pour Mapper une région du fichier choisie ou bien du fichier entier en mémoire. Cette fonction renvoie le pointer du premier octet de la zone où commence le fichier configuré (Mappé).
• Tu employes le pointeur pour lire ou écrire dans le fichier.
• Tu appelles UnmapViewOfFile pour Unmapper le fichier.
• Tu appeles CloseHandle avec l'Handle du fichier configuré (l'Handle du File Mapping) comme paramètre pour fermer le fichier configuré.
• Et enfin, CloseHandle une fois de plus, mais cette fois-ci avec l'Handle renvoyé par CreateFile pour fermer le fichier réel.

Voilà deux sources ou les deux principes sont parfaitement illustrés.

Noteworthy.

[klakman]

Merci pour votre aide.

Bel explication Noteworthy.

Pour ma part voici ce que j'ai réalisé :

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
 
push EBP
mov EBP,ESP
mov dword ptr SS:[ESP], 00403140
call 004018D0                                     ; appel de puts
mov dword ptr SS:[ESP+4], 00403179
mov dword ptr SS:[ESP], 00403170
call 77C0F010                                     ; appel fopen
mov dword ptr SS:[ESP+4], EAX
mov EBX, EAX
mov dword ptr SS:[ESP], 00403140
call 77C10ED3                                     ; appel fputs
mov dword ptr SS:[ESP], EBX
call 77C10AB1                                     ; appel fclose
leave
retn

C'est sans doute pas parfait, mais ça marche.

Si vous avez des remarques n'hésitez pas.

[Rémi Coquet]

J'ai le choix entre: ou +

Illisible, gestion de pile déplorable, assymétrie des méthodes utilisées, Adresses en dur... Tout ce qu'il faut pour faire un travail inexploitable, instable et dont la maintenance sera impossible soit par un tiers soit par toi-même dans deux mois...

Code :

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

1
2
3
4
5
 
push EBP
mov EBP,ESP
leave
retn

Là il faut choisir, enter/leave (fortement déconseillé et utilissé par les HLL seulement pour simplifier le travail (très lent en plus...)

Code :

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

1
2
3
4
5
6
7
 
push EBP
mov EBP,ESP
....
mov ESP, EBP
pop EBP
ret 8 (apparement: 8 = 2 DWORD passés sur la pile en arguments)

Code :

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

1
2
3
mov dword ptr SS:[ESP+4], 00403179
mov dword ptr SS:[ESP], 00403170
call 77C0F010                                     ; appel fopen

abandonne tout de suite cette forme syntaxique (enfin, ce n'est qu'une proposition sensée et sérieuse )
Faire de l'Assembleur en voulant transferer les méthode du C vers le code n'est sûrement pas la bonne solution:

Appel d'api simple:

push DWORD arg 3
push DWORD arg 2
push DWORD arg 1
Call 'NomModule.Api' ou Call 'Nomapi' selon l'assembleur utilisé

Dans le cas qui t'as été proposé de WriteFile api du module KERNEL32.dll
Le SDK est clair:

Code :

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

1
2
3
4
5
6
7
BOOL WINAPI WriteFile(
  __in         HANDLE hFile,
  __in         LPCVOID lpBuffer,
  __in         DWORD nNumberOfBytesToWrite,
  __out_opt    LPDWORD lpNumberOfBytesWritten,
  __inout_opt  LPOVERLAPPED lpOverlapped
);

[klakman]

J'ai le choix entre: ou +

Je te rappelle ( car tu sembles l'avoir oublié ) qu'on débute tous un jour .

Cela étant dis, comment j'ai fais pour programmer ce bout de code?
J'ai coder ce que je voulais faire en C/C++, j'ai compilé ( en release ), ouvert l'exe avec ollydbg.

Ensuite j'ai ouvert un autre exe avec ollydbg ( celui dans lequel je voulais tester la modification ).
Et puis j'ai simplement copié/collé les lignes créées par GCC.

Donc d'après tes dires GCC, serait nul à ce point :

Illisible, gestion de pile déplorable, assymétrie des méthodes utilisées, Adresses en dur...

Permets moi d'en douter.

Cependant pour les adresses en dur, je sais que c'est moche, et merci pour le conseil.

[Rémi Coquet]

J'ai bien compris que tu débutes... justement. autant prendre les bonnes habitudes tout de suite et ne pas mélanger ce qui ne l'est pas (tu seras plus heureux crois moi).

Il est evident que ce code est celui généré par un compilateur (les assymétries typiques et la gestion de pile à l'arrache...) c'est bien la purée habituelle.

Je n'ai pas d'avis sur GCC mais ce code est inexploitable dans la durée et "est véritablement nul à ce point" effectivement.
Un code dé-assemblé doit-être remis en forme et ré-optimisé sur la stratégie et la lecture.

[klakman]

Merci d'avoir pris le temps de répondre.

Donc tu veux dire que pour optimiser totalement son code il faudrait limite reprendre tout en le désassemblant?

Plusieurs questions me viennent à l'esprit.

Pourquoi les compilos ne génèrent-ils pas de code "correct" dès le début ?

Peux tu, m'expliquer pourquoi la stratégie, et la lecture ne sont pas optimisées?

PS: Je ne remets pas en doute ce que tu me dis, mais j'ai véritablement envie de comprendre, pour pouvoir progresser, merci.

[Rémi Coquet]

Pas de lézard, il est toujours TRES sympathique de dialoguer avec un gars qui regarde sous le capot et qui doute de ses interlocuteurs !

Il me semble que la question centrale est:

Pourquoi les compilos ne génèrent-ils pas de code "correct" dès le début ?

Un compilateur est un générateur automatique de code et ton source en est le script.
Deux choses que le compilateur ne peut donc pas "gérer: La première, ta qualité d'écriture -> selon que tu imbriques ou pas les appels, par exemple, le compilateur adopte des stratégies plus ou moins loufoques (plus tu écris compact plus il fait n'importe quoi) et le code le plus court donne souvent lieu aux pires interprétations de sa part.
La seconde, c'est qu'un compilateur ne comprend absolument ni ce que tu veux faire in fine ni les diverses stratégies locales ou globale que tu utilises. Il fait donc le minimum syndical et te propose un maximum d'options (souvent totalement inutiles pour améliorer la qualité du code final) pour tenter de compenser ce qu'il ne comprend pas.
Un compilateur est un outil très générique, un peu comme un OS, il ne peut pas rivaliser avec l'intention humaine car il ne possède aucun moyen de compréhension globale ou même semi-globale. Il n'est capable de "vision" que sur de très petits blocs de script.
Quand tu travailles en Assembleur, avec un assembleur (et pas un compilateur), le code généré est exactement ce que tu as écrit sans qu'aucune interprétation ne soit nécessaire ou faite. Si tu ne sais pas coder, heureusement, personne ne fera le boulot pour toi (pas même une bibliothèque) et tu vas donc devoir apprendre à coder d'une manière responsable et efficace. La naissance des codes managés (.NET et autres inepties) est due au fait qu'un compilateur n'est absolument plus efficient arrivé à un certain niveau et que les personnes utilisant des HLL ont de plus en plus de distance entre leur vision du système et ce qu'il est vraiment. Le niveau d'incompétence va donc grandissant et le nombre de béquilles logicielles pour produire du code n'a jamais été aussi fleurissant chez les éditeurs.
Trouver un codeur C de talent, aujourd'hui, devient de plus en plus compliqué, Assembleur Win32/64… à part mettre la main à (et au fond de !) la poche, aucun espoir (fais-moi confiance, c'est notre problème actuellement…).

Alors, tout dé assembler pour tout reprendre paraît, certes, une voie idéale... mais en fait ce n'est pas vraiment la plus efficace !
Il FAUT écrire avec les stratégies qu'induit l'Assembleur et surtout pas "polluer" celle-ci avec des habitudes liées aux HLL de type C/C++ ou, pire managés. Les choses, dans ce domaine, vont du bas vers le haut jamais du haut vers le bas: Si quelqu'un te raconte autre chose, c'est qu'il ne fait de l'Assembleur que dans ses rêves et n'a pas saisi que toutes les technologies des HLL proviennent de constructions élémentaires de bas niveau: "LP contenu de LP" tout le reste n'étant que diversion: POO, héritages, cast, l'infinité de non de types, portabilité etc. Faire de la POO en Assembleur est relativement basique car tout l'OS est la plupart du temps appuyé sur cette technique qui permet un niveau d'abstraction suffisant pour faire de l'assembleur multi niveau.
C'est elle que tu utilises ici, de manière indirecte certes, mais rendue totalement illisible par un compilateur qui génère un code qui doit être fonctionnel et non LU !

[klakman]

Je ne suis pas sûr d'avoir tout compris.

Que signifie "HLL"?
Quel est le gros défaut du code managé vis à vis de l'Assembleur?

Il FAUT écrire avec les stratégies qu'induit l'Assembleur et surtout pas "polluer" celle-ci avec des habitudes liées aux HLL de type C/C++ ou, pire managés.

Quelles sont les stratégies induites par l'Assembleur?
Et surtout comment essayer dans des langages plus haut niveau, et là je pense surtout pour mon cas au C/C++, de respecter au maximum ces stratégies?

Les langages compilés aujourd'hui sont-ils à ce point loin d'optimiser le code qu'il génèrent?

Ma vision d'après ce que tu me dis et basé sur ma petite expérience c'est que la programmation bas niveau privilégie la qualité d'utilisation de l'application, tandis que la programmation haut niveau privilégie le développement de l'application.

Merci pour toutes ces réponses.

[Rémi Coquet]

Que signifie "HLL"?

désolé, en français courant: Langage de Haut Niveau

Quel est le gros défaut du code managé vis à vis de l'Assembleur?"

Le niveau d'abstraction et d'incompétence augmentant, le code managé tente d'augmenter l'efficacité du compilateur, entre autres en substituant carrément des blocs d'Assembleur selon les directives du script d'origine.
Il faut bien comprendre qu'un script n'est qu'un ensemble de directives, en aucun cas du code et limite un source (c'est un abus de langage accépté). L'idée des langages managés n'est pas bête dans le principe mais ne fait que révéler les limites et l'état des compilateurs précédents.
Le code managé (pour être caricatural) ressemble à ces applications Borland que l'ont pouvait créer par simple glisser/déplacer d'objets tout prêts (un peu comme les spaghettis en boite )

Quelles sont les stratégies induites par l'Assembleur?

comment essayer dans des langages plus haut niveau, et là je pense surtout pour mon cas au C/C++, de respecter au maximum ces stratégies?

Les deux proposes des stratégies différentes: L'une liée au µP et à ses instructions, l'autre, à ce que le compilateur sait comprendre et coder de manière à peu près viable.

Les langages compilés aujourd'hui sont-ils à ce point loin d'optimiser le code qu'il génèrent?

Oui et chaque outil génère une purée différente, ce qui permet aux gars de comparer celui d'Intel à XXX etc. Vu de l'extérieur ça fait un peu rgoler mais bon, je veux pas casser le délire non-plus !

Ma vision d'après ce que tu me dis et basé sur ma petite expérience c'est que la programmation bas niveau privilégie la qualité d'utilisation de l'application, tandis que la programmation haut niveau privilégie le développement de l'application.

C'est une manière traditionelle de présenter les choses qui fait référence aux anciens outils: L'assembleur Win32/64 est vraiment très simple à mettre en oeuvre et tout codeur C qui connait ses API (pas la MFC !!!) et qui est près à apprendre une vingtaine d'instructions courantes, s'en sort très efficacement avec des durées de développement identiques après un peu d'habitude (Nous faisons ça tous les jours et je ne maquette pas en C).

[klakman]

L'assembleur Win32/64 est vraiment très simple à mettre en oeuvre et tout codeur C qui connait ses API (pas la MFC !!!) et qui est près à apprendre une vingtaine d'instructions courantes, s'en sort très efficacement avec des durées de développement identiques après un peu d'habitude (Nous faisons ça tous les jours et je ne maquette pas en C).

On peut développer aussi rapidement en Assembleur qu'en C?

[Rémi Coquet]

Tout à fait, c'est juste une question d'outils appropriés ou pas.
Si le C++ est le règne des bibliothèques et du copier / coller pour refaire N fois la même application, il est tout à fait possible de refaire ce genre de niaiseries (avec du code générique ré-utilisable, sans intérêt donc, les API font cela tout aussi bien et plus rapidement !)
Mais, si tu dois créer une application stable et rapide, (sans fuites mémoires et maintenable) l'Assembleur n'est pas plus complexe à mettre en oeuvre que du C ou du C++ pour ce qui est de la durée (l'apprentissage du C++ contient quelques côtés magiques contrairement à la simplicité puissante de l'Assembleur).

Les nouveaux outils te permettent de créer tes propres abstractions (complètement contrôlées au niveau du code généré) de type branchements conditionnels (if, else, select/case) cast, POO etc. il est donc possible d'utiliser un niveau d'abstraction variable dans le code selon les besoins locaux.
Au final, le code est rapide, compact, et facilement maintenable.

J'ai l'expérience de très grosses applications utilisant de hauts niveaux de parallélisme, gérant réseaux, IHMs locales et distantes, flux médias HD chronovores, tout en POO/Assembleur -> Il n'y a pas photo sur la taille, la stabilité et les perfs. Là où le bas blesse, c'est qu'il faut se farcir les docs système initialement et se mettre à jour à chaque évolution des SDK/DDK (ce qui n'est pas une grosse masse de travail une fois que tu as fait l'effort initial). Le jour ou les profs d'informatique n'enseigneront pas l'Assembleur comme une punition et auront quelques notions réelles dans le domaine, le paysage des compétences et les répétitions sans fin de lieux communs sur l'Assembleur seront largement transformés (donc... il y a le temps +).

Donc, réaliser la dll que tu cherches est un excellent exercice: Si tu as un peu de temps et un peu d'aide.

[klakman]

Ok ok, il faudrait le jour voulu que je fasse sans doute cet effort initiale dont tu parles. Mais pour le moment mes applications ne demandent absolument pas une bête de performances, et j'ai un niveau très débutant en programmation ( environ 8 mois ), donc je vais encore passer un peu de temps en C/C++.

Pour le moment l'assembleur pour moi c'est avant tout un moyen de comprendre le fonctionnement de ma machine. De voir comment s'exécute mes programmes, ainsi que des programmes tiers. D'être capable le jour venu de débugger un programme aussi. ( Enfin je suis en pleine phase d'apprentissage quoi. )

Par contre j'ai déjà vu qu'on pouvait mélanger du C/C++ avec de l'assembleur.

On utilise __asm, puis on peut insérer directement du code assembleur derrière.

Est ce une bonne alternative?

[Rémi Coquet]

Pour écrire dans un fichier, sans performances particulières, Noteworthy t'a proposée une série d'API utilisables directement en C/C++.

Pour ce qui est de l'utilisation (pédagogique) de __asm, dans ton cas ce serait bien compliquer les choses pour rien comme tu l'indiques.
Construire une dll entièrement en Assembleur reste, à mon avis, une solution beaucoup plus élégante et présente l'avantage de la modularité et d'une maintenance plus simple.

Le saupoudrage d'Assembleur dans un script C/C++ n'apporte jamais rien de sérieux à quelque niveau que ce soit et répresente pour de nombreuses raisons qu'un moyen de tests temporaire.

Une bonne maîtrise des API en C/C++ t'apportera plus de joies et de compétences (là, c'est plus une opinion, c'est un fait).

[klakman]

Ok merci, j'ai une idée de ce qu'il me reste à faire now. Je reposterai en cas de problème.

Thanks