Naja, neben der Manipulation auf Datei-Ebene gibt es da noch das Problem der Manipulation auf Verbindungsebene.
Manche „Internet-Security-Software“ überwacht sämtlichen Traffic, den der jeweilige Computer empfängt oder versendet.
Diese Software hat natürlich ein Problem, dass sie in verschlüsselte Datenströme (HTTPS, SMTPS, IMAPS, FTPS usw, alles, was TLS / SSL verwendet) nicht reinschauen kann, „an der Netzwerkkarte“ sieht man bei diesen Verbindungen abgesehen von den TCP/IP-Metadaten nur Rauschen in den Nutzdaten.
Was macht also die „Sicherheits-Software“? Sie installiert einen lokalen Netzwerk-Proxy, und leitet sämtlichen Traffic darüber.
Wird nun eine neue Verbindung aufgebaut, so startet dies zunächst unverschlüsselt, und mit dem Zielserver werden Schlüssel ausgetauscht, um dann in nächsten Schritten eine verschlüsselte Ende-zu-Ende-Verschlüsselung nutzen zu können (eben TLS => HTTPS usw.)
Der Proxy hängt nun quasi als „man in the middle“ dazwischen, nimmt die Anfrage von unserer App entgegen (kennt damit den lokalen Schlüssel-Anteil) und stellt nun selbst eine passende Anfrage an den Zielserver (mit seinem eigenen geheimen Schlüssel). Der Server antwortet mit seinem richtigen Schlüssel (SSL-Zertifikat), dieses wird vom Proxy empfangen und so abgeändert, das jetzt der Proxy der (gültige!) Zertifikatsaussteller ist, das Ergebnis bekommt unsere App.
Damit kann der Proxy also den Traffic (sowohl von der App als auch vom Server) entschlüsseln.
Problem: Das Zertifkat, welches der Proxy an unsere App herausgegeben hat, besitzt logischerweise eine andere Prüfsumme, als das Original-Zertifikat des echten Servers.
Software kann sich gegen diese Form des „Mitlauschens“ schützen, indem sie selbst diese Prüfsummen der Zertifikate speichert, und mit dem Zertifikat vergleicht, welches in der Praxis ausgeliefert wird (Stichworte: HTTP Public Key Pinning, https://de.wikipedia.org/wiki/HTTP_Public_Key_Pinning
oder auch TLS certificate pinning https://labs.nettitude.com/tutorials/tls-certificate-pinning-101/
)
Dann weiß die Anwendung immerhin „ey, hier lauscht jemand mit und manipuliert den Datenstrom!“ Ergebnis: Verbindung wird abgelehnt, da korumpiert.
Dies kann dann tatsächlich ein böser Angriff sein (zum Beispiel wenn man sich in einem öffentlichen WLAN bewegt und der Angreifer Deine Online-Verbindung zu Deiner Bank manipulieren will) es kann aber auch die von Dir selbst installierte „Internet-Security-Software“ sein, die da in Deinen Daten herumschnüffelt (mit Deiner ausdrücklichen Erlaubnis, selbstverständlich!)
Problem: Beim Deaktivieren von Virenscannern / Firewalls, die sowas machen, wird meist der Webproxy eben NICHT deaktiviert, da dazu in der Regel ein Computer-Neustart notwendig ist (mindestens jedoch ein „Neustart“ des gesamten Netzwerk-Stacks) und anschließend die meiste Software mit dem Problem konfrontiert ist, das sämtliche Webzertifikate auf einmal nicht mehr stimmen (alle aktiven gesicherten Browsersessions sind damit kaputt), was zu noch mehr Problemen und noch verwirrteren Kunden führt…
Also läuft der Web-Proxy einfach weiter, obwohl der Anwender auf „Firewall/Virenscanner deaktivieren“ geklickt hat. Es reicht ja, wenn sich der Button entsprechend anders färbt, das beruhigt die meisten Leute. Genaugenommen stimmt es ja auch, der Anwender hätte einfach nur den anderen Button, beschriftet mit „Internet-Security deaktivieren“ drücken müssen, aber meist gibt es diese Option garnicht…