Discussion :

[RamDevTeam]

Mon problème :

J'ai un fichier crypté qui est en fait une DLL.

Au lancement de mon programme, je veux :
- Décrypté la DLL en mémoire (je le fais avec un tmemoryStream)
- Utiliser ses fontions dans mon exe.

Je ne veux pas passer par un fichier temporaire qui laisserait une trace de la DLL décryptée.

Comment faire un équivalent à LoadLibray utilisant non pas un fichier mais un Tmemorystream, ou un array of bytes ?

Si c trop compliquée avec une DLL, l'autre solution, c d'avoir un EXE1 qui se comporte en lanceur, décrypte en mémoire le fichier X correspondant à l'exe2 et lance l'exe 2.

Avez-vous des pistes ou d'autres propositions de raisonnement ?
Dans tous les cas, la version décryptée de l'exe, la dll, ou autre ne doit etre prèsent qu'en mémoire. l'utilisation de fichier temporaire et banni.

[the_magik_mushroom]

je me trompe peut être mais si tu décrypte ta dll en mémoire il y a la possibilité de la recupérer en faisant un dump...

maintenant utiliser loadlibrary pour un fichier en mémoire... hum bonne chance

[RamDevTeam]

je me trompe peut être mais si tu décrypte ta dll en mémoire il y a la possibilité de la recupérer en faisant un dump...

Ca reste effectivement une possibilité mais un peu plus compliqué de prendre un fichier temporaire et de le renommer.

... loadlibrary pour un fichieren mémoire ...

Justement, je ne cherche pas à faire fonctionner loadlibrary avec un fichier en mémoire mais une instruction ou un code ayant le même effet.

Maintenant je ne suit pas exclusivement orienté vers une DLL.
Je dois pourvoir charger la version compilée d'une fonction, d'un objet etc .. (je n'ai pas de choix imposé) et surtout pouvoir l'exécuter depuis mon soft.

Je vais me pencher aussi du coté des threads.

[sjrd]

Si jamais tu ne trouves rien (mais je pense que tu trouveras quand même autrement), tu peux toujours essayer de comprendre le code source de Pascal Script de RemObjects, qui je crois fait ce genre de choses.

[glayag]

C'est juste pour signaler que ma solution demande a etre completer. Il faut en effet appliquer les relocations dans le PE.

En fait, juste un probleme de traduction :

IMAGE_REL_BASED_HIGHADJ : The fixup adds the high 16 bits of the delta
to the 16-bit field at Offset. The 16-bit field represents the high
value of a 32-bit word. The low 16 bits of the 32-bit value are stored
in the 16-bit word that follows this base relocation. This means that
this base relocation occupies two slots.

D'apres mon anglais pas terrible du tout (je sais, c'est tres mauvais
en infos), je comprend qu'apres avoir ajoute les 16 bits du Delta aux
16 bits de poids fort d'une donnée de 32 bits , il faut que je recopie
les 16 bits de poids faible de ce dword dans un word qui suit le dword
?
En clair, la memoire peut se representer sur 48 bits ainsi : 16bits
poids fort du dword | 16 bits poids faible du dword | 16 bits poids
faible du dword ?? ou j'ai rien compris

Voila, c'etait un message que j'avais poste sur un autre forum mais j'ai pas eu de reponse donc le projet etait en stand by.

[tourlourou]

yo, ça m'intéresse, mais je suis loin d'une compréhension suffisante...

et mon anglais est souvent passable mais là, c'est du chinois ! clair comme du jus de boudin !

16 bits hi(delta) puis 16 bits hi(dword) puis 16 bits lo(dword) ???

[glayag]

Pourtant, c'est du copier-coller de la doc de Microsoft (pecoff.doc)...

Si il existe anglophone qui passe sur le poste, ca serait super sympa

[tk_dlph]

D'apres ce ke jai comprit de ton probleme, jai une petite idee elle semble simple mais ta ka definir des variable dans ta dll c'est a dire ke le decryptage sera fait dans la dll meme otrement dit le decryptage sera dans une variable defini dans ta dll ensuite tu envoie cette variable dans ton .exe

[Hauwke]

bonjour,

D'apres mon anglais pas terrible du tout (je sais, c'est tres mauvais
en infos), je comprend qu'apres avoir ajoute les 16 bits du Delta aux
16 bits de poids fort d'une donnée de 32 bits , il faut que je recopie
les 16 bits de poids faible de ce dword dans un word qui suit le dword
?

je lirai plutôt:

Le fixup ajoute les 16 bits de poids forts au champ de 16 bits à l'excentrage. Ce champ de 16 bits représente la valeur forte d'un mot de 32 bits. Les 16 bits de poids faibles de cette valeur de 32 bits sont stockés dans le mot qui suivent [attention pluriel inexplicable!] la relocalisation du mot de 16 bits de poids forts. Ce qui signifie que les valeurs de cette relocalisation occupent deux espaces [sous entendus : 2 espaces de 16 bits contigus]

Moi c'est pas l'anglais qui me dérange mais plutôt l'informatique!
Si j'ai bien compris, il y a d'abord une addition de 2 octets sur 2 octets [Mais le texte original ne dit rien sur la première valeur qui reçoit l'addition! Manque t-il quelque chose dans le texte?] puis ensuite une relocalisation de cette valeur obtenue à proximité immédiate d'une autre valeur de 2 octets de façon à obtenir 2 valeurs de 16 bits traitables en 1 valeur de 32 bits. Peut-il s'agir d'une vieille fonction des systémes 16 bits que Microsoft a bidouillé pour l'adapter aux systémes 32 bits?
Si je n'ai pas trop de doute sur ma traduction, j'ai beaucoup de doute sur l'interprétation que j'en fait. Arf, toujours cette vieille querelle entre le théme et la version! A prendre avec toutes les précautions, je suis loin d'être un expert en informatique...
Cordialement,
Hauwke

[glayag]

Le fixup ajoute les 16 bits de poids forts au champ de 16 bits à l'excentrage. Ce champ de 16 bits représente la valeur forte d'un mot de 32 bits. Les 16 bits de poids faibles de cette valeur de 32 bits sont stockés dans le mot qui suivent [attention pluriel inexplicable!] la relocalisation du mot de 16 bits de poids forts. Ce qui signifie que les valeurs de cette relocalisation occupent deux espaces [sous entendus : 2 espaces de 16 bits contigus]

Merci pour cette traduction.
Si je comprend bien alors, on a un double mot avec les bits de poids forts en premier et les bits de poids faibles en second et on ne modifie que les bits de poids forts ?

Si j'ai bien compris, il y a d'abord une addition de 2 octets sur 2 octets [Mais le texte original ne dit rien sur la première valeur qui reçoit l'addition! Manque t-il quelque chose dans le texte?]

Il y a un champ : le champ a relocaliser.
Le delta qui est le resultat d'une petite operations necessaire auparavant.

Peut-il s'agir d'une vieille fonction des systémes 16 bits que Microsoft a bidouillé pour l'adapter aux systémes 32 bits?

Non, les relocalisations sont faites pour traiter les fichier PE (executables) qui ne peuvent pas etre chargee a l'endroit voulu. En effet, dans un fichier PE, toutes les adresses sont relatives a une adresse appellée "Image Base". Cette adresse est donc theoriquement l'adresse à laquelle le fichier doit etre chargee (en clair, le fichier une fois en memoire commence à l'adresse donnée par "Image Base"). Dans la pratique, beaucoup de fichiers ont la meme adresse dans le champ "ImageBase", on charge alors le fichier ou on veut (surtout là ou il y a de la place), puis on applique les relocalisations (changement des adresses dans le code) en fonction de la difference entre la veritable adresse de chargement et celle du champ "Image Base" (c'est le fameux Delta).
j'esperere avoir ete assez clair

Merci encore à toi

[Hauwke]

Bonsoir,

Si je comprend bien alors, on a un double mot avec les bits de poids forts en premier et les bits de poids faibles en second et on ne modifie que les bits de poids forts ?

Non, les relocalisations sont faites pour traiter les fichier PE (executables) qui ne peuvent pas etre chargee a l'endroit voulu. En effet, dans un fichier PE, toutes les adresses sont relatives a une adresse appellée "Image Base". Cette adresse est donc theoriquement l'adresse à laquelle le fichier doit etre chargee (en clair, le fichier une fois en memoire commence à l'adresse donnée par "Image Base"). Dans la pratique, beaucoup de fichiers ont la meme adresse dans le champ "ImageBase", on charge alors le fichier ou on veut (surtout là ou il y a de la place), puis on applique les relocalisations (changement des adresses dans le code) en fonction de la difference entre la veritable adresse de chargement et celle du champ "Image Base" (c'est le fameux Delta).
j'esperere avoir ete assez clair

Clair, oui et celà me permet de reprendre ma traduction qui manque de petits détails qui te seront certainement utiles maintenant que je pense commencer à comprendre:
Dans l'hypothése où ImageBase fait des économies d'adresse, le texte original sous-entends que tu as l'adresse d'une partie de l'information (le bit de poids fort) et qu'il te suffit de décaler d'un offset pour obtenir l'adresse du bit de poids faible mais il n'implique pas que tu ne puisses travailler que sur le bit de poids fort, au contraire!

The low 16 bits of the 32-bit value are stored
in the 16-bit word that follows this base relocation. This means that
this base relocation occupies two slots.

Qui suit* au sens 'se toucher' confirmé par 2 slots* avec un verbe conjugué au présent. Donc, au moment où tu accédes au poids fort tu sais implicitement où se trouve la seconde partie de l'information. Mais j'iniste, rien ne dit que tu sois limité dans ton intervention au mot de poids fort.
J'espére t'avoir été utile
Cordialement,
Hauwke

[tourlourou]

j'ai trouvé qqch ici :
http://bbs.ee.ntu.edu.tw/boards/Programming/12/18.html

Fixup blocks have the following format:

ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³ PAGE RVA ³
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³ BLOCK SIZE ³
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³ TYPE/OFFSET ³ TYPE/OFFSET ³
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³ TYPE/OFFSET ³ ... ³
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ



Figure 20. Fixup Block Format

To apply a fixup, a delta needs to be calculated. The 32-bit delta
is the difference between the preferred base, and the base where the
image is actually loaded. If the image is loaded at its preferred
base, the delta would be zero, and thus the fixups would not have to
be applied. Each block must start on a DWORD boundary. The ABSOLUTE
fixup type can be used to pad a block.

PAGE RVA = DD Page RVA. The image base plus the page rva is added to
each offset to create the virtual address of where the fixup needs to
be applied.

BLOCK SIZE = DD Number of bytes in the fixup block. This includes the
PAGE RVA and SIZE fields.

TYPE/OFFSET is defined as:

1 1 0
5 1
ÚÄÄÄÄÒÄÄÄÄÄÄÄÄÄÄÄÄ¿
³TYPEº OFFSET ³
ÀÄÄÄÄÐÄÄÄÄÄÄÄÄÄÄÄÄÙ

Figure 21. Fixup Record Format

TYPE = 4-bit fixup type. This value has the following definitions:

o 0h __ABSOLUTE. This is a NOP. The fixup is skipped.

o 1h __HIGH. Add the high 16-bits of the delta to the 16-bit field
at Offset. The 16-bit field represents the high value of a 32-
bit word.

o 2h __LOW. Add the low 16-bits of the delta to the 16-bit field
at Offset. The 16-bit field represents the low half value of a
32-bit word. This fixup will only be emitted for a RISC machine
when the image Object Align isn't the default of 64K.

o 3h __HIGHLOW. Apply the 32-bit delta to the 32-bit field at
Offset.

o 4h __HIGHADJUST. This fixup requires a full 32-bit value. The
high 16-bits is located at Offset, and the low 16-bits is
located in the next Offset array element (this array element is
included in the SIZE field). The two need to be combined into a
signed variable. Add the 32-bit delta. Then add 0x8000 and
store the high 16-bits of the signed variable to the 16-bit
field at Offset.

o 5h __MIPSJMPADDR.

All other values are reserved.

c'est pê plus clair ???

IMAGE_REL_BASED_HIGHADJ = __HIGHADJUST apparemment

ça semble dire que les 16 bits de poids fort se trouvent à l'offset qui suit le type 4h

mais je ne comprends pas si les 16 bits de poids faible sont les suivants (à offset+2) ou sont pointés par l'offset suivant (on ne tiendrait alors pas compte du type ?), ou plutôt constituent l'élément suivant, ces 16 bits prenant la place d'une structure type-offset : cette dernière hypothèse me semble meilleure !


bon courage...

[Hauwke]

Bonjour,
Faut traduire?? En fait, c'est une recette de cusine des fixups. Les mots deveinnent plus clairs au fur et à mesure que je lis ce thread mais pour le coté compréhension au sens "informatique" du terme ça devient carrément du chinois! Je commence à comprendre pourquoi mon Pc patine dans la sciure, parfois! Et je viens de décider de ne jamais accepter un boulot de bit dan un ordinateur. On vous rentre, on vous sort, on vous applique des poids de plus en plus lourds, on vous adjoint d'autres bits et vous finissez tous les uns dans les autres! Ah non, sincérement c'est pas un métier! (Joke for the tavern, sorry but i couldn't prevent me)
Cordialement,
Hauwke

[/dev/null]

Alors... pour le problème des poids faibles / forts... il ne se pose pas en fait
Un slot (Type[4]/offset[12]) contient dans le champ Type la valeur IMAGE_REL_BASED_HIGHADJ, ce qui signifie que le champ Offset contien les 16 bits de poids forts (mais il en fait 12 de bits !?!)... le prochain slot dans la chaine contient les 16bits de poids faibles.
En concaténant les 16 bits du 1er champ et les 16bits du second champ tu devrais obtenir une adresse complette sur 32bits...

Comme ça c'est simple

Maintenant, ce que je ne sais pas, c'est si ce ne sont pas plutôt les 12 bits du premier slot (champs d'offeset uniquement) qui serais employé (les 4 de poids forts sont reservé pour indiquer type normalement ) et les 16 bits du champ suivant serais employé completement, et non celon la stucture Type[4]/offset[12] comme il ce devrait. A mois qu'une adresse sur 24 bits soit suffisante

Si tu arrive à faire quelque chose de corecte... le code m'interressera... je devrais travailler dessus d'ici quelque mois

[Hauwke]

:

Figure 20. Fixup Block Format

To apply a fixup, a delta needs to be calculated. The 32-bit delta
is the difference between the preferred base, and the base where the
image is actually loaded. If the image is loaded at its preferred
base, the delta would be zero, and thus the fixups would not have to
be applied. Each block must start on a DWORD boundary. The ABSOLUTE
fixup type can be used to pad a block.
Pour appliquer un fixup, un delta doit être calculé. Le delta de 32 bits est la différence entre la base préférée (Avec le sens de référencée, ce qui correspondrait au post précédent sur "l'image base du PE), et la base où l'image est chargée réellement. Si l'image est chargée au lieu préféré, le delta serait zéro, et ainsi les fixups ne doivent pas être appliqués. Chaque bloc doit commencer sur une frontière de DWORD. Le type "ABSOLUTE" peut être employé pour socler (fonder) un bloc.

PAGE RVA = DD Page RVA. The image base plus the page rva is added to
each offset to create the virtual address of where the fixup needs to be applied.
La base d'image + le RVA de page est ajoutée à chacun des décalages pour créer l'adresse virtuelle où le fixup a besoin d’être appliqué.

BLOCK SIZE = DD Number of bytes in the fixup block. This includes the
PAGE RVA and SIZE fields.
Nombre de bytes dans le bloc de fixup= Nombre DD (?? Double densité???) de bytes dans le bloc du fixup. Ceci inclut la page RVA et la taille du champs.

TYPE = 4-bit fixup type. This value has the following definitions:
TYPE= Le type de fixup appliqué est codé sur 4 bit (sous entendu par la figure 21, les 4 premiers du mot de poids fort) et peut avoir les valeurs suivantes (sous entendu par le texte: l'une des valeurs du ( 0h __ABSOLUTE,1h __HIGH,2h __LOW,3h __HIGHLOW,4h __HIGHADJUST,5h __MIPSJMPADDR) set of TYPE):

0h __ABSOLUTE. This is a NOP. The fixup is skipped.
C'est un NOP. Le fixup est sauté. (Sous entendu par déclaration plus haut: c'est l'info de base que l'on retrouve dasn toutes les adresses qui n'ont pas eu nécessité d'être modifiées. i.e= l'emplacement réel est = à l'Image Base du PE)

1h __HIGH. Add the high 16-bits of the delta to the 16-bit field
at Offset. The 16-bit field represents the high value of a 32-
bit word.
Ajoute le mot de poids forts 16-bits du delta à la zone de 16 bits du champ de décalage. la valeur (sous entendue=obtenue) de 16 bits représente la valeur de poids fort d'un mot de 32 bits.

2h __LOW. Add the low 16-bits of the delta to the 16-bit field
at Offset. The 16-bit field represents the low half value of a
32-bit word. This fixup will only be emitted for a RISC machine
when the image Object Align isn't the default of 64K.
Ajoute les 16-bits de poids faible du delta à la zone de 16 bits au décalage. La zone de 16 bits représente le mot de poids faible d’un mot de 32 bits. Ce fixup sera seulement émis pour une machine RISC quand l'objet d'image d'alignement n'est pas de 64K par défaut (??).

3h __HIGHLOW. Apply the 32-bit delta to the 32-bit field at
Offset.
Applique le delta de 32 bits à la zone de 32 bits du champs de décalage.

4h __HIGHADJUST. This fixup requires a full 32-bit value. The
high 16-bits is located at Offset, and the low 16-bits is
located in the next Offset array element (this array element is
included in the SIZE field). The two need to be combined into a
signed variable. Add the 32-bit delta. Then add 0x8000 and
store the high 16-bits of the signed variable to the 16-bit
field at Offset.
Ce fixup exige une valeur entière de 32 bits. Le mot de poids fort est situé au décalage, et le mot de poids faible est situé au prochain élément d'alignement excentré (cet élément d'alignement est inclus dans le champs TAILLE). Il y a nécessité pour eux d'être combinés dans une variable signée. Ajoute le delta de 32 bits. Ajoute alors 0x8000 et enregistre le mot de poids fort de la variable signée au champs de la zone de décalage.
Attention!! Là je patine, je comprends pas ce qu'ils disent!!

5h __MIPSJMPADDR
Référencé dasn le texte mais non documenté

Cordialement,
Hauwke

[tourlourou]

@ /dev/null : je crois que tu as raison, sauf pour le 1° Word : 4 bits de type, puis 12 bits qui donnent l'offset où lire le Word <=> Hi(Cardinal),
puis le 2° Word, à interpréter comme le Lo(Cardinal) et non comme une structure Type/Offset

après, quelle cuisine précise en faire ?

[/dev/null]

Alors, il semblerait qu'en fait, les 12 bits du champ offset ne serve pas dans le calcul. Il indique une adresse RVA où doit être appliquer la modification
Le Delta est alors ajouter au 16bits de pointé par le champs offset. Ces 16bits sont donc les 16bits de poids forts d'un DWord . Ensuite, les 16bits du slot suivant sont ajouter au 16bits de poids faible .
Maintenant une question de base ... le delta c'est toi qui le calcul ? Comment ? C’est le points qui empêche une compréhension total de la méthode par mon pauvre encéphale

[tourlourou]

delta = différence entre adresse image de base préférée (classiquement 4000) et adresse réelle de chargement

[/dev/null]

Ok... alors... en théorie, tu ne devrait pas toruver pour un DLL autre chose que IMAGE_REL_BASED_ABSOLUTE ou IMAGE_REL_BASED_HIGHLOW. Donc déjà... c'est pas forcement util de ce prendre la tête
Si non... je dirait, au lumière de ce que j'ai lu et que tu me confirme, l'offset pointer (au format RVA) vers une l'adresse contenant un DWord. Va savoir pourquoi ce pointeur pointe au milieux du DWord que tu doit mettre a jour avec ton Delta...

Si ça ne fonctionne pas, et que ton code n'est pas confidentiel, passe en un morceau ... je veux bien faire des teste :p

[tourlourou]

c'est yarocco/glayag qui se penche sur le format PE avec talent et de petits problèmes de clarté dus à des explications pas limpides !

il s'intéressait donc aux relocalisations, notamment pour les dll, d'où le pb pê bien HS d'ailleurs, même s'il reste à lever !