Ich habe ein Shell-Skript im Ressourcen-Ordner meiner Cocoa-App gespeichert. Bei unsachgemäßer Verwendung könnte es gefährlich sein (obwohl ich Vorsichtsmaßnahmen getroffen habe, um Exploits zu reduzieren, z. B. den absoluten Pfad zu Befehlen zu verwenden). Gibt es eine Möglichkeit, das Skript im Binärformat zu verschlüsseln und es dann zu entschlüsseln, wenn es benötigt wird?Ressourcen in der Cocoa App verschlüsseln?
Dank
Es scheint, als ob Sie sich Sorgen darum machen, dass Leute Schreibzugriff auf das Skript erhalten und es so modifizieren, dass es willkürlichen Code ausführt. Sie können eine Prüfsumme für das Skript in der Binärdatei speichern und diese mit der Prüfsumme des Skripts vergleichen, bevor Sie es ausführen. Nun, wie hältst du Leute davon ab, die Binärdatei zu bearbeiten? Codesignierung Wenn Sie das Shell-Skript im App-Bundle behalten, bricht die Bearbeitung des Scripts die Signatur des Bundles trotzdem ab.
Das ist eine brillante Idee und ich habe nie wirklich daran gedacht es. Ich werde Code-Signing versuchen. – indragie
Ich habe versucht, dieses Tutorial zu folgen: http://www.red-sweater.com/blog/514/development-phase-code-signing Es scheint jedoch keine Warnung zu erheben, wenn die App geändert wurde – indragie
siehe die Handbuchseiten für codesign und csreq, und Sie werden feststellen, dass Sie benutzerdefinierte Anforderungen und Optionen festlegen können. Wenn Sie die "harte" Flagge verwenden, stirbt die App, wenn ihre Unterschrift gebrochen ist. –
Nein, wenn der Benutzer sie es verwenden wird entschlüsseln, dann können sie (und Intercept), um den Klartext zu einem bestimmten Zeitpunkt sehen. Wenn Sie denken, dass Sie "Shell-like" Dinge zu tun haben, tun Sie sie in C/ObjC ... This kann Ihr Freund sein.
Was Sie fragen, ist im Wesentlichen DRM. Ein anderer Zweck ("Sicherheit" statt Urheberrechtsverletzung zu vereiteln), aber der gleiche Ansatz, mit den gleichen Problemen.
Damit der Benutzer das (Musik | Video | -Skript) normalerweise verwenden kann, muss er in der Lage sein, es zu entschlüsseln. Sie würden dies für Sie nur unter den richtigen Bedingungen in Ihrem Player (Player | App) tun, aber das ist egal: Egal, wie gut Sie es verbergen, Sie müssen dem Benutzer immer noch die gesamte Technologie und Schlüssel zum Entschlüsseln zur Verfügung stellen das (Musik | Video | Skript), damit dein (Player | App) das kann.
Und da der Benutzer alle notwendigen Technologien und Schlüssel hat, um sie zu entschlüsseln, kann ein Angreifer sie alle aufdecken und schließlich selbst entschlüsseln (Musik | Video | Skript).
Ich zweite Massa Vorschlag, von einem Shell-Skript zu wechseln. Dadurch wird das Risiko nicht vollständig eliminiert: Wenn ein Angreifer Zugriff auf das Schreiben in Ihr Shell-Skript erhält, kann er ebenso einfach auf eine Mach-O-Datei schreiben. Aber das Bearbeiten eines Mach-O-Programms ist nicht annähernd so einfach, also erhöhen Sie zumindest die Messlatte.
Ich denke PCWiz denkt über Angriffsvektoren wie "Lesen dieses Shell - Skripts und Ändern - zum Beispiel - awk für eine verwundbare Version von awk, jemand kann mein Programm veranlassen, zufälligen Code aus dem Internet auszuführen, ohne den Benutzer zuerst zu fragen usw . " – Massa
Ja, Massa hat Recht. Um es sicherer zu machen, habe ich absolute Pfade zu den Befehlen verwendet (damit die PATH-Variable nicht zum Ausführen von unerwünschtem Code verwendet werden kann), aber wenn ein Angreifer Schreibzugriff auf das Skript erhält, kann er dies leicht ändern. Ich werde den Compiler in Massas Link versuchen. Eine weitere Idee, die ich hatte, war das Speichern des Skripts als NSString in einer ObjC-App, dann das Schreiben des Skripts an einen temporären Speicherort, das Ausführen des Skripts und das anschließende Löschen des Skripts. Würde das funktionieren? Danke – indragie
Es scheint ein Problem mit dem ccsh Compiler zu geben, ich bekomme dies, wenn ich versuche, es online zu starten: Die angeforderte URL /pcgi-bin/ccsh.cgi wurde nicht auf diesem Server gefunden. – indragie
Das macht nicht viel Sinn. Wenn ein Angreifer Zugriff auf diese Skriptdatei hat, hat er wahrscheinlich Zugriff auf eine beliebige Anzahl von Dateien. Ihre Anwendung ist daher weniger wahrscheinlich ein Sicherheitsrisiko, als Angreifer tun könnten.
Ist nicht sinnvoll. Wenn ein "Angreifer" Ihre Skriptdatei bearbeiten könnte, könnte er genauso einfach Ihren ausführbaren Programmcode bearbeiten. Wie schützen Sie den ausführbaren Code Ihrer Anwendungen? – Jacob