iOS -> Android = Switcher unter uns?

Wie willst du diese Technik im Binary blob finden? Und sag bitte nicht, es gibt magische Apple tools die das können. Oder wie sollen die Code Tools das können? Davon hab ich noch nie was gehört. Gibt es dafür vielleicht Quellen? Das einzige was ich finden konnte ist Static Code Analysis. Und die macht sowas nicht.
Und es geht nicht darum was hier verwendet wird. Es gibt nunmal Einsatzgebiete, wo diese Funktionen benötigt werden. Wie soll Apple da erkennen, dass ich es für eine böse Sache benutze?


Den gleichen Punkt kann ich übrigens auch umdrehen. Apples sinnlose Aussage, dass sie ja die Apps gründlich testen wiegt den User in falsche Sicherheit. Wie du selbst schreibst, geht der Exploit auch unter IOS.

Versteh mich bitte nicht falsch, ich hätte gerne das der Exploit auf allen Systemen gefixt wird, aber der Exploit befindet sich auf allen Systemen die ein paar Bedingungen erfüllen. Vor ein paar Jahren wurde der Exploit auch unter Windows gesehen und könnte gut unter anderen Systemen möglich sein.
 
Ich würde es mal mit nm oder otool probieren, zum Beispiel. Zudem führt undokumentiertes iOS-App-Verhalten zum Rauswurf.

Das Problem ist, daß Android behauptet, der User könne mit den Permissions bestimmen, was die App darf. Das funktioniert nicht. Andere Plattformen behaupten so etwas nicht und sichern Apps auf andere Weise gegen unerwünschtes Verhalten; so ist Android-3rd-Party-Apps dynamisches Code-Nachladen erlaubt (dynamische Libraries), iOS-3rd-Party-Apps nicht.
 
Entweder verstehe ich was nicht oder du liegst falsch.
Beispiel:
Ich baue eine App, die sich für das URL Schema foo:// registriert, die einen Browser aufruft und sonst ganz normale nützliche Dinge macht. Das erzähl ich auch Apple und wie du selber schreibst, funktioniert es alles. Nachdem ich das unauffällig in nützliche Funktionen gepackt hab, hab ich im Code eine Datumsschranke, die den Exploit erst nach 3 Monaten auslöst. Dann schalt ich auch meinen Webserver um und bumm. Jetzt bin ich auf dem System. Apple kann nicht nachschauen wie mein Code aussieht. Sie können höchstens Symbole anschauen, die ich einfach harmlos benenne.

Was du von Dynamic Libraries erzählst, verstehe ich nicht wirklich. Es ist egal wo mein Code steckt, ob in einer .dll, .so oder in der App selber. Wenn ich ganz sicher sein will, dann hol ich mir den Code von meinem Webserver (über den oben genannten Exploit), speicher ihn als Text und interpretiere ihn.

Und wie schon gesagt, Apple behauptet, dass alle Anwendungen die in den Store kommen "secure" sind. Oben ist das Gegenbeispiel.

Ich verstehe wirklich nicht mehr so ganz wo dein Problem mit meinen Argumenten besteht.
 
Für Drittsoftware gilt bei iOS: Es sind für iOS-Apps nur statische Libraries, keine dynamischen möglich und erlaubt. Dynamische Libraries können das Verhalten der App nach der Auslieferung verändern, indem veränderte Versionen der Library geladen werden. Statische können das nicht. Apple unterbindet nachträgliche Verhaltensänderungen an Apps durch Richtilinien und technisch. Google tut das mit Android nicht.
Wenn Du Apple erzählst, Deine App würde interpretierten Code von Deiner Webseite in Deine App laden, dann kommt die nicht in den AppStore. Die Nutzung von APIs zum Nachladen oder Interpretieren von Code wirst Du auch kaum verstecken können, unter anderem weil sie vor dem Upload der App von den Apple Tools auf Deinem Rechner geprüft wird. Und auch nach dem Upload vor dem Freischalten.
 
Rede ich eigentlich gegen eine Wand?
Du hast von merkwürdigen Dynamic Libraries erzählt, nicht ich. Ich weiß auch nicht, was die plötzlich mit dem Exploit zu tun haben.

Das erzähle ich Apple aber nicht. Ich erzähle ich muss die Seite aus irgendwelchen anderen Gründen laden. Und APIs zum nachladen oder ausführen von Code brauch ich auch nicht. Ich bekomme meine Daten durch den Url handler. Die parse ich einfach mit Standard String Funktionen und mach dann ein großes Switch Statement, was ich damit mache. Alles was auffällige Funktionen sind mache ich einfach selber.
Apple bekommt davon nichts mit, weil ich erstens meine Symbolnamen verschleiere (einfach) und sie nicht in den Sourcecode schauen können.
 
Und Du meinst, der Code in dem Switch-Statement entgeht der Code-Analyse?
 
Ja tut es: nm zeigt nur symbole an und otool nur anderes Zeug, was nicht mit der Funktion vom Code zu tun hat. Glaubst du Apple hat ein Tool, was beliebigen Code mit einer gewünschten Funktionsweise vergleicht? Wenn ja, dann solltest du dich fragen warum, wir 1. keine Bugs haben, 2. der Herr Gödel nicht mit seinem Halteproblem vorbeikommt (die Reduktion ist ziemlich einfach), 3. warum ich noch nie davon gehört habe.

Weil vielleicht nicht jeder das Halteproblem kennt: Das was du vorschlägst ist ähnlich dem Problem, was bewiesenermaßen von einer Turing Maschine nicht gelöst werden kann. Die weit verbreitete These ist, dass Turing Maschinen gleich mächtig wie jede Programmiersprache ist.
Du scheinst die Mächtigkeit von Statischer Code Analyse etwas zu überschätzen.
 
Mal davon abgesehen, dass die ganze Diskussion davon ausgeht das ein Programm bei gleichen Eingabe-Parameter die gleiche Ausgabe (das gleiche Verhalten) generiert. Kommt ein externer Webserver ins Spiel, der beim Review der App ein anderes Verhalten als später zeigt, ist die ganze Code-Analyse zum Teufel...

Daten sind Code, Code sind Daten

Denk mal drüber nach. Ich kann meine ganze iPhone GUI als XML vom Webserver ziehen. Oder eben erst drei Monate später. Ich kann auch ne ganze Virtuelle Maschine im Code verstecken, die wird nie gefunden.

Das einzige was Apple macht ist nachschauen ob jemand im Addressbuch liest und schreibt, welche Netzwerk API benutzt wird usw.

Code verstecken kann man ohne Ende...

EDIT: Nicht als Code im binären Sinn, sondern als nachträglich hinzugefügte Funktionalität.
 
Zuletzt bearbeitet:
Russel-Athletic, sobald Du verbotene APIs (die mit den unwerwünschten Funktionen) verwendest, fällt das auf. Was willst du also tun in Deiner App-Sandbox?

pmau, bei iOS-Apps darfst Du keine Funktionalität vom Webserver abhängig machen. Die Eigenschaften der App dürfen sich nicht ändern lassen von außen.
 
Zuletzt bearbeitet:
Redet ja keiner von verbotenen API's. Wir reden von Sicherheitslücken.

Addressbuch kopieren und auf 'nem Server mit anderen Personen abgleichen.
GPS Tracking, nachdem der Benutzer einmal wegen einer "legitimen" Funktionalität zugestimmt hat.
Photos aus der Camera Roll lesen und übers Netz pusten, kann man als Login Vorgang tarnen.
Da fallen mir tausend Sachen ein.

Es gibt kein Protokoll darüber was eine App wirklich tut. Nur weil der Netzindikator angeht oder der Ortungspfeil in den
Settings zu sehen ist heisst das noch lange nichts.
 
MacMark: Genau, deshalb ist diese Funktionalität ja aus, bis der App Review durch ist.
Ich mach eine App mit Anmeldung. Die macht alles ganz normal. Nichts ist auffällig.
Dann, wenn sie im Store ist sendet mein Server eine andere Antwort, die dazu führt dass die App GPS Daten an den Server liefert. Oder das Addressbuch koppiert fertig.

Das ganze verstecke ich dann auch beim LOgin und sage nach 30 Sekunden: Login fehlgeschlagen. Timeout.
Damit es nicht auffällt. Fertig. Solange keiner mein HTTPS entschlüsselt bin ich damit aus dem Schneider...
 
Ok hier mein letzter Beitrag dazu. Android verbietet APIs auszuführen, die nicht im Manifest stehen. Ob ich mir jetzt eine beliebige Berechtigung hole weil ich sie in dem Manifest schreibe oder weil ich Apple anlüge was ich mit der API anstelle, kommt auf das gleiche raus.

Ich darf keine Funktionalität vom Webserver abhängig machen. Hä? Wir haben gerade festgestellt, dass wir unerlaubte Kommunikation mit einem Webserver auf beiden OS hinbekommen. Eine Kommunikation die Apple nicht feststellen kann. Dann haben wir festgestellt, dass wir unsere Programmverhalten von dem Webserver beeinflussen lassen können. Wenn du das nicht glaubst, dann kann ich dir auch nicht mehr helfen.

Weil das ohne hin nichts mehr bringt und alle andere Leute sowieso genervt sind, ist das mein letzter Beitrag zu dieser Diskussion.
 
Russel-Athletic schrieb:
Dann haben wir festgestellt, dass wir unsere Programmverhalten von dem Webserver beeinflussen lassen können. Wenn du das nicht glaubst, dann kann ich dir auch nicht mehr helfen.
Zum Vergrößern anklicken....

Häh??? Warst Du nicht der, der meine man kann keinen Code verstecken und alles wird durch Apple's perfekte Analyse gefunden?
Ich muss zurückblättern....

Natürlich kann man, und zwar überall. Android, iOS, Windows, Mac OSX, wo Du willst...

EDIT: Absolut Sorry. Ich meinte MacMark. Das war Bullshit. Gute Nacht.
 
Zuletzt bearbeitet:
pmau, das macht Deine App einmal und sie ist raus. Sowas gab es schon. Als registrierter Entwickler kennt Apple Dich. Und Apple weiß auch, "wo Dein Haus wohnt". Du hast also mit Konsequenzen zu rechnen. Auf die Weise kann Apple dafür sorgen, daß das keiner (zweimal) tut.

Bei Android kannst Du Apps mit selbstsigniertem Zertifikat verbreiten und dadurch Deine Identität verschleiern. Google schaut auch nicht nach, was die App macht. Google wälzt das auf den User ab: Die App zeigt Dir, was sie machen will (Permissions) und Du verläßt Dich darauf, daß sie nichts ohne passende Permissions tun kann. Das ist jedoch falsch. Und damit ist die damit propagierte Sicherheit von Android für die Katz: http://www.macmark.de/android.php#example_exploit Android läßt diverse Wege zu, die Permissions by design zu umgehen und zwar ganz und gar völlig ohne Sicherheitslücken.

Und böse Features kannst Du bei Android viel besser verstecken als bei iOS, weil Android-Apps nämlich völlig legal und ganz offiziell Code nachladen dürfen. iOS-Apps dürfen/können das nicht.

Russel-Athletic, natürlich kann Apple Kommunikation einer App mit einem Webserver feststellen. Wie willst Du das verstecken vor der Code-Analyse?
 
Zuletzt bearbeitet:
Das ist aber jetzt kein technisches Argument ... Das Google nur an der Verbreitung ihrer Plattform interessiert ist und nicht an der Qualität ist mir zumindest klar. Übrigens bin ich mir sicher, dass ich es trotzdem gut verstecken kann, ohne dass sich jemand beschwert.

Das Apple mich als Entwickler dafür zur Verantwortuzng ziehen kann, ist mir klar.

Es ging aber um:

a) Den Code Review um in den Store zu kommen.
b) Die technischen möglichkeiten Schadcode einzufügen.

(Die auf allen Plattformen vorhanden sind)
 
Der Weg von Apple ist wirksamer gegen Malware als der Weg von Google: Review, Ausklammerung von vielen Malware-tauglichen APIs, Konsequenzen für Übeltäter. Alles drei Sachen, die Google nicht bietet. Bei Google hingegen ist man als User selbst schuld und kann sich nicht mal auf die dokumentierten Features (Permissions) einer App verlassen.
 
Ich bin am überlegen, ob ich auf das iPhone 5 warte, was sicher geil werden wird, aber leider noch hin ist. Oder Galaxy 3, wobei ich nicht so der Android fan bin.

Frage: Bei Android wird vor dem App installieren ja immer gefragt, auf was alles zu gegriffen werden darf, soweit ich weiß ist das bei iOS nicht der Fall. Aber heißt das nun, dass iOS alle Berechtigungen gibt, oder gar keine?

Was ich gerade gelesen habe ist, dass es bei iOS und WP7 keine Viren usw gibt, das ist ein Plus Punkt.
 
Bei iOS blockiert das System standardmäßig recht viel. Unter anderem kommt vom iOS System eine Meldung wenn die App das erste mal auf GPS oder Adressbuch zugreifen will - man muss über das System dies dann explizit der App erlauben.

Ist es bei Android nicht eher so, das man beim installieren der App nur eine Info bekommt auf was diese alles Zugriff hat?
 
ja ist es, und man kann diese möglichkeiten auch nur umständlich den programmen verbieten. geht mir leider auch gegen den Strich. Gerade was ortungsdienste angeht
 
Hallo,
so, jetzt auch mein kleiner Beitrag…

Ich bin zwar noch kein Switcher, werd´s aber bald sein..
Ich hab im Augenblick ein iPhone 4 mit 32 GB, und wechsle in den nächsten 1 - 2 Monaten zum HTC One S..
Ich glaub, es gibt kein Video des HTC´s, das ich nicht schon gesehen hab…

Warum ich wechseln will: Ich hab im Augenblick einen T-Mobile Complete L Business Vertrag.. Für knappe 60 Euro im Monat. Den habe ich gekündigt, und wechsle zu Congstar (Datenflat für 10 Euro, und für 7 Euro die Flat ins Festnetz)..
Somit entfallen für mich die subventionierten iPhones von der Telekom. Ausserdem gefällst mir einfach, mal über den Tellerrand zu blicken..

Meine Sachen synce ich im Augenblick eh schon über Google (Adressbuch, Mails, Kalender). Somit sind es eh nur noch Musik und Videos. Das kann ich problemlos über "doubletwist" machen.

Und ich bin ehrlich: Ja, ich freu mich auf meinen Androiden. Ich kanns nicht genau beschreiben, warum.. Das iPhone ist perfekt.. Es läuft, es tut genau das, was es machen soll.. Aber es ist, finde ich, irgendwie langweilig.. (Ich glaube, weils so gut läuft) :)
Wenn ich mir hingegen die Oberfläche von HTC anschaue (Sense 4), dann finde ich das schon sehr beeindruckend….

Die meisten Apps hab ich im Play-Store gefunden, und die ich nicht gefunden hab, werd ich wahrscheinlich auch nicht vermissen… (Solar Walk)..

Ich werde mal berichten, wie´s so läuft (in ein paar Wochen)..

Viele Grüße
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten