Database Users

Android Security: A neglected subject (long)

First of all: I'm an OSS advocate and love the idea of open source. Don't forget that while reading this.
Some 2 month ago, I got myself a Galaxy S. It's not exactly cheap, but on the other side, it's really good hardware. This thread is not about Samsung or the Galaxy S. It's about the missing parts of android security.
We all know it from our home computers: Software sometimes has bugs. Some just annoy us, others are potentially dangerous for our beloved data. Our data sometimes gets stolen or deleted due to viruses. Viruses enter our machines by exploiting bugs that allow for code execution or priviledge escalation. To stay patched, we regularly execute our "apt-get update;apt-get dist-upgrade" or use windows update. We do this to close security holes on our systems.
In the PC world, the software and OS manufacturers release security bulletins to inform users of potentially dangerous issues. They say how to work around them or provide a patch.
How do we stay informed about issues and keep our Android devices updated?
Here's what Google says:
We will publicly announce security bugs when the fixes are available via postings to the android-security-announce group on Google Groups.
Click to expand...
Click to collapse
Source: http://developer.android.com/guide/appendix/faq/security.html#informed
OK, that particular group is empty (except for a welcome post). Maybe there are no bugs in Android. Go check yourself and google a bit - they do exist.
"So why doesn't Google tell us?", you ask. I don't know. What I know is that the various components of Android (WebKit, kernel, ...) do have bugs. There's nothing wrong with that BTW, software is made by people - and people make mistakes and write buggy code all the time. Just read the changelogs or release notes.
"Wait", I head you say, "there are no changelogs or release notes for Android releases".
Oh - so let's sum up what we need to stay informed about security issues, bugs and workarounds:
* Security bulletins and
* Patches or Workaround information
What of these do we have? Right, nada, zilch, rien.
I'll leave it up to you to decide if that's good common practise.
"But why is this important anyway", you ask.
Well, remember my example above. You visit a website and suddenly find all your stored passwords floating around on the internet. Don't tell me that's not possible, there was a WebKit bug in 2.2 that did just that. Another scenario would be a drive-by download that breaks out of the sandbox and makes expensive phone calls. Or orders subscriptions for monthly new ringtones, raising your bill by orders of magnitute. Or shares your music on illegal download portals (shh, don't tell the RIAA that this is remotely possible).
The bug is probably fixed in 2.2.1 - but without changelogs we can't be sure.
But that's not all - there's a second problem. Not only are we unaware of security issues, we also don't have automated update mechanisms.
We only receive updates when our phone's manufacturers release new firmware. Sadly, not all manufacturers support their phones in the long run.
In the PC world, most Distros have a central package management - that Google forgot to implement in Android. Agreed, some phones can receive OTA updates, but that depends on the carrier. And because of the differences in Android versions it's not possible to have a central patch management either. So we do not know if our Android devices might have security issues. We also have no easy way to patch them.
Perhaps you knew this before, then I apologize for taking your time.
What do YOU - the computer literate and security aware XDA users - think about this? Do you think that's a problem? Or would you rather say that these are minor problems?

Very intresting, thanks! The update problem should be fixed with the next release, no more custom UIs and mods from phone manufacturers,at least google said that
Sent from my Nexus One using XDA App

Excellent post and quite agree with you. The other significant problem looming is the granularity (or rather, lack thereof) in app permissions which can cause problems you describe without bugs and exploits. I install an app that does something interesting with contacts and also has internet access to display ads. How do I know that my contacts are not encrypted, so making sniffing useless, and beamed back to mummy? Nothing other than blind trust!
I love Android but it's an accident waiting to happen unless the kind of changes you advocate are implemented and granularity of permissions significantly increased. I don't like much about Apple but their walled garden app store is something they did get right although IMHO, they also abuse that power to stifle competition. Bring out the feds!

simonta said:
The other significant problem looming is the granularity (or rather, lack thereof) in app permissions [...]
How do I know that my contacts are not encrypted, so making sniffing useless, and beamed back to mummy? Nothing other than blind trust!
Click to expand...
Click to collapse
I agree, although I'm not sure that less experienced users might have difficulties with such options.
simonta said:
I love Android but it's an accident waiting to happen
Click to expand...
Click to collapse
Sad but true. I'm just curious what Google will do when the first problems arise and the first users will have groundshaking bills.
If that happens to just a few users, it'll get a kind media coverage Google surely won't like.

I've seen quite a few android exploits posted on bugtraq over the years. It's a high-volume email list, but with some filtering of stuff you don't care about, it becomes manageable. It's been around forever and is a good resource if you want the latest security news on just about anything computer related.
http://www.securityfocus.com/archive/1/description

People are bashing a lot about the Android security model but the truth is you can never have 100% protection with ANY solution.
Apple is not allowing any app in their store. Fine. but mostly they are only filtering out apps that crash, violate some rules or they just don't like them or whatever. but they can never tell what an app is really doing. Therefore they would neeed to reverse-engineer every app they get etc. That's just impossible considering the amount of apps....
Speaking again of Android. I think the permission model is not bad. I mean, no other OS got such detailed description about what an app can do or not. But unfortunately it can only filter out very conspicuous apps, i.e. a Reversi game asking for your location and internet access. But then you never know... if the app is using ads it requires location and internet access, right? so what can you do?

RAMMANN said:
Apple is not allowing any app in their store. Fine. but mostly they are only filtering out apps that crash, violate some rules or they just don't like them or whatever. but they can never tell what an app is really doing. Therefore they would neeed to reverse-engineer every app they get etc. That's just impossible considering the amount of apps....
Click to expand...
Click to collapse
Not really, they do blackbox testing and let the apps run on emulated devices they then check if the app "behaves" as desired...

Of course you can't get 100% security and I don't think that's what we're saying, but there is a lot you can do.
Take for example internet access which is the biggest worry I have. The only reason most apps request internet access is to support ads. I now have a choice to make, don't use the app or trust it. That simple, no other choice.
If I installed an app that serves ads but did not have internet access, then the only way that app can get information off my phone is to use exploits and I'm a lot more comfortable knowing that some miscreant needs to understand that than the current situation where some script kiddy can hoover up my contacts.
However, if internet access and ad serving were separate permissions, you could in one hit address, taking a wild guess, 90% of the risk from the wild west that is Marketplace. With a bit more design and work, it would be possible to get the risk down to manageable and acceptable levels (at least for me).
I absolutely agree with you on Apple, one of the main reasons that I chose a Desire instead of an iPhone, but the Android approach is too far the other way IMHO.
Just my tuppence, in a hopeless cause of imagining someone at Google paying attention and thinking you know what, it is an accident waiting to happen.

marty1976 said:
Not really, they do blackbox testing and let the apps run on emulated devices they then check if the app "behaves" as desired...
Click to expand...
Click to collapse
Well, so why did a tethering app once make it into the appstore?
Also I think there are many possibilities for an app to behave normal, and just start some bad activity after some time. Wait a couple months until the app is spread around and then bang. Or remotely launch some action initiated through push notifications etc.
If there is interest, then there is always a way....

simonta said:
However, if internet access and ad serving were separate permissions, you could in one hit address, taking a wild guess, 90% of the risk from the wild west that is Marketplace. With a bit more design and work, it would be possible to get the risk down to manageable and acceptable levels (at least for me).
Click to expand...
Click to collapse
I agree that a seperate permission for ads would be a good thing.
But there are still many apps which need your location, contacts, internet access.... all the social media things nowadays. And this is where the whole thing will be going to so I think in the future it will be even harder to differenciate.

Getting back on topic: I just read that Windows 7 Phone will get updates and patches like desktop windows. That means patchday once a month plus when urgency is high...

simonta said:
However, if internet access and ad serving were separate permissions, you could in one hit address, taking a wild guess, 90% of the risk from the wild west that is Marketplace. With a bit more design and work, it would be possible to get the risk down to manageable and acceptable levels (at least for me).
Click to expand...
Click to collapse
But, how do you distinguish them? Today, (as a developer) I can use any ad-provider I want. In order to distinguish ads from general internet access, the OS would need one of:
A Google-defined ad interface, which stifles "creativity" in ad design. Developers would simply ignore it and do what they do now as soon as their preferred ad-provider didn't want to support the "official" ad system or provided some improvement by doing so.
An OS update to support every new ad-provider (yuck^2).
Every ad-provider would have to go through a Google whitelist that was looked up on the fly (increased traffic, and all ads are now "visible" to Google whether Google is involved in the transaction or not). This would also make ad-blocking apps harder to implement since Google's whitelisting API might not behave if the whitelist was unavailable. On the upside, it would make ad-blocking in custom ROMs be trivial.
Even if Google did one of these things, it still wouldn't provide any real increase in privacy or security. The "ad service" would still need to deliver a payload from the app to the service (in order to select ads) and another from the service to the app (the ad content). Such a mechanism could be trivially exploited to do anything that simple HTTP access could provide.

http://code.google.com/p/android/issues/list
issues submitted are reviewed by google employed techs... they tell you if you messed up and caused the issue or if the issue will be fixed in a future release or whatever info they find.
probably not the best way to handle it but its better then nothing.

twztdwyz said:
http://code.google.com/p/android/issues/list
Click to expand...
Click to collapse
Knew that bug tracker, but the free tagging aka labels isn't the best idea IMHO.
You can't search for a specific release, for example...
twztdwyz said:
probably not the best way to handle it but its better then nothing.
Click to expand...
Click to collapse
Ack, but I think Google can do _much_ better...

Two more things to have in mind:
1. I doubt that many Android users bother much about what permissions they give to an app.
2. Using Google to sync your contacts and calendar (and who knows what else), is a bad, bad idea.

Netflix on android, sorta good news

I know I've been waiting a while for this, figured i would give a heads up for anyone that wanted to know
http://blog.netflix.com/2010/11/netflix-on-android.html
Hi, this is Greg Peters, from Netflix product development. We recently announced the availability of Netflix on Windows Phone 7 devices, which, alongside the iPhone, represents the second mobile phone platform we have enabled for streaming from Netflix. Notably absent from current supported mobile devices is Android and I wanted to provide an update on where things stand with this important platform.
We regard Android as an exciting technology that drives a range of great devices that our members could use to instantly watch TV shows and movies from Netflix. We are eager to launch on these devices and are disappointed that we haven’t been able to do so already. The hurdle has been the lack of a generic and complete platform security and content protection mechanism available for Android. The same security issues that have led to piracy concerns on the Android platform have made it difficult for us to secure a common Digital Rights Management (DRM) system on these devices. Setting aside the debate around the value of content protection and DRM, they are requirements we must fulfill in order to obtain content from major studios for our subscribers to enjoy. Although we don’t have a common platform security mechanism and DRM, we are able to work with individual handset manufacturers to add content protection to their devices. Unfortunately, this is a much slower approach and leads to a fragmented experience on Android, in which some handsets will have access to Netflix and others won’t. This clearly is not the preferred solution, and we regret the confusion it might create for consumers. However, we believe that providing the service for some Android device owners is better than denying it to everyone.
We live to get Netflix on new devices, so the current lack of an Android-generic approach to quickly get to all Android devices is frustrating. But I’m happy to announce we’ll launch select Android devices that will instantly stream from Netflix early next year. We will also continue to work with the Android community, handset manufacturers, carriers, and other service providers to develop a standard, platform-wide solution that allows content providers to deliver their services to all Android-based devices. I’ll keep you updated on our progress.

Good to hear that. Now, WP7 owners can't say Android don't support netflix blah blah.

Android 2.2.2 Security

2.2.2 has a security fix
http://www.engadget.com/2011/03/02/google-spikes-21-malicious-apps-from-the-market-with-big-downloa/
thoughts?

My thoughts are simple: Sprint needs to get its **** together and release an official 2.3 release. And Google needs to consider some sort of authentication program for apps to be distributed in the Market.
Certainly don't want to cut the independent developer community off, but it shouldn't be their responsibility to release new versions of essential operating software that contain fixes that disable malicious exploits. They are here to enhance our user experience.
The manufacturers need to be concerned about what the deleterious effects of outdated software can open their networks to. After all, these apps had full internet access, as I've heard. Who knows if, say a DDOS attack (or something worse), could be possible using phones, and what kind of effects that could have on the stability of the entire Sprint network.
As for Google, I'm not suggesting that the Market be completely walled-off, but maybe having something like "Google Approved" or "Verified Secure" or something, would give us users more confidence that apps come from verified and vetted sources. We could still install things not verified -- at our own risks -- but at least we'd have a choice and be able to proceed with better, more complete information.

TonyArmstrong said:
My thoughts are simple: Sprint needs to get its **** together and release an official 2.3 release. And Google needs to consider some sort of authentication program for apps to be distributed in the Market.
Certainly don't want to cut the independent developer community off, but it shouldn't be their responsibility to release new versions of essential operating software that contain fixes that disable malicious exploits. They are here to enhance our user experience.
The manufacturers need to be concerned about what the deleterious effects of outdated software can open their networks to. After all, these apps had full internet access, as I've heard. Who knows if, say a DDOS attack (or something worse), could be possible using phones, and what kind of effects that could have on the stability of the entire Sprint network.
As for Google, I'm not suggesting that the Market be completely walled-off, but maybe having something like "Google Approved" or "Verified Secure" or something, would give us users more confidence that apps come from verified and vetted sources. We could still install things not verified -- at our own risks -- but at least we'd have a choice and be able to proceed with better, more complete information.
Click to expand...
Click to collapse
+1 but i also think they should make an official malware scanner.

Rydah805 said:
+1 but i also think they should make an official malware scanner.
Click to expand...
Click to collapse
This.^^^^
I'm an Android convert (from iPhone), and my great fear is that the very openness we enjoy could expose us to very nasty ****. I don't wanna be locked down, but I do want some manner of enhanced security.
That malware scanner in combo with some sort of developer authentication and/or verification program would be excellent.

[Q] Acer Iconia and DRM hardware

I've been reading up lately and I had a question about the Iconia that I haven't been able to find an answer for. Does the Acer Iconia, or Tegra 250 chipset in general, have any kind of hardware DRM? I've been reading up on the upcoming netflix app and it seems like it will only run on android devices that have some type of Hardware DRM incorperated. Does the Iconia have any type of DRM hardware? If not, does that mean we won't ever be able to use the Netflix App when it is made available?

From what we've heard, Netflix will only be working with Intel chipsets at the moment.
When I first read about this news, I was pissed. I even tried to rally a few people to write and protest Netflix because of this. It's a delicate thing. I want to support Netflix because of the great price and the great service, but I don't want them telling me what device I can and cannot use their service on.
It's funny because the CEO was just talking about not being a cable company...yet here they are talking about limiting their exposure on devices.
I really wish we could get a petition going or have everybody with an Android device send them an e-mail telling them we don't want this type of precedent set and that we won't accept it. I could live without Netflix...I just don't want to.
Until we scream and shout for what we want, we'll have to settle using PlayOn to get our Netflix and Hulu fix on your non-Intel tablet.
Sent from my A500 using Tapatalk

beebop483 said:
I've been reading up lately and I had a question about the Iconia that I haven't been able to find an answer for. Does the Acer Iconia, or Tegra 250 chipset in general, have any kind of hardware DRM? I've been reading up on the upcoming netflix app and it seems like it will only run on android devices that have some type of Hardware DRM incorperated. Does the Iconia have any type of DRM hardware? If not, does that mean we won't ever be able to use the Netflix App when it is made available?
Click to expand...
Click to collapse
As far as I know Tegra 2 has no inherent DRM technologies, thus the Iconia A500 isn't blessed with any DRM hardware...HOWEVER, DRM can also be exclusively software based and I'm pretty sure Honeycomb has some keen DRM tech and will be getting updates with even more secure DRM. Of course, Netflix (or moreso, it's partners) may not settle for that so it's still up in the air.
At this point, and though I don't like being pessimistic about things - I'd advise against looking forward to an Official Netflix app on the Google Market (for now). If you want Netflix badly enough, I'd say wait for a tablet that is released with the app built in or wait until an App comes and see what the requirements are. The requirement will either be hardware, eg: requires snapdragon xxxx or Exynos based device or software, eg: requires Honeycomb 3.1.

Thanks for taking the time to respond to my questions, I'm surprised people aren't making a bigger deal out of this. I like the idea of having a petition or email campaign to netflix, not to chastise or threaten them, but rather to express that as educated consumers we would like to know that our money is being spent wisely, and that products we buy today will not be outdated within weeks. I've taken the liberty of drafting a letter that can be sent to netflix. Feel free to copy the letter and send it, or post it somewhere on XDA so that we can try to collect signatures and support.
Dear Netflix,
First and foremost, we would like to take the time to express our gratitude towards your company, and the fantastic service that it provides. Even with the current state of the economy, most companies that provide media and entertainment to consumers charge outlandish fee's, provide poor support, and overall, do not seem concerned with offering customers a quality service at a reasonable price.
Netflix has been one of the very few exceptions to the status quo, and continues to offer great content at a great price, much to the dismay of large cable corporations, who seem content on increasing prices while not improving infrastructure, or providing more content to their customers. We also applaud your companies willingness to provide content on a large variety of devices. Netflix is one of the only companies that seems to actually want to provide an excellent affordable service that users can enjoy on their own terms, on whatever hardware they prefer.
It is because of this, that we would like to reach out to Netflix and open a dialogue concerning the future of the company, and it's plans for Android implementation.
A large concern among the public right now is whether or not Netflix plans to release its Android application in a state that will only allow it to run on devices that contain integrated hardware DRM. As you may already know, a large amount of tablet PC's are being released into the market right now, the majority of which are running on the Nvidia Tegra 250 chipset, which has no native hardware DRM. This puts consumers in a difficult position, on the one hand these devices are very powerful, and offer a good user experience for the price. On the other hand, consumers are unsure about the future of these devices. There have been rumors that new versions of the Honeycomb operating system will contain software DRM, but that still leaves consumers with a lingering question. Do we spend five hundred dollars on hardware that may not be compatible with Netflix, or do we wait indefinitely to see if the devices will be able to utilize Netflix services?
We realize that Netflix is involved in a very competitive business, and for obvious reasons, it is in the companies best interest to not explain it's entire game plan to the world. On the other hand, as consumers, we like to know that we are making wise purchases that will meet the expectations we have.
We are requesting that Netflix reveals more information about it's future plans for supporting the Android operating system. More specifically, we would like to know if the Netflix Android application will work on devices that only have hardware DRM, or if the company has any plans to support software DRM integrated into future releases of the Android operating system.
Any information you could provide on this subject would be of great help to the Android community, as well as consumers who value the service that Netflix provides. Thank you very much for taking the time to read this request, and we hope you will consider releasing information that will clarify the future DRM requirements for the Android Netflix Application.
Thank you.

Makes no difference unless Acer were to pay to have the A500 as a device to work on Netflix servers (assuming the chipset qualifies). LG Revolution is the only device so far.
I wonder if Google will spare a very small fraction of their billions to give blanket approval for Android devices that have the approved chipsets? Nah.

I'm pretty sure the tab's HDMI supports HDCP. For what that is worth.

Having Trouble with USB ports and speakers
Hi, y'all,
I have been around computers software and hardware wise for years. I am new to the Acer a500 Iconia Tab world. But I can not get my acer to acknowledge my computer to root or to upload and now my speakers are gone. Is there someone who can help me on these issues? I think the problems are hardware related. I tried searching the internet but no luck. I hope y'all have a good one.

Vulnerability Allows Attackers to Modify Android Apps Without Breaking Their Signatur

Vulnerability Allows Attackers to Modify Android Apps Without Breaking Their Signatures
This might be the reason why the new MF2 and ME6 are not downgradable and why the 4.2.2 update was delayed.
Source->http://www.cio.com/article/735878/V...ndroid_Apps_Without_Breaking_Their_Signatures
IDG News Service — A vulnerability that has existed in Android for the past four years can allow hackers to modify any legitimate and digitally signed application in order to transform it into a Trojan program that can be used to steal data or take control of the OS.
Researchers from San Francisco mobile security startup firm Bluebox Security found the flaw and plan to present it in greater detail at the Black Hat USA security conference in Las Vegas later this month.
The vulnerability stems from discrepancies in how Android apps are cryptographically verified, allowing an attacker to modify application packages (APKs) without breaking their cryptographic signatures.
When an application is installed and a sandbox is created for it, Android records the application's digital signature, said Bluebox Chief Technology Officer Jeff Forristal. All subsequent updates for that application need to match its signature in order to verify that they came from the same author, he said.
This is important for the Android security model because it ensures that sensitive data stored by one application in its sandbox can only be accessed by new versions of that application that are signed with the original author's key.
The vulnerability identified by the Bluebox researchers effectively allows attackers to add malicious code to already signed APKs without breaking their signatures.
The vulnerability has existed since at least Android 1.6, code named Donut, which means that it potentially affects any Android device released during the last four years, the Bluebox researchers said Wednesday in a blog post.
"Depending on the type of application, a hacker can exploit the vulnerability for anything from data theft to creation of a mobile botnet," they said.
The vulnerability can also be exploited to gain full system access if the attacker modifies and distributes an app originally developed by the device manufacturer that's signed with the platform key -- the key that manufacturers use to sign the device firmware.
"You can update system components if the update has the same signature as the platform," Forristal said. The malicious code would then gain access to everything -- all applications, data, accounts, passwords and networks. It would basically control the whole device, he said.
Attackers can use a variety of methods to distribute such Trojan apps, including sending them via email, uploading them to a third-party app store, hosting them on any website, copying them to the targeted devices via USB and more.
Some of these methods, especially the one involving third-party app stores, are already being used to distribute Android malware.
Using Google Play to distribute apps that have been modified to exploit this flaw is not possible because Google updated the app store's application entry process in order to block apps that contain this problem, Forristal said. The information received by Bluebox from Google also suggests that no existing apps from the app store have this problem, he said.
However, if an attacker tricks a user to manually install a malicious update for an app originally installed through Google Play, the app will be replaced and the new version will no longer interact with the app store. That's the case for all applications or new versions of applications, malicious or non-malicious, that are not installed through Google Play, Forristal said.
Google was notified of the vulnerability in February and the company shared the information with their partners, including the members of the Open Handset Alliance, at the beginning of March, Forristal said. It is now up to those partners to decide what their update release plans will be, he said.
Forristal confirmed that one third party device, the Samsung Galaxy S4, already has the fix, which indicates that some device manufacturers have already started releasing patches. Google has not released patches for its Nexus devices yet, but the company is working on them, he said.
Google declined to comment on the matter and the Open Handset Alliance did not respond to a request for comment.
The availability of firmware updates for this issue will differ across device models, manufacturers and mobile carriers.
Whether a combination of device manufacturers and carriers, which play an important role in the distribution of updates, coincide to believe that there is justification for a firmware update is extremely variable and depends on their business needs, Forristal said. "Ideally it would be great if everyone, everywhere, would release an update for a security problem, but the practical reality is that it doesn't quite work that way, he said."
The slow distribution of patches in the Android ecosystem has long been criticized by both security researchers and Android users. Mobile security firm Duo Security estimated last September, based on statistics gathered through its X-Ray Android vulnerability assessment app, that more than half of Android devices are vulnerable to at least one of the known Android security flaws.
Judging by Android's patch distribution history so far, the vulnerability found by the Bluebox researchers will probably linger on many devices for a long time, especially since it likely affects a lot of models that have reached end-of-life and are no longer supported.
Click to expand...
Click to collapse

I really thought more people would be interested in knowing this. I would really like to know what you guys think about this.

Key phrase here is "for apps not installed through the google store". Hence not an issue for a large fraction of users. Total case of FUD. Someone must be wanting to sell some av software.
Sent from my GT-N7100 using Tapatalk 4 Beta

Kremata said:
I really thought more people would be interested in knowing this. I would really like to know what you guys think about this.
Click to expand...
Click to collapse
Well, X-Ray scanner either does not detect this latest security flaw or N7100 (as of DM6) is allready patched.

Kremata said:
I really thought more people would be interested in knowing this. I would really like to know what you guys think about this.
Click to expand...
Click to collapse
This is the first link I found for XDA on this.
I think it's not that interesting because it's old, old news and exactly why it's being touted as a "new" discovery is beyond me, it's far from new.
We here at XDA have been using this method for years to modify stock Android and OEM system apps with great success. Here's an example by me from 2011: http://forum.xda-developers.com/showthread.php?t=994544 there's a literally hundreds of examples all over XDA.
The real question here is how Bluebox security got everybody to act as a PR machine for them. If they turn up at Black Hat with this "amazing discovery" they're going to get laughed off the stage.

djmcnz said:
This is the first link I found for XDA on this.
I think it's not that interesting because it's old, old news and exactly why it's being touted as a "new" discovery is beyond me, it's far from new.
We here at XDA have been using this method for years to modify stock Android and OEM system apps with great success. Here's an example by me from 2011: http://forum.xda-developers.com/showthread.php?t=994544 there's a literry hundreds of examples all over XDA.
The real question here is how Bluebox security got everybody to act as a PR machine for them. If they turn up at Black Hat with this "amazing discovery" they're going to get laughed off the stage.
Click to expand...
Click to collapse
Ahh! Thats the answer I was waiting for (and from a Recognized Developer). I knew XDA Devs were using this method. My new question is.. If they fix it will it be harder to create Mods? Will it slow down development?

Shouldn't this be posted in the generals forum?

Kremata said:
If they fix it will it be harder to create Mods? Will it slow down development?
Click to expand...
Click to collapse
I suspect so. If they fix it properly it would become impossible to change any aspect of the app without signing it again. If you wanted to maintain compatibility with the original then you'd need the developer's keys.
At the moment really only the manifest and some metadata within the apk is signed, if they extended that to the entire contents of the apk many mods (think themes for stock Google apps etc) are screwed unless users are happy to relinquish Play Store links and updates (i.e. backward compatibility).
Google may not go this far and may only choose to authenticate the code (smali) rather than all of the apk contents (graphics, strings etc), this approach would leave room for some mods to survive. Remains to be seen.