Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
whatfiles — Protokollieren, auf welche Dateien jeder Linux-Prozess zugreift. | Kitploit
Tools/GitHubGitHub/spieglt/whatfiles
Allgemeine DienstprogrammeForensikDigitale Forensik
GitHubspieglt/whatfiles

whatfiles

Protokollieren, auf welche Dateien jeder Linux-Prozess zugreift.

Repository anzeigen
946329vor 1 TagVon Kitploit geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen

whatfiles

build and test

Whatfiles ist ein Linux-Dienstprogramm, das protokolliert, welche Dateien ein anderes Programm auf Ihrem System liest/schreibt/erstellt/löscht. Es verfolgt auch alle neuen Prozesse und Threads, die vom Zielprozess erstellt werden, und zeichnet auf, ob jeder Vorgang erfolgreich war.

Begründung:

Ich war lange frustriert über das Fehlen eines einfachen Dienstprogramms, mit dem man sehen kann, welche Dateien ein Prozess von main() bis zum Beenden berührt. Ob Sie einem Softwareanbieter nicht vertrauen oder besorgt über Malware sind, es ist wichtig zu wissen, was ein Programm oder Installer mit Ihrem System macht. lsof beobachtet nur einen Moment in der Zeit und strace ist groß und etwas kompliziert.

Beispielausgabe:

root@kitploit:~
mode:   exec, file: /usr/bin/cp, syscall: execve(), PID: 17004, process: sh, result: 0
mode:   read, file: /tmp/demo/copy.txt, syscall: openat(), PID: 17004, process: /usr/bin/cp, result: -1 (No such file or directory)
mode:   read, file: /etc/hostname, syscall: openat(), PID: 17004, process: /usr/bin/cp, result: 3
mode: write+create, file: /tmp/demo/copy.txt, syscall: openat(), PID: 17004, process: /usr/bin/cp, result: 4
mode:  chmod, file: /tmp/demo/copy.txt, syscall: fchmodat(), PID: 17005, process: /usr/bin/chmod, result: 0
mode: rename, file: /tmp/demo/copy.txt, to: /tmp/demo/renamed.txt, syscall: renameat2(), PID: 17006, process: /usr/bin/mv, result: 0
mode:   read, file: /tmp/demo/missing.txt, syscall: openat(), PID: 17007, process: /usr/bin/cat, result: -1 (No such file or directory)
mode: delete, file: /tmp/demo/renamed.txt, syscall: unlinkat(), PID: 17008, process: /usr/bin/rm, result: 0
Tool herunterladen

Jede Zeile gibt an, was mit der Datei gemacht wurde, die Datei selbst, welcher Syscall dies getan hat, welcher Prozess und Thread, und was der Kernel zurückgegeben hat. Pfade sind immer absolut: relative Pfade werden gegen das Arbeitsverzeichnis des Prozesses aufgelöst, oder gegen das Verzeichnis, das er an einen *at()-Syscall übergeben hat. result ist der Rückgabewert des Syscalls, sodass fehlgeschlagene und erfolgreiche Zugriffe unterschieden werden können.

Neben Öffnen, Erstellen und Löschen meldet whatfiles rename, link, symlink, mkdir, rmdir, truncate, chmod, chown und exec eines Programms. SYSCALLS.md behandelt, was noch nicht gemeldet wird und warum jede Ergänzung es wert wäre, hinzugefügt zu werden.

Verwendung:

  • Grundlegende Verwendung, startet ls und schreibt die Ausgabe in eine Protokolldatei im aktuellen Verzeichnis:

    $ whatfiles ls -lah ~/Documents

  • Ausgabedateispeicherort mit -o angeben:

    $ whatfiles -o MyLogFile cd ..

  • Debug-Ausgabe einschließen, auf stdout statt in Protokolldatei ausgeben:

    $ whatfiles -d -s apt install zoom

  • An einen aktuell laufenden Prozess anhängen (erfordert Root-Rechte):

    $ sudo whatfiles -p 1234

  • Das verfolgte Programm beenden, wenn whatfiles selbst beendet wird, anstatt es unverfolgt weiterlaufen zu lassen:

    $ whatfiles -k ./installer.sh

Drücken Sie jederzeit Strg-C: whatfiles trennt sich von allem, was es verfolgt, lässt diese Prozesse weiterlaufen und beendet das Schreiben des Protokolls.

Verteilung

Gebrauchsfertige Binärdateien befinden sich auf der releases-Seite! Jemand hat es freundlicherweise auch zum Arch-Repository hinzugefügt, und letompouce hat ebenfalls eine GitLab-Pipeline eingerichtet.

Kompilierung (erfordert gcc und make):

root@kitploit:~
$ cd whatfiles
$ make
$ sudo make install

Unterstützt x86-, x86_64-, ARM32- und ARM64-Architekturen. make install beachtet PREFIX und DESTDIR.

Linux 3.4 oder neuer ist erforderlich. Unter Linux 5.3 und neuer fragt whatfiles den Kernel direkt zu jedem Syscall-Stopp, was die korrekte Dekodierung von 32-Bit-Syscalls auf einer 64-Bit-Maschine ermöglicht; bei älteren Kernels wird auf das Lesen von Registern zurückgegriffen.

Android

Kompilieren Sie mit dem NDK cross, und übertragen Sie dann die Binärdatei auf das Gerät:

root@kitploit:~
$ make android NDK=~/Android/Sdk/ndk/<version>
$ adb push bin/whatfiles-android /data/local/tmp/whatfiles
$ adb shell chmod 755 /data/local/tmp/whatfiles
$ adb shell /data/local/tmp/whatfiles -o /data/local/tmp/ls.log ls /sdcard

ANDROID_ABI wählt arm64, den Standard, oder arm32, x86_64 oder x86. ANDROID_API legt die minimale API-Stufe fest und ist standardmäßig 21.

Einige Dinge unterscheiden sich auf einem Gerät:

  • Legen Sie die Binärdatei in /data/local/tmp. /sdcard ist ohne Ausführungsberechtigung eingebunden.
  • Das Arbeitsverzeichnis in adb shell ist nicht beschreibbar, übergeben Sie daher -o mit einem Pfad unter /data/local/tmp, oder -s, um auf stdout zu schreiben.
  • Das Ausführen eines Befehls unter whatfiles funktioniert als normaler Shell-Benutzer, und ebenso das Anhängen an einen Prozess, den dieser Benutzer gestartet hat. Das Anhängen an alles andere, beispielsweise eine App, erfordert Root, also adb root auf einem userdebug-Build. Auf einem Android 14-Emulator funktionierte das mit durchsetzendem SELinux; die Richtlinie eines Produktionsgeräts kann dies jedoch weiterhin verweigern.
  • make test-android NDK=~/Android/Sdk/ndk/<version> baut whatfiles und die Testprogramme für das verbundene Gerät, führt die Prüfungen dort aus und entfernt, was es übertragen hat.
  • Eine 32-Bit-App, die von einem arm64-Build aus verfolgt wird, wird mit den 32-Bit-Syscall-Nummern und Argument- Registern gelesen, anstatt als 64-Bit-App behandelt zu werden. Dieser Pfad wurde nicht auf echter Hardware erprobt: Der hier zum Testen verwendete Emulator hat keine 32-Bit-ABI.

make test baut die Programme in tests/ und führt sie unter whatfiles aus, um sein Verhalten zu prüfen, einschließlich Signalzustellung, Thread- und Kindprozess-Abdeckung und Interrupt-Behandlung.

Fragen, die irgendwann gestellt werden könnten:

  • Ist das nicht nur eine Neuimplementierung von strace -fe trace=creat,open,openat,unlink,unlinkat ./program?

    Ja. Obwohl es darauf abzielt, einfacher und benutzerfreundlicher zu sein.

  • Gibt es Mac- und Windows-Versionen?

    Nein. Das Verfolgen von Syscalls auf dem Mac erfordert task_for_pid(), was Code-Signierung erfordert, was ich nicht zum Laufen bringe, und außerdem habe ich kein Interesse daran, Apple 100 $/Jahr zu zahlen, um freie Software zu schreiben. dtruss auf dem Mac kann verwendet werden, um einem einzelnen Prozess und seinen Kindern zu folgen, obwohl das -t-Flag anscheinend nur einen einzelnen Syscall zum Filtern akzeptiert. fs_usage macht etwas Ähnliches, obwohl ich nicht sicher bin, ob es Kindprozessen/Threads folgt. Process Monitor für Windows ist ziemlich großartig.

Einschränkungen:

  • Programme, die an eine Kopie von sich selbst übergeben. Besonders Browser: Wenn bereits eine Instanz läuft, übergibt die von Ihnen gestartete Ihre Anfrage an sie und beendet sich, sodass whatfiles nichts mehr zu verfolgen hat und stoppt, während das von Ihnen angeforderte Fenster von der unverfolgten Kopie stammt. Verfolgen Sie stattdessen eine separate Instanz, mit etwas wie whatfiles firefox --no-remote --profile ~/ff-trace-profile und einem Profilverzeichnis, das noch nicht existiert, oder beenden Sie zuerst die laufende Kopie.

  • Keine Sicherheitsgrenze. Ein Programm, das nicht beobachtet werden möchte, kann erkennen, dass es verfolgt wird, und io_uring führt Dateioperationen ohne die Syscalls aus, die whatfiles überwacht. Betrachten Sie das Protokoll als eine Beschreibung dessen, was ein Programm getan hat, nicht als Beweis für alles, was es hätte tun können.

  • Geschwindigkeit. Jeder Syscall stoppt den verfolgten Prozess zweimal, sodass syscall-intensive Programme mehrere Male langsamer als üblich laufen. Dies sind dieselben Kosten, die strace beim Verfolgen aller Syscalls verursacht.

  • Anhängen erfordert Berechtigungen. -p erfordert im Allgemeinen Root oder ein gelockertes /proc/sys/kernel/yama/ptrace_scope. Ein verweigertes Anhängen lässt das Ziel normal weiterlaufen.

  • Wenn whatfiles direkt beendet wird mit SIGKILL, läuft das Programm, das es verfolgte, weiter, unverfolgt, es sei denn, es wurde mit -k gestartet.

Geplante Funktionen:

  • Derzeit keine, offen für Anfragen und PRs.

Vielen Dank für Ihr Interesse, und bitte schauen Sie sich auch Cloaker, Nestur und Flying Carpet an!