2017-01-09 6 views
0

J'ai développé un simple pintool pour lister toutes les sections de l'image exécutable principale du programme (itération sur toutes ses sections), et aussi ses limites basse et haute en utilisant IMG_HighAddress et IMG_LowAddress; selon Pin, ceux-ci renvoient les limites définies de l'image. À ma grande surprise, les sections sont allées bien au-delà des limites basses et hautes rapportées par ces fonctions. Ai-je fait quelque chose de mal ou ces fonctions sont-elles inexactes?Les adresses de section vont au-delà de la région d'image - Intel Pin

Ma fonction de chargement d'image:

VOID ImageLoad(IMG img, VOID *v) 
{ 

if (!IMG_IsMainExecutable(img)) 
    return; 

ADDRINT mainExeImageLowAddr = IMG_LowAddress(img); 
ADDRINT mainExeImageHighAddr = IMG_HighAddress(img);  

cout << "Image limits " << hex << mainExeImageLowAddr << " - " << mainExeImageHighAddr << endl; 

for (SEC sec = IMG_SecHead(img); SEC_Valid(sec); sec = SEC_Next(sec)) 
{ 
    cout << "Section " << SEC_Name(sec) << " at addresses 0x" << hex << SEC_Address(sec) << " - 0x" << SEC_Address(sec)+SEC_Size(sec)-1 << endl; 
} 

} 

Les résultats pour l'exécuter sur/bin/ls:

Image limits 400000 - 418b23 
Section .interp at addresses 0x400200 - 0x40021b 
Section .note.ABI-tag at addresses 0x40021c - 0x40023b 
Section .note.gnu.build-id at addresses 0x40023c - 0x40025f 
Section .dynsym at addresses 0x4002c8 - 0x400eaf 
Section .rela.dyn at addresses 0x401618 - 0x4017c7 
Section .rela.plt at addresses 0x4017c8 - 0x402157 
Section .init at addresses 0x402158 - 0x40216f 
Section .plt at addresses 0x402170 - 0x4027df 
Section .text at addresses 0x4027e0 - 0x412347 
Section .fini at addresses 0x412348 - 0x412355 
Section .rodata at addresses 0x412360 - 0x415e86 
Section .eh_frame_hdr at addresses 0x415e88 - 0x41653b 
Section .eh_frame at addresses 0x416540 - 0x41851b 
Section .dynstr at addresses 0x41851c - 0x418b23 
Section .ctors at addresses 0x619000 - 0x61900f 
Section .dtors at addresses 0x619010 - 0x61901f 
Section .jcr at addresses 0x619020 - 0x619027 
Section .data.rel.ro at addresses 0x619040 - 0x619a87 
Section .dynamic at addresses 0x619a88 - 0x619c57 
Section .got at addresses 0x619c58 - 0x619cef 
Section .got.plt at addresses 0x619cf0 - 0x61a037 
Section .data at addresses 0x61a040 - 0x61a23f 
Section .bss at addresses 0x61a240 - 0x61af5f 
Section .gnu.conflict at addresses 0x61af60 - 0x61b6f7 
Section .gnu_debuglink at addresses 0x0 - 0xf 
Section .gnu.prelink_undo at addresses 0x0 - 0x8ff 
Section .shstrtab at addresses 0x0 - 0x12d 

Répondre

1

Ai-je fait quelque chose de mal

Pas nécessairement.

Il semble que Pin essaie de faire correspondre les concepts ELF aux concepts spécifiques à Windows, et il n'y a pas de correspondance biunivoque.

Intel documentation pour IMG_HighAddress dit:

Tells the highest address of any code or data loaded by the image. 
This is the address of the last byte loaded by the image. 

Mais qu'est-ce que cela signifie exactement?

Le chargement d'image ELF est défini par PT_LOAD segments. Vous pouvez voir les segments, ainsi que le mappage de section à segment, en sortie de readelf -Wl a.out.

Habituellement, il y aura deux LOAD segments: l'une avec r-x protections couvrant .text, .rodata, et d'autres sections en lecture seule, et une seconde avec rw- protections, couvrant .data, .bss et d'autres sections inscriptibles.

Il semble (à partir de votre sortie) comme IMG_HighAddress ne décrit que le premier segment LOAD.

Vous devez également noter que pas tous les sections sont LOAD en mesure, et les sections non LOAD capables ne sont généralement pas couverts par un segment (et n'occupent pas la mémoire lors de l'exécution). Diverses sections .debug* ne sont généralement pas LOAD.

+0

Notez la remarque sur la fonction: 'Dans ce cas, la fonction renvoie l'adresse haute du segment de texte'. Comme les images Unix, comme vous l'avez écrit, ont tendance à être scindées en mémoire, cela arrive presque toujours. – nitzanms