mboost-dp1
oOAnriOo (1) skrev:Er en ordentlig emulator ikke usynlig for det hostede system?
Det skyldes vidst at android.os.Build.MODEL (String) fortæller at den er en emulator. Det kunne nemt rettes.
Men næste problem er at emulatoren af gode grunde ikke emulerer sensore i enheden, så dem kan man også måle på. Hvis der ikke er nogen sensore, er det højs sandsynligt en emulator.
(Her tager jeg udgangspunkt i den emulator der indgår i SDK'en, ved ikke hvor beslægtet den er med omtalte i nyheden)
Så længe bouncer tillader de analyserede applikationer at kommunikere med udviklerens server, så kan applikationen bruges til at analysere bouncer. Tillades det ikke, så kan manglen på adgang til serveren bruges til at afsløre om applikationen kører under bouncer således at malware først aktiveres ude ved brugerne.
Det er lidt af et dilemma. Googles bedste chance er at få bouncer til i højere grad at ligne en ægte Android. Google har udviklet begge, de burde være i stand til at få dem til at ligne hinanden.
Google burde også analysere hvad en applikation gør hvis enkelte branches i koden gør det modsatte af hvad koden siger. På den måde kan man potentielt afsløre hvis koden indeholder skjult funktionalitet som udvikleren kan aktivere senere.
Måske burde Google også have et team hvis eneste opgave er at finde huller i Androids sikkerhedsmodel.
Det er lidt af et dilemma. Googles bedste chance er at få bouncer til i højere grad at ligne en ægte Android. Google har udviklet begge, de burde være i stand til at få dem til at ligne hinanden.
Google burde også analysere hvad en applikation gør hvis enkelte branches i koden gør det modsatte af hvad koden siger. På den måde kan man potentielt afsløre hvis koden indeholder skjult funktionalitet som udvikleren kan aktivere senere.
Måske burde Google også have et team hvis eneste opgave er at finde huller i Androids sikkerhedsmodel.
Det kunne den da godt. Applikationen behøver ikke vide hvor sensordata oprindeligt kommer fra.ISCS (3) skrev:Men næste problem er at emulatoren af gode grunde ikke emulerer sensore i enheden, så dem kan man også måle på.
kasperd (5) skrev:Det kunne den da godt. Applikationen behøver ikke vide hvor sensordata oprindeligt kommer fra.
Ja, de kunne sagtens implementere det, under forudsætning af der så var realistiske, men tilfældige input på sensorerne.
Men der er gode grunde til at det ikke er implementeret i emulatoren endnu, nu har de så en grund at gøre det.
tormok (8) skrev:Ikke lige umiddelbart.
+1
Men jeg tror kblood påpeger at brugeren selv har et ansvar for at tjekke hvad app'en egentlig gør og beder om tilladelse til.
#7
Hvilket jeg tildels er enig i.
Det er bare ikke lige nemt for alle brugere at gennemskue, og Google's tiltag er en god ting for den almindelig bruger. Nyheden her handler så om at det
ISCS (9) skrev:Men jeg tror kblood påpeger at brugeren selv har et ansvar for at tjekke hvad app'en egentlig gør og beder om tilladelse til.
Tjah, hvis det virkeligt er malware, som det vi har set, der var rettet mod HTC telefoner, hvor apps med kun internet adgang kunne få adgang til alt igennem API'er, er det jo ikke muligt for en gennemsnitlig bruger at opdage det. Og permissionsne er underlige. Alle apps, der kører med reklamer skal have fuld internet adgang, og mange af dem skal have adgang til at læse telefon tilstand og ID, for at reagere på telefonopkald. Men ID er er IMEI nummeret. Så i og med at måske 80% af det, du installerer, har brug for de to permissions, er det jo svært at gennemskue om de bruger informationerne til noget, de ikke burde.
Brugernavn (10) skrev:Tjah, hvis det virkeligt er malware, som det vi har set, der var rettet mod HTC telefoner, hvor apps med kun internet adgang kunne få adgang til alt igennem API'er, er det jo ikke muligt for en gennemsnitlig bruger at opdage det. Og permissionsne er underlige. Alle apps, der kører med reklamer skal have fuld internet adgang, og mange af dem skal have adgang til at læse telefon tilstand og ID, for at reagere på telefonopkald. Men ID er er IMEI nummeret. Så i og med at måske 80% af det, du installerer, har brug for de to permissions, er det jo svært at gennemskue om de bruger informationerne til noget, de ikke burde.
Det var en fejl i det der CID eller hvad det nu hed.
Altså det spytool US mobiludbyderne brugte til at finde ud af hvad deres kunder brugte deres mobil til.
Det var svjh ikke noget HTC havde smidt på.
ISCS (3) skrev:Men næste problem er at emulatoren af gode grunde ikke emulerer sensore i enheden, så dem kan man også måle på. Hvis der ikke er nogen sensore, er det højs sandsynligt en emulator.
Det er ikke en god grund. BlackBerry Java PlugIn til Eclipse udvikling af BB-apps stiller en emulator til rådighed hvor man kan emulere mange sensorer.
Faktisk er BB emulatoren kolosalt mere avanceret end Android emulatoren. Og den er hurtigere ... indtil man trykker 'Debug'. Android emulatoren har jeg længe troet var det langsomste stykke software i historien, men ak nej! At få debugging sat i gang på BlackBerry er smertefuldt langsomt :'-(
Zigma (11) skrev:Det var en fejl i det der CID eller hvad det nu hed.
Altså det spytool US mobiludbyderne brugte til at finde ud af hvad deres kunder brugte deres mobil til.
Det var svjh ikke noget HTC havde smidt på.
Det var CIQ, og HTC der loggede data på telefonen, men det var et sikkerhedshul, HTC selv havde lavet, der gjorde det muligt at få adgang til informationerne.
http://www.xda-developers.com/android/remember-the...
Zigma (14) skrev:Jeg har aldrig haft HTCLogger på min HTC Desire.
Også derfor jeg skrev at det må være noget US noget.
Yep, men du skrev også at det ikke var HTC, der var skyld i problemet. Det var det. Og som der står i andre artikler om problemet, var det ikke alle HTC telefoner, der var berørt af det.
Men pointen er at man ikke som almindelig bruger har en levende chance for at identificere malware.
ISCS (9) skrev:Men jeg tror kblood påpeger at brugeren selv har et ansvar for at tjekke hvad app'en egentlig gør og beder om tilladelse til.
Et problem er at man ikke har ret mange muligheder når man finder en applikation som kræver for mange rettigheder. Man kan lade være med at installere den, men så længe det er så få der undlader at installere en applikation af den grund ændrer det ikke på udviklernes opførsel. Og man ser jo også tit at en applikation fra den ene version til den næste pludseligt vil have flere rettigheder. Hvorfor kan brugeren ikke fravælge enkelte rettigheder?Brugernavn (10) skrev:Og permissionsne er underlige.
Ville nu også være rart hvis man kunne nægte programmer permissions selv istedet for et "alt eller intet" system - altså uden at jailbreake systemet først.
kasperd (16) skrev:Og man ser jo også tit at en applikation fra den ene version til den næste pludseligt vil have flere rettigheder. Hvorfor kan brugeren ikke fravælge enkelte rettigheder?
Og hvorfor skal de være så brede at hvis appen skal se om man er igang med et telefonopkald, så skal den også have rettigheder til at læse IMEI nummeret? Og hvorfor er der ikke en app permission, til reklamer? Internet adgang er alt eller intet.
Brugernavn (18) skrev:Og hvorfor er der ikke en app permission, til reklamer? Internet adgang er alt eller intet.
Kunne ikke være mere ening, men ville det blive på bekostning af friheden? Hvis alle adtools skulle gå igennem et lukket API af en art? - Som det ser ud nu skelnes der jo ikke mellem reklamer og "alt" internet.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund