nccgroup/libtalloclibtalloc is a python script for use with GDB that can be used to analyse the "trivial allocator" (talloc)
libtalloc ist ein Python-Skript zur Verwendung mit GDB, mit dem der „trivial allocator" (talloc) analysiert werden kann. Eine Einführung in talloc finden Sie hier:
https://talloc.samba.org/talloc/doc/html/index.html
libtalloc wurde von anderen GDB-Python-Skripten zur Heap-Analyse wie unmask_jemalloc und libheap inspiriert. Einige grundlegende Funktionen sind identisch mit diesen Projekten.
https://github.com/cloudburst/libheap
https://github.com/argp/unmask_jemalloc
Bitte beachten Sie, dass ich kein Python-Guru bin und die Codequalität dies widerspiegelt. Wenn Sie etwas sehen, das Sie abstößt, senden Sie ruhig einen Patch oder geben Sie mir ein paar Vorschläge. Jegliches Feedback ist willkommen.
libtalloc wurde mit verschiedenen 2.x-Releases von talloc getestet und unterstützt eine dynamische Versionserkennung, um die unterschiedlichen strukturellen Unterschiede zwischen den Versionen zu überwinden. Es wurde auf 32-Bit und 64-Bit getestet, allerdings nicht erschöpfend, also wundern Sie sich nicht, wenn es gelegentlich nicht funktioniert.
Es wurde bis zu einem gewissen Grad auf x86 und x64 getestet:
Wenn Sie es mit einer anderen Version testen, lassen Sie mich bitte wissen, ob es funktioniert hat oder was kaputtging, und ich werde versuchen, es und/oder die Doku entsprechend zu aktualisieren.
Das Skript benötigt lediglich eine relativ moderne Version von GDB mit Python-Unterstützung.
Einige LTS-Distributionen wie Ubuntu 12.04 verwenden weiterhin GDB mit Python 2.7, während neuere Versionen wie 14.04 Python 3.0 verwenden. Ich habe versucht, dieses Skript mit beiden zum Laufen zu bringen, sodass Sie nur Folgendes benötigen:
(gdb) source libtalloc.py
Ein Großteil der Funktionalität ist an den Ansatz von unmask_jemalloc angelehnt, bei dem ein separater GDB-Befehl anstelle einer komplexen Reihe von Optionen bereitgestellt wird.
Es sind mehrere Methoden verfügbar, die speziell dazu entwickelt wurden, die C-Funktionen der talloc-Bibliothek nachzubilden, um Personen zu helfen, die libtalloc erweitern möchten, falls sie bereits mit der Bibliothek vertraut sind.
Um eine vollständige Liste der Befehle zu sehen, können Sie den Befehl tchelp ausführen:
(gdb) tchelp
[libtalloc] talloc commands for gdb
[libtalloc] tcchunk -v -x <addr> : show chunk contents (-v for verbose, -x for data dump)
[libtalloc] tcvalidate -a <addr> : validate chunk (-a for whole heap)
[libtalloc] tcsearch <addr> : search heap for hex value or address
[libtalloc] tcwalk <func> : walk whole heap calling func on every chunk
[libtalloc] tcreport <addr> : give talloc_report_full() info on memory context
[libtalloc] tcdump -s <addr> : dump chunks linked to memory context (-s for sorted by addr)
[libtalloc] tcparents <addr> : show all parents of chunk
[libtalloc] tcchildren <addr> : show all children of chunk
[libtalloc] tcinfo : show information known about heap
[libtalloc] tcprobe : try to collect information about talloc version
[libtalloc] tchelp : this help message
Einer der wichtigsten Befehle ist tcprobe. Er muss ausgeführt werden, um herauszufinden, welche Version von talloc tatsächlich installiert ist. Die Strukturlayouts verschiedener Versionen können erheblich variieren. Damit die meisten Funktionen funktionieren, muss die Version daher bekannt sein.
Wenn der Befehl funktioniert, sollte er die erkannte Version anzeigen:
(gdb) tcprobe
Version: 2.1.1
File: /usr/lib/libtalloc.so.2.1.1
Der Befehl tcinfo soll so viele gesammelte Informationen über den Heap wie möglich anzeigen, etwa die Informationen von tcprobe, die null_context-Struktur, falls sie gefunden wurde, und mehr. Derzeit zeigt er nur die Version an und ob null_context gesetzt ist. null_context wird für die meisten Funktionen benötigt, die die eigentliche Hierarchie durchlaufen. Um ihn zu finden, versuchen die meisten anderen Funktionen wie tchunk usw., ihn automatisch zu finden.
Nachdem tcprobe ausgeführt wurde, aber bevor tchunk tatsächlich verwendet wird:
(gdb) tcinfo [libtalloc] null_context not yet found yet [libtalloc] Version: 2.0.7 [libtalloc] File: /usr/lib/i386-linux-gnu/libtalloc.so.2.0.7
Dann, nachdem ein Chunk analysiert wurde, etwa so:
(gdb) tcchunk 0xb94a52b0 WARNING: 0xb94a52b0 not a talloc_chunk. Assuming ptr to chunk data 0xb94a5280 sz:0x0000003c, flags:...., name:struct tevent_context
Sie können anschließend mit tcinfo bestätigen, dass er gefunden wurde.
(gdb) tcinfo [libtalloc] null_context: 0xb94a5028 [libtalloc] Version: 2.0.7 [libtalloc] File: /usr/lib/i386-linux-gnu/libtalloc.so.2.0.7
Jetzt, da null_context gesetzt ist, können Sie andere Befehle ausführen, die normalerweise beanstanden würden, dass er nicht gesetzt ist, wie etwa den Befehl tcsearch.
tcchunk kann Ihnen eine Zusammenfassung des Chunks, eine ausführlichere Ausgabe jedes Feldes oder extrem ausführliche Informationen über jeden umgebenden Chunk liefern.
HINWEIS: Ein wichtiger Punkt zu tcchunk ist, dass intern die Methode tc_chunk() verwendet wird, die versucht, Fehler bei der Übergabe der Chunk-Adresse zu korrigieren. Wenn Sie insbesondere die Adresse der Chunk-Daten selbst übergeben und der erwartete talloc-Magic-Wert nicht gefunden wird, sucht die Methode etwas früher im Speicher nach einem legitimen Chunk-Header. Das kann in korrupten Szenarien Probleme verursachen. Stellen Sie also immer sicher, dass Sie die explizite Adresse übergeben, es sei denn, Sie führen nur eine oberflächliche Analyse durch.
Zusammenfassungsausgabe:
(gdb) tcchunk 0x80a13c88
0x80a13c88 sz:0x00000020, flags:..p., name:struct netr_ServerPasswordSet
Das Folgende ist eine Legende für die Chunks in der Zusammenfassungsausgabe:
p - Member of a pool (POOLMEM flag)
P - Chunk is a pool (POOL flag)
F - Chunk is free (FREE flag)
L - Chunk is looped (LOOP flag)
Ausführliche Ausgabe:
(gdb) tcchunk -v 0x80a13c88
struct talloc_chunk @ 0x80a13c88 {
next = 0x0
prev = 0x80a140c8
parent = 0x0
child = 0x80a14088
refs = 0x0
destructor = 0x0
name = 0x807d9f2f (struct netr_ServerPasswordSet)
size = 0x20
flags = 0xe8150c78 (POOLMEM)
limit = 0x0
pool = 0x80a13248
talloc-Chunks enthalten einige Magic-Werte, mit denen überprüft werden kann, ob sie intakt sind. Der Befehl tcvalidate analysiert einen Chunk, um sicherzustellen, dass die Chunk-Magic wie erwartet ist. Zusätzlich analysiert er alle anderen Zeigermember, um sicherzustellen, dass sie tatsächlich in Speicherbereiche fallen (wie von gdb bekannt), ob die Größe gültig ist usw.
Wir verwenden eine eingebaute Methode, um einen Wert zu ändern und zu zeigen, wie es fehlschlagen könnte:
(gdb) python set_destructor(tc_chunk(0x80a13c88), 0x41414141)
(gdb) tcchunk -v 0x80a13c88
struct talloc_chunk @ 0x80a13c88 {
next = 0x0
prev = 0x80a140c8
parent = 0x0
child = 0x80a14088
refs = 0x0
destructor = 0x41414141
name = 0x807d9f2f (struct netr_ServerPasswordSet)
size = 0x20
flags = 0xe8150c78 (POOLMEM)
limit = 0x0
pool = 0x80a13248
(gdb) tcvalidate 0x80a13c88
Chunk header is invalid:
0x80a13c88: Chunk has bad destructor pointer 0x41414141
tcparents kann verwendet werden, um alle Eltern des angegebenen Chunks anzuzeigen:
(gdb) tcparents 0x80a13c88
0x809f8300: null_context
0x80a08660: TALLOC_CTX *
0x809f8370: talloc_new: ../lib/util/talloc_stack.c:147
0x809fb680: talloc_new: ../lib/util/talloc_stack.c:147
0x80a13258: UNNAMED
0x80a13c58: talloc_new: ../lib/util/talloc_stack.c:147
0x80a13c88: struct netr_ServerPasswordSet
tchildren kann verwendet werden, um alle Kinder (und Enkel usw.) des angegebenen Chunks anzuzeigen:
(gdb) tcchildren 0x80a13c88
0x80a14088: struct netr_Authenticator
0x80a14048: librpc/gen_ndr/ndr_netlogon.c:10964
0x80a14008: librpc/gen_ndr/ndr_netlogon.c:10958
0x80a13fc8: librpc/gen_ndr/ndr_netlogon.c:10951
0x80a13f88: lib/charcnv.c:506
0x80a13ec8: lib/charcnv.c:506
0x80a13d48: librpc/gen_ndr/ndr_netlogon.c:10913
0x80a13e08:
0x80a13cd8: struct ndr_pull
0x80a13f48: struct ndr_token_list
0x80a13f08: struct ndr_token_list
0x80a13e88: struct ndr_token_list
0x80a13e48: struct ndr_token_list
0x80a13dc8: struct ndr_token_list
0x80a13d88: struct ndr_token_list
talloc kennt das Konzept von Pool-Chunks. Dies sind im Grunde normale talloc-Chunks, die jedoch zum Allozieren neuer Chunks verwendet werden, anstatt auf die zugrunde liegende malloc()-Implementierung des Systems zurückzugreifen. Ein Pool-Chunk hat je nach verwendeter Version leicht unterschiedliche Header, manchmal mit Padding und manchmal mit einem Präfix-/Suffix-Header.
tcpool kann verwendet werden, um einen Pool-Chunk-Header ähnlich wie tcchunk zu analysieren:
# First we find a pool to analyze
(gdb) tcchunk -v 0x80a13c88
struct talloc_chunk @ 0x80a13c88 {
next = 0x0
prev = 0x80a140c8
parent = 0x0
child = 0x80a14088
refs = 0x0
destructor = 0x0
name = 0x807d9f2f (struct netr_ServerPasswordSet)
size = 0x20
flags = 0xe8150c78 (POOLMEM)
limit = 0x0
pool = 0x80a13248
(gdb) tcpool -v 0x80a13248
struct talloc_pool_hdr @ 0x80a13248 {
end = 0x80a14108
object_count = 0x19
poolsize = 0x2000
struct talloc_chunk @ 0x80a13258 {
next = 0x0
prev = 0x0
parent = 0x809fb680
child = 0x80a13c58
refs = 0x0
destructor = 0x80429aa0
name = 0x0 (UNNAMED)
size = 0x0
flags = 0xe8150c74 (POOL)
limit = 0x0
pool = 0x0
Im obigen Fall hatte der Pool einen vorangestellten talloc_pool_hdr, der angezeigt wird. Die Option -l kann an tcpool übergeben werden, um alle alloziierten Chunks innerhalb eines Pools aufzulisten:
(gdb) tcpool -l 0x80a13248
Pool summary -- objects: 0x19, total size: 0x2000, space left: 0x1180, next free: 0x80a14108
0x80a13258 sz:0x00000000, flags:.P.., name:UNNAMED
0x80a13288 sz:0x000007a3, flags:..p., name:char
0x80a13a68 sz:0x0000005c, flags:..p., name:struct smb_request
0x80a13af8 sz:0x00000008, flags:..p., name:struct pipe_write_andx_state
0x80a13b38 sz:0x00000038, flags:..p., name:struct tevent_req
0x80a13ba8 sz:0x00000028, flags:..p., name:struct tevent_immediate
0x80a13c08 sz:0x00000014, flags:..p., name:struct np_write_state
0x80a13c58 sz:0x00000000, flags:..p., name:talloc_new: ../lib/util/talloc_stack.c:147
0x80a13c88 sz:0x00000020, flags:..p., name:struct netr_ServerPasswordSet
0x80a13cd8 sz:0x00000038, flags:..p., name:struct ndr_pull
0x80a13d48 sz:0x00000001, flags:..p., name:librpc/gen_ndr/ndr_netlogon.c:10913
0x80a13d88 sz:0x00000010, flags:..p., name:struct ndr_token_list
0x80a13dc8 sz:0x00000010, flags:..p., name:struct ndr_token_list
0x80a13e08 sz:0x00000001, flags:..p., name:
0x80a13e48 sz:0x00000010, flags:..p., name:struct ndr_token_list
0x80a13e88 sz:0x00000010, flags:..p., name:struct ndr_token_list
0x80a13ec8 sz:0x00000008, flags:..p., name:lib/charcnv.c:506
0x80a13f08 sz:0x00000010, flags:..p., name:struct ndr_token_list
0x80a13f48 sz:0x00000010, flags:..p., name:struct ndr_token_list
0x80a13f88 sz:0x00000008, flags:..p., name:lib/charcnv.c:506
0x80a13fc8 sz:0x0000000c, flags:..p., name:librpc/gen_ndr/ndr_netlogon.c:10951
0x80a14008 sz:0x00000010, flags:..p., name:librpc/gen_ndr/ndr_netlogon.c:10958
0x80a14048 sz:0x0000000c, flags:..p., name:librpc/gen_ndr/ndr_netlogon.c:10964
0x80a14088 sz:0x0000000c, flags:..p., name:struct netr_Authenticator
0x80a140c8 sz:0x0000000b, flags:..p., name:/etc/samba
Beachten Sie das P-Flag in der obigen Ausgabe: Der oberste Chunk ist der Pool-Chunk, der alle darunter liegenden Chunks enthält.
tcdump kann verwendet werden, um alle Chunks im gesamten Baum auszugeben. Standardmäßig werden sie in hierarchischer Reihenfolge angezeigt; mit der Option -s kann die Ausgabe jedoch nach Adresse sortiert werden.
(gdb) tcdump -a 0x809f8300
0x809f8300 sz:0x00000000, flags:...., name:null_context
0x80a0b3f8 sz:0x0000000c, flags:...., name:struct handle_list
0x809ff178 sz:0x00000014, flags:...., name:struct security_token
0x80a089e8 sz:0x00000198, flags:...., name:lib/util_nttoken.c:50
0x80a07268 sz:0x00000188, flags:...., name:connection_struct
0x80a08bc8 sz:0x00000020, flags:...., name:struct fd_handle
0x80a00c30 sz:0x000000f0, flags:...., name:struct files_struct
0x80a083b8 sz:0x00000008, flags:...., name:struct fake_file_handle
0x80a08c20 sz:0x0000009c, flags:...., name:struct pipes_struct
0x80a07900 sz:0x00000760, flags:...., name:uint8_t
0x80a07428 sz:0x000000c0, flags:...., name:struct auth_serversupplied_info
0x80a06390 sz:0x00000001, flags:...., name:
0x80a06350 sz:0x00000007, flags:...., name:nobody
0x80a06158 sz:0x000000cc, flags:...., name:struct netr_SamInfo3
0x80a062d8 sz:0x00000044, flags:...., name:struct dom_sid
[SNIP]
tcreport ist ein Befehl ähnlich wie tcdump, der die Ausgabe jedoch etwas verschönert und die von der talloc-Bibliothek selbst bereitgestellte Debug-Funktion talloc_report_full() nachahmen soll.
(gdb) tcreport 0x80a0b3f8 -a
Full talloc report on 'null_context' (total 558651 bytes in 446 blocks)
struct handle_list contains 12 bytes in 1 blocks (ref 67) 0x80a0b3f8
struct security_token contains 428 bytes in 2 blocks (ref 66) 0x809ff178
lib/util_nttoken.c:50 contains 408 bytes in 1 blocks (ref 0) 0x80a089e8
connection_struct contains 531071 bytes in 36 blocks (ref 65) 0x80a07268
struct fd_handle contains 32 bytes in 1 blocks (ref 4) 0x80a08bc8
struct files_struct contains 529681 bytes in 22 blocks (ref 3) 0x80a00c30
struct fake_file_handle contains 529308 bytes in 19 blocks (ref 1) 0x80a083b8
struct pipes_struct contains 529300 bytes in 18 blocks (ref 0) 0x80a08c20
uint8_t contains 1888 bytes in 1 blocks (ref 2) 0x80a07900
struct auth_serversupplied_info contains 934 bytes in 10 blocks (ref 1) 0x80a07428
contains 1 bytes in 1 blocks (ref 4) 0x80a06390
nobody contains 7 bytes in 1 blocks (ref 3) 0x80a06350
struct netr_SamInfo3 contains 290 bytes in 4 blocks (ref 2) 0x80a06158
[SNIP]
Es gibt zwei Befehle zum Suchen: tcsearch und tcfindaddr.
tcsearch kann verwendet werden, um Chunks zu finden, die den angegebenen hexadezimalen Wert enthalten. Es funktioniert, indem es die gesamte Baumhierarchie ausgehend vom null_context (falls bekannt) oder von einem bereitgestellten Start-Chunk durchläuft.
(gdb) python set_destructor(tc_chunk(0x80a13c88), 0x41414141)
(gdb) tcsearch 0x41414141 0x809f8300
[libtalloc] 0x41414141 found in chunk at 0x80a1d218
[libtalloc] 0x41414141 found in chunk at 0x80a13c88
(gdb) tcchunk -v 0x80a1d218
struct talloc_chunk @ 0x80a1d218 {
next = 0x80a00158
prev = 0x809fb0c8
parent = 0x0
child = 0x0
refs = 0x0
destructor = 0x0
name = 0x8071fcbd (uint8_t)
size = 0x80050
flags = 0xe8150c70 ()
limit = 0x0
pool = 0x0
(gdb) tcchunk -x 0x80a1d218
0x80a1d218 sz:0x00080050, flags:...., name:uint8_t
Chunk data (524368 bytes):
0x80a1d248: 0x41414141 0x00000000 0x00000000 0x00000000
0x80a1d258: 0x00000001 0x00000000 0x00000001 0x00020000
0x80a1d268: 0x00000001 0x00000000 0x00000001 0xaaaa0000
[SNIP]
(gdb) tcchunk -v 0x80a13c88
struct talloc_chunk @ 0x80a13c88 {
next = 0x0
prev = 0x80a140c8
parent = 0x0
child = 0x80a14088
refs = 0x0
destructor = 0x41414141
name = 0x807d9f2f (struct netr_ServerPasswordSet)
size = 0x20
flags = 0xe8150c78 (POOLMEM)
limit = 0x0
pool = 0x80a13248
tcfindaddr kann verwendet werden, um festzustellen, ob eine Adresse innerhalb der Grenzen eines Chunks im talloc-Baum liegt. Angenommen, Sie wissen, dass 0x80a1d3280 einige von Ihnen kontrollierte Daten enthält, und möchten sehen, ob sie innerhalb eines Chunks liegen. Beachten Sie, dass die zweite Adresse der null_context ist, aber jeder Chunk verwendet werden kann, der uns den oberen Teil des Heaps finden lässt.
(gdb) tcfindaddr 0x80a1d328 0x809f8300
[libtalloc] address 0x80a1d328 falls within chunk @ 0x80a1d218 (size 0x80050)
Ein Teil der Baumsuche wird mithilfe einer rekursiven Funktion durchgeführt, die ich über den Befehl tcwalk zugänglich gemacht habe. Es handelt sich um eine Hilfsfunktion, mit der Sie eine Python-Methode angeben können, die für jeden im Baum entdeckten Chunk aufgerufen wird.
Im folgenden Beispiel rufen wir die Heap-Validierungsmethode für jeden Chunk im Heap auf, um zu sehen, ob etwas beschädigt ist.
(gdb) tcwalk validate_chunk
0x80a13c88: Chunk has bad destructor pointer 0x41414141
Beachten Sie, dass Sie, falls null_context nicht gesetzt wurde, eine Chunk-Adresse als zweites Argument übergeben müssen.
Geschrieben von Aaron Adams
E-Mail: aaron (dot) adams (at) nccgroup (dot) trust
Twitter: @fidgetingbits