ossillate-inc/packjStatisches und dynamisches Analysetool, das Open-Source-Pakete auf bösartige, verwundbare und riskante Eigenschaften überprüft, mit einer sandboxierten Installation, um Supply-Chain-Angriffe zu verhindern.
Packj kennzeichnet bösartige/riskante Open-Source-PaketePackj (ausgesprochen wie „Package“) ist ein Werkzeug, das hilft, Angriffe auf die Software-Lieferkette zu mildern. Es kann bösartige, anfällige, verlassene, Typo-Squatting- und andere „riskante“ Pakete aus gängigen Open-Source-Paketregistern wie NPM, RubyGems und PyPI erkennen. Es kann einfach angepasst werden, um Rauschen zu minimieren. Packj begann als PhD-Forschungsprojekt und wird derzeit im Rahmen verschiedener staatlicher Fördermittel entwickelt.
Hinweis Der selbst gehostete Packj-Webserver und mehrere Integrationen kommen später in diesem Monat 👊 Beobachten Sie dieses Repo, um auf dem Laufenden zu bleiben.
Wir unterstützen mehrere Bereitstellungsmodelle:
Verwenden Sie Packj, um Abhängigkeiten in Pull Requests zu prüfen.```yaml
Auf dem GitHub [Marketplace](https://github.com/marketplace/actions/packj-security-audit) ansehen. Beispiel [PR-Ausführung](https://github.com/ossillate-inc/packj-github-action-demo/pull/3#issuecomment-1274797138).
### 2. Docker-Image (empfohlen)
Der schnellste Weg, Packj auszuprobieren/testen, ist die Verwendung von Docker. Podman wird ebenfalls für containerisierte (isolierte) Ausführungen unterstützt.```
docker run -v /tmp:/tmp/packj -it ossillate/packj:latest --help
Klone dieses Repository,``` git clone https://github.com/ossillate-inc/packj.git && cd packj
Abhängigkeiten installieren```
bundle install && pip3 install -r requirements.txt
Mit Hilfe beginnen:``` python3 main.py --help
# Unterstützte Ökosysteme #
Packj kann veröffentlichte Pakete von den Paketregistern NPM, PyPI, Rust, PHP und Rubygems überprüfen. Die Rust- und PHP-Unterstützung befindet sich in Arbeit. Wir erweitern aktiv die Unterstützung für weitere Registries.
Es unterstützt auch die Überprüfung lokaler (nicht veröffentlichter) NPM- und PyPI-Pakete.
| Registry | Ökosystem | Unterstützt |
| --------- | ----------- | -------------------- |
| NPM | JavaScript | :white_check_mark: |
| PyPI | Python | :white_check_mark: |
| Cargo | Rust | :white_check_mark: |
| Rubygems | Ruby | :white_check_mark: |
| Packagist | PHP | :white_check_mark: |
| Docker | Docker | :x: |
| Nuget | .NET | :white_check_mark: |
| Maven | Java | :white_check_mark: |
| Cocoapods | Swift | :x: |
# Funktionalität #
Packj bietet die folgenden Werkzeuge:
* [Audit](#prüfung-eines-pakets) – zur Überprüfung eines Pakets auf „riskante“ Attribute.
* [Sandbox](#sandbox-paketinstallation) – zur sicheren Installation eines Pakets.
## Prüfung eines Pakets ##
Packj prüft Open-Source-Softwarepakete auf „riskante“ Attribute, die sie anfällig für Lieferkettenangriffe machen. Beispielsweise werden Pakete mit abgelaufenen E-Mail-Domains (fehlende 2FA), großen Veröffentlichungszeitabständen, sensitiven APIs oder Zugriffsberechtigungen als riskant eingestuft.
Die Prüfung folgender Punkte wird unterstützt:
- mehrere Pakete: `python3 main.py audit -p pypi:requests rubygems:overcommit`
- Abhängigkeitsdateien: `python3 main.py audit -f npm:package.json pypi:requirements.txt`
Standardmäßig führt `audit` nur eine statische Codeanalyse durch, um riskanten Code zu erkennen. Sie können das Flag `-t` oder `--trace` übergeben, um auch eine dynamische Codeanalyse durchzuführen, die alle angeforderten Pakete unter `strace` installiert und das Installationsverhalten der Pakete überwacht. Siehe das Beispiel unten.
<details>
<summary><h4>Beispiellauf/-ausgabe anzeigen</h4></summary>
$ docker run -v /tmp:/tmp/packj -it ossillate/packj:latest audit --trace -p npm:browserify
[+] Fetching 'browserify' from npm..........PASS [ver 17.0.0]
[+] Checking package description.........PASS [browser-side require() the node way]
[+] Checking release history.............PASS [484 version(s)]
[+] Checking version........................RISK [702 days old]
[+] Checking release time gap............PASS [68 days since last release]
[+] Checking author.........................PASS [[email protected]]
[+] Checking email/domain validity.......RISK [expired author email domain]
[+] Checking readme.........................PASS [26838 bytes]
[+] Checking homepage.......................PASS [https://github.com/browserify/browserify#readme]
[+] Checking downloads......................PASS [2M weekly]
[+] Checking repo URL.......................PASS [https://github.com/browserify/browserify]
[+] Checking repo data...................PASS [stars: 14189, forks: 1244]
[+] Checking if repo is a forked copy....PASS [original, not forked]
[+] Checking repo description............PASS [browser-side require() the node.js way]
[+] Checking repo activity...............PASS [commits: 2290, contributors: 207, tags: 413]
[+] Checking for CVEs.......................PASS [none found]
[+] Checking dependencies...................RISK [48 found]
[+] Downloading package from npm............PASS [163.83 KB]
[+] Analyzing code..........................RISK [needs 3 perm(s): decode,codegen,file]
[+] Checking files/funcs....................PASS [429 files (383 .js), 744 funcs, LoC: 9.7K]
[+] Installing package and tracing code.....PASS [found 5 process,1130 files,22 network syscalls]
=============================================
[+] 5 risk(s) found, package is undesirable!
=> Complete report: /tmp/packj_54rbjhgm/report_npm-browserify-17.0.0_hlr1rhcz.json
{
"undesirable": [
"old package: 702 days old",
"invalid or no author email: expired author email domain",
"generates new code at runtime",
"reads files and dirs",
"forks or exits OS processes",
]
}
</details>
> WARNUNG: Da Pakete während der Installation bösartigen Code ausführen könnten, wird empfohlen, `-t` oder `--trace` NUR innerhalb eines Docker-Containers oder einer virtuellen Maschine zu verwenden.
Die Prüfung kann auch in Docker/Podman-Containern durchgeführt werden. Details zu riskanten Attributen und zur Verwendung finden Sie in der [Audit README](https://github.com/ossillate-inc/packj/blob/main/packj/audit/README.md).
## Sandbox-Paketinstallation ##
Packj bietet eine leichtgewichtige Sandbox für die „sichere Installation“ eines Pakets. Insbesondere verhindert es, dass bösartige Pakete sensible Daten exfiltrieren, auf sensible Dateien (z. B. SSH-Schlüssel) zugreifen und Malware persistent machen.
Es sandboxt Installationsskripte, einschließlich nativer Kompilierung. Es verwendet **strace** (d. h. **KEIN** VM/Container erforderlich).
Details zum Sandbox-Mechanismus und zur Verwendung finden Sie in der [Sandbox README](https://github.com/ossillate-inc/packj/blob/main/packj/sandbox/README.md).
<details>
<summary><h4>Beispiellauf/-ausgabe anzeigen</h4></summary>
$ python3 main.py sandbox gem install overcommit
Fetching: overcommit-0.59.1.gem (100%)
Install hooks by running `overcommit --install` in your Git repository
Successfully installed overcommit-0.59.1
Parsing documentation for overcommit-0.59.1
Installing ri documentation for overcommit-0.59.1
#############################
# Review summarized activity
#############################
[+] Network connections
[+] DNS (1 IPv4 addresses) at port 53 [rule: ALLOW]
[+] rubygems.org (4 IPv6 addresses) at port 443 [rule: IPv6 rules not supported]
[+] rubygems.org (4 IPv4 addresses) at port 443 [rule: ALLOW]
[+] Filesystem changes
/
└── home
└── ubuntu
└── .ruby
├── gems
│ ├── iniparse-1.5.0 [new: DIR, 15 files, 46.6K bytes]
│ ├── rexml-3.2.5 [new: DIR, 77 files, 455.6K bytes]
│ ├── overcommit-0.59.1 [new: DIR, 252 files, 432.7K bytes]
│ └── childprocess-4.1.0 [new: DIR, 57 files, 141.2K bytes]
├── cache
│ ├── iniparse-1.5.0.gem [new: FILE, 16.4K bytes]
│ ├── rexml-3.2.5.gem [new: FILE, 93.2K bytes]
│ ├── childprocess-4.1.0.gem [new: FILE, 34.3K bytes]
│ └── overcommit-0.59.1.gem [new: FILE, 84K bytes]
├── specifications
│ ├── rexml-3.2.5.gemspec [new: FILE, 2.7K bytes]
│ ├── overcommit-0.59.1.gemspec [new: FILE, 1.7K bytes]
│ ├── childprocess-4.1.0.gemspec [new: FILE, 1.8K bytes]
│ └── iniparse-1.5.0.gemspec [new: FILE, 1.3K bytes]
├── bin
│ └── overcommit [new: FILE, 622 bytes]
└── doc
├── iniparse-1.5.0
│ └── ri [new: DIR, 119 files, 131.7K bytes]
├── rexml-3.2.5
│ └── ri [new: DIR, 836 files, 841K bytes]
├── overcommit-0.59.1
│ └── ri [new: DIR, 1046 files, 1.5M bytes]
└── childprocess-4.1.0
└── ri [new: DIR, 272 files, 297.8K bytes]
[C]ommit all changes, [Q|q]uit & discard changes, [L|l]ist details:
</details>
# Unsere Geschichte
**TL;DR** Packj begann als PhD-Forschungsprojekt. Es wird durch verschiedene staatliche Zuschüsse unterstützt.
<details>
<summary><h4>Lange Antwort anzeigen</h4></summary>
Packj begann als akademisches Forschungsprojekt. Insbesondere basieren die von Packj verwendeten Techniken zur statischen Codeanalyse auf hochmoderner Cybersicherheitsforschung: dem [MalOSS](https://github.com/osssanitizer/maloss)-Projekt unserer Forschungsgruppe an der [Georgia Tech](http://cyfi.ece.gatech.edu).
<a href="https://arxiv.org/pdf/2002.01139v1.pdf" target="_blank">
<img src="https://assets.kitploit.com/production/public/readmes/5562/c4061028051de04a9aebaf4188c08fdd1bcdb47efa8a818e959d3b3fc7bc5dc7.png" width="300" alt="academic paper">
</a>
Packj wird durch großzügige Zuschüsse von [NSF](https://www.sbir.gov/node/2083473), [GRA](https://gra.org/company/227/OSSPolice.html) und [ALInnovate](https://innovatealabama.org) unterstützt.
</details>
# Warum Packj
**TL;DR** Aktuelle Schwachstellenscanner gehen davon aus, dass der Drittanbieter-Open-Source-Code **BENIGN** ist. Daher adressieren alle diese Werkzeuge NUR Bedrohungen durch versehentliche Programmierfehler in benignem Code (auch bekannt als CVEs wie Log4J). Sie SCHÜTZEN NICHT vor modernen Software-Lieferkettenangriffen nach Art von Solarwinds, die von absichtlich schlechtem (auch bösartigem) Code ausgehen, der von böswilligen Akteuren unter Ausnutzung neuer Schwachstellen im Lieferkanal verbreitet wird, einschließlich Dependency Confusion, Typo-Squatting, Protestware (Sabotage), Account-Hijacking und Social Engineering. Ein aktuelles (Dez. '22) Beispiel ist das PyTorch-Paket, das unter Ausnutzung einer Dependency-Confusion-Schwachstelle (keine CVE zugewiesen) kompromittiert wurde.
Packj prüft nicht nur auf CVEs, sondern führt auch eine tiefgehende statische+dynamische Codeanalyse sowie Metadatenprüfungen durch, um jedes „riskante“ Verhalten und Attribute zu erkennen, wie z. B. das Starten einer Shell, die Verwendung von SSH-Schlüsseln, Abweichungen zwischen GitHub-Code und Paket-Code (Provenienz), fehlende 2FA und viele weitere. Solche unsicheren Attribute qualifizieren nicht als CVEs, weshalb keines der vorhandenen Werkzeuge sie erkennen kann. Packj kann bösartige, Typo-Squatting-, verwaiste, anfällige und andere unsichere Abhängigkeiten (schwache Glieder) in Ihrer Software-Lieferkette erkennen.
<details>
<summary><h4>Lange Antwort anzeigen</h4></summary>
Das aktuelle Bedrohungsmodell der Software-Lieferkette **geht davon aus**, dass der Drittanbieter-Open-Source-Code benign ist, und daher werden Sicherheitslücken nur für versehentliche Programmierfehler (auch bekannt als CVEs) verfolgt. Daher **melden** alle vorhandenen Open-Source-Schwachstellenscanner **NUR** öffentlich bekannte CVEs und adressieren Bedrohungen durch versehentliche Fehler in benignem Code.
Ein typisches Beispiel für einen versehentlichen Programmierfehler ist eine fehlende Bereichsprüfung bei Benutzereingaben, die den Code anfällig für Pufferüberlaufangriffe macht. Bekannte Beispiele aus der Praxis sind Log4J und HeartBleed. Angreifer müssen einen Exploit entwickeln, um CVEs auszulösen (z. B. ein manipuliertes TCP/IP-Paket bei HeartBleed oder eine numerisch hohe Eingabe zur Verursachung eines Pufferüberlaufs). CVEs können durch Patchen oder Upgraden auf eine neuere Version der Bibliothek behoben werden (z. B. behebt eine neuere Version von Log4J die CVE).
Die moderne Bedrohungslandschaft der Software-Lieferkette hat sich **verschoben** nach dem Solarwinds-Angriff. Böswillige Akteure haben neue Schwachstellen gefunden, diesmal jedoch im Lieferkanal, nicht im Code. Diese neuen Schwachstellen wie Dependency Confusion, Typo-Squatting, Protestware (Sabotage), Account-Hijacking und Social Engineering werden ausgenutzt, um Malware zu verbreiten. Tausende kompromittierter NPM/PyPI/Ruby-Pakete wurden gemeldet.
Im Gegensatz zu CVEs ist Malware absichtlich schlechter (auch bösartiger) Code. Darüber hinaus ist Malware selbst ein Exploit und kann nicht durch ein Upgrade auf eine neuere Version gepatcht oder behoben werden. Beispielsweise war der [Dependency-Confusion-Angriff](https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610) absichtlich bösartig; er nutzte keinen versehentlichen Programmierfehler im Code aus. Auch die Sabotage des eigenen Codes durch einen Autor eines beliebten Pakets zum [Protest](https://en.wikipedia.org/wiki/Peacenotwar) gegen den Krieg ist sehr beabsichtigt und nutzt keine CVEs aus. Typo-Squatting ist ein weiterer Angriffsvektor, den bösartige Akteure nutzen, um Malware in beliebten Open-Source-Paketregistern zu verbreiten: Es nutzt [Tippfehler und Unerfahrenheit von Entwicklern](https://discuss.python.org/t/improving-risks-and-consequences-against-typosquatting-on-pypi/5090) aus, nicht versehentliche Programmierfehler oder CVEs im Code.
Vorhandene Scanner **versagen** bei der Erkennung dieser modernen Software-Lieferkettenangriffe nach Art von Solarwinds durch absichtlich anfälligen (bösartigen) Code. Diese Werkzeuge scannen lediglich den Quellcode auf Open-Source-Abhängigkeiten, erstellen eine Liste aller verwendeten Abhängigkeiten und suchen jedes <Abhängigkeits-NAME, Abhängigkeits-VERSION> in einer Datenbank (z. B. NVD), um betroffene Paketversionen zu melden (z. B. anfällige Version von Log4J, von HeartBleed betroffene LibSSL-Version).
Packj prüft nicht nur auf CVEs, sondern führt auch eine tiefgehende statische+dynamische Codeanalyse sowie Metadatenprüfungen durch, um jedes „riskante“ Verhalten und Attribute zu erkennen, wie z. B. das Starten einer Shell, die Verwendung von SSH-Schlüsseln, Abweichungen zwischen GitHub-Code und Paket-Code (Provenienz), fehlende 2FA und viele weitere. Solche unsicheren Attribute qualifizieren nicht als CVEs, weshalb keines der vorhandenen Werkzeuge sie erkennen kann. Packj kann bösartige, Typo-Squatting-, verwaiste, anfällige und andere unsichere Abhängigkeiten (schwache Glieder) in Ihrer Software-Lieferkette erkennen. Lesen Sie mehr in der [Audit README](https://github.com/ossillate-inc/packj/blob/main/packj/audit/README.md#faq)
</details>
# Anpassung #
Packj kann einfach an Ihr Bedrohungsmodell angepasst werden (kein Rauschen). Fügen Sie einfach eine [.packj.yaml](https://github.com/ossillate-inc/packj/blob/main/.packj.yaml)-Datei im obersten Verzeichnis Ihres Repositorys/Projekts hinzu und reduzieren Sie die Alarmmüdigkeit, indem Sie unerwünschte Attribute auskommentieren.
# Gefundene Malware #
Wir haben mit diesem Tool über 40 bzw. 20 bösartige Pakete auf PyPI bzw. Rubygems gefunden. Einige davon wurden entfernt. Siehe ein Beispiel unten:
<details>
<summary><h4>Beispiel-Malware anzeigen</h4></summary>
$ python3 main.py audit pypi:krisqian
[+] Fetching 'krisqian' from pypi...OK [ver 0.0.7]
[+] Checking version...OK [256 days old]
[+] Checking release history...OK [7 version(s)]
[+] Checking release time gap...OK [1 days since last release]
[+] Checking author...OK [[email protected]]
[+] Checking email/domain validity...OK [[email protected]]
[+] Checking readme...ALERT [no readme]
[+] Checking homepage...OK [https://www.bilibili.com/bangumi/media/md140632]
[+] Checking downloads...OK [13 weekly]
[+] Checking repo_url URL...OK [None]
[+] Checking for CVEs...OK [none found]
[+] Checking dependencies...OK [none found]
[+] Downloading package 'KrisQian' (ver 0.0.7) from pypi...OK [1.94 KB]
[+] Analyzing code...ALERT [needs 3 perms: process,network,file]
[+] Checking files/funcs...OK [9 files (2 .py), 6 funcs, LoC: 184]
=============================================
[+] 6 risk(s) found, package is undesirable!
{
"undesirable": [
"no readme",
"only 45 weekly downloads",
"no source repo found",
"generates new code at runtime",
"fetches data over the network: ['KrisQian-0.0.7/setup.py:40', 'KrisQian-0.0.7/setup.py:50']",
"reads files and dirs: ['KrisQian-0.0.7/setup.py:59', 'KrisQian-0.0.7/setup.py:70']"
]
}
=> Complete report: pypi-KrisQian-0.0.7.json
=> View pre-vetted package report at https://packj.dev/package/PyPi/KrisQian/0.0.7
</details>
Packj stufte KrisQian (v0.0.7) als verdächtig ein, aufgrund des Fehlens eines Quell-Repositorys und der Verwendung sensibler APIs (Netzwerk, Codegenerierung) während der Paketinstallationszeit (in setup.py). Wir haben uns entschieden, genauer hinzusehen und fanden das Paket bösartig. Unsere detaillierte Analyse finden Sie unter [https://packj.dev/malware/krisqian](https://packj.dev/malware/krisqian).
Weitere Beispiele von Malware, die wir gefunden haben, sind unter [https://packj.dev/malware](https://packj.dev/malware) aufgelistet. Bitte kontaktieren Sie uns unter [[email protected]](mailto:[email protected]) für die vollständige Liste.
# Ressourcen #
Um mehr über das Packj-Tool oder Angriffe auf die Open-Source-Software-Lieferkette zu erfahren, siehe unsere
[](https://www.youtube.com/watch?v=Rcuqn56uCDk)
[](https://www.youtube.com/watch?v=a7BfDGeW_jY)
- PyConUS'22 [Vortrag](https://www.youtube.com/watch?v=Rcuqn56uCDk) und [Folien](https://speakerdeck.com/ashishbijlani/pyconus22-slides).
- BlackHAT Asia'22 Arsenal [Präsentation](https://www.blackhat.com/asia-22/arsenal/schedule/#mitigating-open-source-software-supply-chain-attacks-26241)
- PackagingCon'21 [Vortrag](https://www.youtube.com/watch?v=PHfN-NrUCoo) und [Folien](https://speakerdeck.com/ashishbijlani/mitigating-open-source-software-supply-chain-attacks)
- BlackHat USA'22 Arsenal-Vortrag [Detecting typo-squatting, backdoored, abandoned, and other "risky" open-source packages using Packj](https://www.blackhat.com/us-22/arsenal/schedule/#detecting-typo-squatting-backdoored-abandoned-and-other-risky-open-source-packages-using-packj-28075)
- Akademische [Dissertation](https://cyfi.ece.gatech.edu/publications/DUAN-DISSERTATION-2019.pdf) zur Open-Source-Softwaresicherheit und das [Paper](https://www.ndss-symposium.org/wp-content/uploads/ndss2021_1B-1_23055_paper.pdf) unserer Gruppe an der Georgia Tech, das diese Forschung begann.
- Open Source Summit, Europe'22 Vortrag [Scoring dependencies to detect “weak links” in your open-source software supply chain](https://osseu2022.sched.com/overview/type/SupplyChainSecurityCon) – Präsentationsvideo auf [YouTube](https://www.youtube.com/watch?v=a7BfDGeW_jY)
- Präsentations-[Video](https://www.youtube.com/watch?v=PgvlSjl-mrY) und [Folien](https://drive.google.com/file/d/1qLXIXzsIhRlS0mo8nwWI9KmD12CImZY9/view?usp=sharing) bei NullCon'22 [Unearthing Malicious And Other “Risky” Open-Source Packages Using Packj](https://archive.nullcon.net/website/goa-2022/speakers/unearthing-malicious-and-other-risky-open-source-packages-using-packj.php)
# Feature-Roadmap #
* Rust-Analyzer hinzufügen. Rust ist in Arbeit [ETA: Feb. '24].
* Funktionalität zur Erkennung mehrerer (TODO) „riskanten“ Code- sowie Metadatenattribute hinzufügen [ETA: Feb. '24].
* Selbst gehosteter Packj-Webserver und mehrere nützliche Integrationen (z. B. Gitlab-Runner) [ETA: Apr. '24].
Beobachten :eyes: Sie dieses Repository, um auf dem Laufenden zu bleiben.
Haben Sie eine Feature- oder Support-Anfrage? Bitte besuchen Sie unsere [GitHub-Diskussionsseite](https://github.com/ossillate-inc/packj/discussions/) oder treten Sie unserer [Discord-Community](https://discord.gg/qFcqaV2wYa) für Diskussionen und Anfragen bei.
# Team und Mitwirkende #
Packj wurde von Cybersicherheitsforschern bei [Ossillate Inc.](https://packj.dev/team) und externen Mitarbeitern entwickelt, um Entwicklern zu helfen, die Risiken von Lieferkettenangriffen bei der Verwendung von nicht vertrauenswürdigen Open-Source-Softwareabhängigkeiten Dritter zu mindern. Wir danken unseren Entwicklern und Mitarbeitern. Zeigen Sie Ihre Wertschätzung, indem Sie uns einen :star: geben, wenn Ihnen unsere Arbeit gefällt.
Gründungsmitglieder:
* Ashish Bijlani
* Devdutt Patnaik
* Ajinkya Rajput
Wir heißen Code-Beiträge mit offenen Armen willkommen. Siehe die [CONTRIBUTING.md](https://github.com/ossillate-inc/packj/blob/HEAD/CONTRIBUTING.md)-Richtlinien. Einen Fehler gefunden? Bitte öffnen Sie ein Issue. Siehe unsere [SECURITY.md](https://github.com/ossillate-inc/packj/blob/HEAD/SECURITY.md)-Richtlinien, um ein Sicherheitsproblem zu melden.
# FAQ #
<details>
<summary><b>Welche Paketmanager (Registries) werden unterstützt?</b></summary>
Packj kann derzeit NPM-, PyPI- und RubyGems-Pakete auf „riskante“ Attribute überprüfen. Wir erweitern die Unterstützung um Rust.
</details>
<details>
<summary><b>Welche Techniken setzt Packj ein, um riskante/bösartige Pakete zu erkennen?</b></summary>
Packj verwendet statische Codeanalyse, dynamische Ablaufverfolgung und Metadatenanalyse für eine umfassende Prüfung. Statische Analyse allein reicht nicht aus, um anspruchsvolle Malware zu erkennen, die sich durch Code-Verschleierung besser verstecken kann. Dynamische Analyse wird durchgeführt, indem das Paket unter `strace` installiert und sein Laufzeitverhalten überwacht wird. Lesen Sie mehr in der [Audit README](https://github.com/ossillate-inc/packj/blob/main/packj/audit/README.md).
</details>
<details>
<summary><b>Funktioniert es bei verschleierten Aufrufen? Zum Beispiel ein Base64-verschlüsselter String, der entschlüsselt und dann an eine Shell übergeben wird?</b></summary>Dies ist ein sehr häufiges böswilliges Verhalten. Packj erkennt sowohl Code-Verschleierung als auch das Ausführen von Shell-Befehlen (exec-Systemaufruf). Zum Beispiel kann Packj die Verwendung von `getattr()` und `eval()` API kennzeichnen, da sie auf "Laufzeitcodegenerierung" hinweisen; ein Entwickler kann dann einen genaueren Blick darauf werfen. Siehe [main.py](https://github.com/ossillate-inc/packj/blob/main/packj/audit/main.py#L512) für Details.
</details>