LBE o.ä. für JellyBean

[bitstopfen]

warum führen wir die Diskussion nicht einfach sachlich?

Fakt ist doch... als Entwickler hast du mit einer App, die ROOT-Rechte benötigt leichtes Spiel. Was jeder draus macht oder nicht ist kaum abzusehen. Die einen lächeln darüber, was oder was nicht mit den Daten passiert, die anderen akzeptieren es zähneknirschend und dann gibt es noch diejenigen, die es hinterfragen - und das sind WIR alle doch irgendwie

Das Argument ist unsinnig, da Apps kein gerootetes System brauchen, um an Rechte zum SMS versenden, telefonieren etc. zu kommen. Eher im Gegenteil der User braucht Root, um die Rechte wieder zu nehmen. Das versuchen wir hier in dem Thread die ganze Zeit zu erklären, ihr ignoriert nur diese Tatsache und sucht den einzig bösen Buben in LBE.

Tapatalk

 

[smosch]

warum führen wir die Diskussion nicht einfach sachlich?

Fakt ist doch... als Entwickler hast du mit einer App, die ROOT-Rechte benötigt leichtes Spiel. Was jeder draus macht oder nicht ist kaum abzusehen. Die einen lächeln darüber, was oder was nicht mit den Daten passiert, die anderen akzeptieren es zähneknirschend und dann gibt es noch diejenigen, die es hinterfragen - und das sind WIR alle doch irgendwie

wenn du solche bedenken hast, dann darfst du niemals eine "custom rom" installieren (die meiner nach die grösste bedrohung darstellt)!!! ebenso musst du unverzüglich follgende rootapplikationen deinstallieren: titanium backup, rom-manager, superuser, rootexplorer, droidwall, proxydroid, ... Ach, eigentlich solltest du gleich alles neu aufsetzen ... naja, eigentlich ist es jetzt ja eigentlich sowieso zu spät!

da gebe ich meinem vorredner recht und beim linux ip-table verfahren kann ich im protokoll einsehen was historisch passiert ist und kann durch das remounten auf r/w = r/o der protokolldatei das umschreiben re-remount blockieren.


BEI EINEM WLAN GERÄT WIE BEIM GALAXY TAB 8.9 P7310 / OHNE 3G IST ES ANHAND DER EXTERNEN FIREWALL 100% NACHWEISSBAR OB LBE NACHHAUSE TELEFONIERT!!!
... UND DA SPIELEN ROOTRECHTE KEINE ROLLE!!!

Durch die vergabe einer 128bit /256 bit verschlüsselung der protokolldatei der iptables sowie der aufnahme ganzer ip range blocks in der eigenen externen firewall die hinter dem dsl- router steckt ist 100% nachweissbar ob / wie & wann lbe nachhause telefoniert oder nicht!!! Und ich kann dieses gejammere nicht mehr hören und ausserdem hier noch ein netter bericht warum chinesische und indische developper nicht ihre apps bei google vergüten können:
Why Are India and China Excluded from Selling Paid Android Apps? - AndroidPIT

Achja, nochmal ein aspekt warum die app kostenlos ist und warum auch diese nicht in englisch übersetzt werden

 

[4ndr0]

wenn du solche bedenken hast, dann darfst du niemals eine "custom rom" installieren (die meiner nach die grösste bedrohung darstellt)!!!

Das musst du bitte genauer erklären. Bei einer etablierten Custom ROM, deren Quellcode offen liegt, gehe ich davon aus, dass sich genug erfahrene Programmier dem Quellcode angeschaut haben, zumal üblicherweise viele Menschen an der Entwicklung arbeiten. Bei Stock ROMs habe ich mehr Bedenken als bei FOSS Custom ROMs.

beim linux ip-table verfahren kann ich im protokoll einsehen was historisch passiert ist und kann durch das remounten auf r/w = r/o der protokolldatei das umschreiben re-remount blockieren

Verstehe nicht ganz, was du meinst. Erstmal kannst du nur ein Dateisystem remounten und nicht eine einzelne Datei und zweitens kann Root auch jederzeit Dateisysteme remounten. Also was meinst du? Erklärung bitte.

BEI EINEM WLAN GERÄT WIE BEIM GALAXY TAB 8.9 P7310 / OHNE 3G IST ES ANHAND DER EXTERNEN FIREWALL 100% NACHWEISSBAR OB LBE NACHHAUSE TELEFONIERT!!!
... UND DA SPIELEN ROOTRECHTE KEINE ROLLE!!!

Wer sagt dir, dass der Entwickler sich dieses Problems nicht bewusst ist, und seine App Daten nur über das mobile Netz versenden lässt? Um eben genau diesen Mitschnitt an einer externen Schnittschnelle zu verhindern?

Durch die vergabe einer 128bit /256 bit verschlüsselung der protokolldatei der iptables

Verstehe ich auch nicht. Was meinst du mit "vergabe einer 128bit /256 bit verschlüsselung"?

 

[bitstopfen]

Ein Quellcode der offen ist, bietet überhaupt keine Sicherheit mehr, dann kann jeder Angreifer sehen, wo die Schwächen sind.

Tapatalk

 

[4ndr0]

Du hast da einen Denkfehler drin.

Für jemanden, der genug kriminelle Energie besitzt, ist es sicherlich ertragsreicher, eine unfreie Anwendung zu disassemblieren und auf potentielle Schwachstellen zu untersuchen, als Lücken in einer FOSS App zu suchen, da diese viel schneller erkannt und gefixt werden

 

[bitstopfen]

Denkfehler? Das mit den USSD Codes wurde auch schnell erkannt? Wenn man bedenkt auf wieviel Geräten die Lücke seit Jahren vorhanden war? Nicht ein sinnvolles Argument kommt von euch.

Tapatalk

 

[4ndr0]

Ich mutmaße jetzt mal, ohne meine Aussage belegen zu können:

Der USSD-Bug ist gerätespezifisch und daher unterhalb der Betrachtung des ROMs an sich einzuordnen.

Und auch bei FOSS Custom ROMs muss ein solcher Bug erstmal gefunden werden. Das geht schneller als bei Stock ROMs.

Menschen, die moralische Grundsätze vertreten, neigen eher dazu, solche Bugs zu melden bzw. zu fixen, statt diese zu missbrauchen. Und darüber können wir froh sein.

Wie ist sonst der von Digitask programmierte "Staatstrojaner" zu erklären? Hier hat sich nur offenbar unterdurchschnittlich qualifiziertes Personal gefunden. Gut so. Siehe

Wer glaubwürdige "Security-Software" anbieten möchte, muss dessen Quellcode offen legen. Period.

 

[bitstopfen]

Wir reden von Millionen verkauften Einheiten, nicht nur Samsung war/ist betroffen.

Der Quellcode vom Staatstrojaner war nicht offen und OpenSource Software nimmt einen geringeren Stellenwert im Markt ein, wie du denkst. Sicherheitssoftware ist in den meisten Fällen nicht OpenSource.

Tapatalk

 

[Lauschebart]

Wenn man es genau nimmt, hätte man jahrelang unter Windows XP keine closed Source Software installieren dürfen. Da wurde auch alles als Admin ausgeführt.

@Smosch: Danke für den Artikel, das wusste ich noch nicht.

 

[M. Kuketz]

Eine lange Nacht und ein kurzer Morgen später:

PDroid Custom ROM Patch – Datenschutz für Android Teil3

Habe die Patch Anleitung fertig gestellt. Würde mich über Feedback freuen. Kritik ist auch immer gern willkommen. Falls etwas fehlt oder ich etwas übersehen habe.

Viel Spaß beim lesen.

 

[Lion13]

Liest sich gut; ich würde ggf. bei Punkt 4 (Patch einspielen) nicht nur die ClockworkMod-Recovery erwähnen, sondern generell von "Custom Recovery (z.B. CWM)". Es gibt ja auch Alternativen.

 

[Sunfire]

Ich hab nun nicht alle Seiten komplett gelesen. Aber es war schon sehr informativ...
Ich selber nutze den Appguard und muss sagen, dass dieser auch mit JB gut funktioniert.
Auch da gibt es sicherlich wieder Argumente warum ja bzw. warum nein.

Ich finds halt nur praktisch, dass ich bei einigen Apps halt sagen kann was sie dürfen und was nicht.
Anbei der Link:

SRT AppGuard | Backes SRT

Vllt. nutzt das ja auch der ein oder andere.
Bei mir lief es mit JB Leak und nun mit der SuperNexus Build 5 ohne Probleme.

 

[Dreamweaver]

Aber wir sind hier wieder auf einer sachlichen Ebene angelangt

Hab jetzt mein Test SGS3. Dann kanns ja los gehen...

Sent from my Samsung Galaxy S3 GT-I9300 with Android Revolution HD ROM using Tapatalk 2

 

[Lion13]

Bei SRT sehe ich aber auch als Nachteil, daß die Apps zuerst deinstalliert, dann gepatcht (!) und anschließend neu installiert werden - Updates über den PS gibt es so natürlich nicht.

Open Source ist die App natürlich auch nicht.

 

[Sunfire]

Da hast schon Recht mit Lion.
Aber die Apps, die ich zumindest habe alle soweit laufen, sehe ich für mich keinen Grund das upzudaten.
Falls es doch notwendig wird, muss ich halt ma schauen.

 

[BjoernT]

Also wenn SELinux wirklich ein Bestandteil von Android 4.2 wird... dann gilt der Satz eine App mit root rechten dürfe alles auch nicht mehr

Richtig konfiguriert, darf LBE eben selbst mit root rechten dann auch nicht mehr alles...

Wobei das auch nur etwas für Leute sein wird die etwas tiefer in der Materie stecken SELinux zu konfigurieren ist nicht wirklich einfache Kost da steht der Laie mal ganz schnell vor einem Lockscreen den er nur noch durch eine Neuinstallation aufbekommt

 

[Dreamweaver]

Eine lange Nacht und ein kurzer Morgen später:

PDroid Custom ROM Patch – Datenschutz für Android Teil3

Habe die Patch Anleitung fertig gestellt. Würde mich über Feedback freuen. Kritik ist auch immer gern willkommen. Falls etwas fehlt oder ich etwas übersehen habe.

Viel Spaß beim lesen.

Vielen Dank!

Ich hab mittlerweile ein Test-SGS3 und hab mir mal ein CM10 gepatcht und den Patch nach Installation des ROMS und der GAPPS laufen lassen. Läuft sehr gut. Nun müsste man nur noch grob wissen welche Einstellungen man Minimum setzen muss

Die Auto-Update Funktion von CM10 kann ich nun vergessen, da ich jedes neue Nightly mit der GUI neu patchen müsste, right?

PDroid ist ein wunderbares Tool, aber ist halt alles recht umständlich und verbrennt viel wertvolle Freizeit Aber für Paranoide genau das Richtige


PS: Ich hab die CM10 nightly vom 17.10. genommen und mit der gibts keine Probleme.

 

[4ndr0]

Die Auto-Update Funktion von CM10 kann ich nun vergessen, da ich jedes neue Nightly mit der GUI neu patchen müsste, right?

Richtig, jede neue ROM-Version muss vor dem Flashen gepatcht werden. Für die angepeilte Zielgruppe sollte das aber kein Problem darstellen.

Nun müsste man nur noch grob wissen welche Einstellungen man Minimum setzen muss

Grundsätzlich kannst du erstmal alles verbieten, was dir seltsam vorkommt und bei den entsprechenden Apps "Data Access Notification" aktivieren. Wenn dann irgendwas nicht mehr wie gewünscht funktioniert, kannst du Berechtigungen selektiv wieder aktivieren. Oder Random/Custom-Werte setzen

 

[Lauschebart]

Aus dem Artikel:

[...]Wer es auf einem Stock ROM zum laufen bekommen hat, der schreibe mir bitte eine E-Mail.[...]

Daran wäre ich auch interessiert.

 

[4ndr0]

Es wird nie mit einem reinen Stock-ROM funktionieren, da Stock ROMs odexed sind. What do “Odex” and “Deodex” mean? The All Inclusive Explanation | TalkAndroid.com

Aus dem PDroid XDA-Thread:

Will only work with deodexed ROMs (take a look into your ROM's system/framework directory; if there are any *.odex files, your ROM is NOT deodexed)

Der Aufwand, ein Stock ROM zu deodexen, ist höher als ein Custom ROM zu installieren. Das macht nur Sinn, wenn man unbedingt seinen Flash-Counter auf 0 belassen will.

Custom ROMs sind in der Regel pre-deodexed.