Commentaires de rt15 sur delphifr

CodeS-SourceS est h�berg� par Frontier.fr

Ce site au d�marrage

AccueilCodesTutorielsForumsEmploiLivresConnexion

begin process at 2008 10 13 04:28:59

[SILVERLIGHT] EN ATTENDANT SILVERLIGHT 2 RTW par Audrey

LE NOUVEAU GOJIRA, C'EST POUR LUNDI. par coq

SHAREPOINT : NOUVEL ARTICLE SUR LA MISE EN PLACE DES SCOPES DANS MOSS SEARCHS par ROMELARD Fabrice

HELLO CS par julz

MSDN/TECHNET/MICROSOFT DAYS TOUR 2008 à LILLE LES 13 ET 14 OCTOBRE ! par redo

RE : [INIFILES] DéTERMINER LE TYPE D'UNE VALEUR par f0xi

RE : PAPIER PAIN D'ECRAN par lidia22

RE : PAPIER PAIN D'ECRAN par L_art_ment

RE : [INIFILES] DéTERMINER LE TYPE D'UNE VALEUR par cantador

RE : EDITION D' éTATS par cantador

+ de logiciels � t�l�charger

1�260�886 membres
50 nouveaux aujourd'hui
14�413 membres club

Trouver une ressource

Trouvez une ressource parmi 38�838 codes, 1�186�016 messages d'aide etc...

Recherche: dans [ Derni�res recherches ]

Filtre:Tous les codes.NET uniquementExclure .NET

Vous ne trouvez pas de r�ponse � votre probl�me ? Alors posez la question dans le forum. Souvenez-vous qu'il n'y a jamais de question b�te, mais rester dans l'ignorance parce que l'on n'ose pas poser une question, �a c'est une erreur !

22 commentaire(s) de rt15 sur des sources sur delphifr

Le : 15/07/2008 11:45:45
Source : HOOK D'API, INJECTION DE DLL, TABLE D'IMPORT

Cela marcherait si le code de l'exe passait par sa propre table d'export pour appeler cette fonction. Mais il serait stupide de passer par celle-ci pour récupérer une adresse que l'on connait déjà. Donc il y a peu de chance que des compilos le fasse.

Par contre...

Ton exe exporte la fonction, donc tu peux facilement récupérer son adresse dans le processus distant (Pour cela, on peut exploiter la technique d'injection de ce source). Une fois que l'on a l'adresse de cette fonction, rien n'empèche de modifier le début du code de cette fonction pour appeler une fonction à nous, injectée elle aussi.

1. Injection d'une dll dans le processus distant, via la technique de ce source ou autre.

2. Dans le code de la dll, récupérer un handle du .exe avec GetModuleHandle.

3. Récupérer l'adresse de la fonction exportée avec GetProcAdresse, en lui passant le handle du .exe.

4. Modifier le début de la fonction exporté (Ecriture à l'adresse ci-dessus). La fonction commence très certainement par un :
push ebp
mov ebp, esp

(Les compilos Microsoft mettent généralement un mov edi,edi en début de fonction, idéal pour un hook)

Remplacer ce début par un jmp vers une fonction de la dll que l'on a injecté.

5. La fonction de la dll qui va récupérer les appel doit faire le début qui a été remplacé, et doit faire un saut vers la fonction originale à la fin.

Bien qu'un peu technique, c'est très faisable.
Par contre, je ne vois pas dans quel cas ce serait utile...

Le : 19/12/2007 12:32:45
Source : HOOK D'API, INJECTION DE DLL, TABLE D'IMPORT

Les sniffeurs de réseaux sont généralement implantés plus bas au niveau des drivers, mais certains utilisent en effet des hooks pour espionner la socket d'un processus en particulier.

Pour le rs232, je sais pas, mais si tu veux juste espionner une application en particulier cette méthode marcherait peut être, le tout est de trouver les fonctions qu'elle utilise.

Par exemple, elle peut utiliser RSCOM.DLL :
http://delphipage.free.fr/portserie.html

ou encore WriteFile :
http://www.delphifr.com/codes/EAGLE-ENSEMBLE-FONCTIONS-UTILES-FICHIERS-SYSTEME-STRINGS-RS232_30232.aspx

Le : 17/12/2007 17:45:33
Source : HOOK D'API, INJECTION DE DLL, TABLE D'IMPORT

f0xi -> Ca m'est venu très récemment le coup des parenthèses. Je me suis dit : pourquoi pas ?
Bah maintenant j'ai ma réponse...

Je mettrai mes sources dans "expert" quand j'emploierai des fonctions de M$ non documentées par M$. Niark niark.

Le : 07/11/2007 15:06:18
Source : RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN

Le Extended le plus rapide des flottants, arf j'avais dit tout le contraire, vu que c'est le plus précis et le plus gros. Pour les calculs, OK, mais pour les affectations, passage par valeur en argument d'une fonction... Là y doit déjà plus souffrir.

Pour les calculs sur les flottants, le compilo de Delphi fait du code machine qui va utiliser la FPU. D'un flottant à l'autre, les instructions change pas vraiment, juste les tailles des opérandes.

Un petit tour dans le intel manual volume 1, chapitre 7.4 parlant des types de flottants supportés par la FPU :
"With the exception of the 80-bit extended-real format, all of these data types exist in memory only. When they are loaded into FPU data registers, they are converted into extended-real format and operated on in that form."

Donc la FPU à l'air de convertir automatiquement tout ce qu'on lui donne en Extended... Ceci explique peut être cela.

Le : 16/10/2007 13:26:55
Source : COLLISIONS DE BABALLES

"Le plus gros du calcul vient de la recherche des collisions."

Tu peux faire des zones ou utiliser un quadtree. Dans ton cas (A vu de nez de la capture), des zones risques d'être plus appropriée, car tu a pas mal d'objets pas trop mal répartits.

Quand je dis zones, je pense à un bête quadrillage, avec une largeure de case par exemple égale au diamètre de ton plus gros disque. Chaque disque se trouve alors dans une case. Pour chaque disque, tu peux ainsi faire des tests qui portent sur les disques de la même case et sur les 8 cases adjacentes.

Le : 05/12/2006 13:19:48
Source : RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN

Désolé pour le double post (Et le code moche), mais voici une version sans classe nettement plus simple.

type TCallBack = procedure (Self: Integer; sTitle: String);
type TCallBackObj = procedure (sTitle: String) of object;

type
  TForm1 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    procedure MsgBoxObj(sTitle: String);
  end;

procedure Run(uCallBack: TCallBack);

var
  Form1: TForm1;

procedure MsgBox(Self: Integer; sTitle: String);

implementation

{$R *.dfm}

procedure TForm1.MsgBoxObj(sTitle: String);
begin
  Application.MessageBox('Méthode', PChar(sTitle));
end;

procedure MsgBox(Self: Integer; sTitle: String);
begin
  Application.MessageBox('Classique', PChar(sTitle));
end;

procedure Run(uCallBack: TCallBack);
begin
  uCallBack(0, 'Le titre');
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
  Run(@TForm1.MsgBoxObj);
  Run(@MsgBox);
end;

Le : 05/12/2006 12:26:58
Source : RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN RIEN

Salut,

Certains progs C surchargent les fonction d'allocation pendant le débugage. De cette manière, ils détectent toute fuite de mémoire pendant le développement. Cela leur permet de se passer de garbage (Qui consomme des ressources) par la suite avec une certaines assurance.

Pour ce qui est de trouver un autre moyen de faire des callback objet ou pas, y a un bricolage. Du style de bricolage pas possible en DOTNET je suppose d'ailleurs.

C'est juste basé sur le fait que le Self caché des méthodes fait 32 bits et est placé à gauche.

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;

type TCallBack = procedure (Self: Integer; sTitle: String);
type TCallBackObj = procedure (sTitle: String) of object;

type
  TForm1 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    procedure MsgBoxObj(sTitle: String);
  end;

type TCallCallBack = class(TObject)
  public
    constructor Create(uCallBack: TCallBack); overload;
    constructor Create(uCallBack: TCallBackObj); overload;
    procedure Run;
  private
    fuCallBack: TCallBack;
end;

var
  Form1: TForm1;

procedure MsgBox(Self: Integer; sTitle: String);

implementation

{$R *.dfm}

procedure TForm1.MsgBoxObj(sTitle: String);
begin
  Application.MessageBox('Méthode', PChar(sTitle));
end;

procedure MsgBox(Self: Integer; sTitle: String);
begin
  Application.MessageBox('Classique', PChar(sTitle));
end;

constructor TCallCallBack.Create(uCallBack: TCallBackObj);
begin
  inherited Create;
  fuCallBack:= TCallBack(uCallBack);
end;

constructor TCallCallBack.Create(uCallBack: TCallBack);
begin
  inherited Create;
  fuCallBack:= uCallBack;
end;

procedure TCallCallBack.Run;
begin
  fuCallBack(Integer(Self), 'Le titre');
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  uObj1: TCallCallBack;
  uObj2: TCallCallBack;
begin
  uObj1:= TCallCallBack.Create(@TForm1.MsgBoxObj);
  uObj2:= TCallCallBack.Create(@MsgBox);
  uObj1.Run;
  uObj2.Run;
  uObj1.Free;
  uObj2.Free;
end;

end.

Le : 01/12/2006 18:52:13
Source : FEN�TRE UN PEU CUSTOMIS�E

Apparement, il est pas possible d'empècher le TSpeedButton d'afficher sa bordure lorsque la souris se déplace dessus.

Et le TSpeedButton gère Haut, Désactivé, Cliqué, Bas... Mais pas le survol de la souris.

Donc je ne vais pas remplacer les TImages a priori...

Le : 29/11/2006 13:37:45
Source : SFCDELPHILITE(AVEC CETTE LIBRAIRIE VOUS POUVEZ CR�ER UNE APPLICATION WINDOWS AVEC SEULEMENT QUELQUES KILO OCTETS !!!)

Salut,

Tout d'abord, bravo pour ce source qui permet des gains en taille impréssionnants.

Je vais juste revenir sur le bricolage des lignes 123 et suivantes de sfcDL_Forms, et proposer une solution (Pas parfaite certe mais, pas nulle non plus je pense).

Déjà, je vais essayer d'expliquer ta solution, pour ceux qui n'auraient pas fait assez d'assembleur pour la saisir.

Windows a besoin d'une CallBack. Autrement dit, de l'adresse d'une fonction à appeler, auquel il donnerat des arguments précis (Des information sur le
message).

Cette fonction serat appelé à chaque clique de bouton nottement.

Côté applicatif, tu dispose d'une instance de bouton par bouton, et dans chacune de ces instances, tu as un pointeur sur la fonction qui doit être executée en
cas de clique sur cette instance de bouton.

Il faut donc que tu fasse le lien entre le message envoyé par windows, et la bonne instance de bouton.

Un autre problème est que ton code est tout en objet, et que tu n'as donc que des méthodes.

Une méthode diffère d'une instance classique (A prototype équivalent) par l'ajout d'un argument implicite tout a fait caché : l'adresse de la structure
(Stockant les attibuts nottement) de l'instance.

En gros :

a.Msg(b);

est compilé

Msg(a, b);

De là, tu sautes sur l'occasion, tu vas ajouter l'adresse de la structure à la volée.

Le code d'ajout de l'adresse, ne peut par définition se trouver que dans la structure de l'objet lui même, du fait qu'il y a une adresse d'instance par
instance.

Ensuite, il suffit de donner l'adresse de cette attribut, contenant le code d'ajout de l'adresse, à windows (Qui l'appelerat sans se poser de question)

Cette attribut appellerat ensuite une méthode prenant les paramètre envoyés par windows, en plus de l'adresse caché.

Le code de l'attribut revient donc à :

1 pop ebx
2 push adresse strucuture
3 push ebx
4 jmp méthode

1 On récupère en fait l'adresse de retour qui serat executé quand la callback aurat fait son taffe.
2 Puis on pousse l'adresse de la structure de l'instance. (Les arguments sont empilé de droite à gauche, l'argument caché etant situé à gauche).
3 On remet en place l'adresse de retour.
4 On se déroute sur la méthode.

Ce code serat executé dans le tas (Dans les structures des différentes instances) à chaque fois que windows enverrat un message.

Cette astuce est manifique, diaboliquement efficace, et vachement bien trouvé.

Néanmoins, elle est pas franchement lisible, et l'execution de code dans le tas est pas super propre.
Sans compter que des protection empèchant l'execution de code dans le tas existent.

Ma proposition de solution, c'est d'utiliser une valeur sur 32 bits laissé au bon vouloir de l'utilisateur dans les données de la fenêtre gérée par windows.
(Je ne parle pas des données supplémentaire, qui seraient chiante à mettre en place car il faudrait recoder les classes BUTTON et companie).
Mais d'utiliser l'attribut GWL_USERDATA.

Il est affectable via SetWindowLong, et récupérable via GetWindowLong.

L'inconvénient est que l'overhead est plus important qu'avec ta méthode. Mais il n'est pas non plus monstrueux.

Le : 28/11/2006 13:34:35
Source : LE MINIMUM POUR UNE FEN�TRE WIN32

Nan je l'avais pas vu.
C'est effectivement le même système, sauf que lui est plus courageux que moi.

Par contre j'ai adoré sa mise en place de callback (ligne 123 de SfcDL_Controls) !

Ch'tite execution de code dans le tas, du grand art !

Par contre, faut pas que le PC cible le protège son tas.

C'est quand même bizarre qu'il soit obligé d'en arriver là...