Das Suchwerkzeug passend zum Hinweis auswählen
Wenn Sie Strings in Ghidra suchen, entscheiden Sie zuerst, ob Sie bereits definierte Daten, sichtbaren Text im Programmmodell, rohe Bytes im geladenen Speicher oder eine exakte Adresse suchen. Defined Strings ist eine gute Übersicht, aber keine vollständige String-Suche. Ein kurzer String kann undefiniert sein, Unicode kann eine andere Darstellung verwenden und ein Speicherblock außerhalb des aktuellen Bereichs kann im selben Fenster fehlen.
Für Adressen bleibt Listing die wichtigste Quelle. Verwenden Sie Decompiler erst, nachdem Sie den Hinweis gefunden haben, um eine Funktion zu erklären. Die offizielle Einsteigerdokumentation beschreibt den größeren CodeBrowser-Ablauf; diese Seite konzentriert sich auf die Suchentscheidungen, die am Anfang leicht übersehen werden.
Untersuchen Sie nur Software und Systeme, für die Sie eine Erlaubnis haben. Ein Suchtreffer ist ein Hinweis auf eine Datei, keine Erlaubnis zur Analyse und keine Sicherheitsgarantie.
- Bekannter Text: mit Defined Strings oder Search for Strings beginnen und Referenzen prüfen.
- Name, Symbol, Funktion oder Kommentar: Search Program Text oder Symbol Tree verwenden.
- Exakte Adresse: Go To verwenden und Block sowie dekodierte Instruktion prüfen.
- Bytefolge oder Muster: Search Memory mit passendem Bereich verwenden.
- Verwendende Funktion: XREFs verfolgen und Listing, Function Graph und Decompiler vergleichen.
Strings suchen, statt im Decompiler zu raten
Wenn Sie eine Meldung, URL, Datei, einen Befehl oder einen Fehlerausschnitt kennen, suchen Sie den Text, bevor Sie Hunderte Funktionen lesen. Öffnen Sie Defined Strings für eine Liste der bereits erkannten Strings. Fehlt der Wert, verwenden Sie die String-Suche und prüfen Encoding, Mindestlänge, Ausrichtung, Nullterminierung und Speicherbereich. Ein leeres Ergebnis bedeutet oft, dass Definition oder Suchbereich nicht passen.
Ein Treffer ist erst nach der Adressprüfung nützlich. Öffnen Sie ihn in Listing, sehen Sie sich Bytes und benachbarte Daten an und bestätigen Sie, dass er in einem geladenen Block liegt. Wenn Ghidra undefinierte Daten anzeigt, prüfen Sie Ausrichtung und nahe Referenzen, bevor Sie sie definieren. Vor vielen Definitionen immer eine Projektkopie anlegen.
- 1
Mit einem eindeutigen Hinweis beginnen
Eine vollständige URL, ein seltener Hinweis oder eine ungewöhnliche Dateiendung liefert weniger Fehlalarme als ein allgemeines Wort oder ein Initialisierungsname.
Defined Strings / Search for Strings - 2
Encoding und Bereich prüfen
ASCII, UTF-8, UTF-16 oder die passende Darstellung testen und zwischen geladenen Blöcken, allen Blöcken und Auswahl unterscheiden.
Encoding + memory block scope - 3
Adresse in Listing öffnen
Bytes, Datentyp, benachbarte Strings und Referenzen prüfen. Eine Markierung beweist noch nicht die richtige Funktion.
Open in Listing - 4
Eine brauchbare Referenz verfolgen
Über References oder XREF zu Vergleich, Aufruf, Formatierung oder Verzweigung gehen und die Rolle des Strings klären.
References / Show XRefs
Ermitteln, wo ein String verwendet wird
Eine URL oder Meldung zu finden ist meistens nur die Mitte der Untersuchung. Wählen Sie das Datenelement und prüfen Sie seine Referenzen. Eine URL kann an eine Netzwerkfunktion übergeben, mit einem lokalen Wert verglichen oder unbenutzt gespeichert werden. Eine Meldung kann zu einem Fehlerpfad, einer Lizenzprüfung, einem Menü oder einem Debug-Zweig gehören. Die Referenzadresse zeigt den Verbrauchsort; Aufrufer und Aufgerufene erklären die Rolle.
Bei einer komplizierten Funktion zwischen Listing und Decompiler wechseln. Listing zeigt die tatsächlichen dekodierten Befehle und Adressen; Decompiler schlägt Kontrollfluss und Variablenmodell vor. Erst nach ausreichenden Belegen umbenennen und Beobachtung von Vermutung trennen.
- Prüfen, ob es eine echte Code- oder Datenreferenz und nicht nur eine nahe Adresse ist.
- Den Basisblock lesen und Vergleich, Aufruf oder Formatierung identifizieren.
- Aufrufer und Aufgerufene prüfen, bevor eine fachliche Bedeutung vergeben wird.
- Function Graph verwenden, wenn Verzweigungen im linearen Listing unübersichtlich sind.
- Bei Pseudocode-Fragen die Decompiler-Anleitung öffnen.
Speicheradresse, Wert oder Byte-Muster finden
Eine Frage wie „Wo liegt 0x00421A3F?“ ist zuerst ein Navigationsproblem. Mit Go To zur Adresse springen und anschließend Programm, Speicherblock, Sprache und Adressraum im Listing prüfen. Datei-Offsets, virtuelle Adressen, Image-Basen und relocierte Adressen sind nicht austauschbar. Wenn eine kopierte Adresse nirgendwohin führt, muss ihre Quelle geklärt werden: Datei, Debugger-Trace, Log oder relociertes Modul.
Für Rohdaten ist Search Memory besser als eine Textsuche. Bytes in der richtigen Reihenfolge suchen, Endianness und Ausrichtung beachten und bei vielen Treffern Block oder Auswahl einschränken. Ein Treffer kann in Code, Daten, Padding oder einer unabhängigen Struktur liegen. Die Suche erzeugt Kandidaten; Bytes und Referenzen im Umfeld liefern den Kontext.
Debugger, Dateibetrachter und Ghidra können unterschiedliche Koordinatensysteme verwenden. Quelle der Adresse bewahren und bewusst umrechnen, statt so lange eine Konstante zu addieren, bis der Wert plausibel wirkt.
| Hinweis | Erstes Werkzeug | Danach prüfen |
|---|---|---|
| Exakte geladene Adresse | Go To | Adressraum, Block, Instruktion oder Daten |
| Hex-Bytefolge | Search Memory | Endianness, Ausrichtung, Bereich, Referenzen |
| URL oder Meldung | String-Suche | Encoding, Definition, XREF, verwendende Funktion |
| Name oder Label | Symbol Tree / Search Program Text | Namensraum, Typ, Aufrufer und Aufgerufene |
| Wert aus Log oder Debugger | Go To + Listing | Rebase, Modulbasis und Offset gegenüber Adresse |
Befehle und Befehlsmuster suchen
Eine Befehlsuche braucht eine präzisere Frage als „finde dieses Wort“. Gesucht werden können Mnemonic, Register, Konstante, Sequenz oder Compiler-Bytes. Search Program Text hilft bei stabilem Text im Listing; Search Memory ist besser, wenn die Bytekodierung der stabile Hinweis ist. Architektur und Importsprache bestimmen, wie dieselben Bytes dekodiert werden. Diese Einstellungen vor dem Vergleich prüfen.
Bei Java-Befehlen oder plattformspezifischen Begriffen Quellsprachenwörter und Disassemblierungssyntax nicht vermischen. Die Form suchen, die im Listing tatsächlich erscheint, und einen Treffer über Operanden und Kontrollfluss prüfen. Für wiederholbare Muster Architektur, Endianness, Wildcards und Suchbereich dokumentieren.
- 1
Muster definieren
Mnemonic, Operanden, Bytes, Register oder Konstanten notieren und variable Teile markieren.
Muster = Mnemonic + Operanden + optionale Wildcards - 2
Text oder Bytes wählen
Textsuche nutzen, wenn die dekodierte Form stabil ist; Memory-Suche, wenn die Byteform stabil ist.
Search Program Text / Search Memory - 3
Treffer validieren
Ergebnis öffnen, vollständige Instruktion und Block lesen und Referenzen sowie Aufrufer vergleichen.
Listing + XREF + Function Graph
Funktionen, undefinierte Funktionen und Grenzen finden
Wenn ein Suchtreffer auf Code zeigt, über Symbol Tree, Function Window oder den aktuellen Listing-Kontext prüfen, ob Ghidra bereits eine Funktion erkannt hat. „Undefined“ kann bedeuten, dass die Analyse noch keine Grenze erstellt hat, dass die Adresse Daten enthält oder dass die importierte Architektur überprüft werden muss. Eine Funktion nicht nur deshalb erstellen, weil eine nahe Sequenz bekannt aussieht: Einstiegspunkt, Referenzen, Calling Convention und Rückkehr prüfen.
In einem suchgetriebenen Ablauf ist die Funktion eine Ordnungshilfe für Belege, aber kein Beweis für das Verhalten. Adresse, gefundene Daten oder Instruktion, verbindende Referenz und nächste konsumierende Funktion notieren. Die Einsteigeranleitung behandelt Auto Analysis und Function Graph im größeren Zusammenhang.
| Ergebnis | Bedeutung | Sicherer nächster Schritt |
|---|---|---|
| Benannte Funktion | Symbolische Grenze vorhanden | Aufrufer, Aufgerufene, Signatur und Referenzen prüfen |
| FUN_... oder namenlose Funktion | Funktion vorhanden, Rolle unbekannt | Strings, Aufrufe und Datenfluss vor Umbenennung nutzen |
| Undefinierte Adresse | Noch keine verlässliche Grenze | Code/Daten-Klassifizierung prüfen und Kopie analysieren |
| Treffer in einem Block | Hinweis nahe Code oder Daten | Block vollständig lesen und XREF verfolgen |
| Keine Referenzen | Indirekte Nutzung oder unvollständige Definition | Pointertabellen, Relocation und Analysebereich prüfen |
Keine oder zu viele Ergebnisse korrigieren
Der häufigste Fehler ist ein Unterschied zwischen Hinweis und Darstellung im Programm. Eine URL kann geteilt, kodiert, komprimiert, als UTF-16 gespeichert oder zur Laufzeit aufgebaut werden. Eine Adresse kann zu einer anderen Modulbasis gehören. Ein Instruktionsmuster ändert sich schon, wenn der Compiler ein anderes Register wählt. Immer nur eine Variable ändern und den ursprünglichen Hinweis bei den Einstellungen behalten.
Bei zu vielen Treffern Block, Auswahl, Datentyp, Mindestlänge, Sprache oder Adressbereich einschränken. Bei keinen Treffern eine Bedingung erweitern, Nachbarbytes prüfen, anderes Encoding versuchen und sicherstellen, dass der Speicher geladen ist. Bei versionsabhängigen Menüs die aktuelle offizielle Hilfe statt eines alten Screenshots verwenden.
| Symptom | Wahrscheinliche Ursache | Nächste Prüfung |
|---|---|---|
| Kein Stringtreffer | Encoding, zu kurzer String oder undefinierte Daten | Passendes Encoding testen und Bytes prüfen |
| Zu viele Texttreffer | Häufiges Wort oder weiter Bereich | Eindeutigen Ausschnitt und Blockbereich verwenden |
| Adresse nicht erreichbar | Offset, Rebase oder Adressraum falsch | Koordinatensystem und Modulbasis bestimmen |
| String ohne XREF | Indirekte Nutzung oder Pointertabelle | Nahe Pointer und fokussierte Analyse prüfen |
| Instruktion fehlt | Syntax, Architektur oder Compiler anders | Bytes oder stabilen Operanden suchen |
| Decompiler weicht ab | Pseudocode ist eine Interpretation | Zu Listing, Bytes, Referenzen und Function Graph zurück |
Fragen zur Suche in Ghidra
Wie sucht man in Ghidra am einfachsten nach Strings?
Mit Defined Strings als Übersicht beginnen und die String-Suche verwenden, wenn der Wert fehlt oder das Encoding unklar ist. Treffer im Listing prüfen und XREFs verfolgen.
Wie findet man eine URL-Adresse in Ghidra?
Einen eindeutigen URL-Teil als String suchen, Encoding und Adresse im Listing prüfen und Referenzen bis zur lesenden oder vergleichenden Funktion verfolgen. URLs können zur Laufzeit zusammengesetzt werden.
Wie sucht man eine bestimmte Speicheradresse in Ghidra?
Go To verwenden und Adressraum, Speicherblock sowie dekodierte Instruktion oder Daten prüfen. Datei-Offsets und Debugger-Adressen vorher umrechnen.
Wie sucht man bestimmte Befehle in Ghidra?
Search Program Text für stabilen dekodierten Text oder Search Memory für stabile Bytes verwenden. Architektur und Endianness prüfen und Treffer in Listing sowie Function Graph validieren.
Warum findet eine Ghidra-String-Suche nichts?
Encoding, Mindestlänge, Ausrichtung, geladene Speicherbereiche und eine mögliche Aufteilung oder Laufzeit-Erzeugung des Werts prüfen. Bedingungen einzeln erweitern.
Sollte man den Decompiler zum Suchen eines Strings verwenden?
Meist zuerst String oder Bytes suchen und den Decompiler danach zum Verständnis der referenzierenden Funktion einsetzen. Listing und Bytes sind die direktere Evidenz für den Treffer.