Database Info

android malware prototype

Hi,guys, l want to implement a malware on android as my graduation paper, and now i am hard to think more good ideas, would you like to share your novel ideas with me ?
thank you very much!

How bout something useful, like gps logger, call log, browser history. Make an app/server side interface that can customize various parameters such as minutes between gps logs and upload server. Several small companies would love to trace their employees activities on company phones. Might even get you paid.
westwind1120 said:
Hi,guys, l want to implement a malware on android as my graduation paper, and now i am hard to think more good ideas, would you like to share your novel ideas with me ?
thank you very much!
Click to expand...
Click to collapse
Sent from my MB855 using XDA App

1) Build an android HTTP server that parses the user agent and serves a different browser exploit depending on what android version is on, if it's a miss, forward to the actual requested page, if it's a hit, go for it!
2) + Arpspoof
3) ???
4) Graduation
Or something that will overwrite the default CD .iso image in the device (the one that is mounted when you plug the phone on the pc) and make a modified version of that with something evil that will jump on the pc.
jk... so is it going to be some app or PoC or a paper explaining potentials of exploiting from/to Android (like Zimperium - Anti / Faceniff / Droidsheep)?
I made a malware-related graduation paper many years ago...

jokersax11 said:
How bout something useful, like gps logger, call log, browser history. Make an app/server side interface that can customize various parameters such as minutes between gps logs and upload server. Several small companies would love to trace their employees activities on company phones. Might even get you paid.
Sent from my MB855 using XDA App
Click to expand...
Click to collapse
As a matter of fact, i want to write a rootkit on android, but at moment, it is lack of some useful cases, so as above, i need some ideas.....i promise it is just for study not for profits

ell3 said:
1) Build an android HTTP server that parses the user agent and serves a different browser exploit depending on what android version is on, if it's a miss, forward to the actual requested page, if it's a hit, go for it!
2) + Arpspoof
3) ???
4) Graduation
Or something that will overwrite the default CD .iso image in the device (the one that is mounted when you plug the phone on the pc) and make a modified version of that with something evil that will jump on the pc.
jk... so is it going to be some app or PoC or a paper explaining potentials of exploiting from/to Android (like Zimperium - Anti / Faceniff / Droidsheep)?
I made a malware-related graduation paper many years ago...
Click to expand...
Click to collapse
oh, guy, i just want to do some security research on mobile phone,and i don't want to attack others, i am a student who love researching information security.Forgive my poor english

This is the kind of thing you need to learn about yourself. Knowledge is a dangerous thing, and those who know how to exploit Android aren't about to share that kind of knowledge here unless it is clearly as a part of how to PREVENT such exploits.

lotherius said:
This is the kind of thing you need to learn about yourself. Knowledge is a dangerous thing, and those who know how to exploit Android aren't about to share that kind of knowledge here unless it is clearly as a part of how to PREVENT such exploits.
Click to expand...
Click to collapse
thanks, my friend, i am also realize that it is a long way to study android,and i will do my best,thank you again

I would recommend start learning reversing android malware, As you progress you will know the tricks of the trade and you can write your own stuff.
I been doing some reversing for a while as part of my job, A simple idea would be to write a small piece of code which sends sms to preminum rate numbers with out users knowlege (there are loads of them already doing it)etc..Start with simple ones which does not have support for command and Control center (C&C).
Read more about exsiting malwares which are around and i am sure you can prototype the one you wish to start with.

Random off the top of my head something I'd probably consider playing with someday:
if running on rooted device: install a system app and whatever is necessary, to then attempt overclocking the CPU enough to make the device go ape . 5Ghz Optimus One anyone?
Sent from my Transformer TF101 using Tapatalk

Cydia Substrate — Native (or Java) Runtime Code Modification

Cydia Substrate is a code modification platform. It can modify the code of any major process, whether that code is written in Java or C/C++. It has been designed to support an ecosystem where many developers are interested in hooking the same processes. It is designed to be powerful and efficient.
== How do I get Substrate? ==
You can either download it from the Play Store or directly from its website.
== How do I develop for Substrate? ==
You download its SDK using the Android SDK manager or from its website. There is extensive documentation on the website.
== What is Substrate's website? ==
http://www.cydiasubstrate.com/
== How is this different from Xposed? ==
Many compare it with Xposed, but Xposed only supports a single use case: hooking Java functions inside of app_process. Substrate can hook native code, such as is required to modify the way styles are loaded inside of the Android asset manager. There are many other differences, however, as Substrate's API is based on five years of experience managing a community of runtime code modification for iOS. I normally avoid doing direct comparisons, but after attending Big Android BBQ and presenting on Substrate, I have been encouraged to make the differences and advantages of Substrate's approach more explicit here on XDA.
Xposed requires an inverted form of logic based on "before" or "after" hooks while Substrate lets the developer use more straightforward "replace and call previous" implementations. This also enables more complex interactions with the previous implementation that have been shown to be valuable among the thousands of developers using Substrate on other platforms. Xposed attempts to offer something similar with "replace" hooks, but those do not provide access to the previous implementation, and while Xposed provides a way to call the "original" implementation, that skips any other hooks that might be stacked.
Xposed requires the developer to find a safe moment to interact with the class being hooked. To make this possible, there are numerous lifecycle events such as "VM loaded", "package loaded", and "command line application started". However, this does not solve the problem that touching classes can change the order in which they statically initialize. This also means that it will not be possible to provide declarative syntax wrappers (such as Logos, which developers use on iOS) on top of Xposed, as this context will have to be made implicit in imperative logic. Substrate solves this class initialization problem by allowing developers to hook the classloader itself, getting a callback when a class is "linked" so that the developer can find a class loaded in any classloader (even as a plugin to an application an hour after that application starts, where the code is downloaded as a .dex from the Internet).
Xposed has a method hook implementation that makes it lose track of which method was hooked, requiring it to do a lookup every time such a method is called. This implementation is currently linear in the number of hooks, making it slow down the more hooks you install. Worse, there is a high constant multiplier on this algorithm, as the comparison between entries is very expensive (and was made more expensive when recently fixing a longstanding bug caused by this lookup being slightly incorrect). Substrate, in comparison, uses runtime code generation to avoid the need to every look anything up at runtime: you can use Substrate to hook small functions in tight loops without experiencing the same kind of performance issues you would see with Xposed.
Substrate is also designed with a different user focus: while it currently has a setup interface, it would prefer to not have any UI at all (and this will be strived for in subsequent versions, assuming anyone cares to use it). Upgrades to Substrate can be automatically installed by the Play Store and do not require the user to interact with Substrate for the changes to "stick". Substrate itself is distributed via Play. Rather than confine these kinds of modifications to advanced users who use forums such as XDA, the idea is that everyone should have access to using this kind of technology. If you have a ROM or another store in which you'd like to see Substrate distributed, I would be more than happy to talk to you about this to make that happen, and these installations will be fully supported.
For some more information on the differences between Xposed and Substrate (or if you are wondering why you should bother paying any attention to things that I say, as maybe you don't remember me from my earlier Android projects), I encourage you to read the comments I left a couple posts down from here on this thread that describe the history of Substrate, how I fit into the Android ecosystem, and more about how Substrate differs from Xposed. I will also likely be posting the talk I gave at Big Android BBQ (with either notes to go along with each slide or in the form of a video I will record re-giving the talk and advancing the slides), which might make some of these things more clear.

Current Changelog
[this is the changelog from Play, which has been compressed slightly. I will bring the more full changelog back, as I have it saved somewhere, and put it here or link it here]
v0.9.4011:
* fix decoder bug inside ARM emulator
* support Genymotion Intel emulator
* add symbol names for Moto X
v0.9.4010: critical Android 4.3 fix, avoid old Superuser bug
^^ must install before Android 4.3 OTA!
v0.9.4009: work around Xposed bug, 4.2 fix, better errors
v0.9.4008: HTC linker path patch, limit symbol exports
v0.9.4007: RAZR i 4.1.2, detect HTC override, avoid ps
v0.9.4005: incompatibility detector, avoid mount/ln/mkdir
v0.9.4004: Holo, Script Failure, detect physical /vendor

Comments from Developer
So, yeah: I'm the developer of Cydia Substrate, the framework everyone uses on iOS to do runtime code modification. Back in 2011, I gave a talk at Android Open along with a demo of Substrate running on Android 3.0. However, after some in-depth discussions with people there who were interested, I realized that what I had at the time "wasn't sufficient": it was just the core of an implementation, not an end-to-end offering. By the time it had everything I felt it needed to launch--including a comprehensive website filled with documentation, a configuration application to install with it, fully tested support for both ARM and x86, a forward-compatible pure Java API vetted by a bunch of the top people in the iOS modding community (as I feel like breaking APIs after launch is one of the more evil things a framework can do), and an extension that would make sense to end users that they could try (so that trade press wouldn't be horribly confused, as I knew they would report on the release)--it was already 2013.
http://www.youtube.com/watch?v=tA9cnemnQ0A <- Android Open 2011 keynote teaser
As many people then know, I released it in June. A lot of people have tried it (165k installs just from Play, and another 20k downloads of the APK off the site), and many of those people even like it enough to keep it installed and leave positive reviews, despite there being almost nothing available to use with it except WinterBoard (which I really only did as a demonstration). However, I also get comments from people who seem to believe I'm some kind of "interloper" in the world of Android. Additionally, there are the people who leave reviews saying stuff like "this is stupid, we already have Xposed" (sometimes then explicitly adding in the "go home to iOS" kind of spiel). The #1 complaint, however, is "nothing I can do with it", because developers never seem to talk about it or use it much, and the people installing it are all end users. Clearly this isn't the kind of reaction that I thought would happen, especially after having discussed Substrate at length with pulser_g2 before launch (who said that the community here tends to be very good about judging things on their usefulness and technical merits as opposed to having emotional attachments).
http://www.cydiasubstrate.com/ <- Cydia Substrate
Given this, and after an encouraging back/forth I had with some people on reddit's Android subreddit a few days ago in some threads about the analysis I did of that recent Android iMessage client (people who didn't know much about the ways in which Substrate is very different than Xposed in capability and focus), I figured I'd finally make a post on XDA. I kind of had been waiting to make this post as well, honestly (as again: I like things to be more perfect before I release them than maybe people are used to around here ;P), but it seems like I'm now waiting for something that is itself causing the delay (I had really expected to do this in July, before the whole thing got more actively depressing). This is clearly that post ;P. I've responded to a bunch of other threads here talking about Substrate (and the many other Android projects I've released) in the past, but this is the first time I've actually started a thread.
(In specific, Substrate currently doesn't support some Samsung devices due to a change they make to the linker paths, and I wanted to have 100% device coverage before making the inaugural XDA post. However, I'm finding it very demotivating to spend the time to think through all the options I've been considering for workarounds given the overall lackluster reaction to my work, so I'm not even making fast progress anymore: I tend to work on the things that people react positively to, and while I got a lot of positive reactions on the balance from users, I got much less than I expected from developers given how many people use Substrate on iOS and how powerful the framework is. I think, from some conversations I've had, this is largely due to confusion over how Substrate on Android relates to Xposed, which many people seem to think of as the "home-town competitor" "that does the same thing". I thereby figure that I may as well attempt to directly address that core motivation problem, to see if I should even bother continuing spending time helping out in this community, hence this ludicrously long and highly personal post about what is essentially a technical framework ;P.)
[Readers who find the next section boring should skip below to "=== Substrate ===".]
I imagine I (sadly) thereby need to start by defending my history in the Android community, as many people seem to not be aware of much of it; it actually goes back very far, as I had promised the overall mobile community that if Android were ever rooted, I'd immediately start looking at it in earnest (before there was a device, I had already been messing around with the emulator, but the device concepts Google had at the time were more like slightly souped-up feature phones, not competitors to something like an iPhone). So, in 2008, when that first "root console attached to keyboard" mistake was found on the G1 that let you get a root telnetd running by just typing it into any search field, I dropped everything and drove two hours to Los Angeles to pick up a G1 (they were not selling them in Santa Barbara yet, due to T-Mobile not really having a presence here at the time). As promised, I immediately set to work attempting to help out.
As I ran a number of mailing lists already for iOS, I set one up for Android called g1-hackers, which attracted a good number of people, and even a few Google employees who worked on bionic and the kernel. On this list is where the G1's bootloader was first dumped: if you've ever heard the stories about Eddie Dost figuring out how to do it, this is that. In fact, it was from my G1, with a kernel I compiled (following Eddie's direction: I did not know much about flash drivers), that that first Android NAND was obtained (as Eddie had already updated his device and thereby didn't actually have root). Here is a link to the mailing list thread, directly to the post where we finally succeeded and I provided the kernel image I used so that others could perform the same dump on their own devices.
http://www.telesphoreo.org/pipermail/g1-hackers/2008-December/000096.html <- [g1-hackers] G1 boot code
Around that same time, I was also contributing to AOSP, providing a bunch of patches to things like mount and init, as I wanted to be able to get Android devices to a state where they could run something much closer to Debian than Android (I had my eyes set on kind of a hybrid). In the process of doing this, I wrote a guide that for a couple years subsequent were the canonical instructions for getting a bootstrapped build of Debian installed as a chroot under Android. At the time the patch turnaround on AOSP was sometimes over half a year (and almost never shorter than a couple months), which made contributing to the project sufficiently painful that I eventually stopped. If you search through Android's codebase, though, you still find some of my work.
http://www.saurik.com/id/10 <- Debian & Android Together on G1
At the time, I honestly do not remember XDA having yet become "the place" where people spent much time talking about Android: instead, a lot of conversation happened on IRC (which is where the iOS community had already been, and where it remains). There was a channel that I was a part of which included a bunch of people whose names would hopefully be familiar to people around here, including JesusFreke (and, much later, Cyanogen). I got to see the birth of a lot of great websites and tools (such as JesusFreke's smali/baksmali) while participating on that channel. Apparently, I was talking about "Substrate for Dalvik" on that channel in November of 2008 (which is also when I first joined XDA): that's how long I've been staring at this ;P.
During the next couple years, I ended up developing and maintaining a website called Cyrket, which had the mission to allow developers and users to search the contents of the Android Market using their desktop web browser. It also solved a few key problems that developers had with comments, in that you could only see comments for apps your device had access to that were then written in your language. Developers without devices, or with devices that could not see their product (which often included those that paid extra for the ADP1, which could not see copy-protected apps) could not see comments at all. Cyrket presented all of the comments for your application in all regions in all languages (and even used Google Translate to translate them all into your own language).
The way Cyrket had worked is that I scraped the contents of the Market using the same protocol Google's client used, indexed it (supporting find-as-you-type search), and exported it all to the site (well, originally, it was actually just a live client, but then it got really popular ;P). It got me into some mild trouble occasionally with the Android Market team, but overall no one seemed to mind it that much. Cyrket was actually the primary site people used for this purpose for a long time, and I even got the impression that people at Google were begrudgingly using it as it was more convenient than the alternatives. There were a few times where it had to be taken offline (due to changes and rate limits from Google), one time for months, but I'd usually figure out some new way to get it running. Honestly, though: I was really glad when Google finally launched a website for the Market and I was able to stop working on Cyrket ;P (and also glad that Google added most of Cyrket's features for developers to their publishing console, features that Apple actually still doesn't have AFAIK).
http://www.androidtapp.com/cyrket-android-market-browser-back-from-awol/ <- Cyrket Android Market Browser Back from AWOL!
Since those times, I mostly felt the need to get Substrate "awesome" (which started to really come together during 2011, after Cyrket was no longer needed), and so didn't do many larger projects on Android until recently. That said, I have been involved in things related to exploits and security. One of the higher impact things that I did was to release mempodroid, an implementation of the mempodipper exploit described by Jason A. Donenfeld for Linux 2.6.39+, which became the primary method to root devices running Android versions 4.0.0 through 4.0.2. Much more recently, users have been using Impactor, my implementation of the various "Master Key" exploits (based both on bugs described by Jeff Forristal as well as techniques I pioneered against a random AOSP bug).
https://github.com/saurik/mempodroid <- mempodroid README
http://www.saurik.com/id/17 <- Exploit (& Fix) Android "Master Key"
Given all of this, I hope people can get a feeling for just how strange and depressing it feels to me when people seem to suddenly believe I'm some kind of foreign invader . (FWIW, I also feel rather awkward having to describe all of this in this fashion, but frankly I'm at a point where I'm realizing that if I don't explain it in this much detail myself, no one else will. While I'm certain I'll get some people responding really negatively with comments like "he's such a blowhard, going on and on about silly little things he did", so far when I've given similar spiels to people in person at conferences, they often go "oh wow, I remember that tool/happening, but didn't remember that that was also you", and so figure that this might go a long way to fixing this weird problem: I'm not just "that iOS jailbreak guy".)
=== Substrate ===
Alright, now with that aside: in time for Google I/O (which was arguably bad timing, as I was then immediately unavailable for days ;P), I finally released Substrate. Substrate (in my clearly biased opinion ;P) is actually really cool: as far as I know, it is currently the only tool available for Android that allows developers to easily modify native code without patching/replacing. I know, for example, that people often ask how to modify features like the holo themes that are implemented in C, and the answer is Substrate: if you can find the code (which is often exposed via a symbol as there are tons of C++ symbols available on most Android builds) you can use Substrate to hook it at runtime in a way that avoids having to patch the files on disk, allows developers to deploy their changes across multiple ROMs, and supports the idea that users should be in charge of the specific features that they have on their devices (as opposed to ROM distributions).
As another concrete example that maybe makes this more obvious: sometimes you download a program from the Play Store (which, incidentally, I have a very hard time not constantly still calling the Android Market ;P) that is pretty much just a massive JNI binary--maybe an OpenGL game or a media player of some sort--that refuses to run on a device that has been rooted. A really common way that developers implement such checks is to do things like verify the existence of files on disk. The simple/common checks are very easy to detect and defeat using Substrate as you can hook the native "open" call from the C standard library, check if the filename is something like /system/xbin/su, and return "nope, not there".
http://www.cydiasubstrate.com/api/c/MSHookFunction/ <- MSHookFunction()
Substrate lets you do this kind of hooking in any system daemon (not just those spawed via app_process). Yes: if there's a program running in the background of your phone, some native service written by the OEM that manufactured the device, you can use Substrate to modify it. A lot of very interesting extensions on iOS involve these kinds of hack; for an extreme example, the software unlocks that we used to have for earlier iPhones involved modifying CommCenter, a native program that initializes the radio hardware: by hooking some of the code in that daemon, it was possible to, at just the right moment, inject a different command sequence over the serial connection to the baseband, exploiting it for the unlock.
http://www.cydiasubstrate.com/inject/android/ <- Android Native Injection
Of course, Substrate also supports hooking Java code (yes, a little like Xposed, which at some level uses the same underlying trick I walked people through in my talk at Android Open 2011). Somehow, though, a lot of developers don't seem to catch all that other stuff that Substrate lets you do, and get hung up on this one part that Xposed also manages, leading to all those aforementioned irritating comments about how "there's no point to Substrate because we already have Xposed": Xposed can't do most of the things Substrate can do (and the developer has even told me that he actively tries to avoid Substrate-like techniques as they are "pretty complicated", so it isn't even moving in that direction). FWIW, on iOS it took a lot of time for Substrate to get these features (it did not have them in 2008 when I first released it): they aren't trivial ;P.
http://www.cydiasubstrate.com/api/java/MS.hookMethod/ <- MS.hookMethod()
Even within the restricted context of modifications to Java, however, I think Substrate has a lot to offer. Again: I actively refused to release Substrate until I felt I had truly nailed a few things, including in particular the Java API (at Android Open 2011, I only supported JNI, which developers there told me would not lead to traction). I was a major proponent of aspect-oriented programming when I was younger, I got into byte-code engineering in college, and I co-published a paper on a Java code modification framework called jMonitor in 2004: this is something I've been thinking about for a long time, and I think the approach I take has some merit in and of itself. I know a lot more can be done (I feel it would be really interesting to have AspectJ-style pointcuts, for example, or the kind of bytecode-level instruction matching that I implemented as part of jMonitor <- features not described in the paper, I think ;P), but I felt a good first step was be to directly leverage the iOS community's six years of experience.
http://www.cydiasubstrate.com/id/6dfa187d-6e04-4f97-b63a-ae75b5338e01/ <- jMonitor [RV '04]
To this end, Substrate provides an API for Java that is very analogous to the API that it provides for modifying C/C++ and Objective-C. The focus is on "I know about some code and I want to modify it", allowing you to not have to think much about the timing or execution details of the program that may be loading that code (so you never have to think about "packages" or "processes" or "applications": you just concentrate on "classes", and thereby don't need a million "helper APIs" to handle each narrow timing case). To enable this, I use the aforementioned ability of Substrate to modify native code to hack features into the VM itself, giving me the ability to instrument events like "a class has been loaded". If you want to hook a method of a class from Apache Commons, and you want to hook that class no matter whether it was loaded as part of an application or dynamically as part of a classloader for a plugin downloaded by an application, this is trivial to express with Substrate. AFAIK, that use case isn't even describable using Xposed.
http://www.cydiasubstrate.com/api/java/MS.hookClassLoad/ <- MS.hookClassLoad()
This kind of VM-level modification and runtime code generation support (that is heavily flexed on iOS Substrate, and thereby has had years of in-the-field testing; so far Android has exposed just one bug in its ARM reassembler after release, and that was only in the qemu emulator for some reason) also means that Substrate's implementation of hooks is highly efficient: to compare again to Xposed, every time a method that has been hooked is called via Xposed, there is a linear-time search through a linked list doing a rather heavyweight comparison to determine which method it was after the fact; with Substrate, every call is direct, there are no lookups, and there are no comparisons, so you can hook an arbitrary number of methods with no slow down, so even very small methods that are called very often can be hooked without issue.
Additionally, with Substrate I wanted to address a specific pain point that many people would bring up when I'd give talks: "how is this secure, and how do I control what apps can use these features". This became even more important, as I wanted Substrate extensions on Android to be easily deployable via conventional means, such as the Play Store (yes: Cydia Substrate itself is in the Play Store, as I believe it is important for these kinds of features to not just be in the hands of developers on forums, but to be used by end users everywhere). To this end, I integrate into the Android security model, providing a special permission that applications must have to install a Substrate extension. This helps enable the idea that Substrate mostly "gets out of the way", becoming more of a technical detail behind your extension rather than something users will need to interact with constantly to activate or update your product.
I also wanted to provide at least something that would help solve the "reflection hell" that developers seem to always find themselves in while attempting to do runtime code modification in Java (even back on desktop Java using AspectJ). I thereby provide the means to "bless" a class loader, allowing it to access private fields and classes without the overhead of reflection: the access checks, for just that one class loader, no longer apply. Substrate extensions are loaded into such a "blessed" classloader. (I do not, even though I could, ever just whack an access check VM-wide; Xposed does this, and I feel like it is going to have security implications on Java security contexts applied to class loaders for plugins.) In the case of WinterBoard, for example, I don't ever have to deal with invoking Methods or getting Fields: setAccessible is just a dim memory.
Being able to use this functionality, however, can be awkward, and in some cases is almost impossible: while testing this feature, I realized that developers would end up needing "public stubs" for all the classes they were working with, but the calling convention for a public method and a private one is different, so the calls fail at runtime. I thereby ship as part of the Substrate SDK (yes, there's an easily-updated SDK package that you can download using the Android SDK Manager ;P) an extension to javac itself (as you might imagine at this point, written using AspectJ) that turns off access control checks: you can thereby access private fields or call private methods with no extra work both during development and at runtime. This all works sufficiently well that I generally run all of ant under the modification, such that anything ant compiles becomes "blessed".
http://www.cydiasubstrate.com/id/c17c554f-b603-4e3b-8f99-ebb3528e3ef8/ <- Java Access Controls
(And yes: this is one of the things that caused Substrate to get delayed even longer than it already had been. There was also a rather serious delay caused by my attempts to really nail the boundary between "code that is shipped with Substrate" and "code that is shipped with the extension", something that burned me a lot throughout 2013 as it was the kind of problem that spending time actively thinking about didn't directly help, requiring an epiphany I had soon before Google I/O. Arguably had I been willing to ship without documentation at all, and had I generally cared less, I would probably have had everything out in very early 2012, but during January-May I started working on the initial draft of cydiasubstrate.com, as I had apparently incorrectly thought that such efforts would be critical to developer adoption.)
Again, I write this in the hope that it clears up misconceptions, either about myself or about Substrate. As far as I can tell, Substrate has a lot of very unique value propositions: things that currently are only made possible by Substrate; and, even within the restricted scope of hooking Java code inside of a service being managed by Zygote (the only area of overlap with Xposed), I think that it offers a bunch of advantages in security, performance, deployment, and ease of development that cannot be so casually dismissed with a flippant "we already have Xposed (go home)". A lot of these features (and I haven't even gone into all of them: I could write paragraphs about the advantages of how Substrate's API handles chained hooks, the ways I enable extensions that need to cross classloader boundaries, or the way Substrate makes it easy for end users to temporarily disable extensions without complex tooling) come from having spent over a decade now thinking about this problem and the last five years actively managing a developer ecosystem with tens of millions of users on iOS.
I am thereby happy to answer any questions about how to use Substrate, issues with Substrate on any device (I never blame the device: I might not have a fix immediately for a specific problem, but I always consider it Substrate's job to work around issues the device throws at it to get its functionality in place so the task will at least end up on my todo list), or even about me (as a lot of why I find writing this both so important and so painful are due to the occasional-yet-present more-personal attacks/misconceptions I often seem to receive about somehow being an "outsider"). (That said, please do have some patience: sometimes my ravenous need to do nearly 24/7 testing on a specific device has to give way so I can go to a conference I'm giving a talk at, or so I can focus on a different problem that might be more pressing or simply have a higher probability of near-term success: spending an infinite amount of time on one problem is unfair to all of the other problems that exist ;P.) [And, in fact, I have a meeting I have to be at tonight, but which hopefully won't take insanely long.]

Reserved Post
["reserved", as apparently you always should have at least one of these ;P]

Links to Extension Threads
[and finally, I can see ending up with a page that might link to other threads on XDA, although arguably I should put this on cydiasubstrate.com. right now, most projects that use Substrate are in Play. I am not certain if I'm now just misunderstanding how to use XDA, though: again, this is my first thread I've started myself]

Wow. The timing couldn't be any more perfect for you to post this.
I do not have an Android device yet and have been theorizing exactly how I could easily make modifications to applications.
Because I am just getting started in the Android development community, I don't have any biases towards one framework or the other.
Sooo.... this is on my watch list.

gugbot said:
Wow. The timing couldn't be any more perfect for you to post this.
Click to expand...
Click to collapse
The opinion of many (reasonable) people differ ;P.
gugbot said:
Sooo.... this is on my watch list.
Click to expand...
Click to collapse
Yay! If you have a moment, I'm curious: how/why did you find this thread? It seems like very few people actually go to this "Frameworks" sub-forum; there are almost no threads posted to it except the one about Xposed, which I'm presuming people must be finding by links from other places (whether random websites or other threads on XDA).

saurik said:
The opinion of many (reasonable) people differ ;P.
Yay! If you have a moment, I'm curious: how/why did you find this thread? It seems like very few people actually go to this "Frameworks" sub-forum; there are almost no threads posted to it except the one about Xposed, which I'm presuming people must be finding by links from other places (whether random websites or other threads on XDA).
Click to expand...
Click to collapse
I was browsing in development tools and was surprised to see that a Saurik posted about Cydia Substrate!
I was brought to this forum by one about theme development?... Maybe you should post this in a forum with more traffic. There seems to be an endless amount of categories for everything.

i have try your cydia substrate on cm10.1.3 stable..device samsung i9300..
install winterboard..apply icon pack but icon pack not applied..
then when want to open other apps the apps fc..except winterboard..

slipar said:
i have try your cydia substrate on cm10.1.3 stable..device samsung i9300..
install winterboard..apply icon pack but icon pack not applied..
then when want to open other apps the apps fc..except winterboard..
Click to expand...
Click to collapse
Yeah, as I mention in this thread WinterBoard was more of a demo that has been difficult to justify improvements to . This isn't an issue with Substrate, at least.
Would you mind sending me the crash report from the adb log? At least, would you mind telling me the name of the theme you applied? Also, thinking about it, CyanogenMod already has a theme engine... it never occurred to me how WinterBoard would interact with the existing theme engine in CyanogenMod (although I guess thinking even longer about it, I see no reason why it would fail horribly... it should just layer on top).

saurik said:
Yeah, as I mention in this thread WinterBoard was more of a demo that has been difficult to justify improvements to . This isn't an issue with Substrate, at least.
Would you mind sending me the crash report from the adb log? At least, would you mind telling me the name of the theme you applied? Also, thinking about it, CyanogenMod already has a theme engine... it never occurred to me how WinterBoard would interact with the existing theme engine in CyanogenMod (although I guess thinking even longer about it, I see no reason why it would fail horribly... it should just layer on top).
Click to expand...
Click to collapse
hope i send u the correct logcat..
im using ios7 concept theme..g play link here

slipar said:
hope i send u the correct logcat..
im using ios7 concept theme..g play link here
Click to expand...
Click to collapse
Thank you so much for the information. Here is a new version of WinterBoard that seems to work with this theme.
http://cache.saurik.com/apks/com.saurik.winterboard_0.9.3922.apk

thanx saurik..tested but this time winterboard just fc when try to change theme..
logcat attach..

slipar said:
thanx saurik..tested but this time winterboard just fc when try to change theme..
logcat attach..
Click to expand...
Click to collapse
I'm sorry about that issue... this is actually quite interesting to me as it might indicate that I need to do some more work on the blessed compiler as it relates to miranda methods. I had verified that the theme functioned, but had not gone back to attempt to re-verify the setup activity itself, which I guess hadn't been recompiled in a long time. I've added a temporary workaround to the issue while I investigate further. ("Humorously", if you have Xposed installed, I am pretty certain that the WinterBoard settings activity would have worked, as Xposed just destroys the access control checks for the entire VM.)
http://test.saurik.com/xda/com.saurik.winterboard_0.9.3922+1.gf733f01.apk

Hey there, I just happened upon this thread while deeply perusing the boards after just getting home from a 17hr drive and being unable to go to sleep yet. I am VERY interested in the substrates capabilities, it sounds like a very interesting concept. I am a new developer and am wanting to learn more and play more....I use xposed on my phone now and was considering starting to develop modules for it, buuuttt I think I just changed my mind I'm on an att sgs4 running a 4.3ge Rom. Going to install the substrate the night via Play Store and mess around with it starting tomorrow. Thanks for this
Sent from my GT-I9505G using Tapatalk

Sc4ryB3ar said:
I'm on an att sgs4 running a 4.3ge Rom. Going to install the substrate the night via Play Store and mess around with it starting tomorrow. Thanks for this
Click to expand...
Click to collapse
Yay! (Now, watch your GT-I9505G be one of those few Samsung devices Substrate detects as incompatible ;P. Samsung has so many model numbers that all map to the same high-level marketing names that it's difficult to keep track of what's what. If that happens, and you are interested in helping out, I can implement one of my alternative injectors quickly for you to work with.)

saurik said:
Yay! (Now, watch your GT-I9505G be one of those few Samsung devices Substrate detects as incompatible ;P. Samsung has so many model numbers that all map to the same high-level marketing names that it's difficult to keep track of what's what. If that happens, and you are interested in helping out, I can implement one of my alternative injectors quickly for you to work with.)
Click to expand...
Click to collapse
It installed just fine, quickly and with no apparent issues
winterboard, however rendered neither theme I chose correctly, wondering if its the themes though.... Didn't get a logcat and then I hosed my system last night messing around too much, so I started fresh and haven't gotten back to substrate and wb yet....I'll be back to it withing a couple of hours
Sent from my GT-I9505G using Tapatalk

substrate source code
Saurik,
I've been dabbling some with Cydia Substrate and it seems to offer a lot of unique possibilities for Android apps.
Do you have any plans to release the source code for this like you did on iOS? I'd be very curious to learn more about how it works. Also, is there a link to your talk from the Android Open conference?
Thanks,
Fred

(Ugh. I have no clue how people keep up with a forum, especially with the website as slow to load every page as it is ;P.)
fjones8856 said:
Do you have any plans to release the source code for this like you did on iOS? I'd be very curious to learn more about how it works.
Click to expand...
Click to collapse
I currently do have an intention to release the source code, but I'm not certain under what license (all of the licenses I normally use don't solve the specific issues related to Substrate). That said, no one seems to care much about Substrate on Android: on iOS people tend to (almost to a level of it being a problem) jump on new solutions to evaluate constantly, whereas on Android people seem to just snark "we already have X" even when there are compelling advantages to a replacement. Given this situation, I am highly unmotivated to spend the time to figure out the right solution, given that in a way Substrate is "my magnum opus": it is the culmination of the research and experience of so many years of my life, that passing up the ability to license it to the companies that sometimes talk to me about that (for either enterprise wrapping or security) to satisfy a group of people who are mostly asking for the source code specifically to replicate the technique *and then avoid using Substrate*, makes very little sense.
On the project side of it, Substrate on iOS only ever received a single code contribution from someone I wasn't already so close with that I was sharing code already. It isn't even the kind of project that one would expect getting many contributions: it is more of a backend technology, and the extent to which it has a GUI is actually a bug (I intend for it to be 100% seamless as part apps that use it: Substrate on iOS does not have a GUI and never will have a GUI, and that's how I think it really should work on Android as well, but of course right now I need the silly Install button). If anything, on iOS, we often end up with random companies that want to "own the scene", which ends up with them forking Substrate in ways that cause platform incompatibilities for other developers: Substrate on iOS has thereby actually been closed source now for almost two years, and it has actually improved the stability of the platform. I thereby am somewhat loath to "repeat the same mistakes from before" and end up with forks.
fjones8856 said:
Also, is there a link to your talk from the Android Open conference?
Click to expand...
Click to collapse
There was no recording of the actual talk, just of the keynote introduction that I already link to from my website. In the talk I walked people through a demonstration of using an early version of the JNI-level Substrate API, and showed how it worked (which was very simple at the time). In essence, I demonstrated, with my exact code on the projection, the technique that Xposed started using half a year later (which is just "oh, I'll change the contents of this Method object, as apparently the runtime doesn't care if the Method is allocated as part of a Class; if I do it right I can simulate registerNatives") and the most obvious way of implementing MSJavaHookClassLoad (which--for the really really low-level API I had at the time, on pre-4.0 VMs that didn't have complex JNI stacks--is clearly "MSHookFunction the class load and provide a callback"). Everything is going to be new for ART, though: the techniques are going to have to be much more sophisticated (which I'm excited by, as this is a game changer).

Pm sent
Sent from my GT-I9505G using Tapatalk

Detection of law enforcement malware (e.g. FinFisher)

Ladies and Gentlemen,
I am opening this discussion in order to not only receive some high-quality answers on the following questions, but also to learn what everyone does in order to ensure security and integrity of Apps on their phones (especially when working in environments where attacks are likely or possible due to intersting files on the phone or similar).
Here is my question: Let's suppose a phone is ROOTED, is locked with a Pattern, is updated daily, has TitaniumBackup installed, runs Trust as well as an Antivirus App and on top of that, installed Apps are monitored in a regular basis through TitaniumBackup. Is it even possible for law enforcements or hackers to install malware? If so, what would be necessary for them to do so? Physical access? Malformed Apps with matching signature? Other types of attacks (encouraging @He3556 the owner of Smartphone Attack Vector to chime in)?
Second question (hope @jcase can answer this): What would be the best way of preventing attacks of afforementioned groups and alike? What do YOU personally do?

SecUpwN said:
Ladies and Gentlemen,
I am opening this discussion in order to not only receive some high-quality answers on the following questions, but also to learn what everyone does in order to ensure security and integrity of Apps on their phones (especially when working in environments where attacks are likely or possible due to intersting files on the phone or similar).
Here is my question: Let's suppose a phone is ROOTED, is locked with a Pattern, is updated daily, has TitaniumBackup installed, runs Trust as well as an Antivirus App and on top of that, installed Apps are monitored in a regular basis through TitaniumBackup. Is it even possible for law enforcements or hackers to install malware? If so, what would be necessary for them to do so? Physical access? Malformed Apps with matching signature? Other types of attacks (encouraging @He3556 the owner of Smartphone Attack Vector to chime in)?
Second question (hope @jcase can answer this): What would be the best way of preventing attacks of afforementioned groups and alike? What do YOU personally do?
Click to expand...
Click to collapse
Pe rooted, with common rooted apps installed? Would be easy to compromise that phone, as you have already done it for them.
Use a stock firmware, chose a vendor with a recent history of good security (Samsung, nexus, motorola in that order imo), keep it up to date, reduce the number of apps you run, don't root it. Disabled usb debugging.

jcase said:
Pe rooted, with common rooted apps installed? Would be easy to compromise that phone, as you have already done it for them.
Use a stock firmware, chose a vendor with a recent history of good security (Samsung, nexus, motorola in that order imo), keep it up to date, reduce the number of apps you run, don't root it. Disabled usb debugging.
Click to expand...
Click to collapse
Thanks for answering. So that means, in short words, buy a phone and only update official stuff. How boring, I wouldn't be here on XDA then! But I get your point. I'm especially interested in the question of detection. If such agencies have installed anything that would leak data (and I'm sure it's fairly easy to do for them), how would they hide that specific App from the list of TitaniumBackup? Also, how would they trick the Trust Even Logger created by @Dark3n to not show any installation?
Most importantly though, is there some way of detecting such installations or manipulations afterwards?

There is growing so called "Zero-Day-Exploit" Industry, with names like vupen or FinFisher , the one who are working for the German Gov. but also for countries like Saudia Arabia and Iran. They know how to find exploits, nobody knows about (zero-day) and program trojans for all kinds of platforms. So antivirus software can't help here. And it is easy to bypass security if you know one of the bugs - and we know there are many of them in firmware, operating systems, plugins, frameworks and so on... Beside this "white" marked there is also a grey and black marked. So if you need to track your woman or steal information from other companies, you will find somebody with a tool for that, i suppose.
You would need a "Intrusion Detection Software" - sorry but this won't work for Smartphones, because there is a lot of calculation, data and energy needed - you find this special hardware in big data centers.
Do not root and do not install Apps you don't really need is still a good advice, specially when people don't know so much about all this.
Another way to sneak in is to compromise the users pc, that is (maybe) connected to the phone sometimes (work with iphone sync but also with android to change DNS and get SMS with e-tan's - you will find more info it in the media)
Or if you have the "power" you can can use the cloud services (iOS, Google, Windows or other 3rd party services) to steal user data (sms, pictures, GPS history...) or just let it sync the malware to the phone. So you don't have to break in directly.
What would be the best way of preventing attacks of afforementioned groups and alike?
Click to expand...
Click to collapse
tomorrow i will have time, there are to many possibilities

Thanks for clarifying, @He3556!
Now I know that phones in general are hard to lock down for such agencies. Time to quote myself:
SecUpwN said:
Most importantly though, is there some way of detecting such installations or manipulations afterwards?
Click to expand...
Click to collapse

Hey @He3556, if you've been following security news the past weeks, this topic here is becoming more relevant with each revelation. Since the trojan-coding company FinFisher has highly likely been hacked and some cool whisteblowers are publishing very sensitve data like price lists and handbooks on their Twitter account GammaGroupPR, more details of their secret software FinSpy Mobile is being revealed. And this is exactly the type of software that I am talking about here in this thread. I want to know how users can protect themselves from crap like that. According to the video that has been leaked, It is being installed through a fake update, or even through messages via E-Mail to "please" install this "very important update":
And just to make everyone more curious, FinSpy Mobile has been leaked on Twitter! It obviously works for all operating systems, including Android, Blackberry, Windows Mobile, and Symbian. Another trophy is source code of FinFly Web, which found its way the code hosting platform GitHub. It is designed to provide remote and covert infection of a Target System by using a wide range of web-based attacks. FinFly Web provides a point-and-click interface, enabling the Agent to easily create a custom infection code according to selected modules. Target Systems visiting a prepared website with the implemented infection code will be covertly infected with the configured software. Regarding FinSpy Mobile and similar software: How would law enforcements possibly attack a cautious member of XDA (or any other site)? I mean, people that have been in the field of flashing new ROMs, updating their firmware and recovery themselves, not installing strange APKs sent via E-Mail and controlling installed Apps through TitaniumBackup should be somewhat immune to such type of attacks, right?
It appears to me as if their software might work for the general masses, but highly-likely not on people like @jcase or other Android security-gurus. Since I linked you, I'd be very happy if you could expand on that a little. I am sure such companies might even have the possibility of messing with the baseband of a target phone through only knowing the phone number of a target. But I am really curious what their "standard procedure" is if they face a target with thorough Android knowledge, maybe even a security-enthusiastic Android developer. Wouldn't their only option be to manually manipulate the handset?

There are two methods to keep away all kinds of trojan and malware...
1. use a SIM with data connections only: There are SIM cards on the marked you can use in a USB Stick for Notebooks or tablets.
You won't have a cell phone number and can't receive SMS. You won't be able to use the circuit switched (GSM & UMTS-cs) part of your cell phone. For communication you have to use a VoIP provider - with Secure SIP and SRTP.
2. Web browser, Apps, e-mail client and all other connection must be use VPN.
But there is one more stepp to take.
The virtualization of all services and Apps you are using. This works like Team Viewer on a PC. The App is running on a cloud server while you only see the desktop of the remote controlled application. This technique is already used when you want to use flash with iOS device (photon, cloudbrowse, puffin and so on..)
More details about this you can find here: http://itwatch.info/Products/ReCAppS
But i am sure there are more projects about this out there...

He3556 said:
There are two methods to keep away all kinds of trojan and malware...
1. use a SIM with data connections only: There are SIM cards on the marked you can use in a USB Stick for Notebooks or tablets.
You won't have a cell phone number and can't receive SMS. You won't be able to use the circuit switched (GSM & UMTS-cs) part of your cell phone. For communication you have to use a VoIP provider - with Secure SIP and SRTP.
Click to expand...
Click to collapse
I know this works, but the only guy who is so insane and is already doing that is probably @InvaderX.
Honestly, what's the purpose of a phone if I can't receive SMS and call anyone without internet connection?
He3556 said:
2. Web browser, Apps, e-mail client and all other connection must be use VPN.
But there is one more stepp to take.
The virtualization of all services and Apps you are using. This works like Team Viewer on a PC. The App is running on a cloud server while you only see the desktop of the remote controlled application. This technique is already used when you want to use flash with iOS device (photon, cloudbrowse, puffin and so on..)
More details about this you can find here: http://itwatch.info/Products/ReCAppS
But i am sure there are more projects about this out there...
Click to expand...
Click to collapse
Better yet: Living under a rock should solve all these problems. Seriously though, can such law enforcement agencies silently update stuff on my phone (possibly baseband) that goes unnoticed even when using TitaniumBackup and flashing a fresh ROM every month? From the things you mentioned as for protection, I highly doubt that I'll move that way. And no matter how hard I try, the bad guys (or, to put it in the wording of those companies: the agencies that are "protecting our freedom") will likely always find a way in - even if that means tapping the phone through listining in on my calls or deploying an IMSI-Catcher. But talking about this makes me wonder: It seems as if the probability is high that most of the time they are selling a fake update to the target. Is there a convenient way of knowing that stuff like FinSpy Mobile has been installed, where such agencies can't possibly tinker with any records of what was happening on the phone? I especially check the Trust - Event Logger by @Dark3n very often. Could they change such records? Is there a better App to warn about unauthorizes access or (hidden) App installation?

Trust is not a security app!
If an attacker has root, you can just alter the database of apps like Trust, which would be the easiest way.
There are probably also ways to alter the system so it does not broadcast certain events(which is how Trust monitors most things).
It is just not build to withstand such attacks.
SecUpwN said:
Seriously though, can such law enforcement agencies silently update stuff on my phone (possibly baseband) that goes unnoticed
Click to expand...
Click to collapse
Maybe? But there are much easier ways if it is not desired to target specific persons.
I'll brain storm a bit for you:
I would divide the attack vectors into those that work with root and those that don't.
Without root apps can still do plenty of malicious actions, including tracking your position or uploading all files on your sdcard (INTERNET;SDCARD;LOCATION permissions) etc.
If an attacker gains root permission he could install rootkits, modify existing apps, inject malicious code into dex files of installed apps etc.
Basicly do what the hell he wants.
While not using a rooted device would certainly make it more difficult to do malicious things, it's doesn't prevent it.
A normal app you install could still root your phone through vulnerabilities. It works the same way apps such as TowelRoot or ZergRush root your phone.
Downloading new apps that request root is also very dangerous ofc, once you pressed "grant", it's too late, anything could have been done. So be wary when trying out new root apps of devs you don't know/trust?
Abusing trust in existing apps is probably the biggest danger.
The most obvious danger here is downloading apps you usually trust but from unknown sources.
Sure there could be signature issues when updating over your current app, but what if you don't have it installed? I could also think about a few ways to inject malicious code without altering the signature (did not try, just a thought, might be impossible).
The issue is that you probably wouldn't even notice, as the compromised app retains it's original functionality.
Want a botnet?
Inject malicious code into a popular root up that is paid, crack it and upload it somewhere.
While this more dangerous (or worth for an attacker) with root apps, it's still viable for non root apps, just pick one that already aquires many permissions.
It's way too easy, people constantly underestimate the danger of this. It's not all about piracy it's bad, it's a barn door sized security hole.
A bit more difficult variant would be abusing known security holes in existing apps that can be root or nonroot apps, such as modifying files the other apps uses, such that it executes your malicious code for you, so some type of code injection. First thought would be looking for root apps that use scripts or binary files and then check the permissions on those files to see whether they are writeable.
Now those are all ways to target a broad mass of users.
If a single user is the target, it would be more difficult, but there are still plenty of options:
- MITM attacks at public hotspots,
- Pressuring developers of apps you use. What dev wouldn't implement a security hole into an app of his, if a guy in a black suit comes up and points a gun to his head? Well that escalated quickly... But with "secret courts" and all the **** that happens secretly sanctioned or is just done by some agencies because they are above the law, is it really such an impossible scenario? The ends justify the means? Do they?
- My favorite plan yet, making a popular app themselves that they know you will try
It is usually never impossible, just a matter of resources and whether its unfeasible to spend so many resources on that goal.
edit: So the best course of action? Don't install anything you don't trust. Don't trust the manufactor either? Install a custom ROM, but as those often use binary blobs for certain parts of the software, it's not really a 100% solution... There could also be compromising hardware built in, but now I'm really climing up the tinfoil tree, but as recents new story suggest that the NSA is intercepting hardware packets from manufactors such as cisco to modify them, what's really impossible?
TL;DR Best course of action that is feasible to adhere to is probably to just not install stuff one doesn't know or trust.
edit2: More specific answers to your questions.
You might be able to monitor files changes on an a system level, but if your attacker gains highlevel priviledges, what keeps him from changing the monitoring system?
SecUpwN said:
Seriously though, can such law enforcement agencies silently update stuff on my phone (possibly baseband) that goes unnoticed even when using TitaniumBackup and flashing a fresh ROM every month?
Click to expand...
Click to collapse
How does TiBu help prevent such injection? Flashing a new ROM would probably undo such changes, but what prevents "them" from just doing it again.
SecUpwN said:
And no matter how hard I try, the bad guys (or, to put it in the wording of those companies: the agencies that are "protecting our freedom") will likely always find a way in - even if that means tapping the phone through listining in on my calls or deploying an IMSI-Catcher.
Click to expand...
Click to collapse
This is the thing, with enough resources, there is always a way.
SecUpwN said:
It seems as if the probability is high that most of the time they are selling a fake update to the target.
Click to expand...
Click to collapse
Exactly disguising as something legit is the cheapest way, "trojan horse".
SecUpwN said:
Is there a convenient way of knowing that stuff like FinSpy Mobile has been installed, where such agencies can't possibly tinker with any records of what was happening on the phone? I especially check the Trust - Event Logger by @Dark3n very often. Could they change such records? Is there a better App to warn about unauthorizes access or (hidden) App installation?
Click to expand...
Click to collapse
I don't know any surefire way to detect this. The issue is that with enough priviledges (which can be gained without authorization, zero day exploits are worth a lot money to "agencies" as well as criminal organisations, though I'm no longer sure where the difference is), you can just clean up your track of malicious behavior.

Whoa, this has to be the longest answer I've received since registering here. Huge thanks! Grab a coffee..
Dark3n said:
Trust is not a security app!
If an attacker has root, you can just alter the database of apps like Trust, which would be the easiest way.
There are probably also ways to alter the system so it does not broadcast certain events(which is how Trust monitors most things).
It is just not build to withstand such attacks.
Click to expand...
Click to collapse
Ok, fair. Will keep it anyhow.
Dark3n said:
Maybe? But there are much easier ways if it is not desired to target specific persons.
I'll brain storm a bit for you:
I would divide the attack vectors into those that work with root and those that don't.
Click to expand...
Click to collapse
Just to mention it here: An awesome site to see which attack vectors and vulnerabilities exist is Smartphone Attack Vektor by @He3556.
Dark3n said:
Without root apps can still do plenty of malicious actions, including tracking your position or uploading all files on your sdcard (INTERNET;SDCARD;LOCATION permissions) etc.
If an attacker gains root permission he could install rootkits, modify existing apps, inject malicious code into dex files of installed apps etc.
Basicly do what the hell he wants.
Click to expand...
Click to collapse
Ok, I get the point. Also like @jcase already pointed out: If we root, we pwn ourselves. And if we don't, too.
Dark3n said:
While not using a rooted device would certainly make it more difficult to do malicious things, it's doesn't prevent it.
A normal app you install could still root your phone through vulnerabilities. It works the same way apps such as TowelRoot or ZergRush root your phone.
Downloading new apps that request root is also very dangerous ofc, once you pressed "grant", it's too late, anything could have been done. So be wary when trying out new root apps of devs you don't know/trust?
Click to expand...
Click to collapse
I only install trusted Applications.
Dark3n said:
Abusing trust in existing apps is probably the biggest danger.
The most obvious danger here is downloading apps you usually trust but from unknown sources.
Sure there could be signature issues when updating over your current app, but what if you don't have it installed? I could also think about a few ways to inject malicious code without altering the signature (did not try, just a thought, might be impossible).
The issue is that you probably wouldn't even notice, as the compromised app retains it's original functionality.
Click to expand...
Click to collapse
Guess if I use the F-Droid Store I should be pretty safe, right? But don't worry, I don't rely on it - as for me, smartphones are huge bugs with touchscreens. That is why I also built a phone signal blocking pouch for myself and friends. Further good recommendations can be found on the bottom of my GitHub.
Dark3n said:
Want a botnet?
Inject malicious code into a popular root up that is paid, crack it and upload it somewhere.
While this more dangerous (or worth for an attacker) with root apps, it's still viable for non root apps, just pick one that already aquires many permissions.
It's way too easy, people constantly underestimate the danger of this. It's not all about piracy it's bad, it's a barn door sized security hole.
Click to expand...
Click to collapse
Actually, no. I already have two or three. Or maybe even four?
Dark3n said:
A bit more difficult variant would be abusing known security holes in existing apps that can be root or nonroot apps, such as modifying files the other apps uses, such that it executes your malicious code for you, so some type of code injection. First thought would be looking for root apps that use scripts or binary files and then check the permissions on those files to see whether they are writeable.
Now those are all ways to target a broad mass of users.
Click to expand...
Click to collapse
Good to know we've come to an end here. Reading all this makes me want to throw my phone out of the window.
Dark3n said:
If a single user is the target, it would be more difficult, but there are still plenty of options:
- MITM attacks at public hotspots,
Click to expand...
Click to collapse
I DON'T use public hotspots. Why? Because you can be almost certain that stuff will be logged and analyzed once you use that. Over here in my town, we've got a HUGE Apple Store. And guess what - FREE WIFI for everyone! Yeyyy... not.
- Pressuring developers of apps you use. What dev wouldn't implement a security hole into an app of his, if a guy in a black suit comes up and points a gun to his head? Well that escalated quickly... But with "secret courts" and all the **** that happens secretly sanctioned or is just done by some agencies because they are above the law, is it really such an impossible scenario? The ends justify the means? Do they?
You are right, threats against family, friends and relatives are a no-go. If I remember correctly, something similar had happened to my beloved XDA developer @idcrisis who invented CrossBreeder. He left development of his toolset because starnge things occured in his life which he linked to his development. Shortly after leaving his project, he proposed a new license: The Aware License. Hope this guy is still living a happy life, though. Added to the above security-issues: Trust NOONE! How come? Well, just read this stunning story I discovered yesterday where a US critical infrastructure company last year revealed that its star developer had outsourced his own job to a Chinese subcontractor and was spending all his work time playing around on the internet adn surfing cat videos. ^^
Dark3n said:
- My favorite plan yet, making a popular app themselves that they know you will try
Click to expand...
Click to collapse
I don't quite get what you meanb by that. Please clarify, it sounds interesting.
Dark3n said:
It is usually never impossible, just a matter of resources and whether its unfeasible to spend so many resources on that goal.
Click to expand...
Click to collapse
The way I see it: The only thing that we have no real access to, is the baseband. I am sure that these are full of backdoors and switches for agencies that they just need to trigger - just like the Samsung Galaxy Backdoor discovered by Replicant.
Dark3n said:
edit: So the best course of action? Don't install anything you don't trust. Don't trust the manufactor either? Install a custom ROM, but as those often use binary blobs for certain parts of the software, it's not really a 100% solution...
Click to expand...
Click to collapse
Nope, I don't trust the manufacturer either. And I am SICK of bloatware! hence, I am a happy user of AOKP since several years - but regarding the binary blobs, I would certainly love to try out Replicant (sadly not yet available for the HTC One).
Dark3n said:
There could also be compromising hardware built in, but now I'm really climing up the tinfoil tree, but as recents new story suggest that the NSA is intercepting hardware packets from manufactors such as cisco to modify them, what's really impossible?
Click to expand...
Click to collapse
Nothing is impossible, everything can be done. A wise man once said: Everything you can imagine, will happen.
Dark3n said:
TL;DR Best course of action that is feasible to adhere to is probably to just not install stuff one doesn't know or trust.
Click to expand...
Click to collapse
Good advice, I already do follow that one. As already said, if I were a spy company, I'd just team up with manufacturers of basebands..
Dark3n said:
You might be able to monitor files changes on an a system level, but if your attacker gains highlevel priviledges, what keeps him from changing the monitoring system?
Click to expand...
Click to collapse
Highly-likely nothing. I already know that there is not much I can do to prevent them to get in, but at least I do want to detect them - and having such a detection mechanism raises the bar in disguising their actions even further - and who knows, maybe they're not interested anymore then?
Dark3n said:
How does TiBu help prevent such injection? Flashing a new ROM would probably undo such changes, but what prevents "them" from just doing it again.
Click to expand...
Click to collapse
Not much.
Dark3n said:
This is the thing, with enough resources, there is always a way.
Exactly disguising as something legit is the cheapest way, "trojan horse".
Click to expand...
Click to collapse
Absolutely right. But what I am really curious of: How do people from the security-community really protect their phones? Do you have friends that are using their phones to just communicate via VPN and VOIP, not sending SMS and never calling people? Perfect place for @InvaderX to chime in, he told me before to really do a combination of that approach.
Dark3n said:
I don't know any surefire way to detect this. The issue is that with enough priviledges (which can be gained without authorization, zero day exploits are worth a lot money to "agencies" as well as criminal organisations, though I'm no longer sure where the difference is), you can just clean up your track of malicious behavior.
Click to expand...
Click to collapse
Sigh.. mobile phones are a total threat to humanity, I get it..

At least I am not the only one paranoid about this kind of thing. LOL

lostangelintx said:
At least I am not the only one paranoid about this kind of thing. LOL
Click to expand...
Click to collapse
It doesn't have much to do with "Paranoia". The very reason you started to care about this, is because phones are in fact very insecure devices - most people just don't realize or care about it. Another very interesting thread I found lately: Android Security for Conscious Mind.

a tool against 0-day exploits
don't freak out to early - this tool is only for windows desktops.
But at least it shows how it could work for mobile devices, too.
It is called Enhanced Mitigation Experience Toolkit (EMET 5.0) ...is a utility that helps prevent vulnerabilities in software from being successfully exploited.
These technologies function as special protections and obstacles that an exploit author must defeat to exploit software vulnerabilities. These security mitigation technologies do not guarantee that vulnerabilities cannot be exploited. However, they work to make exploitation as difficult as possible to perform.
SSL/TLS certificate pinning - This feature is intended to detect (and stop, with EMET 5.0) man-in-the-middle attacks that are leveraging the public key infrastructure (PKI).
Ok, they do not guarantee 100% security - but who could? Even this software comes from Microsoft, it's still a good solution and closes the gap between anti-virus, firewall and keeping your software updated.
Here is a test from 2010 (EMET 2.0) http://www.rationallyparanoid.com/articles/emet-testing.html
And one of 2014 http://www.offensive-security.com/vulndev/disarming-enhanced-mitigation-experience-toolkit-emet/
Does anybody know a APP for Android, iOS, WP8 or BB?

Just a small side note:
In regard to device security vs. rooting.
There are essentially 2 schools of thought. On the one side we have those who believe we should trust the device manufacturers experience and knowledge to keep malware out of AOS, and you phone from spilling your data when stolen, which also means keeping users from rooting their devices, simply because they know security better, than the average user. (I think @jcase may be one of those, but he'd have to answer for himself.) On the other hand we have people like me, who firmly believe that the best way to keep your device secure is by being rooted, since we cannot trust anyone, especially large companies who scream "TRUST US". For us, we own the device and everything it does, and that your phone should not be able to send a single photon of radiation, without your permission. Then at least we have the choice to provide our own security by Firewalls, open source baseband, and encrypted phone calls etc. So no, this is not part of the majority of phone owners. But we think it should be. So who's right? Well, we're both right of course. What we need is to be able to make this choice at the time of purchase, and independent of the device you like. To be able to choose if you have a fully open device that you can secure on your own or if you like one that is claimed as secure, but you will never be able to check or control on your own. But unfortunately, this is not possible in most circumstances.

I trust neither the ODMs, nor the custom roms. However I KNOW the average custom rom is just as if not MORE vulnerable than current stock roms, add su into the mix and it is without a doubt more vulnerable. Show me a custom rom dev that claims he ships a secure firmware, and I'll show you someone ignorant of the facts. Ask most of them what CTS is, and they will look at you like you are referencing 18th century medical terms.
That is my stance. In regards to root making a device more vulnerable, I can back that statement time and time again. From key compromises of the superuser apps, to vulnerabilities in the app, to vulns in the su binaries, to vulns in apps that typical make su requests, to stupid users who will grant it to anyone. Having any access point to "root" makes turning a small vuln to a complete compromise relatively easy.
E:V:A said:
Just a small side note:
In regard to device security vs. rooting.
There are essentially 2 schools of thought. On the one side we have those who believe we should trust the device manufacturers experience and knowledge to keep malware out of AOS, and you phone from spilling your data when stolen, which also means keeping users from rooting their devices, simply because they know security better, than the average user. (I think @jcase may be one of those, but he'd have to answer for himself.) On the other hand we have people like me, who firmly believe that the best way to keep your device secure is by being rooted, since we cannot trust anyone, especially large companies who scream "TRUST US". For us, we own the device and everything it does, and that your phone should not be able to send a single photon of radiation, without your permission. Then at least we have the choice to provide our own security by Firewalls, open source baseband, and encrypted phone calls etc. So no, this is not part of the majority of phone owners. But we think it should be. So who's right? Well, we're both right of course. What we need is to be able to make this choice at the time of purchase, and independent of the device you like. To be able to choose if you have a fully open device that you can secure on your own or if you like one that is claimed as secure, but you will never be able to check or control on your own. But unfortunately, this is not possible in most circumstances.
Click to expand...
Click to collapse

@jcase : So I think we agree on that what you say, but from another perspective, we can ask ourselves whether or not a stupid user with root, can possibly endanger a smart user with root? I think this is not generally possible, apart from some automated DDOS attack, which would ultimately originate from a smart user with root, using the stupid user as a transport.
To what extent should ODM's be able to decide who is a smart root user and stupid root user? (And regardless their decision, why should we believe them?) There may not be an answer here, but the discussion is interesting also from a political point of view. How much should the "government" be responsible for a certain individual's action, regardless of their intelligence? Personally I think they're not, and should only provide security to prevent individuals from directly hurting each other, and not preventing them from hurting themselves, if they choose to do so.

Reading all this, it makes me wonder if the antivirus apps help at all..

stefeman said:
Reading all this, it makes me wonder if the antivirus apps help at all..
Click to expand...
Click to collapse
Let's put it this way.
In 6 years of heavy 24/7 PC use, my anti-virus have prevented me from a "possible" remote exploit exactly once, while having annoyed me with lengthy uninterruptible scans and ignoring my ignore settings about a 1000 times, due to adware and various other false positives. Then only god knows how many different countries governments are already present in my PC. Go figure. And yes, I have tweaked every possible setting and tried multiple well know AV's.
Forget AV's and get a good FW and with a well tuned host file, and well tuned common sense.

E:V:A said:
@jcase : So I think we agree on that what you say, but from another perspective, we can ask ourselves whether or not a stupid user with root, can possibly endanger a smart user with root? I think this is not generally possible, apart from some automated DDOS attack, which would ultimately originate from a smart user with root, using the stupid user as a transport.
To what extent should ODM's be able to decide who is a smart root user and stupid root user? (And regardless their decision, why should we believe them?) There may not be an answer here, but the discussion is interesting also from a political point of view. How much should the "government" be responsible for a certain individual's action, regardless of their intelligence? Personally I think they're not, and should only provide security to prevent individuals from directly hurting each other, and not preventing them from hurting themselves, if they choose to do so.
Click to expand...
Click to collapse
Really, I dont want to do this again, this conversation.
Most stupid people don't realize they are stupid, they assume they are smart. (We are all stupid in some regards).
I think I could endanger a user from root, pretty sure I can either screw the phone up, or possibly catch it on fire. If it had a sim in it, and was on the network I am certain I could make them regret ever rooting their device.
Here is a question, how many of you understand how these unlocks/exploits work?
I sometimes leave messages hidden in mine, and have only had ONE person reply to the hidden message, out of 100,000s of runs. People don't even know what they are running to gain root, let alone any idea what these "rom devs" do.
Open source is the answer right? Everyone can read the code, and everyone does! Thats why no backdoors or vulns have ever been in open source projects. Every open source project gets a line by line audit by a team of security professionals.</sarcasm>
I'll join back in when someone shows me a custom rom/open device that has the same or better security precautions taken by leading ODMs. Until then, it is generally just as easy or (generally) easier to abuse and exploit one of these custom roms floating around.

stefeman said:
Reading all this, it makes me wonder if the antivirus apps help at all..
Click to expand...
Click to collapse
Won't help a lick for anything originating from a government.

Will we ever have full control of our devices without fighting?

With the continuing checks, big developers (Ahem, Samsung, Netflix, Snapchat) keep putting out to block rooted devices and th list of apps rooted devices can't use keeps increasing. Personally, I find it hard to use a non-rooted device, due to the fact I like having data access, full system access, and overall control of my battery. Though for the first time, I'm finding it a royal pain that my device doesn't pass safetynet. It makes me wonder a few things.
A. What does the future hold for those who want to actually have full control of their devices? Eventually, I could forsee most apps requiring SN.
B. If Linux is inherently more secure, and we can gain root access there, why not on a phone running Android?
C. What can we do to fight back? Am I the only one who would laugh if all these companies got Mr. Roboted over this kind of restriction?
What are your thoughts?

hkbladelawhk said:
With the continuing checks, big developers (Ahem, Samsung, Netflix, Snapchat) keep putting out to block rooted devices and th list of apps rooted devices can't use keeps increasing. Personally, I find it hard to use a non-rooted device, due to the fact I like having data access, full system access, and overall control of my battery. Though for the first time, I'm finding it a royal pain that my device doesn't pass safetynet. It makes me wonder a few things.
A. What does the future hold for those who want to actually have full control of their devices? Eventually, I could forsee most apps requiring SN.
B. If Linux is inherently more secure, and we can gain root access there, why not on a phone running Android?
C. What can we do to fight back? Am I the only one who would laugh if all these companies got Mr. Roboted over this kind of restriction?
What are your thoughts?
Click to expand...
Click to collapse
Yes we will have control
You actually already do ,but to make future things ,you must be at the front on the line. Or in a leadership or position of information or power.
If you have the right intelligence... You can do anything.

solarsoap said:
Yes we will have control
You actually already do ,but to make future things ,you must be at the front on the line. Or in a leadership or position of information or power.
If you have the right intelligence... You can do anything.
Click to expand...
Click to collapse
Care to expand?

hkbladelawhk said:
Care to expand?
Click to expand...
Click to collapse
Expanded
I'm currently working on a ROM and a kernal basis to give a base control starting point.
If we segment and completely remove the manufacturing sector right from the beginning. We then have software control of the free source which they also have control.
If we can program without any manufacturing interference and eliminate the user screw up down to a minimal level ,we can be in base control.
The bases of a ruled followed release. Simple stripped down measures. Starting with the kernal.
Take any kernal and strip out all of the manufacturing segments and drivers right from the beginning. Get only the basics loaded and stable.
That would first solve allot of confusion.
If we can boot it we can run it.
That is one example.
I'm currently setting up the guidelines to help everyone who helps me in the dream project to make the base kernels and base ROMs avalible.
I have a blog started and updating the information as I make spare time.
I have no one helping me as of yet.
I don't know where and how to post the information on this forum thing as of yet.
We will never be in control of certain elements...
For 1 specific reason.
National Security trumps our civil liberties. A countries security rules above all else. They force certain things to take place regarding safety.
That negates anyone's freedoms ,because your freedoms can jepordize security.
Even in the programming and manufacturing sectors of any device or invention.
Open source is about as free as you can get
Please forgive spelling errors and other things
Thank you.

Remote Code Execution in media framework. Severity: critical

From https://source.android.com/security/bulletin/2017-12-01 --
The most severe vulnerability in this section could enable a remote attacker using a specially crafted file to execute arbitrary code within the context of a privileged process.
Thoughts on this one, guys?
Any possibility this could be mitigated somehow, short of tossing the Android device in the trash and buying an iPhone instead?
In particular, is there any way to just disable the mediaserver or whatever altogether? It would be much better to not be able to play videos, than the possibility of any video pwning your entire device, no?

Vulnerabilities like these are patched almost every month (just have a look at the bulletins of the months before), so this one doesn't seem any worse than those that have been there before. To the best of my knowledge, neither of these have ever been exploited in the wild - not even Stagefright back in 2015, according to Google: https://www.theregister.co.uk/2017/02/15/google_stagefright_android_bug_zero_success/
Note that the security bulletin you linked to also states the following:
"The severity assessment is based on the effect that exploiting the vulnerability would possibly have on an affected device, assuming the platform and service mitigations are turned off for development purposes or if successfully bypassed."
Click to expand...
Click to collapse
I hope they can't be bypassed too easily...
What I don't understand is what 'privileged' means here. Does it mean 'root' or does it relate to Android app permissions? The former sounds much worse, and I'd find it alarming if the media framework stuff would (still) run as root (or something similar). Would be great if someone could clarify this.
As I tend to be kinda paranoid when it comes to computer security, I'm also always worried by issues like these, but my impression is it's probably something we have to live with :-/
In particular, I don't see a reason to believe the iPhone is more secure (apart from the fact that it receives regular updates in contrast to most Android phones...)
One would probably be better off with a system that is so exotic that no one would bother to develop an exploit for it - unfortunately, I haven't found one so far...