Ajouter des fonctions a vb6 (etude, assembleur x86, compilation)

Soyez le premier à donner votre avis sur cette source.

Vue 7 476 fois - Téléchargée 476 fois

Description

[C'est plus une etude qu'une source. Elle permet d'ajouter des fonctions a vb6 d'une maniere plutot inhabituelle]

Tout d'abord lisez la presentation avant d'emettre un avis !

Donc comme je le dis plus haut, cette source est un essai dans
le cadre d'une etude sur la compilation avec C2/Link qui a montré
plusieurs phenomenes etonnants... je ne vais pas vous exposer ici
toute la these mais je vais prendre un petit exemple simple que vous
pourrez tester vous meme :

(peut etre connaissez-vous deja tout cela, mais pensez a ceux qui ne le savent
pas encore...)

- Ouvrez un nouveau projet vb, ajoutez un module tapez le texte suivant :

Option Explicit

Sub Main()
MsgBox AddressOf A
MsgBox AddressOf B
End Sub

Function A(ByVal n As Long) As Long
n = n + 1
End Function

Function B(ByVal v As Long) As Long
v = v + 1
End Function

- executez le dans l'ide
- compilez et executez le !
- puis comparez le resultat !

VB a tout simplement fusionné les deux fonctions en une seule !
logique puisqu'elles font la meme chose... mais plutot inattendue pour
un programmeur qui s'attend a avoir deux procedures distinctes !
cela vient du mode d'optimisation du code (vitesse/taille).
Tout ça pour dire qu'il ne faut presumer de rien

L'idée de la source est donc de créer des fonctions qui ne font
rien dans l'ide, un canvas de fonction en qlq sorte pour allouer
un espace memoire et un type de declaration pour pouvoir, une fois
le projet compilé placer dans cette meme memoire notre propre
code que l'on aura decomposé en sequence.

Le probleme : pour créer cet espace memoire il faut connaitre
quelle va etre le taille du canvas une fois compilé. Pour le
connaitre on va compilé notre projet avec plusieurs hypotheses.
Puis une fois créé on va "dumper" la memoire de ces fonctions
pour les placer au niveau du point d'entrée d'un faux programme
pour observer le code grace au debug de visual studio !

Une fois tout cela fait, il ne nous reste plus qu'a créer des sequences
en assembleur ou en c pour les integrer dans nos canevas et donc créer
des fonctions conpletement nouvelles.

Dans le zip vous trouverez la source des qlq fonctions teste
comme les decalages de bit ou la copie de memoire
vous trouverez egalement l'outil qui sert a placer du code dans
le point d'entrée d'un prog et un exemple d'utilisation des fonctions

Voici un exemple qui transforme un nombre signé en
non signé :

Value = adv_BitOff(Value,31)

Un autre exemple qui remplit un tableau de n byte avec la valeur 1

dim Tbl(32) as byte
adv_MemoryFill varptr(Tbl(0)),1,32

Compte tenu des differents systemes en vente aujourd'hui je ne garantis
pas le bon fonctionnement du programme ni meme des sources

Source / Exemple :


'Dans le zip
(Désolé pour les fautes)

Conclusion :


J'ai bcp hesité a poster cette source car je sais pertinement
que certains ne vont pas "comprendre" les objectifs réels de
de celles-ci mais vont voir en elle rien d'autre qu'un code
douteux et completement inutile...

Alors je ne vous demande pas de comprendre ma façon de coder
mais juste de moderer vos propos et considerer le labeur

Cordialement,

EB

Codes Sources

A voir également

Ajouter un commentaire

Commentaires

BruNews
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
13 -
Force est de constater la masse de boulot produite mais a ce point la question de la finalite doit se poser. Booster vb c'est indispensable mais ecrire toutes ces fonctions en C ou ASM et produire une dll ne serait pas moins laborieux pour un resultat au moins egal ?
Wazcrack
Messages postés
34
Date d'inscription
jeudi 29 mai 2003
Statut
Membre
Dernière intervention
17 mars 2004
-
En tout les cas, bravo pour le boulot. Y'en a. Je suis encore au point d'en savoir autant au sujet de VB mais c'est plutot pertinent. Bonne continuation.
spy166
Messages postés
207
Date d'inscription
jeudi 21 novembre 2002
Statut
Membre
Dernière intervention
29 mars 2006
-
Ouai, c'est intéressant mais bon, je trouve que c'est un peu trop se déchirer pour du vb.
cs_EBArtSoft
Messages postés
4531
Date d'inscription
dimanche 29 septembre 2002
Statut
Modérateur
Dernière intervention
22 avril 2019
5 -
BruNews> tres bonne question, tu pense bien que j'y ai deja pensé
et la reponse, du moin ma reponses est : non ! le resultat n'est
pas le meme pour deux raisons :

1 - On evite l'emploi d'une dll donc on facilite la redistribution
la maitenance, l'installation et le debuggage du prog

2 - Voici le code d'un appel d'api dans vb :

004013D0 56 push esi
004013D1 E8 26 CE FF FF call 003FE1FC
004013D6 8B F0 mov esi,eax
004013D8 FF 15 34 10 40 00 call dword ptr ds:[401034h]
004013DE 8B C6 mov eax,esi
004013E0 5E pop esi
004013E1 C3 ret

ce qui veut dire en gros que pour un appel avec une api vb
va d'abord charger la dll rechercher le point d'entrée de la fonction
puis l'appeler faire des check de stack etc...

dans le cas d'un appel d'API avec une type lib le loader
vas charger les addresses des fonctions et la dll au lancement
du programme puis a chaque appel va pointer la table des import
avant d'appeler la fonctions :

004013D0 FF 25 00 10 40 00 jmp dword ptr ds:[401000h]

7347AC18 FF 74 24 08 push dword ptr [esp+8]
7347AC1C FF 74 24 08 push dword ptr [esp+8]
7347AC20 6A 00 push 0
7347AC22 E8 F0 53 FF FF call 73470017
7347AC27 8B 04 85 50 FC 39 73 mov eax,dword ptr [eax*4+7339FC50h]
7347AC2E C2 08 00 ret 8

maintenant voici le code d'un appel d'une fonction "'hacker" avec writeprocessmemery, vb va appeler directement la fonction comme
si elle avais été ecrite dans l'ide sans pratiquer aucun teste

004013D0 E8 9B F1 FF FF call 00400570
004013D8 C3 ret

donc on gagne des cycles et dans certain type d'application
comme par exemple une application graphique le moindre
cycle peut faire gagné un temp non negligable

Malheureusement la mise en oeuvre est trop complexe pour pouvoir
etre correctement utilisé... mais je travail justement dans l'optique
de faire qlq chose de digest et utile

@+
BruNews
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
13 -
Bien certain que appel vers DLL plus couteux que interne mais 2 raisons me font penser que tes competences sont employees dans ce cas a fond perdu:
1) application graphique ne se fait pas en vb.
2) vb est desormais voue a une mort assez rapide, le passage a .net est inexorable.

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.