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
Related
This is a continuation of this thread: http://forum.xda-developers.com/showthread.php?t=567870, which covered cracking the original "basic" copy protection of Marketplace.
---
I have now cracked the "advanced" copy protection used by Marketplace. As you may know, this is a "better" protection than the original "CAB copy protection" Marketplace offered. This "advanced" protection uses license keys that are verified when you run the application, and given out and controlled by Microsoft.
Several developers are annoyed that Microsoft does not allow us to use our own licensing schemes, and are forced to use "no protection" (the original CAB copy protection) or use Microsoft's scheme which is essentially a single point of failure for all Marketplace protected apps.
This new "advanced" protection was released today by Microsoft, and as far as I know no app available already uses it at the time of this writing.
So I got the code snippets you are supposed to put in your app and it was simply jawdroppingly WTF. While it was not exactly easy to beat, it took me less than two hours to devise a "generic" hack, without modifying any files on the device. (Well hey, at least it's better than the 5 minutes it took for the "basic" protection, right?)
A "generic" hack? Yes, by this I mean that this single hack (actually, running an EXE in the background) will completely bypass the entire code snippet provided by Microsoft that is supposed to check and validate your license code, for all Marketplace apps that use this "advanced" protection.
I will not publish the code that performs this hack, so don't ask. My goal is not to crack Marketplace apps, my goal is to get MS off their ass and allow us to use our own licensing systems, like the good little resellers they're supposed to be. I will tell you that it has to do with runtime patching the crypto API, but that's it. All in all, I don't think it will take long for the warez people to duplicate this hack.
---
Some further reasoning about anti-piracy, solutions, etc can be found in post 13 on page 2.
if there are no apps that use it yet, how do u know your hack works?
Because the Marketplace portal provides code ("code snippet") you have to compile in your EXE, and that takes care of the whole licensing thing.
So you look at that source, spot the weak points, devise a hack. Then compile a program using said "code snippet" and try the hack on it.
If developers simply copy/paste the snippet they are given by the Marketplace portal, this hack will work.
Chainfire said:
This is a continuation of this thread: http://forum.xda-developers.com/showthread.php?t=567870, which covered cracking the original "basic" copy protection of Marketplace.
---
I have now cracked the "advanced" copy protection used by Marketplace. As you may know, this is a "better" protection than the original "CAB copy protection" Marketplace offered. This "advanced" protection uses license keys that are verified when you run the application, and given out and controlled by Microsoft.
Several developers are annoyed that Microsoft does not allow us to use our own licensing schemes, and are forced to use "no protection" (the original CAB copy protection) or use Microsoft's scheme which is essentially a single point of failure for all Marketplace protected apps.
This new "advanced" protection was released today by Microsoft, and as far as I know no app available already uses it at the time of this writing.
So I got the code snippets you are supposed to put in your app and it was simply jawdroppingly WTF. While it was not exactly easy to beat, it took me less than two hours to devise a "generic" hack, without modifying any files on the device. (Well hey, at least it's better than the 5 minutes it took for the "basic" protection, right?)
A "generic" hack? Yes, by this I mean that this single hack (actually, running an EXE in the background) will completely bypass the entire code snippet provided by Microsoft that is supposed to check and validate your license code, for all Marketplace apps that use this "advanced" protection.
I will not publish the code that performs this hack, so don't ask. My goal is not to crack Marketplace apps, my goal is to get MS off their ass and allow us to use our own licensing systems, like the good little resellers they're supposed to be. I will tell you that it has to do with runtime patching the crypto API, but that's it. All in all, I don't think it will take long for the warez people to duplicate this hack.
Click to expand...
Click to collapse
amen
hallelujah
hit me now
YEAH
have given the issue some press : http://www.1800pocketpc.com/2009/11/13/marketplace-advanced-copy-protection-cracked-in-less-than-2-hours.html
anti-piracy protection is intended to stop ordinary users from transferring cabs between devices and it is successful at that. there is no protection that will stop apps from being pirated, certainly not for handheld devices. the new advanced protection is adequate and any further techniques are redundant and a waste of time, because no matter how 'strong' they are, they WILL be cracked.
Slightly if not totally off-topic: A mainstream consumer's view
mnet said:
anti-piracy protection is intended to stop ordinary users from transferring cabs between devices and it is successful at that. there is no protection that will stop apps from being pirated, certainly not for handheld devices. the new advanced protection is adequate and any further techniques are redundant and a waste of time, because no matter how 'strong' they are, they WILL be cracked.
Click to expand...
Click to collapse
I agree with you and your premise. Now a quick story.
I consider myself a mainstream consumer... but I have been a member of XDA for, what, i think 4 years, using 2 WM phones, first the T-Mobile MDA, then the Wing (HTC Herald), and I am about to switch to Android with the HTC Hero. I am reasonably savvy about tech, just not a coder. But I've done all the hard SPL, flashing ROMS, using beta software, and supporting developers here with pretty significant donations. I am also a User Experience / Usability designer for web as a profession. THAT'S MY BACKGROUND.
To date, my experience buying WM apps has been universally AWFUL. Whether it was, just recently, Resco Picture Viewer from PocketGear, or WM Defrag from Wizcode, or PocketPlayer from Conduits. I am more than happy to buy excellent software that works, and has a decent UI. But in each case, the process of buying the app and getting it onto my phone has been absurd, and frustrating beyond belief. Each provider makes all sorts of assumptions -- often wrong -- including "you must be downloading this from a PC, so we will download for you an executable that runs on a desktop PC then installs via active sync onto your device."
Whatever the percentage is, doesn't matter: A lot of people, like me, download all my cab files, and purchase apps, on my Mac... and either email myself the .cab file or .zip files, or place my microSD card from my phone into a USB reader. Thus, what a frikkin headache to end up getting PocketPlayer on my phone... but because i didn't download it from a Windows PC, I was screwed.
This stuff is archaic. This past week it has taken 5 days to get Resco Picture Viewer on my phone after purchasing from PocketGear.com . They have a completely retarded transactional process, a terrible UI, broken software in terms of user recognition and resetting username and password, and a completely phone-UNFRIENDLY site, with most sub-level menus not even accessible from browsers like Opera Mobile, Netfront, Iris ... They are dumbass pull downs using god knows what -- flash or javascript, whatever. But fact is: a simple navigation process to access the products on the phone itself can't even be achieved by these clowns -- yet everyone is in overdrive now trying to get their version of "THE" WindowsMobile app store online, while Microsoft stumbles.
The fact is: I would LIKE to see a uniform transaction process which is designed professionally, and supports great usability design, and once I buy the app, quit making me go through absurd backflips just to get access to the cab file. Stop requiring me to use a Windows PC. And stop all the "special OUR way" authentication processes. Because if they were so good, there wouldn't be the kind of problems I have described. I'll even grant anyone who wants to -- to say "well you're just a dumb**** user who doesn't understand their particular process"... I'll grant you that, and my answer would be:
If you plan to sell a lot of apps -- ie, make money via VOLUME transactions vs pricey apps -- a la iphone -- then it makes a hell of a lot of sense to make a uniform system of delivery if you're buying it through an app store, and for god's sake, cut the crap and figure it out. It's not so hard to send an authentication code via email or text message. But it's exactly WRONG to be having 1000 developers using 1000 special "our way" authentication processes, because the odds of 1000 app developers having a great, simple, effective UI and safe authentication system that prevents priacy of their app is pretty low, based on the experiences I have had to date with MAINSTREAM products for WM.
That's my view. But I see a whole lot of clumsiness from the Windows Mobile side of the fence pertaining to this whole new way of monetizing apps. There's a reason apple succeeds in that department -- even with their bloated catalog and draconian approval processes. They understand how to deliver products to consumers -- vs repelling them from a dumbass process, no matter how good that process may be in theory.
quicksite said:
I agree with you and your premise. Now a quick story.
I consider myself a mainstream consumer... but I have been a member of XDA for, what, i think 4 years, using 2 WM phones, first the T-Mobile MDA, then the Wing (HTC Herald), and I am about to switch to Android with the HTC Hero. I am reasonably savvy about tech, just not a coder. But I've done all the hard SPL, flashing ROMS, using beta software, and supporting developers here with pretty significant donations. I am also a User Experience / Usability designer for web as a profession. THAT'S MY BACKGROUND.
To date, my experience buying WM apps has been universally AWFUL. Whether it was, just recently, Resco Picture Viewer from PocketGear, or WM Defrag from Wizcode, or PocketPlayer from Conduits. I am more than happy to buy excellent software that works, and has a decent UI. But in each case, the process of buying the app and getting it onto my phone has been absurd, and frustrating beyond belief. Each provider makes all sorts of assumptions -- often wrong -- including "you must be downloading this from a PC, so we will download for you an executable that runs on a desktop PC then installs via active sync onto your device."
Whatever the percentage is, doesn't matter: A lot of people, like me, download all my cab files, and purchase apps, on my Mac... and either email myself the .cab file or .zip files, or place my microSD card from my phone into a USB reader. Thus, what a frikkin headache to end up getting PocketPlayer on my phone... but because i didn't download it from a Windows PC, I was screwed.
This stuff is archaic. This past week it has taken 5 days to get Resco Picture Viewer on my phone after purchasing from PocketGear.com . They have a completely retarded transactional process, a terrible UI, broken software in terms of user recognition and resetting username and password, and a completely phone-UNFRIENDLY site, with most sub-level menus not even accessible from browsers like Opera Mobile, Netfront, Iris ... They are dumbass pull downs using god knows what -- flash or javascript, whatever. But fact is: a simple navigation process to access the products on the phone itself can't even be achieved by these clowns -- yet everyone is in overdrive now trying to get their version of "THE" WindowsMobile app store online, while Microsoft stumbles.
The fact is: I would LIKE to see a uniform transaction process which is designed professionally, and supports great usability design, and once I buy the app, quit making me go through absurd backflips just to get access to the cab file. Stop requiring me to use a Windows PC. And stop all the "special OUR way" authentication processes. Because if they were so good, there wouldn't be the kind of problems I have described. I'll even grant anyone who wants to -- to say "well you're just a dumb**** user who doesn't understand their particular process"... I'll grant you that, and my answer would be:
If you plan to sell a lot of apps -- ie, make money via VOLUME transactions vs pricey apps -- a la iphone -- then it makes a hell of a lot of sense to make a uniform system of delivery if you're buying it through an app store, and for god's sake, cut the crap and figure it out. It's not so hard to send an authentication code via email or text message. But it's exactly WRONG to be having 1000 developers using 1000 special "our way" authentication processes, because the odds of 1000 app developers having a great, simple, effective UI and safe authentication system that prevents priacy of their app is pretty low, based on the experiences I have had to date with MAINSTREAM products for WM.
That's my view. But I see a whole lot of clumsiness from the Windows Mobile side of the fence pertaining to this whole new way of monetizing apps. There's a reason apple succeeds in that department -- even with their bloated catalog and draconian approval processes. They understand how to deliver products to consumers -- vs repelling them from a dumbass process, no matter how good that process may be in theory.
Click to expand...
Click to collapse
Couldn't agree more!
I'll add one more reason I wrap my head in ductape every time I download/install an app.
Think it's bad with every developer having their own authentication method? How about when each developer has a DIFFERENT authentication scheme for every app they make?
I like a rant - thanks for doing it for me as I agree with you 100%.
The top of my annoyance list (which you did include) are sites selling mobile software which are NOT mobile browser friendly, WTF is that all about?
Big Up, I still don't think anyone else would have done it in two hours.
Hey you warned them didn't you.
Haha Chainfire is there anything you cant do?
More in the Dutch press:
http://tweakers.net/nieuws/63713/nederlander-kraakt-nieuwe-beveiliging-windows-marketplace.html
While I do appreciate the "rant", I think you're missing my point - or perhaps I just don't agree. (Edit: that is in response to this post http://forum.xda-developers.com/showpost.php?p=4936479&postcount=7)
When I say "use our own licensing schemes", I do not mean codes sent back and forth through websites, screen you have to type stuff in etc. This is exactly not needed because Marketplace is also the delivery mechanism. In other words, the license code can be installed by Marketplace directly without the user ever seeing or hearing about it.
This is partly how the new system works, actually. However, if Microsoft supported license codes you give them things would be more secure (though granted, for a large part by obscurity).
Some authors will not care and simply not use it all, for example with the cheap apps it may not be worth their while. Others may wish to track license key usage, so that if suddenly 10.000 users start using the same key instead of the 1 who bought it, that key can be disabled, etc. Some may want the app to call home, some will not. Imagine that developers that do employ such anti-piracy measures will write their own verification / communication code, this beats the single point of failure we currently have. The crackers are back to having to crack each app independently and even then have a much lower chance of success.
Marketplace is the perfect opportunity to implement such a system that does provide some piracy security for the authors while for once it does not unnecessarily annoy the user.
To make the obligatory bad car analogy that fails in many ways, take you car keys. Everyone thinks it's normal to have a car key, so people can't just take your car. Of course, in line with some of the arguments against anti-piracy measures, car keys aren't really that useful, as there's always a brick - the universal key, and a car thief that really wants your car will get it. (You also lock the doors on your house, right?)
Now, the current situation is pretty much that everyone has the same car key. How useful is a car key in that situation? They way I see it (and I'm sure I'm not alone in that), is more like the actual car key situation. Some car keys are laser etched, or have something RFID-like in them and a receive in the car, or simply use different shapes, etc. That's a lot more useful than everyone having the same car key.
Sure, no matter what you do, eventually things will get cracked and it is a cat and mouse game. One of the reasons this is easily doable is because of the open nature and the very few restrictions of Windows Mobile. This is a good thing. No developer in their right mind would want to get to a restrictive system like is the case on the iPhone or other mobile OS's. That is not the point. That doesn't mean anti-piracy measures are useless though, far from it. The longer you can keep a release from being warez'd, the less you lose.
There are two arguments I hear coming back in various places by various people:
(1) If the normal users can't just copy it, then that is enough (even MS says this)
(2) Piracy works as advertising, you get more eventual sales, etc. etc
Both of these, are from my own experience, completely untrue. The thing is if one person cracks it, it usually spreads on those warez sites pretty quickly.
The big thing here is, the average user is apparently tech-savvy enough to search the warez sites first before buying, and that is just how it is:
We have played the game with that one warez site, monitoring sales when (apparent) cracks were listed and when they weren't (they do remove releases on request). This made a 30-50% difference in sales (with the number being highest during the weekends, and lowest during weekdays). For me that is enough data to know that both (1) and (2) are complete nonsense in the case of mobile apps. No matter all the pretty reasons and perhaps seemingly logical reasons you may come up with for (1) and (2), the numbers don't lie.
So, how would you like to get a 30-50% paycut? It's not like us developers are getting rich here, you know. Can we be blamed for trying to prevent this?
Now, here we have the chance to implement a system that is completely transparent for the user and can be made reasonably safe (and updatable), an obvious win-win situation for everyone involved except the warez people. Why exactly shouldn't we be aiming for this?
What is also painfully apparent here, as Microsoft themselves claim reason (1), that they have no idea what they are talking about.
i am no programmer so excuse my ignorance but doesnt everything eventually get cracked. Is there any mobile platform which hasnt a non cracked market place or sites where you can download paid apps for free?
Well done Chainfire
Hello Chainfire,
I am the webmaster of the Tamoggemon Content network, and just covered you:
http://tamsppc.tamoggemon.com/2009/11/13/advanced-marketplace-drm-broken/
http://tamswms.tamoggemon.com/2009/11/13/advanced-marketplace-drm-broken/
Furthermore, an email went out to MSFT asking for a statement. but this is not the reason why I registered here (!!!) - I am instead here to vent a bit being a Symbian dev myself.
While I fully understand your frustration, I think that allowing every developer to run his own DRM is not gonna do the store good. The reason is that the store was made to make purchasing apps simple - and by allowing everyone to run his own DRM I dont see much of a venue to do this anymore.
Whenever some kind of backend gets involved, there is a single point of failure - the only trhing I can think off now would be a very complet system based on servers.
Or, of course, platform security like on S60. But trust me - we wont want that!
Thanks! However, if you read my other post carefully you'd see it wouldn't make any difference to the ease of using the store (it wouldn't make any difference for the user at all), just to a part of the backend. And of course, each DRM system has a single point of failure, but the difference is in my case there is a point of failure per app, while in the current case it's a single point of failure for everything. There is no perfect solution, but there are better solutions than the current one.
I've been contacted by a handful of big WM devs by now who are of somewhat the same opinion.
microsoft.... when it comes to security, they are clueless as usual.
only apple is worse.
I find they windows-7 VPN and "encryption" funny , is there anybody that would trust it ? - even if it was not for the backdoors ?
Just wondering, is anyone else having problems accessing the windows marketplace from the phone? I was able to download a couple of apps yesterday after I installed a custom ROM (TPC Pro Series V3.2), but today I get a message saying there is an update, it installs the update but then I get the following message:
"Windows Marketplace for Mobile cannot connect right now. Try again later."
Is this because of the custom ROM and the latest update to the marketplace, or is this something other people are experiencing?
Remember the days when purchased mp3s were DRM protected and some companies like Sony even put rootkits on music CDs? Did that stop piracy?
Hopefully Microsoft will not repeat these mistakes... There is no need for any further 'protection' for marketplace apps. If a developer isn't satisfied with this mechanism then he/she doesn't have to publish their apps on the marketplace. There's no point in having a centralized app store if every developer uses his/her own licensing scheme.
I came across this article while surfing the internet. I wanted to share this with you guys, and see what your feelings were on this.
"Mobile Device Security and Android File Disclosure
Back in November, Thomas Cannon brought to light an issue within the Android operating system. Specifically, he found that it was possible to obtain the contents of files on an Android device by simply persuading its owner to visit a web site under attacker control. The issue only garners a 3.5 CVSS score, but yet it’s still fairly serious.
Thomas reported this issue responsibly to Google and they took it seriously. However, since then they have come back with a ridiculous remediation plan. Granted, its probably not entirely Google’s fault, but the overall situation looks very bleak for Android.
The problem is that Google stated that a fix will be available as part of an update to the upcoming Android 2.3. While that, in itself, may not be totally ridiculous, the reality of the situation is that Google is only one party involved in Android. There are two other groups, namely OEMs and Carriers, that must also do their part in getting the fix to users. Although Android devices are becoming increasingly functional, the security posture remains abysmal.
The security posture for desktop applications has improved vastly with all of the sand-boxing, automatic updates, and various other exploit mitigation technologies. Meanwhile, Android includes almost none of existing security protections. In fact, mobile users are being left out in the cold, unable to get a patch for a trivially exploitable cross-zone issue. For that matter, they can’t even control whether their device’s browser automatically downloads files or not.
This situation is not news, rather it is a sad fact. It is totally unfair for end users to be left out to fend for themselves. After all, they are paying a small fortune for these devices and the service to be able to use them. Hopefully the vendors involved will wake up before a network worm outbreak occurs.
Originally, Thomas disclosed the details of his bug on his blog. Later, he removed some details to help protect users. I believe that responsible disclosure is a two-way street that requires responsibility on both sides. Since Google, OEMs, and carriers all continue to act irresponsibly, it is necessary bring more attention to this issue and the situation as a whole.
I spent a little time and managed to recreate the issue with nothing more than HTML and JavaScript. As of today, I have released a Metasploit module to take advantage of the flaw. It is available in the latest copy of our Framework product, or you can view the source via the link to our Redmine project tracker above.
Before I go deeper into the consequence of this bug, I want to point out that Thomas outlined several workarounds for this vulnerability in his blog.
Now, take a deep breath give some thanks to the fact that, under Android, most every process runs under a separate, confined, unix-style user account. This design feature partially mitigates this issue, lowering confidentiality impact to “Partial” and bringing the CVSS score from 5 to 3.5. That said, an attacker can still gain access to some pretty interesting stuff.
For starters, an attacker can steal any world-readable file. In my tests it was possible to get potentially sensitive information from the within the “proc” file system. This type of information could include kernel versions, addresses, or configuration that can be used enhance further attacks.
Also, you can snarf any files that are used by the browser itself. This includes bookmarks, history, and likely more. This kind of information could potentially be embarrassing or possibly even give an attacker access to any saved passwords or session cookies you might have stored.
Perhaps the easiest win though, is that you can grab anything off of the SD card. You might ask, “Anything?! What about the user separation?” Well, because the SD card has been formatted with the “vfat” (aka “fat32”) file system, there is no concept of ownership. All files are owned by the same user id since the file system itself cannot encapsulate who created which file. As Thomas said, files in the SD card that have predictable names are ripe for the picking. This includes pictures and movies. These may in fact be some of the most private data on your device.
In conclusion, I hope that the Android security debacle will get resolved as soon as possible. If Google, OEMs, and carriers can’t work it out, perhaps another party will step in to maintain the operating system. I believe this could be very similar to the way various Linux distributions operate today. If the situation is not resolved, I fear the Android device pool could become a seething cesspool of malicious code..."
Here is the address
http://blog.metasploit.com/2011/01/mobile-device-security-and-android-file.html
Sent from my PC36100 using XDA App
Shocking. Thanks for the info.
Nice find. You are right that oems and manufactures need to stay on top to mantain security. Hopefully meaningful post like this will make users aware of the possible dangers of the internet, data, and phone usage
Sent from my ADR6300 using Tapatalk
Ouch. Wish Android updates were like iOS..
Android is open, one of the main assumptions is that there is no single company, which controls it. I could create my own phone with Android, sell it to people and give them no support at all - Google can't do anything about it.
There is only one solution to this problem: people have to choose their phones wisely. People look at phone specs, at CPU, RAM, camera, but they ignore future support and openess. Recently Motorola has stated they will lock bootloaders in their future phones. People will go for these phones anyway and then they will complain they can't do anything with some horrible bugs, they will complain about Android and Google, but they should complain about Motorola and themselves. While Nexus S owners will have same bugs fixed by both Google and community.
Choose your phones wisely.
SD with vfat...good catch. Horrible bug while many users trying to move their apps to SD. And maybe 80-90% of the apps in the market require modify SD card perm? Horrible. Verizon SGS is screwed since that phone have little internal and lots of external SD.
I'm so glad you guys came across this thread, and it didn't get lost in all the other threads. I hope some of the devs see it. Can a fix be implemented at the Rom or kernal level?
Sent from my PC36100 using XDA App
Good day community,
Over the past several months, a few of us have been working on a projerct some may be familiar with. We have bundled an add-on to specific BlueStacks versions to allow for a complete Operating System environment, full of communications tools.
We didn't "develop", any of it. We have taken the time to scour the internet and primarily this site to garner the education, information and knowledge to actually bring it to fruition. We would like to say a big THANK YOU to the entire community here. We feel this is am important piece to a software life-cycle where developed information is compiled into a fully functioning system, exposing your people's craftsmanship.
The motive here is a moral one. I have been a communications engineer for 22 years and have seen and done things I thought weren't possible. I have been tasked with trying to develop an education platform technology matrix for schools. Specifically using my innovation abilities to solve problems. I am not a coder, I am more of a script writer. I have found success in making disparate hardware and software work together, and producing middle-ware scripts and functions to technologically solve challenges. In every sector.
I believe I have identified one of the major issues related to student success rates. Basic communications is hindered in many schools, internet cut out, and dictator like classroom regime. I feel communications is the king of industry and whomever has the information the fastest, cheapest, and accurate, wins. This is proven time and time again in capitalism. I feel students should be able to sms, or exchange pictures and peruse social networks, both to each other and their teachers. These are real-world tools, and the primary back-bone of a child's social life. But students need to learn to be accountable for they digital actions,
This "OS" changes things ever so slightly., not every student can afford the gear required to have that type of communication. If every kid could afford an iphone and ipad, than I don't need to do this project. Android on the other hand, little or no cost at all.
I will be deploying Android for Windows across the board. Students will have to setup a Google account and online storage. Copies of AW can be had for their home computer. The environment is the environment kids all love and use, the emulated touch interface is "cool" and the kids can support it and maintain it mostly themselves, and sync it to their PC phones or other devices, but those are NOT required. And no need to upgrade the PC's for a while, BlueStacks is Linux(ish), it's hardware demands are low, and I can keep the PC's at there current level.
I distribute it on thepratebay, another long story for another day, but this is the best way to ensure it stays out there, and the price is right to be able to push it out to the world. We have tirelessly worked to ensure compatibility with the apps the devs release and I know this particular release of AW has restored many of the items BlueStacks cripples
We have started a mini marketing campaign to drum up interest, although modest. And for you devs, this open an ENTIRE new revenue stream you didn't even have before. Making Android the primary OS used.
---------------------------
That's the agenda, I would like to open a support thread for it somewhere on here. I have an armada of info, tools, rootkits, tricks and troubleshooting information that we feel can be valuable to the community. I'll get things posted here ASAP. Anyone that has played with this at all before will be able to appreciate all of the challenges we had to solve.
We did not knowingly disassemble or modify any of the original distribution files of any applications, staying in accordance with about every license agreement on earth.
--------------------------
Looking for some feedback, questions, thoughts, ideas.. have to get 10 posts or something anyway...
Thank you to everyone!
-js
What's the difference between your project and the Android x86 project?
syung said:
What's the difference between your project and the Android x86 project?
Click to expand...
Click to collapse
AFAIK Bluestacks has its own VM, so you doesn't need to install Virtual Machine any more.
I used this for a several months and it helps me to try an application without to send it to any Android device.
If you use Android x86 project, yo need to install it inside a Virtual Machine or make a USB Bootable, and as far I know it has limitations in the Play Store. Only some application that supports the architecture can be downloaded..
The Android x86 project is a piece of this absolutely. What BlueStacks is and what they have done is this:
Taken x86 gingerbread and ad an arm translator inside there. This is very unique, all of the other arm emulations fail out there after you even try to put them to the test with heavier use or apps. Basically the compatibility is just not there.
BlueStacks then added the vm player which is the most sophisticated player there is. Network mounts to shared fordler without installing drivers, and opengl support for limited HD graphics.
What we did
BlueStacks also crippled the hell out of the original ROM. All kinds of things missing that had to be put back in piece by piece, and still ensure compatibility. Some things fine to leave out, other maybe useful.
poring over the information, rooting bluestacks came easy, so we rooted every single v7.x of bluestacks, and began the mountain task of building compatibility. The winners are 7.4 for SD and 7.8 for HD. 7.8 handle the interface scrolling operations WAY better than later revisions. I can tell it was after this rev they forced on Surface Pro support, not back checking compatibility. And 7.4 installs on any machine but drops the arm translator. Still a nice product to put on an old machine, but little support for modern apps, and there won't be
Then doing a fair assessment of applications to do all the tasks one needs, file manipulation, printing, music, calling etc, We've spent over 200 hours trying to get a reliable lock screen, failed on that But we got most of it.
Finally adding and getting gapps to fully function was about like trying to drink a beer while standing on your head, it was like a marathon game of whack mole, we'd fix something, then something else friggen slam us over the head. Then we got to writing script, and adding widows apps like virtual keyboards and mouse to basically be able to run the entire OS with 1 finger as if you were Stephen Hawking.
We had an excellent response to the initial concept stuff version 1.1. It held on to around 400 seeders and 1000 user swam for about a week then began to fizzle. We expect that to triple and estimate 100,000 downloads in the first week. It is my opinion thepiratebay is the most accurate source for demand of anything digital, people that keep a copy and seed, actually really like something, versus an artificial "like" that other sites have and profit from. That's all Trip9d0zen stuff, about removing fake values and replacing it with real information exchange freedoms, so actually all financial can get to a creator, don't want to digress to far in this thread, but there is an ideology we have in common with thee twitters and thepitatebay's who have just the extreme basics of censorship, only to ensure safety, but never manipulated the information. We have evidence and models to change current businesses, and put the devs out in-front of these projects (or the artist selected agents). The more systems Android runs on, more success one can have. And Windows being the biggest, hands down, why not?
We feel this is by far the most compatible Android environment one can use, and can actually be used by anyone as an effective tool.
We know full well that once released, the ungodly amount of app work requests will be at its highest, but that's why I am here, where the devs are.. is this a revenue stream they want to suppport,?
I am personally using it exclusively for all my communications, social media and document creation, I only use windows for video playing files.
Hope that helps answer, here is the info to commercials for it, as our lil-1337s eloquently cranked out, smartasses...
youtube search for js99912
-js
It looks interesting, i'll check that up!
Dexcellium said:
It looks interesting, i'll check that up!
Click to expand...
Click to collapse
Me too. Thanks
Android for Windows 2.0
new version just went live..... can someone reply with a hot-link, thanks
thepiratebay.sx
/torrent/8440340
Adding Game Data / Mount SDcard.sparse BlueStacks
Ok, I have been asked about this more than anything,
Used to be the SDcard was a .fs file and could be manipulated easy, now it's a bit more involved, but none to difficult.
You need to download:
thepiratebay.sx/
torrent/8453985
This will get you to be able to mount the SDcard.sparsefs as a drive letter in windows... Nothing new, just consolidating info as I have been requested for this more than anything else. Enjoy!
-js
I don't own a smartphone yet, but I'm thinking about getting an Android phone soon. It will be my first smartphone. I’m also new to XDA-Developers. Please help me, as I have questions about Android security and though I’ve posted this message to several other web sites--android.stackexchange.com, Quora.com, and Reddit--no one has answered all of my questions completely and thoroughly. I’ve only gotten short responses that are a few sentences long and only talk about one or two things. I really need more help than that, and I’m hoping that I can get it here!
I know that this message is long, but please, if anyone can read through it and then try to answer all of my questions, I would REALLY appreciate it!
Here are my questions.
1. Is Android’s stock browser updated directly by Google, or do updates to it have to go through phone manufacturers (Samsung, HTC, etc)?
2. If I buy a phone that runs a manufacturer-customized version of Android, such as the TouchWiz version of the S4 or the Note II, will keeping Android’s stock web browser--as well as any other browser I choose to use--up to date keep me safe from web-based exploits, even if that phone’s manufacturer is slow to deliver updates? (Edit: I want to add that I'm interested in technical details.) By “updates” I mean updates to everything provided by or customized by the phone’s OEM: the customized version of Android, the manufacturer’s pre-installed apps, etc. (Edit: what I'm asking here is whether the OS needs to be kept up to date to protect against web-based exploits, or is that accomplished solely by keeping the web browser up-to-date, whatever web browser it is).
3. I have read that OEMs are often slow to update their devices, and because of that I have limited myself to only looking at Nexus devices and Google Play Edition devices. But I really need to know if I SHOULD limit myself to Nexus and GPE devices for the sake of web security. (Again, I'm interested in technical details.) I don't want to buy a phone from a manufacturer that takes months to release security updates, leaving me vulnerable to web browser exploits and malware in the interim. But if I am wrong about ANY of this, please tell me so, because I would like to be able to consider devices that run manufacturer-customized versions of Android, such as the Touchwiz version of the S4 or the Note II (or maybe the future Note III).
(Edit: the answer to question #3 would depend on the answer to question #2; if the answer to #2 is ‘no, the underlying OS does not need to be kept up-to-date to protect you from web browser exploits’, then I guess the answer to #3 would be that I can consider buying a device that runs a manufacturer-customized version of Android that won’t receive OS updates as quickly as a Nexus does. If, on the other hand, the answer to #2 is ‘yes, to protect yourself from web browser exploits you need to keep both your browser AND your OS up-to-date’, then I guess for maximum web security I’d need to buy either a Nexus or a Google Play Edition device.)
4. I’ve read that in-app advertising can be a security risk. I’m really hoping that someone here will explain this to me. (Edit: again, I'm interested in the technical details, but keep in mind that I'm new when it comes to smartphones.)
I’d like to add a few comments:
1. I will only get my apps from the official app store--Google Play--or maybe Amazon.com’s Appstore for Android.
2. I'm concerned about web security and in-app advertising.
3. I don't plan on rooting my phone. I'm not saying I won't, I'm just saying that I don't plan on it.
1. Only nexus devices are updated directly by google. Even htc one Google edition will be updated by htc, so as the browser since it's a part of the software.
2. Manufacture updates are slower than Google. Most of the good apps available should receive updates and solve security issues.
3. If you want to disable advertising then use adaway, notice that you will need root.
1. The stock browser I believe does get updated when the OS is updated. I've read about people getting OS updates to find the stock browser is then faultering and assume this then gets updated. The update of the OS is usually done by the device manufacturer unless you are using a custom rom. Whomever creates the rom used on the device, is responsible for the internal updates for it, to whatever level they wish to support it. I have read that google don't mainstream care about the stock browser as they are pushing Chrome for the win and a separate team deals with the stock browser.
2. The world and his hedgehog are not safe from hack exploits. The quality of protection out there in any sense is mirrored by the quality of hacker. If you have a crap security level, any old hacker can exploit it. If you have the worlds most renowned secure, then the best hackers will break in at some stage while the wannabe hackers struggle to threaten their way out of a paper bag. However with some people, they need gold bullion and jail style security while others wonder why they need it. People can recommend you do this or do that, and some recs are excellent while others are not quite but almost hilarious but at the end of the day, if a child can hack into high security places, our devices are not so hard to get into. That said... we can run paranoid while there may be no threat at all. If you are concerned, just be careful of what you do with your device. Myself, I use it for every day communication and have not yet used a credit card on it with no real need to.
3. Even the greatest have not updated their OS. The Motorola Xoom promised one from purchase yet people were moaning long after the stock sold out that it never came. Granted it surely must be true that certain companies are quicker to advocate update releases than others. But the higher paying vs the cheap low end thing isn't something to run with either. I have a very cheap quad core tablet and that has just had a firmware update from last week and as far as I can see, it's an almost brand new device, market wise so it seems the update from them was fluid. Again, that said, the updates seem to be more about the OS running well, with the hardware and app capabilities than security although I dare say there are some inevitable security fixes in there too. My quad tablet was sluggish to some extent and a bit crashy but so far, it is fine after the update although I have only done it a few hours ago... everything me and the kids have tried, has either worked better of been flawless. No sign of lag yet anyway.
4. In-app advertising can be dangerous for a few reasons i guess. but the reality again, is I think any file can have dangerous code attached and configured in a way that the OS or security cannot smell it. Of course there is the ability of spam links to scam sites. There is also false flag things that are or maybe are possible too. For example, using x file with y file and requesting a cup of tea from z file can make a security team think your couch is about to disappear and your granny is about land bump on the floor, when indeed an app just wanted to execute a command using an ancient method of pressing Q. This is something I learned in windows based operating systems where using certain dll files with certain other files can trigger an alarm, as innocent as the intentions were. I built a website not so long ago and called some iFrames in that had no < head > or < body > tags. the pages worked perfectly but some chinese company employed to protect a british isp flagged the site as a security risk and blocked any visitors from viewing it. Thankfully, long gone are the days that visiting a website would fry your motherboard.
On your remaining comments.. seems like wise advice as of course there are scammers out there who will give your granny that bumpy ride off the disappearing couch onto the floor or steal your account and all those types of greed based madness which is a shame because it ruins the experience of say if a friend is trying to build an app and they ask you to give it a go, you are somewhat rightfully not willing to play ball.
FYI I have been around computers for a long time but am by no stretch of the imagination an android expert at all. I hope what I have wrote above is helpful and not by any means, wrong. I have not long posed the question about rooting and security as I do not qualify understanding the realm at all. I dare say it is a huge question, to some extent.
Also, security risk aside as no smartphone tablet or computer escapes that realm, Android for me is the best device, then IPhone, then Windows Phones, then Crapberry. I would never purchase the latter three.
Hi codQuore,
Thank you for your responses to my questions. I need to clarify two of my questions in my original post. (I have edited my original post to include these clarifications.) In question #2, I was attempting to ask whether the OS needs to be kept up to date to protect against web-based exploits, or is that accomplished solely by keeping the web browser up-to-date (whatever web browser it is). In question #3 I asked whether I should only look at Nexus and Google Play Edition devices for the sake of web security, and the answer to that would depend on the answer to question #2; if the answer to #2 is ‘no, the underlying OS does not need to be kept up-to-date to protect you from web browser exploits’, then I guess the answer to #3 would be that I can consider buying a device that runs a manufacturer-customized version of Android that won’t receive OS updates as quickly as a Nexus does. If, on the other hand, the answer to #2 is ‘yes, to protect yourself from web browser exploits you need to keep both your browser AND your OS up-to-date’, then I guess for maximum web security I’d need to buy either a Nexus or a Google Play Edition device.
What are your answers to those two questions?
Truth_Seeker1 said:
What are your answers to those two questions?
Click to expand...
Click to collapse
At a guess I would say, for browsers that are built in to the OS, there will be two ways this can update, via the OS update and independently. The OS update would be a total OS replacement that is not automated and you would need to use a built in checking feature (if available) or manually check yourself periodically. Browsers that you add yourself will be offered updates from notification unless the ability to auto update is allowed then it should happen seamlessly of course letting you know. Google "android chrome update" to see something along the lines of what the update history shows.
Yes, you would want to update but I would recommend having a read first as on any computer device, an update can be flawed or give more problems than it's worth. Although more often than not, an update should be an improvement on performance and stability and of course for security.
If you are working blind, then do an update and assume security improvements are happening and go for it. If not, then you will know what is happening. I have never gone to the lengths of checking an update list before updating for android, but with pcs I do depending on what is updating, check what the update is worth and how people are getting on with the update. I did beta testing for years (hence the knowledge of flawed updates and reluctance to do the updates) so for me it's one of those do you risk it scenarios.
Sadly as I said above, we are never safe from hacks but with some hindsight and genuine attempt to protect, we are safe from the majority. For me it's 90% "what are you worried about?" and 10% "I don't blame you for being paranoid!"
As for the preference of buying google branded devices, the foundation of an android release is surely never set for these devices "out of the box" so to speak. I would assume that the team who look after these devices have the same process of having to streamline the OS thereafter before they can release it for their device update. This is somewhat proven by people wanting to put a custom rom on their Nexus and such. For some reason, people aren't happy with the normal rom and want or need to replace it. naturally, it is easy to think a nexus device for example, is closer to home and should by rights get updated a bit quicker than my Ampe tablet but in some respects I think this could be a bit of swings and roundabouts, again depending on the company and their apportioned team force to output the update. Yes you should be better off with a more directly linked device, to google but in my opinion, the concern is not a great one. You would be better off thinking about your budget, what you can save and ultimately do with the extra cash alongside the knowledge of which devices and companies actually do spend an effort on looking after them.
I'm in no position to afford these devices and if I were, I would rather throw my money in the bin (or spend it on my loved ones) than give it to the highest bidder.
So in the end, yes updates are 99/100 important and should be done. Be careful of what you browse and do all secure data passing before you go out on the internet highway and risk getting robbed. It is probably safer to "remember my password" to avoid future keysniffers than worry about indepth data mining. Of course, anyone can give you a sniffer but data mining is more clinical, I would say.
Finally, i wouldn't worry about these things too much but as concerned as you are, do some research. But do remember that in one hand, the UK government said "the internet isn't safe so we don't use it" yet on the other, the majority of secure usage is 'watched' by paid professionals for banking and such and is alot safer than you may think aswell as protection for credit card fraud and such.
Thanks again codQuore. I understand your point that there is no such thing as 100% bullet-proof security, but I still need to know whether both the OS and the browser need to be kept up-to-date to protect against web-based exploits, or is that accomplished solely by keeping the web browser up-to-date (whatever web browser it is).
You are most welcome, TS. I would say generally yes, to both, to be on the safe side. I'd like to guarantee the OS update will update the browser if it has been updated in the update and that the browser can be updated on it's own. However, I think I am right in saying you have to check for OS updates yourself and the same for certain apps whilst some apps will auto offer the update. You may be able to force this auto update for all apps, but how this is done per different version of android, escapes me. I do remember seeing the option come up after a factory reset or buying a new device and running the first time setup of playstore and such. There's an option for it somewhere. but I don't think the OS itself offers an auto update, it has to be checked for, in my experience. I have just done my tablet and it required installing some software on my pc from the tablet manufacturer and getting that to update the firmware/os. It was a 525MB download and everything was in chinese lol. I managed it with the help of google translate but it also helped that I had previously done the same thing on a t-mobile vivacity for my daughter after her OS died and got stuck at the rotating t-mobile logo on first boot.
It is essential to update but across the board it's not majorly important to check every minute, so to speak. You'll be fine. For the record though, my quad core tablet cost £70 from singapore and I knew I was taking a bit of a gamble but was protected by returns if all went wrong and get my money back. A similar tablet is something like £120. I plan on doing the same thing for my next phone upgrade too... but I don't have a contract phone running, I am on pay as you go and all I use is internet, no calls. Incidentally, I pay £20 for 6months net from t-mobile and the only limit is 1gb per month on video. when that expires, youtube and such stops working, some video sites carry on and everything else, FB mail, tethering, ftp via pc and stuff, all still works. I have even streamed radio from my android phone, flawlessly.
codQuore said:
I'd like to guarantee the OS update will update the browser if it has been updated in the update and that the browser can be updated on it's own.
Click to expand...
Click to collapse
LOL, I had to read that sentence several times in order to process it because you used the word "update" so many times :laugh:
If I remember what you said earlier, I think you said that the stock browser doesn't get updated on its own, but only as part of big OS updates? So it won't receive security patches as vulnerabilities are discovered, and won't be updated until the next version of Android arrives?
If this is true, then I'll use a different browser. But even if I use a different browser, is code from the stock browser used in other things, meaning that it is STILL a security risk if it isn't kept up-to-date?
It also occurred to me that if an OEM is slow to release OS updates for its phones, will it be just as bad at keeping its pre-installed apps up-to-date, and if so, does that pose a security risk.
Haha, looking back I can't believe I wrote that and am wondering if its a valid statement. I'll leave it for someone else to contradict lmao.
The core of the os and apps that run built are updated I guess separately and together. EG, say the browser gets an update to 1.1 the next update of the OS will most likely carry that updated version but if it doesn't it should still offer an update after you hit the playstore setup. naturally, these apps use core parts of the OS and i think some updates for apps will carry their own additional bypass of outdated os core, where applicable. That said, the bypass could be more secure in one sense and less secure in another. I'm guessing this is even possible. One thing I am yet to see, knowing how windows and linux works a little, is android have to update x- because something app wise has been installed that requires it. Alot of software on windows, requires things like framework to be added, linux is or can be the same.
The chances are you will be 99% secure in any event. The core defence for mobile phones is the phone companies themselves as that is in the realms of trillions of dollars at risk. They've been cracked before and they know it, so there is some possible reassurance for the devices, from that angle.
I’ve been a CyanogenMod user since CM6 for the HTC EVO. While I can’t claim to have contributed much directly to the community (I’m no developer and more of a sys admin kind of guy), I have installed CM on countless phones over the years - basically any friend or family member who sat their phone down long enough. As soon as it was available, I snagged a OnePlus One, and it’s still the phone I have today. While I was initially excited to see where the foundation of Cyanogen Inc. would take the project, I’ve become increasingly disappointed with the direction that things have gone (both CM and COS), and I think my next phone will likely be a Nexus device with stock Android. I’m fairly certain that this post won’t accomplish much (aside from starting a flame-war/trolling/what-have-you), but I thought I would post it just to see what might come of it.
What I initially loved about CM was the fact that it added a number of useful features to stock Android, it allowed a ton of functional customization, it seemed to be more efficient and stable, and it let me continue to update devices that manufacturers had artificially sunsetted. I was impressed by the fact that lead developers were more interested in code quality and security than by shiny features. Amidst the desire to make Android better, there was also a sense of perfectionism to CM as evidenced by the “don’t ask for ETAs” mantra - it would get done when it was ready, and I was always willing to wait.
When Cyanogen Inc. formed, I was curious to see how they planned to make money. I actually decided to be a bit bold, contacted Kirt and Steve via LinkedIn, and offered to share some of my ideas. One of my biggest suggestions was that they should do something to fill the gaping hole left by Blackberry. At that point (and even still today), no manufacturer had really been able to provide the enterprise-grade functionality provided by Blackberry and BES. MDM solutions were (and are) a double-edged sword that are really just a patch for the solution. Given the huge priority that Cyanogen placed on security, I thought it would be a good direction to take. I’ve sent a few other suggestions over the years (including attempting to get the OnePlus One on the shelves at Walmart when I worked at the corporate offices), but it never seemed to go anywhere.
Right now, when I wake my phone, I have a reminder that there is a system update ready for my OnePlus One that will install COS 13.1. This update adds “new mods for Cortana, OneNote, Microsoft Hyperlapse, Skype, and Twitter.” I have yet to hit install. My issue is far less that Cyanogen is working with Microsoft and more with the fact that the company, much like Canonical/Ubuntu, seems to have the not-invented-here syndrome. (Side note: here’s a great article from the Turnkey Linux team that serves as partial inspiration for this post https://www.turnkeylinux.org/blog/ubuntu-not-invented-here-syndrome). Instead of offering new and useful features, Cyanogen is reinventing wheels and cramming the OS full of things that aren’t really at the top of anyone’s list for issues that could be solved or features that could be added. The innovation just seems to be gone. Most of the features that were exclusive to CM and drew me to the project are now part of stock Android. It makes me wish Cyanogen had taken up Google on their $1B offer.
Here are a few examples. Who remembers when ADW was the stock launcher of CM? I do. In contrast, who actually uses Trebuchet? I think it’s a featureless piece of junk. No gestures? No ability to hide icons in the drawer? No useful functionality that really sets it apart from other launchers? Why develop something new just for the sake of doing it yourself when it only provides basic functionality? Right up there with it is the File Manager application. There are plenty of other more feature-rich applications on the market, and I frankly never use the app provided by Cyanogen because it isn’t nearly as functional as something like ES File Explorer.
Similarly (but more egregiously), is the Browser application. Show of hands: who uses the browser provided in AOSP? No? Me, neither. Be it Chrome, Firefox, Opera, or something else, no one uses the browser built into the ROM. Why did Cyanogen feel the need to create another browser that lacks functionality, is rarely updated for security patches like mainstream offerings, and is basically just another piece of lint on everyone's phones? I fail to see the innovation, there.
I initially loved the idea of having a Cyanogen Account because it was pre-Google Device Manager. However, now that Device Manager exists, I don’t see a reason to use my Cyanogen Account because there haven’t been any additional additions to the feature set. I emailed Kirt and Steve once about potentially folding the WebKey project into Cyanogen and linking it to the Cyanogen account. That would provide remote access, remote file management, a remote shell, and countless other features (most or all of which could be made to work without needing root if baked into the ROM). How much would that add to the ROM and set it apart from other offerings? Neither Google, Apple, Microsoft, or Blackberry have anything close, and it would be a game-changer.
The Themes engine. Alright, so some may disagree with me, here, but I don’t really care about theming my phone or my computer. For me, that was cool back when Compiz/Beryl were the hotness for Linux. Now, I’m more interested in function over form. Why spend so much time building this thing when there are actually useful additions that could be made to CM/COS?
In conjunction to this, there are a number of features provided by CM that are now part of AOSP and make me wonder why I'm still on CM/COS. Google has added permissions management. They have included tethering. The majority of Developer Options are baked in. They switched the whole tap/long press to turn on/off/open settings feature in the notification panel. There isn't much to set Cyanogen apart, anymore.
Instead of just complaining, I wanted to start a list of things that I really thought Cyanogen would have provided by now (or would have at least considered). Some of these would provide Cyanogen with a revenue stream so they wouldn't have to keep cozying up to Microsoft, something that I'm sure most of us would appreciate (does anyone actually use Cortana?) I’d be interested to hear what other features the community would like to see added to CM/COS:
WITHOUT root, implement NFC tag actions that are available with the screen off. For example, allow a user to unlock/wake their phone, turn certain settings on or off, switch to a different profile, or perform a set of pre-defined actions by tapping a NFC tag. Obviously, there would have to be some security mechanisms built in order to whitelist trusted tags so the functions can be used with the screen off, but I’ve always wanted to be able to set my phone down on a tag at my desk and have it automatically connect to my company’s WiFi, put my phone on vibrate, etc.
Partner with an existing developer or independently build parental controls into COS.
Add a login manager for public hotspots to accept terms and conditions on subsequent logins after the first connection (would need to use MAC address, GPS, or some other unique identifier since some companies use the same provider, e.g. Starbucks and McDonald's both use ATTWiFi as their network name but have different captive portals)
Make a Kiosk version for customers at coffee shops and the like.
Create a mobile pay kiosk version similar to the Chili’s tablets since Cyanogen is known for security.
Make a version tailored toward the elderly (lock certain features, provide a restricted set of capabilities that are easy to access, etc).
As previously mentioned, build in WebKey or similar functionality that is tied to a Cyanogen account.
Include Tor without needing root.
Allow the ability to modify DNS settings.
Develop AirPlay compatibility for the Cast feature.
Right now, I’m at the point that I was at with Ubuntu about five years ago. Canonical had “improved” Debian into a bloated nightmare complete with in-house developed projects such as Unity, Ubuntu One, the Ubuntu Software Center, Mir, and others that no one asked for or wanted. If Distrowatch rankings are to be believed, Debian (and Mint) is now more popular than Ubuntu, likely as a result of Canonical’s decisions.
This is not a call to arms but rather a suggestion. Perhaps it is time that the community creates, by way of analogy, a Cyanogen Mint. Maybe we need to go back to the foundation of AOSP just like many users have done by going back to Debian. For me, at least, Cyanogen isn’t satisfying the same needs that it did two years ago, and I’d like to have a mobile OS or ROM that does. There are a lot of custom ROMs out there like Paranoid Android, AOKP, and OmniROM, but they are incredibly fragmented in the devices that they support, and none of them have the level of backing that Cyanogen gained. Perhaps as a community, we need to consolidate our efforts, focus on a common project, and bring forth a high-functioning ROM that can fill the void that Cyanogen no longer does.
In light of today's news about the layoffs at Cyanogen, thoughti might bump my thread to see if anyone would be interested in joining this conversation.