Related
Hi.
I recently came across some chinese / asian websites which kang / modify and release a diversity of roms.
I'm not specifying sources / which roms are, this is a general announcement to be careful with what we download & flash into our devices, and why ?
I flashed in order to test some of these roms (not the sense 5 kang tho), since I work in network security, I had noticed on our firewall logs when my mobile connected through the wifi, a bunch of UDP requests / DNS queries to russian websites. This can be used to botnets, DoS, even malware / spam propagation (a diversity of not cool stuff, basically).
A colegue of mine which also has a 'droid had once an app which sent repeatedly ICMP requests in "not random" but specific hours / intervals, he asked me to test his rom which he downloaded and flashed from "another" website, and I confirmed the suspicious behavior. There was established connections to foreigner addresses through a diversity of protocols, data being sent / received and at times, a udp flood directed to specific addresses. This is bad, my friends.
We don't know what these roms have inside, what's their mechanism besides the standard transparent operations which most of us are familiar with, and they could be very well used to do illegal things which I guaranty we don't want to be part of.
Flashing a rom, connecting through 3G or Wifi, and then our mobile is now part of a botnet which participates without our knowledge on such illegal operations is just one of the things that could happen. Phishing is also very possible - in other hand, a lot of things are possible without our knowledge and consent. We don't want this do we ?
The last Rom which I have experienced this, the link was removed and is no longer online. So i'm not pointing URL's / Rom names because this is something that each one of us has to be careful about.
Fortunately we have ways to detect / avoid / remove and make sure our device is used only for us and does only what we "tell" it to do.
We can use this thread to report such roms (since they're not published on xda, we can only warn each other and be aware) and applications that have malicious content.
I'll also be updating this thread with methods, applications for android to detect malware / suspicious activities (I'm not going into depth like using a sniffer or protocol / packet analyzer (although we can) I'll try to keep as simple as possible.
Suggestions, reports are very welcome and should be reported here. We can use this thread to protect our droids and help each other making our devices secure.
This post has the intention of protecting ourselfs, but privacy tips / applications are also welcome. Be careful tho, would be ironic to suggest an app to protect user privacy and in the end the app itself sends private data to GodKnowsWhere.
To be continued / Updated Soon.
List of Applications to monitor / analyze traffic:
Netstat Professional - Allows you to see what connections your android has established. Allows whois info, Real time IP / Port and status information (pretty much like netstat -an), and what service is running / port information.
Wi.cap. Network Sniffer - Much like a network protocol analyzer / network sniffer. This neat app allows you to see what connections are estabilished / protocol / status / analyze packets. If there's a connection estabilished - it will be listed. [Root needed]
Shark for Root - Traffic sniffer for 3G & Wifi (supports FroYo tethered mode too). Records traffic which later you can open with WireShark. To preview you can use Shark Reader.
List of Applications fo scan for malware.
Coming Soon...
Procedures to discover / analyze / report malware / suspicious behaviours and such.
Coming Soon...
Post reserved for procedures which will include:
- Common Sense
- How a malware works (the term malware is used to include viruses, trojans, custom scripts and apps.
- What to look for / suspicious behavior which you should pay attention to (also included in Common Sense).
- Basic tools to detect / analyze / remove malware.
More to come.
Sent from my HTC Z710e using xda premium
Generally, i suggest to use ROMs from XDA only, except for CM/MIUI official website. The risk is real! Thanks to @MidnightDevil for his help and his time
I suggest to read this thread to all the users!
XxXPachaXxX said:
Generally, i suggest to use ROMs from XDA only, except for CM/MIUI official website. The risk is real! Thanks to @MidnightDevil for his help and his time
I suggest to read this thread to all the users!
Click to expand...
Click to collapse
Thank you for your support
If anyone has suggestions / knowledge about this sort of matter please share
There's a LOT of info that I tend to post on this thread in a way to educate / share knowledge with everyone.
Trusting the developers and sources is the first step for prevention. Be careful with dodgy websites and roms which you don't know about.
Scanning the rom zip file with a virus scanner is useless in this matter.
Unknown Rom
The threat is over when a secure rom is installed (after using a none xda rom) ??
MidnightDevil said:
Thank you for your support
If anyone has suggestions / knowledge about this sort of matter please share
There's a LOT of info that I tend to post on this thread in a way to educate / share knowledge with everyone.
Trusting the developers and sources is the first step for prevention. Be careful with dodgy websites and roms which you don't know about.
Scanning the rom zip file with a virus scanner is useless in this matter.
Click to expand...
Click to collapse
phearell said:
The threat is over when a secure rom is installed (after using a none xda rom) ??
Click to expand...
Click to collapse
So far there isn't malware which persists after full wipe. Can't speak of the contents of the sdcard tho. But usually yes. But then you have the apk's which can contain malicious code and so forth...
Those apps are usually banned from the PlayStore, but there's a short window between published / report / removed from Store which users can download it.
Unless I didn't understood your post
MidnightDevil said:
So far there isn't malware which persists after full wipe. Can't speak of the contents of the sdcard tho. But usually yes. But then you have the apk's which can contain malicious code and so forth...
Those apps are usually banned from the PlayStore, but there's a short window between published / report / removed from Store which users can download it.
Unless I didn't understood your post
Click to expand...
Click to collapse
AFAIK google also scan apps installed on the device. When installing a 3rd party app (not via Google Play), you get a prompt to allow google to scan it anyway for malicious content.
Also, there are a couple of anti-virus apps available from well known companies such Avast for android, and also from AVG.
I never really tried those, but they might help protecting your device. However I doubt if they scan system apps/services, for in most cases they are supposed to be safe (from the OEM itself).
It is well known that the biggest security hole is the user. So the best thing to do is to keep away from unknown ROMs/sources.
astar26 said:
AFAIK google also scan apps installed on the device. When installing a 3rd party app (not via Google Play), you get a prompt to allow google to scan it anyway for malicious content.
Also, there are a couple of anti-virus apps available from well known companies such Avast for android, and also from AVG.
I never really tried those, but they might help protecting your device. However I doubt if they scan system apps/services, for in most cases they are supposed to be safe (from the OEM itself).
It is well known that the biggest security hole is the user. So the best thing to do is to keep away from unknown ROMs/sources.
Click to expand...
Click to collapse
No doubt the biggest flaw usually comes from the end user.
But answering your statemente about anti viruses.
Usually anti viruses (specially in portable devices) act base upon a database of known signatures and suspicious behavior. They provide no protection against a custom developed script or code with a work-around for this behavior. Basically - avoids behaving like a malware.
A code is considered malicious when acts upon suspicious behavior (for example, on windows - when an app registers itself on registry autorun / startup folders / tries to load a file on temp directory / temporary internet files, hooks itself into a process / uses a windows process to deliver it's payload faking a signature, etc etc). Knowing this, any custom app / script that avoids suspicious behavior / does not have a present signature on a AV database and a few more details - all doors are "open" and is a highway to hell.
Google scan engine uses the same mechanism, in fact, I'm not even sure if it has any sort of protection against suspicious behavior as it only executes upon apk install.
Believe me, the biggest flaw is the user as the best protection is also a well educated user. It's a matter of knowing what can do and what should avoid. Fear or suspicion is an important thing these days, as they prevent us from making mistakes as installing an app from a dodgy site. We should know better.
MidnightDevil said:
No doubt the biggest flaw usually comes from the end user.
But answering your statemente about anti viruses.
Usually anti viruses (specially in portable devices) act base upon a database of known signatures and suspicious behavior. They provide no protection against a custom developed script or code with a work-around for this behavior. Basically - avoids behaving like a malware.
A code is considered malicious when acts upon suspicious behavior (for example, on windows - when an app registers itself on registry autorun / startup folders / tries to load a file on temp directory / temporary internet files, hooks itself into a process / uses a windows process to deliver it's payload faking a signature, etc etc). Knowing this, any custom app / script that avoids suspicious behavior / does not have a present signature on a AV database and a few more details - all doors are "open" and is a highway to hell.
Google scan engine uses the same mechanism, in fact, I'm not even sure if it has any sort of protection against suspicious behavior as it only executes upon apk install.
Believe me, the biggest flaw is the user as the best protection is also a well educated user. It's a matter of knowing what can do and what should avoid. Fear or suspicion is an important thing these days, as they prevent us from making mistakes as installing an app from a dodgy site. We should know better.
Click to expand...
Click to collapse
I just remembered of an app called "Who is tracking" (was featured on the portal a while ago), that also scans system files (bloatware) and tells you which app tracks you. tried using it a while ago, but didn'y really try to understand it, and it seems to have changed since. will try it myself.
Agreed with Patcha, unless you 100% trust the source (CM/MIUI are well known and if they did something untrustworthy a massive ****storm would ensue) then I would stick to ROM's posted on XDA (though frankly I avoid MIUI out of moral principle #SouceCodeMuch?). Anything untrustworthy that is posted on XDA is picked up very quickly and dealt with effectively.
More to come from me on this, I need to organize what I want to say so it doesn't sound like a mad persons ramblings
Edit: A thing to look out for in google play store is the permissions, READ THEM, read what they mean, read what permissions the app requests and if you don't know why an app needs that permission or if it looks dodgy (like the permission to send sms messages without the user knowing) then for God's sake don't use the app util you've found out what the app needs that permission for (quick google search or email to the developer). Don't just blindly agree to all the permissions without reading them.
These permissions are declared by the developer in the Android_manifest.xml file and pulled from there when publishing the app on play store. As far as I am aware, there is no way to fool this system - you can't edit the visible permissions through the developer panel of play store, only by editing the manifest - I have a developer account on play store so this I am 100% sure on.
Yup, very true. Something I forgot to mention earlier and is VERY important.
Always check the permissions and what for the permissions are used. Some good developers write what for they need the permissions. Some things are obvious, others not so quite.
Also reading the comments of an app helps as well. More experienced users tend to write a more complete review and sometimes they draw the attention to things that sometimes other users miss. About permissions or anything else.
Any user can write a review, so if you find something important, you can also write in the review. Just make sure you don't underrate an app because of a doubt
Usually developers also have their contact email in case of doubts, it can be used to to bring some things to light.
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
CVE-2014-3153 was published 5 June 2014.
Affected Kernels: <= 3.14.5 (see specifics)
Affected Devices: Multiple!
As of last night, security researcher @geohot proved that the Samsung Galaxy S5 from AT&T
was vulnerable, by gaining root. He also believes the Verizon version is affected.
The details of this can be found here:
http://seclists.org/oss-sec/2014/q2/467
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3153
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3153
http://www.reddit.com/r/netsec/comments/27fl04/another_linux_kernel_exploit_this_time_reachable/
The description of the vulnerability is best described by the comments from the experts themselves:
From seclists.org:
Pinkie Pie discovered an issue in the futex subsystem that allows a local user to gain ring 0 control via the futex syscall. An unprivileged user could use this flaw to crash the kernel (resulting in denial of service) or for privilege escalation.
Click to expand...
Click to collapse
Specifically, the futex syscall can leave a queued kernel waiter hanging on the stack. By manipulating the stack with further syscalls, the waiter structure can be altered. When later woken up, the altered waiter can result in arbitrary code execution in ring 0. This flaw is especially urgent to fix because futex tends to be available within most Linux sandboxes (because it is used as a glibc pthread primitive).
Click to expand...
Click to collapse
This is a serious flaw from all levels, as one commenter state:
Indeed. This is probably the biggest security flaw in Linux in the past 5 years (if not the biggest ever) since it allows a full kernel compromise even from extremely tight sandboxes...
Click to expand...
Click to collapse
Or as user gsuberland writes and explains in this Reddit thread:
Ok, so I read the code, and I think I know what's happening. A futex is a "fast usermode mutex", which is kind of locking mechanism for memory pages that prevents bad things like two threads writing to a page at the same time.
There's a function in the implementation called futex_requeue(), which "requeues waiters from uaddr1 to uaddr2". I'm not really sure what that means, but basically uaddr1 is the address of a source futex in user-mode memory, and uaddr2 is the address of a destination futex in user-mode memory. But, because it was assumed that they'd always be distinct, the code provisions a bunch of stuff expecting to have two objects to deal with, and in the end some of them are just left there doing nothing - they point to uninitialised structures or memory.
Basically, the trick is that if you get a futex and call futex_requeue() with your futex as both uaddr1 and uaddr2, the structure that describes the futex (in user-mode memory, which you can access) is left with "dangling pointers", i.e. pointers to memory that hasn't been allocated yet. By then looking at those pointers and allocating memory to the locations it describes, you can write your own stuff there. Once execution passes down to kernel-mode, you've essentially got a situation where kernel-mode code is using data that you control, but in a context where it expects the data to be trusted. This could lead to all sorts of nasty stuff like read-what-where or write-what-where conditions, which can be used to privesc.
I probably got some of this wrong so don't quote me, but hopefully I at least described the core of the issue correctly.
EDIT: Also, I don't know why this is linked to as an "exploit". The Chrome bit makes sense once you read OP's comment about the sandbox escape - basically Chrome didn't restrict certain futex-related calls which could be used to trigger this bug. I still don't know how exploitable it is, though, or which vector would be used to exploit it. As far as I can tell it's just a "this is probably bad" situation until someone finds kernel-mode futex code that can be messed with by crafting data to coincide with the dangling pointers. Feel free to correct me if I'm wrong, though.
Click to expand...
Click to collapse
Since geohot said he wouldn't be releasing the exploit publicly, can we talk a bit of methodology/implementation. I for one would really like to get this moving forward for those having att & vzw. Basically, what do we need to do to trigger the futex_requeue error utilising chrome?
ks3rv3rg said:
Since geohot said he wouldn't be releasing the exploit publicly, can we talk a bit of methodology/implementation. I for one would really like to get this moving forward for those having att & vzw. Basically, what do we need to do to trigger the futex_requeue error utilising chrome?
Click to expand...
Click to collapse
Did I read right that it said you need a ChromeOS to be able to trigger it?
ks3rv3rg said:
Since geohot said he wouldn't be releasing the exploit publicly, can we talk a bit of methodology/implementation. I for one would really like to get this moving forward for those having att & vzw. Basically, what do we need to do to trigger the futex_requeue error utilising chrome?
Click to expand...
Click to collapse
kprice8 said:
Did I read right that it said you need a ChromeOS to be able to trigger it?
Click to expand...
Click to collapse
You do not need to execute this through Chrome. It is a generic flaw in the Linux kernel, that happens to be shared on many, many Android devices. I have been studying this for the Razr M (vulnerable), and have been coming up with theories how to implement this...
Basically, the futex_requeue error allows a segment of code to be written to memory, and then executed as root. This means that you can modify system files through this error, meaning that you can write scripting that will gain root, save it to the memory, and execute it.
I am trying to implement this on my Razr M, and have even more incentive seeing that it was used of the Galaxy successfully. I don't have a lot of experience in this area, but am researching a lot and have a couple of theories to try out.
I should note that this is just my understanding on the exploit, and I am only in the very early stages researching it... I could be completely wrong.
For those wanting to root a device using this vuln:
I don't believe this is a good vulnerability to target Android devices with, the difficulty is beyond most of us (myself included), and the success rate is going to be rather low on all/many/most devices. A more successful approach would be to spend the research time seeking another vulnerability.
ks3rv3rg said:
Since geohot said he wouldn't be releasing the exploit publicly, can we talk a bit of methodology/implementation. I for one would really like to get this moving forward for those having att & vzw. Basically, what do we need to do to trigger the futex_requeue error utilising chrome?
Click to expand...
Click to collapse
Chrome is not needed, Pinkie Pie used this vulnerability in conjunction with Chrome vulnerabilities when collecting a Chrome bounty (I could be wrong, I'm assuming without researching).
kprice8 said:
Did I read right that it said you need a ChromeOS to be able to trigger it?
Click to expand...
Click to collapse
No, see above
xKroniK13x said:
You do not need to execute this through Chrome. It is a generic flaw in the Linux kernel, that happens to be shared on many, many Android devices. I have been studying this for the Razr M (vulnerable), and have been coming up with theories how to implement this...
Basically, the futex_requeue error allows a segment of code to be written to memory, and then executed as root. This means that you can modify system files through this error, meaning that you can write scripting that will gain root, save it to the memory, and execute it.
I am trying to implement this on my Razr M, and have even more incentive seeing that it was used of the Galaxy successfully. I don't have a lot of experience in this area, but am researching a lot and have a couple of theories to try out.
I should note that this is just my understanding on the exploit, and I am only in the very early stages researching it... I could be completely wrong.
Click to expand...
Click to collapse
Can you test my Pie exploit on that device?
jcase said:
For those wanting to root a device using this vuln:
I don't believe this is a good vulnerability to target Android devices with, the difficulty is beyond most of us (myself included), and the success rate is going to be rather low on all/many/most devices. A more successful approach would be to spend the research time seeking another vulnerability.
Chrome is not needed, Pinkie Pie used this vulnerability in conjunction with Chrome vulnerabilities when collecting a Chrome bounty (I could be wrong, I'm assuming without researching).
No, see above
Can you test my Pie exploit on that device?
Click to expand...
Click to collapse
Yes, I am willing to test it, however, I believe it is confirmed not working for the 2012 Droid series (HD, MAXX, M).
Sent from my XT907 using Tapatalk
xKroniK13x said:
Yes, I am willing to test it, however, I believe it is confirmed not working for the 2012 Droid series (HD, MAXX, M).
Sent from my XT907 using Tapatalk
Click to expand...
Click to collapse
Let me know, it was working a few months ago but may have been patched
Sent from my MotoX+1 using XDA Premium 4 mobile app
jcase said:
Let me know, it was working a few months ago but may have been patched
Sent from my MotoX+1 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
I believe it was patched with the KK update, but I'll let you know later today. If you have anything else to test just let me know!
Sent from my XT907 using Tapatalk
---------- Post added at 11:30 AM ---------- Previous post was at 11:13 AM ----------
jcase said:
Let me know, it was working a few months ago but may have been patched
Sent from my MotoX+1 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
It indeed failed,
Code:
rm failed for /data/local/atvc/blop.asec, No such file or directory
rm failed for /data/local/atvc/blop, No such file or directory
If there's any other ideas, let me know, I'd be glad to help. We can also move to PM's if you would prefer. :good:
xKroniK13x said:
I believe it was patched with the KK update, but I'll let you know later today. If you have anything else to test just let me know!
Sent from my XT907 using Tapatalk
---------- Post added at 11:30 AM ---------- Previous post was at 11:13 AM ----------
It indeed failed,
Code:
rm failed for /data/local/atvc/blop.asec, No such file or directory
rm failed for /data/local/atvc/blop, No such file or directory
If there's any other ideas, let me know, I'd be glad to help. We can also move to PM's if you would prefer. :good:
Click to expand...
Click to collapse
Those errors are meaning less, just pre-emptive clean up. If it didn't work, it is probably patched
jcase said:
For those wanting to root a device using this vuln:
I don't believe this is a good vulnerability to target Android devices with, the difficulty is beyond most of us (myself included), and the success rate is going to be rather low on all/many/most devices. A more successful approach would be to spend the research time seeking another vulnerability.
Click to expand...
Click to collapse
How do you know how difficult it is, if you haven't done it?
Most of the time difficulties are overcome by new ideas and fresh angles.
And all of the time I am wondering who you "actually" work for?
And now I wonder how the #$^# (mod edit) you can be more "successful" looking
for unknown vulnerabilities, when you have a great one already sitting
on your desk?
Basically you're saying; if you venture out to planet X and look for new fish in
the oceans there, you're less likely to go hungry, than if you figure out how
to cook and eat the one in your home aquarium. I just don't understand why
you would say such a thing.
E:V:A said:
How do you know how difficult it is, if you haven't done it?
Most of the time difficulties are overcome by new ideas and fresh angles.
And all of the time I am wondering who you "actually" work for?
And now I wonder how the #$^# (mod edit) you can be more "successful" looking
for unknown vulnerabilities, when you have a great one already sitting
on your desk?
Basically you're saying; if you venture out to planet X and look for new fish in
the oceans there, you're less likely to go hungry, than if you figure out how
to cook and eat the one in your home aquarium. I just don't understand why
you would say such a thing.
Click to expand...
Click to collapse
For one, if you want your threads to stay open, don't curse at mods giving you accurate advice.
I know it is difficult because I spend all day researching android security and actually looked at it?
Who I work for is well public, it was even published on XDA's portal. As they say, the search feature is your friend. Who do you work for? Since mine is public, and you questioned mine, I think you should make your's public.
How you can be more successful? Because for most people capable of developing at futex exploit, it would take less time locate an easier vulnerability. Even GeoHot took 4 days to develop his futex exploit, and it has something like a 10% success rate. I do believe his skill level in this field is beyond most of the people posting in this sub forum.
If you go to planet X, and you see a fish that is obviously extremely hard to catch by looking at it, and it is also slippery so once you catch it it might escape, or you see a bunch of trees that probably have plenty of bananas if you go an Look. Where do you go for your food supply? Do you spend a months trying to eat the fish, or a few hours picking bananas? Of course you go and find the bananas.
jcase said:
For one, if you want your threads to stay open, don't curse at mods giving you accurate advice.
Click to expand...
Click to collapse
You know that I know better, than cursing at the mods I most often find helpful.
That is just a quirk of English, that "you" can be very personal or it can be
the completely opposite. I was simply Cursing out Loud. (CUL?)
Anyway, I have the right to question such statements regardless of their origin. And at that, it was not clear at all that you actually had been looking closer at it. BTW. I don't really care who you work for. Just a flash in my mind, that I should have kept to myself.
Thanks anyway.
Can people please quit arguing and just find a mostly successful exploit? No good is coming from any of this. Every thread I read is 90% bickering and 10% people volunteering to test when a method is ready. If I knew anything about how this stuff works I would be too busy digging to post complaints. Just saying.
weasel87 said:
Can people please quit arguing and just find a mostly successful exploit? No good is coming from any of this. Every thread I read is 90% bickering and 10% people volunteering to test when a method is ready. If I knew anything about how this stuff works I would be too busy digging to post complaints. Just saying.
Click to expand...
Click to collapse
Everything is cool now. There's a lot of stuff bubbling under that will surely surface soon. Some which already have. Just search XDA for "S5 root".
"..There's a function in the implementation called futex_requeue(), which "requeues waiters from uaddr1 to uaddr2". I'm not really sure what that means, but basically uaddr1 is the address of a source futex in user-mode memory, and uaddr2 is the address of a destination futex in user-mode memory. But, because it was assumed that they'd always be distinct, the code provisions a bunch of stuff expecting to have two objects to deal with, and in the end some of them are just left there doing nothing - they point to uninitialised structures or memory.
Basically, the trick is that if you get a futex and call futex_requeue() with your futex as both uaddr1 and uaddr2, the structure that describes the futex (in user-mode memory, which you can access) is left with "dangling pointers", i.e. pointers to memory that hasn't been allocated yet. By then looking at those pointers and allocating memory to the locations it describes, you can write your own stuff there. Once execution passes down to kernel-mode, you've essentially got a situation where kernel-mode code is using data that you control, but in a context where it expects the data to be trusted..."
aah, terminal - "man futex" .. the man pages -
http://man7.org/linux/man-pages/man2/futex.2.html
how it ties in with the mobile phones, it has to do with the network sockets within the android (linux) kernel..
even the nexus 5 is reported to be issued an security update in relaton to this - https://community.sprint.com/baw/thread/163896 & that's only labeled a *security patch*...
these socket views came up some years ago, in the gnome d.e. & was asked about, & they're all related to network timing sockets -
What is the “Waiting Channel” of a process?
~good link~
you could actually see them, then analyze them later with the netstat command, & see the process in action via **cat /proc/some_pid/stack** in a shell..
in the upper userspace, you can *feel* it on action on your phone;
especially on a nexus 5 on sprint -
it's single path at a time triband rf chip when it lulls to/from lte to 3g at times, some ppl complain they see a *telephone calls unavailable now* or something to that nature,
or wifi that won't catch when turned on
or an lte signal that simply won't latch, keeping them stuck on 3g..
underneath in that chipset, it's like a human mind processing a blank for a few trying to decide before acting,
** it's that dead moment**
right then, that this issue speaks of, like below from that gnome link in '10..
1.A task can be either a Process3 or a Thread2
2.A Thread is a sub-section of a Process. Many threads can run parallel
3.A process is a full-blown program, it consists of one or more threads, though a program can consist of multiple processes as well.
4.Remember, this is still a very high level view of things, it's not considering the implementation details
•
__skb_recv_datagram
Wait for some data on a locked network socket.
•
sk_wait_data
Wait for some data on a network socket.
•
do_exit
This is the last part of quitting a process. do_exit() calls the schedule() next, to schedule another process. When do_exit() is called, the process is a ZOMBIE.
•
do_wait
A process is added to the schedulers wait queue.
•
pipe_wait, unix_stream_data_wait
A Process is waiting for data from a subprocess. This happens, for example, when you run this sort of code:
ooh, the *top* command can expose the upper levels of those processes also!
you know when i can *see* it?
when i'm listening to music while riding the subway underground with my nexus 5;
as my signal changes between stops losing service, re-gaining it.. it effects the volume of the music, this morning, the train had to pause between stops in a tunnel, & my music player sounded kind of muffled but the music was, edible for my ears, that pause in the tunel, made the nexus 5 lose total signal, & BAM, that loss, of processing in the networking , gave me gain in volume with the music player!
it's related to one chip doing all the work...
xKroniK13x said:
You do not need to execute this through Chrome. It is a generic flaw in the Linux kernel, that happens to be shared on many, many Android devices. I have been studying this for the Razr M (vulnerable), and have been coming up with theories how to implement this...
Basically, the futex_requeue error allows a segment of code to be written to memory, and then executed as root. This means that you can modify system files through this error, meaning that you can write scripting that will gain root, save it to the memory, and execute it.
I am trying to implement this on my Razr M, and have even more incentive seeing that it was used of the Galaxy successfully. I don't have a lot of experience in this area, but am researching a lot and have a couple of theories to try out.
I should note that this is just my understanding on the exploit, and I am only in the very early stages researching it... I could be completely wrong.
Click to expand...
Click to collapse
you know, since yesterday, i've been thinking, & pondering about this exploit, it's not the same as on desktops, many processing calls DO makes Lo (or loopback / 127.0.0.1 for window users) calls that don't hit the outside..
but with phones, these are different beasts, (they are networking animals) their design is currently for TOTAL world facing calls to the outside, mostly, & with android phones which this exploit adresses, & with the newer qualcomm chips being single pathed, that plays a significant part in this..
the post i made on how to overcome the ecsbf issue - http://forum.xda-developers.com/google-nexus-5/help/nexus-5-e-csfb-issue-t2729014 which i DEARLY wanted participation, but i think it went clean over everyone's heads, even the mod that closed it, it was relating to the how these chipsets interact with the network at hand (sprint's)
the biggest issue with the chipset was that it was an asymmetric multiprocessor, i mentioned it before - http://forum.xda-developers.com/showpost.php?p=52708292&postcount=15
in the last link i posted (What is the “Waiting Channel” of a process?), that guy stated -
"..If you really want more detailed information you could check the kernel source.
If you type cat /proc/some_pid/stack in a terminal you'll get some output like that one :
[<c0227f4e>] poll_schedule_timeout+0x3e/0x60
[<c022879f>] do_select+0x55f/0x670
[<c0228f40>] core_sys_select+0x140/0x240
[<c0229241>] sys_select+0x31/0xc0
[<c05c9cc4>] syscall_call+0x7/0xb
[<ffffffff>] 0xffffffff
And on the first line you get what's displayed on the system monitor. As far as I know, poll_schedule_timeout indicates that your process is waiting for something.
It deals with asynchronous I/O and polling..."
reference - Asynchronous I/O
...............
android is linux at it's heart, & what does linux have as a stateful firewall, yes, **iptables** built into the kernel!
we have to find out what effects this exploit has on the stateful tables in the kernel to create the gateway for the exploit(s) ..
has to be the tables, with the single chipset qualcomm has unleashed, 3g (gsm / cdma) switching to & from lte, & wifi, presents a new ip address everytime, it's NEVER the same IP addy while in wifi, 3g or 4g.. & how many times within **an hour** does a phone switches just between 3g & 4g?
we have to find out how futex_requeue() effects iptables..
i have to give credit to another poster today, which made me post what i suspected, he found this gem -
"..I think i've found an acceptable explanation from another site for z4root and it must be almost the same with towelroot:
What z4root (or any other rooting program) does it runs some exploit to change its own uid (user-id) to 0 (root). You can think of it as of performing some kind of hack and tricking kernel into thinking it actually has the right to be root (then if z4root was a virus it could do everything with your phone from installing keyloggers to bricking it). Of course if it is possible to trick kernel in such a way to give you root access it is considered a security vulnerability (any app could do that and perform some malicious stuff) and usually gets fixed in future kernel updates (that's why z4root may not work if you upgrade your firmware).
When z4root has set its uid to 0 it does the following: remounts /system partition as writable (by default it's read-only), copies over su binary, Superuser.apk and busybox and then remounts /system back as read-only.
So how does the su binary give you root access without doing "the hack" thing when normally applications have same uid as parent process? This is because su binary has set-uid flag set and is always ran as uid 0 (root).
Now, if you have copied su binary over to /system/bin then you must have had root access which means you have to change owner/permissions (chown root:root /system/bin/su; chmod 6755 /system/bin/su). .."
from - http://forum.xda-developers.com/showpost.php?p=53492633&postcount=71 (i'm going to thank him after this post)
we know busybox on the linux desktop is simply a window manager, like fluxbox, like what i use, openbox, or metacity, etc, they all make Lo calls...
this exploit is a 2-3 step exploit; it CAN'T have r00t privileges w/o 1st, gaining access, which means, it must 1st be granted r00t access to network sockets (**THE** MOST DANGEROUS THING TO GRANT) TO DO the rest...
towelroot is called a root *toolkit*... lol
but, if you snatch the *tool* from root toolkit...
imaleave it alone.. lol
it's not that towelroot, was **malicious by intent** ;
i don't believe so, it was coded with good intentions, it's just had, a nasty side effect; in a nutshell -
". . .the app runs some code, the code crashed [sic] android and leave it confused, in its confused state it thinks that the app should be root, then the app installs something to allow other apps to become root..."
‘Towelroot’ exploit reveals security nightmare for Android
me.. i like to understand HOW things work, see & study the source of why it fails, or why it does things better than whatever, before simply adding it in, w/o any understanding at all of how it work.. that's just me...
like if i'm to modify the radio on the nexus 5, do i understand HOW it works better than the older or newer radio? .. many would ask "should i"?
just take it on word from others that it just works, or an issue is what it is, ther's no way around it...
sorry, i'm not built like that..
Hi,
Where I download source of exploit using CVE-2014-3153?
Thanks
Alex
Anyone happen to know where a public exploit for this can be found searched google mainly sites that talk about it but it doesn't appear to be public so i assume its still a 0day.
Guess i better check my servers kernel version and see which one my vps is running i never checked but i was curious to see just never got around to it im that lazy to ssh into my vps.
ZaraByte said:
Anyone happen to know where a public exploit for this can be found searched google mainly sites that talk about it but it doesn't appear to be public so i assume its still a 0day.
Guess i better check my servers kernel version and see which one my vps is running i never checked but i was curious to see just never got around to it im that lazy to ssh into my vps.
Click to expand...
Click to collapse
I couldn't find the source to any, but it would be simple to check your kernel version and update it!
Sent from my RAZR M xt907 (KitStalk) using Tapatalk
Welcome everyone,
I am making a presentation about android security as a whole system and I'd like to ask you for little help.
As far as theory goes it seems there is enough clear information to find but to finish my project I need to show practical vulnerabilities of the system like an exploit ( I was thinking about showing a process of rooting ) or some kind of virus. Could you guys recommend to me something in this taste? 'Safe' malicious app and a way to monitor it.
Another idea of mine is to get control of android using pc but all I could think of was get 'the user' install an app which would get additional privilege to let control the system.
I was thinking of using android system on virtual machine - like this one: osboxes.org/android-x86
If you guys know some app which would let me monitor every movement in the system like even facebook app to show how many connections it does it would help me greatly.
Sorry if my English is not the best it is not my first language.
Thanks in advance Keve LiSipi
You could discuss the Anserverbot Trojan, which is used to infect non-virus applications and fetches the malicious payload. There exists a whole paper on the analysis.
To take control, you could look at the Stagefright vulnerability, you could use an exploit to get root shell on a device.
And also you can show the exynos abuse xploit
This may be stupid, but I couldn't find any resources regarding this. We have custom recoveries for android devices but why isn't there custom bootloaders like there is for PCs ? Like in the PC space we have the likes of reFind and gnu grub.
Thanks
There are some instances of alternate bootloader projects. Just that they are not popular,
[Bootloader] LK for Xperia T
LK for Xperia T LT30p Only - Unlocked Bootloader Required WARNING 1: This modification makes changes to the devices partition table. I (lilstevie) am not responsible for any damage to your device or data loss that may occur. WARNING 2: ICS...
forum.xda-developers.com
EFIDroid
EFIDroid is a easy to use, powerful 2ndstage-bootloader based on EDKII(UEFI). It can be installed one-click with the EFIDroidManager app. You can add/remove/edit multiboot ROM's. There's no special support needed by ROM's or RecoveryTools(no...
forum.xda-developers.com
The developer of EFIdroid stopped developing in 2019.
efidroid on Android 9 and 10 devices ? · Issue #152 · efidroid/projectmanagement
Hi, I just want to know if efidroid supports devices with 6 GB RAM and 64/128 GB Storage devices running Android 9 and Android 10 ? thanks.
github.com
Not to mention you would need OEM's to cooperate....
Thanks @karandpr for that github comment a lot of info there. Thanks @galaxys too. So a quick summary would be that the reason is that for the bootloader to work smoothly there has to be support from the kernel too, which the OEMs should do and probably would not. But I didn't think about the support in the kernel was an issue. That does seem to be a lot of work and I see the reason now.
al_l_en said:
Thanks @karandpr for that github comment a lot of info there. Thanks @galaxys too. So a quick summary would be that the reason is that for the bootloader to work smoothly there has to be support from the kernel too, which the OEMs should do and probably would not. But I didn't think about the support in the kernel was an issue. That does seem to be a lot of work and I see the reason now.
Click to expand...
Click to collapse
I don't think Google intends to open up android anymore. They want restrictions like iOS but pretend to be open source for the "goodwill". What's the use of AOSP if you cant effectively install it on a device or your important apps don't work?
I believe PinePhones are the ones that can have truly open-source compatible hardware. The specs are underwhelming but the community is really good.
You can get spares easily and the battery is removable.
Only thing is they are mostly out of stock.
karandpr said:
I don't think Google intends to open up android anymore. They want restrictions like iOS but pretend to be open source for the "goodwill". What's the use of AOSP if you cant effectively install it on a device or your important apps don't work?
I believe PinePhones are the ones that can have truly open-source compatible hardware. The specs are underwhelming but the community is really good.
You can get spares easily and the battery is removable.
Only thing is they are mostly out of stock.
Click to expand...
Click to collapse
Yeah those are great but the problem is that they are not usable for "normies" which will prevent mass adoption and hence cannot have a sustainable business model.
But I think google is not the only one to blame, like couldn't the OEMs actually provide bootloaders that can boot signed os images. Or is there any technical or security difficuties in doing that.
al_l_en said:
Yeah those are great but the problem is that they are not usable for "normies" which will prevent mass adoption and hence cannot have a sustainable business model.
But I think google is not the only one to blame, like couldn't the OEMs actually provide bootloaders that can boot signed os images. Or is there any technical or security difficuties in doing that.
Click to expand...
Click to collapse
Normies are afraid to change the default browser, so bootloader is really out of their leagues.
Phone tinkering is a hobby, not a necessity. Phone tinkering itself is not a sustainable model.
Google is to blame primarily. Because they have a stringent list of requirements for devices to pass CTS. You can read the bootloader requirement and judge yourself.
Android 11 Compatibility Definition | Android Open Source Project
source.android.com
Without passing CTS, devices cannot use Google apps, they cannot get push notifications and they cannot pass SafetyNet checks used by most banking apps.
At the end of the day do I want to spend 100s of hours to bring a feature to an android phone which will probably be used by 10 users and deprecated by the time I finish doing it?
or do I want to buy a phone which will allow me to tinker freely in a community and ecosystem which allows modification?
For our tinkering pleasures, Pinephone is the way to go for now. They have support from Manjaro, Debian and KDE. Which is a big thing IMO.
Or else there you can roll your thing in RaspberryPi?
While going through related details I found an article about google probably switching to hardware based safetynet checks which could be ending google play compatibility on custom roms.
It really seems like google is using security as an excuse to make sure that there are no competitors in their business space.
Maybe this is because I have been only doing web development and only started learning app dev, but the reasons google use for CTS like for enforcing DRM, is also handled on websites while allowing openness and being neutral (or maybe the web is not as secure as something like this, so forgive me if I am wrong). Android could really take pages off the web ecosystem for being a neutral platform.
I really appreciate the patience for hearing out and also the references(and the rabbit holes that it was followed by) really taught me a lot about general android architecture.
al_l_en said:
While going through related details I found an article about google probably switching to hardware based safetynet checks which could be ending google play compatibility on custom roms.
It really seems like google is using security as an excuse to make sure that there are no competitors in their business space.
Maybe this is because I have been only doing web development and only started learning app dev, but the reasons google use for CTS like for enforcing DRM, is also handled on websites while allowing openness and being neutral (or maybe the web is not as secure as something like this, so forgive me if I am wrong). Android could really take pages off the web ecosystem for being a neutral platform.
I really appreciate the patience for hearing out and also the references(and the rabbit holes that it was followed by) really taught me a lot about general android architecture.
Click to expand...
Click to collapse
Theoretically, Google can end GPlay compatibility on Custom ROMs anytime they wish. It's just that lot of App Developers don't use SafetyNet the way it is intended and Google doesn't roll out its strict check. They do it once in a while.
They don't have any competitors in their business space. It's a very well-thought monopoly.
CTS restricts Google Play API access to vendor operating systems. So vendors like Samsung, OnePlus and others have to play by their rules. IIRC, the cost of Play API is around 15$ per device but it is subsidized for large quantities.
End users don't really care about Play API. But App Developers do.
Without Play services, there is no easy way to integrate push notifications, ads, maps, analytics, metrics, and so on. Rolling your own thing will take years to develop and won't work as seamlessly as the play service counterparts.
I don't think Google will ever cede their monetary interests for open collaboration.
karandpr said:
I don't think Google will ever cede their monetary interests for open collaboration.
Click to expand...
Click to collapse
Yeah that's for sure. The only way this monopoly can break is when an opensource alternative to google play services and other apis exist and while doing that it must be compatible with the existing google apis. And that is probably not going to happen in a long time. Although microg does solve this to some extent, but still it is a second citizen.
Some of the functionality is already there, like most of the google apps like docs and drive could replaced by nextcloud and then maps could be replaced by osmand. If some company, preferably an OEM, comes and integrates all of these into a package maybe there's hope. I think /e/ os tries to do this to some extent.
You might find this resource useful. As they have gone over a comprehensive set of bootloader software and tried to outline their primary features in detail. Hopefully, you’ll be able to determine the best one for your use case. https://www.ubuntupit.com/best-linux-bootloader-for-home-and-embedded-systems/