Ist das AUR sicher? So prüfen Sie jedes PKGBUILD

Ist das AUR sicher? Die kurze Antwort

Das AUR (Arch User Repository) ist nur so sicher wie das PKGBUILD, das Sie vor dem Bauen gelesen haben. Die Pakete laden Benutzer hoch. Im Juli 2025 lagen dort drei Pakete mit einem Trojaner für den Fernzugriff, bis das Arch-Team sie nach zwei Tagen entfernte. Im Juni 2026 meldete Arch dann sehr viele bösartige Übernahmen und Updates bestehender Pakete. Die Prüfung ist also Ihre Aufgabe. Sie gilt für jedes Update und nicht nur für die erste Installation.

Dieser Beitrag ist für Ihren eigenen Desktop oder Entwicklerrechner mit Arch Linux gedacht. Ein typischer Zeitpunkt ist der Moment direkt nach der Grundinstallation, wenn das erste yay -S ansteht. Alle Befehle führen Sie selbst auf diesem Rechner aus. Sie brauchen dafür Netzwerkzugriff auf aur.archlinux.org.

Was im AUR liegt und was pacman damit macht

Die offiziellen Repositories liefern fertige Pakete. Das AUR liefert etwas anderes: pro Paket ein Git-Repository mit einem PKGBUILD und manchmal weiteren Dateien. Ein PKGBUILD ist eine Bauanleitung. Das Handbuch PKGBUILD(5) beschreibt den Ablauf in einem Satz: Das Paket wird mit makepkg gebaut und mit pacman installiert.

Daraus folgt etwas Wichtiges. pacman kennt AUR-Pakete nicht. Für pacman ist ein selbst gebautes Paket eine lokale Datei, die Sie mit pacman -U installiert haben. Helfer wie yay und paru erledigen das Klonen, Bauen und Installieren automatisch. Geprüft ist ein AUR-Paket dadurch aber nicht. Es ist nur schneller installiert.

Juli 2025: drei Browser-Pakete mit Trojaner

Am 18. Juli 2025 schickte Quentin Michaud eine Sicherheitsmeldung an die Mailingliste aur-general. Der Betreff lautet „[SECURITY] firefox-patch-bin, librewolf-fix-bin and zen-browser-patched-bin AUR packages contain malware“. Sie können die Meldung im Archiv der Mailingliste nachlesen.

Laut der Meldung wurde das erste Paket am 16. Juli hochgeladen. Zwei weitere Pakete desselben Benutzers folgten wenige Stunden später. Die Pakete installierten ein Skript aus einem GitHub-Repository. Die Meldung stuft dieses Skript als „Remote Access Trojan (RAT)“ ein, also als Programm, mit dem ein Fremder den Rechner aus der Ferne steuern kann. Am 18. Juli entfernte Arch die Pakete. Wer sie installiert hatte, sollte sie entfernen und das System auf eine Kompromittierung prüfen. Die Meldung nennt genau diese drei Pakete und keine weiteren.

Zwei Lehren stecken in diesem Vorfall. Die Pakete waren vom 16. bis zum 18. Juli abrufbar. Wer sie in dieser Zeit installiert hat, hatte den Trojaner auf dem Rechner, bevor jemand gewarnt hat. Auf eine Kontrolle vor der Veröffentlichung können Sie sich also nicht verlassen. Außerdem klangen die Namen nach bekannter Software. Ein Name wie firefox-patch-bin sagt nichts darüber aus, wer das Paket gebaut hat und was es herunterlädt.

Juni 2026: Ein vertrautes Paket kann den Besitzer wechseln

Am 12. Juni 2026 veröffentlichte Campbell Jones auf archlinux.org die Meldung „Active AUR malicious packages incident“. Sie berichtet von „a high volume of malicious package adoptions and updates“, also von sehr vielen bösartigen Übernahmen und Updates von Paketen. Das Team suchte nach vorhandenen bösartigen Commits und versuchte, neue zu verhindern. Bis zu einer dauerhaften Lösung warnte die Meldung vor Einschränkungen beim Anlegen neuer AUR-Konten, beim Hochladen von Updates und beim Übernehmen oder Anlegen von Paketen. Paketnamen nennt die Meldung nicht.

Der Rat an die Benutzer war deutlich. Lesen Sie vor jedem Update alle Änderungen an PKGBUILD und Install-Skripten, gerade jetzt. Verdächtige Commits in einem Paket, das Sie nutzen, melden Sie über die Mailingliste aur-general an das Arch-Team.

Der Unterschied zu 2025 ist entscheidend. 2025 ging es um neue Pakete mit neuen Namen. 2026 ging es auch um Übernahmen und Updates. Ein Paket, das Sie vor einem Jahr sorgfältig geprüft haben, kann mit dem nächsten Update anderen Code enthalten. Ihre Prüfung bei der ersten Installation schützt Sie deshalb nicht beim zehnten Update.

Wo der Code eines AUR-Pakets tatsächlich läuft

Bevor Sie ein PKGBUILD lesen, sollten Sie wissen, welcher Teil wann und mit welchen Rechten läuft. Es gibt zwei Stellen.

Die erste Stelle ist der Bau. makepkg liest das PKGBUILD als Bash-Skript ein und führt die Funktionen darin aus, etwa prepare(), build() und package(). Code, der außerhalb dieser Funktionen steht, läuft schon beim Einlesen. makepkg verweigert den Start als root. Das Handbuch makepkg(8) nennt dafür den Exit-Code 10 mit der Beschreibung „User attempted to run makepkg as root.“ Der Bau läuft also mit Ihrem normalen Benutzer.

Das klingt harmlos, ist es aber nicht. Ihr normaler Benutzer kann Ihr ganzes Home-Verzeichnis lesen, mit SSH-Schlüsseln, Browser-Profilen und gespeicherten Zugangsdaten. Ein curl ... | sh in build() läuft mit genau diesen Rechten. Auch makepkg -o ist kein reiner Download. Laut Handbuch lädt es die Quellen herunter, entpackt sie und führt prepare() aus.

Die zweite Stelle ist die Installation. Ein PKGBUILD kann mit der Variable install ein Install-Skript angeben, meist eine Datei mit der Endung .install. Laut PKGBUILD(5) kann pacman ein solches Skript zum Paket speichern und beim Installieren, Aktualisieren oder Entfernen ausführen. Die Funktionen darin heißen pre_install, post_install, pre_upgrade, post_upgrade, pre_remove und post_remove. Sie installieren mit sudo pacman, also laufen diese Funktionen als root. Ein schädliches post_install hat damit vollen Zugriff auf das ganze System.

Die Paketseite lesen, bevor Sie klonen

Jedes AUR-Paket hat eine eigene Seite auf aur.archlinux.org. Sie ist der erste Filter. Achten Sie dort auf diese Punkte:

• Wer pflegt das Paket? Ein Konto, das seit Jahren viele Pakete pflegt, ist ein anderes Signal als ein Konto, das Sie nirgends sonst finden.
• Wann kam das letzte Update? Ein Update von gestern ist nicht verdächtig. Aber genau dieses Update lesen Sie besonders genau.
• Wie viele Stimmen und wie viel Beliebtheit zeigt die Seite? Viele Stimmen bedeuten, dass viele Menschen das Paket nutzen. Sie bedeuten nicht, dass jemand die letzte Änderung gelesen hat.
• Was steht in den neuesten Kommentaren? Dort schreiben Benutzer, wenn ihnen an einem Paket etwas auffällt.
• Hat das Paket vor kurzem den Maintainer gewechselt, etwa weil jemand ein verwaistes Paket übernommen hat? Nach dem Vorfall vom Juni 2026 ist eine frische Übernahme ein Grund, das nächste Update Zeile für Zeile zu lesen.

Keine dieser Angaben beweist etwas. Ein Schadpaket kann einen bekannten Namen tragen. Ein Paket mit tausend Stimmen kann morgen übernommen werden. Die Paketseite sagt Ihnen, wie genau Sie lesen müssen. Das Lesen selbst ersetzt sie nicht.

Jedes AUR-Paket ist ein Git-Repository. Deshalb sehen Sie die Geschichte eines Pakets auch ohne Browser:

git clone https://aur.archlinux.org/paketname.git
cd paketname
git log --format='%h %an %ad %s' --date=short

Ein neuer Autorname in den letzten Commits kann bedeuten, dass jetzt jemand anderes das Paket ändert. Den Autornamen eines Commits kann allerdings jeder frei setzen. Er ist ein Hinweis und kein Beweis.

Ein PKGBUILD lesen: worauf Sie achten

Lesen Sie das PKGBUILD vollständig, bevor Sie irgendeinen makepkg-Befehl starten. Sehen Sie sich danach alle anderen Dateien im Verzeichnis an, etwa Patches, Startskripte oder eine .install-Datei.

less PKGBUILD
ls -la

Die source-Einträge

Laut PKGBUILD(5) ist source „an array of source files required to build the package“. Ein Eintrag ist eine URL, die makepkg herunterlädt, oder eine Datei im selben Verzeichnis wie das PKGBUILD. makepkg unterstützt auch Versionsverwaltung: Git, Mercurial, Subversion, Bazaar und Fossil.

Fragen Sie bei jeder URL: Zeigt sie auf die offizielle Projektseite oder auf die Release-Seite des Projekts? Oder zeigt sie auf ein fremdes GitHub-Konto, einen Dateihoster oder eine nackte IP-Adresse? Im Juli 2025 kam der Schadcode aus einem GitHub-Repository. Der Name GitHub allein ist also kein Qualitätsmerkmal. Entscheidend ist, wem das Repository gehört.

Bei einer Git-Quelle ohne festen Stand, also ohne #tag= oder #commit= am Ende der URL, baut makepkg den aktuellen Stand des Repositorys. Was Sie heute lesen, ist dann nicht unbedingt das, was morgen gebaut wird.

SKIP in den Prüfsummen

Zu jeder Quelle gehört eine Prüfsumme, zum Beispiel in sha256sums. PKGBUILD(5) sagt dazu: „If SKIP is put in the array in place of a normal hash, the integrity check for that source file will be skipped.“ Ein SKIP heißt also: Für diese Datei vergleicht makepkg keine Prüfsumme. Eine Signatur prüft makepkg trotzdem. Dateien in source mit der Endung .sig, .sign oder .asc erkennt makepkg laut Handbuch als PGP-Signaturen und verwendet sie automatisch, um die zugehörige Quelldatei zu prüfen.

Das ist nicht immer verdächtig. Das Beispiel im Handbuch selbst setzt SKIP bei einer Signaturdatei (.sig). Auch bei Git-Quellen ist es üblich, weil ein ausgecheckter Stand keine einzelne Datei mit fester Prüfsumme ist. Ein SKIP bei einem normalen Tarball oder einem fertigen Programm, zu dem keine Signatur in source steht, ist dagegen eine Frage, die Sie beantworten müssen, bevor Sie bauen.

curl, wget und Downloads in build() oder package()

Alles, was ein Paket herunterlädt, gehört in source. Nur dann prüft makepkg es gegen die Prüfsummen. Ein curl oder wget innerhalb einer Funktion umgeht diese Prüfung ganz. Ein schneller Suchlauf findet die auffälligsten Muster:

grep -nE 'curl|wget|base64|eval|\| *(ba)?sh' PKGBUILD *.install

Gibt es keine .install-Datei, meldet grep nur, dass diese Datei fehlt. Findet grep etwas, lesen Sie die Zeile im Zusammenhang. Ein curl ... | sh, eine lange Zeichenkette, die mit base64 -d dekodiert wird, oder ein eval auf heruntergeladenen Text sind Gründe, nicht zu bauen. Findet grep nichts, ist das Paket damit noch nicht sicher. Der Suchlauf ersetzt das Lesen nicht.

Pakete mit -bin im Namen

Bei einem Paket mit -bin im Namen erwarten Sie ein fertig gebautes Programm statt Quellcode. Prüfen Sie im PKGBUILD, ob das stimmt und woher das Programm kommt. Den eigentlichen Code können Sie hier nicht lesen. Sie vertrauen dem, der das Programm gebaut hat. Die einzige Frage, die Sie wirklich beantworten können, lautet deshalb: Kommt die Datei von der offiziellen Release-Seite des Projekts? Alle drei Schadpakete vom Juli 2025 endeten auf -bin.

validpgpkeys

Viele Projekte signieren ihre Releases. Ein PKGBUILD kann dann die Signatur in source aufnehmen und die erlaubten Schlüssel in validpgpkeys nennen. Laut PKGBUILD(5) akzeptiert makepkg dann nur Signaturen von den dort genannten Schlüsseln. Vergleichen Sie den Fingerabdruck mit dem, den das Projekt auf seiner eigenen Webseite veröffentlicht. Ein Fingerabdruck, den nur das PKGBUILD kennt, beweist wenig.

Das .install-Skript lesen

Das Install-Skript läuft als root. Darum lesen Sie es mit besonderer Sorgfalt.

grep -n '^install' PKGBUILD
cat ./*.install

Ein harmloses Install-Skript gibt meist einen Hinweis aus oder aktualisiert einen Cache. Ein Download, ein neuer systemd-Dienst, eine Änderung an /etc/sudoers oder an SSH-Schlüsseln hat in post_install oder post_upgrade nichts zu suchen. Sehen Sie so etwas, bauen Sie das Paket nicht.

Das erste Paket von Hand bauen

Bauen Sie Ihr erstes AUR-Paket ohne Helfer. Oft ist das erste Paket ohnehin der Helfer selbst, also yay oder paru. So lernen Sie jeden Schritt kennen, den ein Helfer später für Sie erledigt. Arbeiten Sie als normaler Benutzer, nicht als root.

sudo pacman -S --needed base-devel git
mkdir -p ~/aur && cd ~/aur
git clone https://aur.archlinux.org/paketname.git
cd paketname
less PKGBUILD
makepkg -s

makepkg -s installiert laut Handbuch fehlende Abhängigkeiten mit pacman. Das funktioniert nur für Abhängigkeiten aus den offiziellen Repositories. Hängt das Paket von einem anderen AUR-Paket ab, bauen Sie dieses vorher auf dieselbe Weise.

Lassen Sie -i absichtlich weg. Die Option -i installiert das Paket direkt nach dem Bau. Sie wollen sich das fertige Paket aber erst ansehen:

ls *.pkg.tar.zst
pacman -Qlp ./paketname-1.0-1-x86_64.pkg.tar.zst

Den genauen Dateinamen nehmen Sie aus der Ausgabe von ls. pacman -Qlp zeigt alle Dateien, die das Paket auf Ihr System legen würde. Eine Datei in /etc/systemd/system/ oder /usr/bin/, die nicht zum Programm passt, ist ein Warnzeichen. Passt alles, installieren Sie:

sudo pacman -U ./paketname-1.0-1-x86_64.pkg.tar.zst

Bei jedem Update: nur die Änderung lesen

Ein Update eines AUR-Pakets ist ein neuer Commit im Git-Repository. Sie müssen also nicht jedes Mal das ganze PKGBUILD neu lesen. Sie lesen nur, was sich geändert hat:

cd ~/aur/paketname
git fetch
git log -p HEAD..@{u}

git log -p HEAD..@{u} zeigt jeden neuen Commit mit seinen Änderungen. Ändert ein Update nur pkgver und die Prüfsumme, ist das ein normales Versions-Update. Eine neue Quell-URL, ein neues Install-Skript oder ein neuer Autor nach einer Übernahme verdienen dagegen Ihre volle Aufmerksamkeit. Erst wenn der Diff in Ordnung ist, übernehmen Sie ihn und bauen neu:

git merge --ff-only
makepkg -s

yay und paru: Wo die Prüfung im Helfer sitzt

Ein Helfer spart Ihnen das Klonen und Bauen. Die Prüfung nimmt er Ihnen nicht ab. Er kann Ihnen aber das PKGBUILD und den Diff zeigen. Welche Optionen es dafür gibt, hängt von der Version ab. Prüfen Sie deshalb zuerst Ihre Version und lesen Sie das passende Handbuch:

yay --version
man yay
paru --version
man paru

yay. Das Handbuch zu yay v13 (Stand v13.0.1) beschreibt zwei Optionen für die Prüfung. --diffmenu zeigt laut Handbuch „the diff menu. This menu gives you the option to view diffs from build files before building.“ --editmenu zeigt ein Menü, in dem Sie PKGBUILDs vor dem Bau ansehen oder bearbeiten können. Das Handbuch nennt keinen Standardwert für diese Optionen. Ob Ihr yay die Menüs zeigt, sehen Sie in Ihrer aktuellen Konfiguration oder bei Ihrem ersten Update. Sie können die Menüs auch für einen einzelnen Aufruf ausdrücklich anfordern:

yay -Pg | grep -i menu
yay -S --diffmenu --editmenu paketname

yay -Pg gibt die aktuelle Konfiguration aus. Mit yay -G paketname laden Sie nur das PKGBUILD herunter, ohne etwas zu bauen. yay v13.0.0 (Juni 2026) brachte außerdem eine Lua-Konfiguration in ~/.config/yay/init.lua mit Hooks wie AURPreInstall. In den Such- und Update-Menüs zeigt yay seitdem auch, wie lange die letzte Änderung am PKGBUILD her ist. Ein Hook kann zum Beispiel einen Bau abbrechen, wenn eine verbotene Quell-URL auftaucht. Der Autor von yay schreibt selbst, solche Prüfungen sollen das Lesen der Build-Dateien ergänzen und nicht ersetzen.

paru. Das Handbuch zu paru v2.1.0 nennt --review („Don't skip the review process.“) und --skipreview („Skip the review process.“). Mit --fm prüfen Sie PKGBUILDs in einem Dateimanager Ihrer Wahl. Auch hier nennt das Handbuch keinen Standardwert. Sehen Sie in ~/.config/paru/paru.conf nach, ob dort die Prüfung abgeschaltet wird. Im Zweifel rufen Sie paru ausdrücklich mit --review auf. Mit paru -Gp paketname geben Sie ein PKGBUILD im Terminal aus, statt es herunterzuladen.

Eine Regel gilt für beide Helfer: Wenn ein Menü einen Diff zeigt, lesen Sie ihn. Ein Helfer, bei dem Sie jede Abfrage mit Enter überspringen, ist nur ein schnellerer Weg zum ungeprüften Paket.

Welche AUR-Pakete habe ich installiert? pacman -Qm

pacman kann alle installierten Pakete auflisten, die in keiner Repository-Datenbank stehen. Das Handbuch pacman(8) beschreibt die Option -m (--foreign) so: „Restrict or filter output to packages that were not found in the sync database(s).“ Entscheidend ist also, ob eine eingebundene Repository-Datenbank den Paketnamen kennt, und nicht, woher das Paket kommt. Ein selbst gebautes AUR-Paket steht deshalb nur darin, solange kein Repository-Paket denselben Namen trägt. Haben Sie etwa ein offizielles Paket durch eine eigene Variante gleichen Namens ersetzt, fehlt diese Variante in der Liste.

pacman -Qm

Die Ausgabe ist Ihre eigene Liste, mit Name und Version jedes fremden Pakets. Pakete aus einem Repository, das Sie später aus /etc/pacman.conf entfernt haben, erscheinen hier ebenfalls. Gehen Sie die Liste regelmäßig durch. Jedes Paket darin ist eines, dessen Updates Sie selbst prüfen müssen. Ein Paket, das Sie nicht mehr brauchen, entfernen Sie besser.

Ob eines der drei Pakete vom Juli 2025 dabei ist, zeigt dieser Befehl:

pacman -Qm | grep -E '^(firefox-patch-bin|librewolf-fix-bin|zen-browser-patched-bin) '

Keine Ausgabe heißt: Keines der drei Pakete ist laut pacman installiert.

Was tun, wenn Sie ein gemeldetes Paket installiert haben?

Die Meldung vom Juli 2025 rät, die Pakete zu entfernen und das System auf eine Kompromittierung zu prüfen. Wir empfehlen mehr. Code aus einem AUR-Paket läuft beim Bau mit Ihren Benutzerrechten und über ein Install-Skript sogar als root. Was er nachgeladen hat, steht in keiner Paketliste. pacman -R entfernt nur die Dateien, die zum Paket gehören. Was ein Skript zusätzlich heruntergeladen und eingerichtet hat, bleibt liegen.

1. Trennen Sie den Rechner vom Netz.
2. Entfernen Sie das Paket mit sudo pacman -Rns paketname.
3. Gehen Sie davon aus, dass der Rechner kompromittiert ist. Ändern Sie von einem anderen, sauberen Gerät aus Ihre Passwörter, ziehen Sie SSH-Schlüssel und API-Tokens zurück und melden Sie offene Browser-Sitzungen ab.
4. Installieren Sie das System neu und spielen Sie Ihre Daten aus einer Sicherung von vor dem Installationsdatum zurück.

Schritt 4 ist unsere Empfehlung und nicht die von Arch. Ein Rechner, auf dem ein Fremder Code ausführen konnte, lässt sich nicht zuverlässig aufräumen. Eine Neuinstallation dauert meist weniger lange als die Suche nach der Antwort, ob Sie wirklich alles gefunden haben.

Was eine Prüfung nicht leisten kann

Seien Sie ehrlich zu sich selbst, was Ihre Prüfung abdeckt. Eine Prüfsumme beweist nur, dass Sie genau die Datei erhalten haben, die das PKGBUILD nennt. Nennt das PKGBUILD eine bösartige Datei, passt die Prüfsumme zur bösartigen Datei. Was Prüfsummen und Signaturen beweisen und was nicht, erklärt der Beitrag Downloads mit Prüfsummen und Signaturen prüfen.

Ihre Prüfung erkennt auch keinen kompromittierten Tarball des Projekts selbst. Wenn jemand das offizielle Release eines Projekts verändert, sieht das PKGBUILD völlig normal aus. Es zeigt auf die richtige Seite und auf die richtige Datei. Eine Signatur mit validpgpkeys hilft hier nur, solange der Schlüssel des Projekts nicht selbst gestohlen ist. Dieses Problem hat das AUR mit jedem anderen Paketsystem gemeinsam, das Code von Fremden lädt. Bei npm sieht es ähnlich aus, wie Supply-Chain-Angriffe über npm auf einem Server zeigen.

Zwei Gewohnheiten senken das Risiko trotzdem deutlich. Halten Sie die Liste aus pacman -Qm kurz, denn jedes Paket darin müssen Sie selbst prüfen. Und führen Sie Werkzeuge, denen Sie wenig vertrauen, nicht auf dem Rechner mit Ihren Schlüsseln aus. Eine Wegwerf-VM ist dafür der bessere Ort, so wie bei Coding-Agenten in einer Wegwerf-VM. Für Omarchy, einen Desktop auf Basis von Arch, gelten beim AUR dieselben Regeln. Hakt dort das Update der offiziellen Pakete, hilft Keyring-Fehler beim Omarchy-Update beheben.

FAQ

Ist ein AUR-Paket mit vielen Stimmen sicher?

Nicht automatisch. Viele Stimmen zeigen, dass viele Menschen das Paket nutzen. Sie zeigen nicht, dass jemand die letzte Änderung gelesen hat. Die Arch-Meldung vom 12. Juni 2026 berichtet von sehr vielen bösartigen Übernahmen und Updates. Ein beliebtes Paket kann also mit einem einzigen Update gefährlich werden. Lesen Sie vor jedem Update den Diff mit git log -p HEAD..@{u} oder im Diff-Menü Ihres Helfers.

Prüfen yay und paru die AUR-Pakete für mich?

Nein. Beide Helfer können Ihnen das PKGBUILD und den Diff zeigen, aber lesen müssen Sie selbst. In yay v13 heißen die Optionen --diffmenu und --editmenu, in paru v2.1.0 --review und --skipreview. Die Handbücher nennen keine Standardwerte. Prüfen Sie deshalb mit yay -Pg oder in ~/.config/paru/paru.conf, wie Ihr Helfer eingestellt ist.

Wie sehe ich, welche AUR-Pakete auf meinem Rechner installiert sind?

Führen Sie pacman -Qm aus. Die Option -m zeigt alle installierten Pakete, die pacman in keiner Paketdatenbank der Repositories findet. Darunter sind Ihre selbst gebauten AUR-Pakete, sofern kein Repository-Paket denselben Namen trägt, und Pakete aus Repositories, die Sie nicht mehr eingebunden haben. Für jedes Paket in dieser Liste sind Sie selbst für die Prüfung der Updates zuständig.

Ich hatte firefox-patch-bin, librewolf-fix-bin oder zen-browser-patched-bin installiert. Was nun?

Diese drei Pakete nennt die aur-general-Meldung vom 18. Juli 2025 als Träger eines Trojaners für den Fernzugriff. Trennen Sie den Rechner vom Netz und entfernen Sie das Paket mit sudo pacman -Rns. Ändern Sie dann von einem sauberen Gerät aus Ihre Passwörter und ziehen Sie SSH-Schlüssel und Tokens zurück. Arch rät, das System auf eine Kompromittierung zu prüfen. Wir empfehlen zusätzlich eine Neuinstallation mit Daten aus einer Sicherung von vor der Installation, weil sich nachgeladene Schadsoftware nicht zuverlässig finden lässt.