Dans lequel la bibliothèque est le MD5() la fonction?

Que je suis en train d'écrire le code à installer sur une machine cible, je me demandais sur les dépendances et remarqué qu'il n'y avait pas de bibliothèque openssl nécessaire. Je me demandais parce que je sais que je suis en utilisant OpenSSL:

#include <openssl/md5.h>

...
MD5(a, b, c);
...

À ma grande surprise, il semble que nous obtenons seulement lié à l'encontre de la libc. Est-MD5 vraiment mis en œuvre dans la libc et non dans la libssl bibliothèque?

objdump me donne les infos à propos de la bibliothèque de liens:

Dynamic Section:
  NEEDED               libQtCore.so.4
  NEEDED               libstdc++.so.6
  NEEDED               libgcc_s.so.1
  NEEDED               libc.so.6
  SONAME               libcontent.so

Comme suggéré par noloader j'ai essayé avec la commande ldd et de ne toujours pas voir une bibliothèque qui aurait du sens pour le MD5. libcontent.donc, est directement à l'aide de MD5()...

ldd ../BUILD/snapwebsites/plugins/content/libcontent.so 
    linux-vdso.so.1 =>  (0x00007fff4f3ff000)
    libQtCore.so.4 => /usr/lib/x86_64-linux-gnu/libQtCore.so.4 (0x00007ff37ad0f000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ff37aa0c000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff37a7f5000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff37a42c000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff37a20f000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007ff379ff7000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff379df3000)
    libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007ff379af7000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007ff3798ee000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff3795e9000)
    /lib64/ld-linux-x86-64.so.2 (0x00007ff37b5e5000)
    libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007ff3793a9000)

Aussi, juste pour être sûr, j'ai essayé nm sur que le contenu de la bibliothèque et je peux voir le MD5 d'entrée:

                 w _ITM_registerTMCloneTable
00000000003c9468 d __JCR_END__
00000000003c9468 d __JCR_LIST__
                 w _Jv_RegisterClasses
                 U MD5                       <---- it's here...
                 U memcmp@@GLIBC_2.2.5
                 w pthread_cancel
                 U pthread_mutex_destroy@@GLIBC_2.2.5

Comment avez-vous appris que ce binaire est uniquement lié à l'encontre de la libc?
Qu'allez-vous être à l'aide de MD5?
J'ai fait une mise à jour avec la sortie de objdump -x.
Je l'utilise déjà. Je suis en train de travailler sur un CMS pour les sites web. Lorsque vous téléchargez un fichier, je calcule le MD5 et de l'utiliser comme clé dans la base de données Cassandra (l'ID, si vous le souhaitez). Il fonctionne très bien, je suis juste surpris qu'un correspondant .il n'est donc pas présent.
Ce n'est qu'une bibliothèque, libcontent.so , à proprement parler, il n'a pas besoin de lien vers une bibliothèque qui fournit MD5(). Mais quelle que soit l'application qui se charge de cette bibliothèque.

OriginalL'auteur Alexis Wilke | 2014-02-21

md5 openssl

4

Dans lequel la bibliothèque est le MD5() la fonction?

La bibliothèque OpenSSL. Lien vers libcrypto. Voir md5(3).

MD5 est vraiment mis en œuvre dans la libc et non dans la libssl bibliothèque?

Bien, elle n'est pas dans Ubuntu libc:
```
$ nm -D  /lib/x86_64-linux-gnu/libc.so.6 | grep -i md5
$
```
Et c'est dans OpenSSL est libcrypto:
```
$ nm -D /usr/lib/x86_64-linux-gnu/libcrypto.so | grep MD5
0000000000066840 T MD5
0000000000066640 T MD5_Final
0000000000066790 T MD5_Init
0000000000066630 T MD5_Transform
0000000000066420 T MD5_Update
```
La T signifie le symbole (MD5) est définie dans le TEXTE de l'article et de son exportation. Un t signifie le symbole est défini dans la section de TEXTE, mais ses pas exporté de sorte que vous ne peut pas lier contre elle (pensez du CCG visibility=private ou statique de la déclaration).

Si vous obtenez une U, alors cela signifie que le symbole est nécessaire, mais pas défini et d'une bibliothèque aura à fournir.
```
#include <openssl/md5.h>

...
MD5(a, b, c, d);
```
MD5(a, b, c, d); n'est pas de l'installation de OpenSSL MD5. L'installation de OpenSSL MD5 a trois paramètres, et non pas quatre.

objdump me donne les infos à propos de la bibliothèque de liens

ldd peut vous donner des résultats différents. Ses ce que j'utilise pour vérifier les dépendances (et je n'utilise pas objdump):
```
$ cat t.c
#include <openssl/md5.h>

int main(int argc, char* argv[])
{
    const char password[] = "password";
    char hash[MD5_DIGEST_LENGTH];    
    MD5(password, sizeof(password), hash);

    return 0;
}

$ gcc t.c -o t.exe -lcrypto
$ ldd t.exe 
    linux-vdso.so.1 =>  (0x00007fff435ff000)
    libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007fbaff01b000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbafec90000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fbafea8b000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fbafe874000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fbaff429000)
```
Et t.exe'symbole non résolu:
```
$ nm t.exe | grep MD5
    U MD5@@OPENSSL_1.0.0
```
Je ne vois toujours libcrypto dans la liste des dépendances. Serait-ce que parce que c'est une .donc, il va le résoudre au moment de l'exécution, et si le processus principal est lié à l'encontre de la libcrypto alors ce sera bien? (Je viens de vérifier et l'application principale est liée à l'encontre de la libcrypto.ainsi, alors que ce serait la réponse! qu'en pensez-vous?)
Le U dans U MD5 signifie que le symbole n'est pas défini et d'une bibliothèque doit fournir. Essayez de dumping libQtCore (nm -D) pour voir si libQtCore fournit; ou essayez de dumping, les dépendances de libQtCore pour voir si libQtCore liens contre l'installation de OpenSSL libcrypto.so.
Notez que j'ai la charge .donc, en utilisant ldopen(). J'ai regardé toutes les bibliothèques qui sont liés à l'encontre de cela .donc, et aucun n'a la libcrypto.so fichier. Toutefois, il est là, dans la principale de l'application. En utilisant le paresseux reliant le mode de ldopen(), je pense qu'il est capable de trouver à la bibliothèque de l'librairies de l'application principale... je suppose que c'est ok, seulement ce n'est pas ce que j'appellerais coffre-fort (parce que les bibliothèques pourraient être retirés de l'application principale et puis le lazy load fonctionne, mais si j'ai appeler cette fonction, il va pas dire qu'il n'a pas pu résoudre le symbole au moment de l'exécution.)

OriginalL'auteur jww

Vous devez vous connecter pour publier un commentaire.