Related
Sometimes I come across an app thats not on the Android market and you have to install it manually. Has anyone come across a virus/trojan on Android yet? Im curious how easy or hard it is to modify a legit applications and put a virus/trojan in it?
Lol have not seen one yet. Android isn't that big yet so doubt hackers would really spend time putting trojans to get stuff like your email password lol.
Take everything you know about microshaft windoze and forget it. The system architecture of android is almost completely invulnerable to viruses/worms/etc.
In a typical unix system, hacks can take one of very few possible approaches;
1) service bug targeting, i.e., if one were to discover a security vulnerability in the Apache HTTP server, one could theoretically compromise it. That particular service I mean.
2) user account targeting, i.e., one could convince a user to run something dangerous, which would infect that specific user's account, of course, this attack would limit itself to damaging that user's personal data and would not be able to take down the whole system unless it also targeted a kernel or X-server exploit.
Note specifically regarding #1, that in a well configured system, that targeting a particular service would be restricted to a specific user account just as in #2 since each service runs as its own username.
3) Targeting KERNEL defects; this is perhaps the most frightening possibility. It is also the least likely since it would also require #1 or #2. Any particular kernel attack, particularly in Linux is also very unlikely to work for long due to the open sourced nature of Linux. There are a LOT more people involved in monitoring the fundamental securities of the Linux kernel than any other OS because of its open nature. It is also a source of PRIDE for kernel HACKERS that they ALSO be responsible for openly providing the SOLUTION to any exploits that they discover. And they usually do this with their REAL NAME since it basically immortalizes them. The end result is that every time a kernel exploit is discovered, it tends to be patched within hours of its first application.
Now of course you want to know how this affects Android, since by all appearances, there is no user-level security. WRONG. The Android security level is actually on par with service level security on unix servers. EVERY SINGLE application installed is granted is own user account, which means that if any particular application is dangerous, its range of damage is restricted to that particular application's private data, as well as any permissions that the application is explicitly granted (i.e. when you install an application, it gives you the required security list). There is also the very slim possibility of a kernel exploit (though this is extremely unlikely), and it could damage the data on the sdcard (since it is an MS-crap filesystem with no security restrictions).
Of course you will note that older versions of the ADP1 system image came with an unregulated 'su' command (which you could also end up with using a "cat sh > su; chmod 4755 su" root approach) which basically can be used by any application to take over the whole system. Make sure that you don't have any such su command on your droid. Either use a password-protected su command (which will cause problems for trusted apps requesting root privileges), or the gui-supported su command. Subsequent ADP1 images came with an su command that was restricted to the debugging terminal user, which is fine.
In other words... you don't have much to worry about. Just don't do anything really stupid, like installing an untrusted application that wants a boat load of privileges that it shouldn't be asking for.
lbcoder said:
EVERY SINGLE application installed is granted is own user account, which means that if any particular application is dangerous, its range of damage is restricted to that particular application's private data, as well as any permissions that the application is explicitly granted (i.e. when you install an application, it gives you the required security list).
Click to expand...
Click to collapse
Might be worth pointing out that android apps are for the most part interpreted language apps, meaning the onus of security and stability (just from an apk standpoint) falls largely on the vm. All the lower level subsystems are pretty well protected by the Linux kernel, and these have been significantly tried in fire by decades of Linux server deployment.
lbcoder said:
The system architecture of android is almost completely invulnerable to viruses/worms/etc.
Click to expand...
Click to collapse
jashsu said:
Might be worth pointing out that android apps are for the most part interpreted language apps, meaning the onus of security and stability (just from an apk standpoint) falls largely on the vm. All the lower level subsystems are pretty well protected by the Linux kernel, and these have been significantly tried in fire by decades of Linux server deployment.
Click to expand...
Click to collapse
All the points about the protection offered from the Linux kernel and the VM are valid. Computer secuity is an ongoing battle between the software originators and the hackers trying to get in. I'm not saying it's remotely likely, particularly due to the market share, but rule one in my book is don't taunt the hackers.
lbcoder said:
Take everything you know about microshaft windoze and forget it. The system architecture of android is almost completely invulnerable to viruses/worms/etc.
Click to expand...
Click to collapse
Until the Android Dev team screw up again and lets any app run in the system process when requested (which was why cupcake was delayed in the US).
thanks for the post.
I was curious if someone could unpack a .apk file and modify a application easily, say have it send personal info to xyz server instead of the server the app was designed for or send it to both servers so the user doesnt think anything is wrong.
Are the files in the .apk editable, like an .exe is compiled for windows and the .exe cannot be edited (since its machine code).
androidmonkey said:
thanks for the post.
I was curious if someone could unpack a .apk file and modify a application easily, say have it send personal info to xyz server instead of the server the app was designed for or send it to both servers so the user doesnt think anything is wrong.
Are the files in the .apk editable, like an .exe is compiled for windows and the .exe cannot be edited (since its machine code).
Click to expand...
Click to collapse
Yes, apks are basically just zip files with cryptographic signatures. If you get your apks from Market then there is little to no risk of apks being tampered with. If you install your apks from any source other than Market, then you just have to trust the source that the apk hasn't been modified. Obviously if the apk itself doesn't ask for many permissions then it shouldn't be a problem. For example if you download a game apk from a developer's personal webpage and it asks for just permission to keep the screen alive, there's little risk to your data. However if you download an app that has read/write access to your contacts, or has root access, then you better be sure that the site you get it from is trustworthy.
jashsu said:
Yes, apks are basically just zip files with cryptographic signatures. If you get your apks from Market then there is little to no risk of apks being tampered with. If you install your apks from any source other than Market, then you just have to trust the source that the apk hasn't been modified. Obviously if the apk itself doesn't ask for many permissions then it shouldn't be a problem. For example if you download a game apk from a developer's personal webpage and it asks for just permission to keep the screen alive, there's little risk to your data. However if you download an app that has read/write access to your contacts, or has root access, then you better be sure that the site you get it from is trustworthy.
Click to expand...
Click to collapse
So the files in the .apk not executables, rather interpreted with the VM? Im curious if those files can be read and changed. For instance, can someone open the file in a Java SDK and change the code? Or are those files protected so they cant be modified? For instance, could you download soundboard app from the Market, "unzip" the .apk, and put your own sounds in it?
androidmonkey said:
So the files in the .apk not executables, rather interpreted with the VM? Im curious if those files can be read and changed. For instance, can someone open the file in a Java SDK and change the code? Or are those files protected so they cant be modified? For instance, could you download soundboard app from the Market, "unzip" the .apk, and put your own sounds in it?
Click to expand...
Click to collapse
Unless the classes are specifically performing security/sanity checks, there's nothing keeping you from replacing asset files (pngs, wavs, etc) and then resigning the apk with any key of your choosing. However, altering xmls and classes is more difficult as they are obfuscated/optimized by default.
For apps distributed officially through the Android market, the only way Google can provide assurance for the app producer against tampering is app-protected folder. Of course that assumes that root access is not provided, which is most likely a prerequsite for any phone to be branded "with Google" and have Market access. From the viewpoint of the consumer, apps are guaranteed by Google against tampering only if retrieved through Market. Once the app is on the device, it is protected via Android's use of Linux user access permission model (each app is its own user). The consumer may of course alter the file him/herself, unless it is a protected app, in which case root is required.
sounds buggy. i hope not. this reminds me of when Mozilla firefox became popular i slowly starte dto see code become available to make pop ups n my belloved browser
Virus found on Android phone...
Article 1:
NEWS
An employee at Spanish antivirus firm Panda Security received a new Android-based Vodafone HTC Magic with malware on it, according to researchers at Panda Labs.
"Today one of our colleagues received a brand new Vodafone HTC Magic with Google's Android OS," researcher Pedro Bustamante wrote on the Panda Research Blog on Monday.
"The interesting thing is that when she plugged the phone to her PC via USB, her Panda Cloud Antivirus went off, detecting both an autorun.inf and autorun.exe as malicious," he wrote. "A quick look into the phone quickly revealed it was infected and spreading the infection to any and all PCs that the phone would be plugged into."
Article 2:
Mariposa virus back on Vodafone Android smartphones
HTC Magic According to a Spanish blogger, around 3,000 memory cards supplied by Vodafone Spain were infected with the Mariposa bot client. The mobile network operator has now reportedly confirmed that these included HTC Magic Android-based smartphone models, as well as other devices. A spokesperson for the company has told CNET that it is a "local incident". Vodafone says it has identified customers that could potentially be affected and it will be sending them new memory cards. It has also offered to supply them with tools to restore the integrity of their devices.
Reports of an HTC Magic smartphone carrying the virus were first published less than two weeks ago, however the malware is not able to harm the Android smartphone itself. The bot only attempts to contact a command & control server when connected to a Windows PC. The virus should be detected by most up-to-date anti-virus solutions.
Personal take:
Interesting to note that the virus being carried on an Android phone and was used to infect PC's NOT other Android phones. It came straight from manufacturing with the virus on, so as of yet I still haven't heard of a virus that can infect an android phone.
Further more, I have seen Anti-virus software on the market place AND being offered by Norton. What do they protect against if there are no known virus threats? Do they just draw a nice pretty anti-virus logo on the screen to make you feel comfy? hehehe.
Trojans in the hacked up ROMs people are distributing
androidmonkey said:
Sometimes I come across an app thats not on the Android market and you have to install it manually. Has anyone come across a virus/trojan on Android yet? Im curious how easy or hard it is to modify a legit applications and put a virus/trojan in it?
Click to expand...
Click to collapse
I've found a trojan in at least one of the ROMs being distributed on here. Even reported directly from the developer's own file sharing site.
"Stock" ROM http://forum.xda-developers.com/showthread.php?t=2066023
Attached is a photo of the file scanned from the linked file sharing site for the KERNEL he wants you to INSTALL!!
Click the link to JB_KERNEL_3.17.841.2_EVITA_Init.d_Support_Installer.zip - 8.54 MB in that thread and see for yourself.
Be careful what you install on your device. ANDR.Trojan.GingerBreak takes full administrative control of your device and downloads more trojans to siphon out your private personal data.
Taken from an user in Androidforums.com ...
that kind of crossed my thoughts when I rooted my phone, what is the possibility though?
n0gik said:
This is a wonderful thread - and my apology if I've missed this question here or anywhere else.
Regarding 'rooted' Hero (or any other Android) phones, once they're rooted, can you set a root password? ('passwd' command after issuing 'su' command)
It would seem to me that leaving the superuser unprotected, with escalated execution privileges NOT protected, then downloading/installing a maliciously written application could become an issue. I'd hate to see thousands (millions?) of Android phones become disabled, DOS attack points or spamming mailer daemons.
Just trying to make an educated decision before rooting.
Click to expand...
Click to collapse
no answers????
I've not done much research on the subject however the superuser apk is there to protect us with custom roms so you can be protected from potentially malicious applications.
We really cant set a password on our root, especially since this is not a "Full" linux distro, it's very watered down to fit and run "well", this includes the SElinux. The SuperUser app offers protection, when an app runs that requires Root, superuser kicks in and asked Always Allow, Allow, Dont Allow, Never Allow.
Given, superuser probably has its weeknesses all security apps do and anyone with the smarts to figure out the loop holes will. It's a cell phone, not your bank account or medical records. I can't see you or anyone carying anything too private on it, maybe some corp. emails. Viruses happen, luckily there doesn't seem to be to much circulating in the way of Android. There are even a few AV apps on the market if you look for them.
The only app I have that requires root is WiFi Tether. Maybe, oneday, when we get full kernel source someone can protect our root a little better than it currently is. If having an Android phone has taught me anything, it is that Google security policies must be Garbage. Look at how they protect paid apps, if I was a Dev that wanted to make money on his code there is no way I could cope with only having stuff in a protected folder. Looks like they would have to make their own software protection, and some have.
Lcarpenter, thanks for answering.
I can breathe a little better now..
We have all seen this CIQ information in SFR thread and repeated all over the internet on various forums and blog sites.
Code:
What Is Carrier IQ? Why Should We Care?
3/31/2011: Hello, Slashdotters!
Put simply - and bluntly - Carrier IQ is a software package buried deep within Android by Samsung at the behest of Sprint. It has been in active use since the time of the Moment, if not before. The company that develops it, also known as Carrier IQ, bills it as "Mobile Service Intelligence". In their own words,
[T]he combination of the MSIP and IQ Insight lets you move seamlessly from broad trend data across many users, through comparative groups down to diagnostic data from individual devices. Now, not only can you identify trends, you have the power to drill down to specific instances, giving you the insight your specialists need to make a difference.
On its own, that description can vary from harmless, to worrying, depending on how you look at it. It's not until one drills deep down into the system and ferrets out every piece of the software that one truly knows what it contains. As some of you might remember, ACS took the first steps toward disabling the Carrier IQ software with the release of SyndicateROM and Xtreme Kernel 1.0. That, however, didn't even scratch the surface.
Carrier IQ's native libraries are plainly visible - libiq_client.so and libiq_service.so in /system/lib. During every boot, this service is launched - you can see it in Settings > Applications > Running Services as "IQAgent Service". These native libraries are called by non-native (Android application) libraries located in ext.jar (the client) and framework.jar (the service). Removal of these (rather obviously-named) libraries alone, be it the .so files or the libraries in framework or ext, will, obviously, break boot. So I - k0nane - had to dig deeper. To make a long story short, reference to the IQ Service and IQ Client were littered across the deepest portions of the framework, and some of the most basic functions of the Android system as we know it.
Carrier IQ as a platform is designed to collect "metrics" at any scale. What I found it to hook into is far beyond the scope of anything a carrier needs - or should want - to be collecting. Carrier IQ sits in the middle of, and "checks" the data of, SMS and MMS messages. It listens for and receives every battery change notifications. It hooks into every web page you view, and every XML file your device reads. It receives every press of the touch screen. It 'sees' what you type on the physical keyboard. It reads every number you press in the dialer. It can track which applications you use, what 'type' they are, how often, and for how long. It hooks into data sent and received.
.................
What I am asking in this thread is for any specific information about CIQ that Dev's who have worked with it are willing to provide from their personal experience with investigating and removing it. I am also asking Dev's and Forum Members who have come across other articles, threads in other forums, etc, to please provide information with links.
Code:
Provided by chris41g
to be effectively removed you only need to remove it from 4 files. it is referenced elsewhere scattered throughout... but the four main files are
DialerTabActivity.apk
ext.jar
framework.jar
services.jar
then in the kernels initramfs, you have to disable the service in the init.rc
Provided by mkasick
Here's all the files that reference "CIQ", "carrieriq", or "libiq" with instances unrelated to Carrier IQ removed:
/ (initramfs):
- init: /dev/ttyCIQ0 UART, presumably to communicate with radio.
- init.rc: Start iqmsd service if property:service.iq.active=1.
- lib/modules/dpram.ko: Implements ttyCIQ UARTs.
/system:
- app/DialerTabActivity.odex
- app/FactoryTest.odex
- bin/iqmsd
- framework/ext.odex
- framework/framework.odex
- framework/sec_feature.odex
- framework/services.odex
- lib/libiq_client.so
- lib/libiq_service.so
Of these, bin/iqmsd is a purpose-unknown daemon, and libiq_client.so & libiq_service.so the client & service native code. The client & service managed code is implemented in framework/ext.odex & framework/framework.odex respectively.
In addition, the following framework classes reference Carrier IQ in some fashion:
framework/ext.odex:
- org.apache.http.impl.client.DefaultRequestDirector
framework.framework.odex:
- android.inputmethodservice.InputMethodService
- android.net.http.Request
- android.webkit.{BrowserFrame,CallbackProxy,LoadLis tener,WebViewCore}
- com.android.internal.telephony.SMSDispatcher
framework.services.odex:
- com.android.server.BatteryService
- com.android.server.WindowManagerService
- com.android.server.am.UsageStatsService
Finally, libiq_service.so is used exclusively by framework/framework.odex (com.carrieriq.iqagent.client.NativeClient), and libiq_client.so is used by:
- bin/iqmsd
- framework/ext.odex (com.carrieriq.iqagent.service.IQService)
- lib/libopencore_player.so
I am seeking facts, file names, files, information on CIQ in the framework, specifically what files CIQ hooks into, etc. Thank you for taking the time to read this.
I received a response yesterday (June 15, 2011) from a group that has disassembled IQAgent & CarrierIQ.
in response to questions about CIQ's capabilities.
We have actually disassembled IQAgent/carrierIQ and captured its behavior to find exactly what it is sending back to sprint on the samsung optimus phone. The information we found it to collect was basic, such as cell towers, signal strengths, device battery. Nothing alarming on that phone, but Sprint could send a remote update to enable the surveillance features without the owner being aware.
Click to expand...
Click to collapse
Now while the above statement is about the Optimus, I was able to confirm through another source that IQAgent & CarrierIQ collection and transmission capabilities are set the same across all Sprint Android offerings.
During a telephone call with Sprint and in a follow up email Sprint responded to requests for information on Carrier IQ, who was responsible for the installation on Sprint's hardware and asked to directly address concerns over its potentially invasive nature.
the software that is in the Android phones is supplied by Google themselves as well as the manufacturer. We
(Sprint) has no control over the actual operating system supplied to us such as the Carrier IQ as it is indigenous to the Android platform.
Click to expand...
Click to collapse
Off the record, Google has denied this referencing that the Nexus S did not have CIQ installed on it because they would not let carriers install such software on their native Android devices.
In the same conversation and follow up email Sprint stated;
removing the Carrier IQ software from your Samsung Epic device can void your manufacturer warranty.
Click to expand...
Click to collapse
The representative was questioned on Sprint's use of the word "can" but could not elaborate on under what circumstances removal of CIQ would not void the warranty.
Update July 5, 2011
Sprint still refuses to address the concerns over Carrier IQ's potentially invasive nature. When directly questioned on if CIQ as it is installed on Sprint hardware is capable of the level of invasive data collection as previously reported by Steve Toplez, Sprint responds with complete silence.
I have since requested contact and an official response from both Sprint's compliance department and General Counsel. Once again, the silence is deafening.
Good thinking
Sweet ... but this might just start another debate ..
Lets hope it doesn't. I would really like to see this community come together and allow this information to be provided with little or no flaming, thread hijacking or warring.
Description of CarrierIQs Service
Mobile Service Intelligence
Mobile Service Intelligence is the process of analyzing data from phones to give you a uniquely powerful insight into mobile service quality and user behavior. Carrier IQ's Mobile Service Intelligence Platform (MSIP) is the smart database at the heart of our solution. It receives raw data (known as Metrics) from phones and converts them into reliable, repeatable Measures which feed into analytic applications. The MSIP delivers true enterprise grade performance, with its proven ability to process data submitted by millions of phones with outstanding integrity and security.
Get the Insight
We know you don't just want data, you want to solve business problems and identify new business opportunities. The IQ Insight application suite uses data from the MSIP to deliver true Actionable Intelligence, tailored to specific business areas. From the performance information to support the launch of a new phone or service to historical information to understand in detail customer behavior and usage patterns, the IQ Insight suite cuts through the complexity to allow you to focus on critical business issues, create and track Key Performance Indicators (KPIs) and all in the knowledge that the data is measured at the point the customer experienced it – in the phone.
What's more, the combination of the MSIP and IQ Insight lets you move seamlessly from broad trend data across many users, through comparative groups down to diagnostic data from individual devices. Now, not only can you identify trends, you have the power to drill down to specific instances, giving you the insight your specialists need to make a difference. That is the power of Mobile Service Intelligence.
Click to expand...
Click to collapse
http://www.freshnews.com/news/383257/carrier-iq-powers-android-platform-mobile-service-intelligence
twolostminds said:
Lets hope it doesn't. I would really like to see this community come together and allow this information to be provided with little or no flaming, thread hijacking or warring.
Click to expand...
Click to collapse
as info is provided, you should compile it (in an easy to read format) in the first post so others don't have to read through (potentially) pages and pages of stuff.. (you can use 'code' HTML tags to 'condense' longer text into smaller boxes I think)
Just my .02
and hopefully the community can come together and compile good/relevant info without all the drama.
http://www.carrieriq.com/overview/IQInsightServiceAnalyzer/ServiceAnalyzer.datasheet.pdf
by the way, as far as framework.. to be effectively removed you only need to remove it from 4 files. it is referenced elsewhere scattered throughout... but the four main files are
DialerTabActivity.apk
ext.jar
framework.jar
services.jar
then in the kernels initramfs, you have to disable the service in the init.rc
http://www.carrieriq.com/overview/IQInsightDeviceAnalyzer/DeviceAnalyzer.datasheet.pdf
this datasheet, makes it sound like its installed for testing the phone, then turned off and can be turned on if needed for support..
daddymikey1975 said:
as info is provided, you should compile it (in an easy to read format) in the first post so others don't have to read through (potentially) pages and pages of stuff.. (you can use 'code' HTML tags to 'condense' longer text into smaller boxes I think)
Just my .02
and hopefully the community can come together and compile good/relevant info without all the drama.
Click to expand...
Click to collapse
I will be updating the OP on a regular basis and once enough verifiable information is gathered I will be creating a Wiki-like posting.
i would think that if we are rooting and also using custom roms or taking features Sprint has built into the phone (Carrieriq) then would we not be violating the terms and conditions of service. And lets not forget that google can tell if we are rooted as we can not get movie rentals from the market. Also google and sprint are able to see what apps we have installed and if they see super user app then its a safebet we are rooted. If google wants to get rid of rooted apps they can by simply removing them from the market upon carrier request like vzw and att did for wifi tether.
chris41g said:
...
then in the kernels initramfs, you have to disable the service in the init.rc
Click to expand...
Click to collapse
sorry noob here, I'm running stock EC05, how do I remove it from init.rc?
chris41g said:
http://www.carrieriq.com/overview/IQInsightDeviceAnalyzer/DeviceAnalyzer.datasheet.pdf
this datasheet, makes it sound like its installed for testing the phone, then turned off and can be turned on if needed for support..
Click to expand...
Click to collapse
I don't know much about it but I do know it runs in the background at boot. To me, that's not "turned off."
dchawk81 said:
I don't know much about it but I do know it runs in the background at boot. To me, that's not "turned off."
Click to expand...
Click to collapse
The service is running, with logging and reporting turned off, and can (presumably) be remotely activated..
Sent from my SPH-D700 using XDA App
chris41g said:
The service is running, with logging and reporting turned off, and can (presumably) be remotely activated..
Sent from my SPH-D700 using XDA App
Click to expand...
Click to collapse
Right. So it's not truly off. Standby isn't off.
Since it's not off, I prefer it gone.
From what I've been able to gather from it it doesn't do much of anything. It has the potential to track stuff, but i'd bet stuff for marketing purposes and possibly troubleshooting remotely.
Everyone is all up in arms over removing it, but there or not it doesn't have any effect on your phone, or battery life.
As far as security purposes, you may as well stop using your phone all together, because thats similar to the kind of stuff google can collect from your phone at any point. Its not a big deal, its not important, and the performance gain for removing any of it is nil.
Well if it doesn't do anything at all, it doesn't need to be there.
chris41g said:
http://www.carrieriq.com/overview/IQInsightServiceAnalyzer/ServiceAnalyzer.datasheet.pdf
by the way, as far as framework.. to be effectively removed you only need to remove it from 4 files. it is referenced elsewhere scattered throughout... but the four main files are
DialerTabActivity.apk
ext.jar
framework.jar
services.jar
then in the kernels initramfs, you have to disable the service in the init.rc
Click to expand...
Click to collapse
Does anyone have a list of every file that references CIQ?
twolostminds said:
Does anyone have a list of every file that references CIQ?
Click to expand...
Click to collapse
That would be an almost impossible task, without going through the source... and even then there are likely to be closed source files too....
The list I gave you is what is edited in a nociq rom though..
Sent from my SPH-D700 using XDA App
chris41g said:
That would be an almost impossible task, without going through the source... and even then there are likely to be closed source files too....
The list I gave you is what is edited in a nociq rom though..
Sent from my SPH-D700 using XDA App
Click to expand...
Click to collapse
You are probably right, it would be impossible without access to both open and closed source. My goal is to put together the most complete and comprehensive information source on CIQ's implementation and capabilities as installed in Android. So any other references that have been found would be greatly appreciated.
WARNING: This is not a place for you to come to say how great you think Chainfire is. I'm not calling his character into question, only his methodologies and the character of the outfit he sold out to (and I don't question the act of selling out, that's business, pays the bills, and puts kids through college). The debates about what people prefer and why are as old as the first software. And of course, I will not tell you what to do, no matter how much I disagree with you. If you UNDERSTAND what I have to say, then THIS software is for you. If you don't, you are probably better off with binaries.
The root situation on Android 5.x left a lot to be desired. There was basically just one distributor of a functional substitute user command (su), and it was binary. Recently, ownership of that binary and all of its history has become the property of a previously unknown legal entity called "Coding Code Mobile Technology LLC". While it was presented as a positive thing that that entity has a great involvement with android root control, this is actually a VERY frightening development.
The people at CCMT are no strangers to the root community. They have invested in, or own, a number of popular root apps (though I am not at liberty to disclose which ones) - chances are, you are running one of them right now. I believe SuperSU has found a good home there, and trust time will not prove me wrong.
Click to expand...
Click to collapse
There are precisely two motives I can imagine for buying up all the root control software for Android;
1) monetizing it, which is contrary to the user's best interests,
2) something very frightening and dangerous involving the potential exploitation of everybody's devices.
You don't know the owners, and they are distributing a binary, so who the heck knows WHAT is going on.
Now a few important considerations with respect to your security and privacy;
1) Obfuscated binary cannot be sanely audited.
2) Function of this binary depends on the ability to manipulate selinux policies on the fly, including RELOADING the policy altogether and replacing it with something possibly completely different. Frankly, I've never heard a single reason why this should be necessary.
3) While a root control application may give you nice audits over other software that is using its service, it can *EASILY* lie about what it is doing itself. It can delete logs, it can share root with other applications that they have made deals with, it can directly sell you out to spammers, etc.
That is WAY too dangerous, and not worth the risk.
Frankly, you are safer if you disable selinux AND nosuid, and just run the old style of root where you set a copy of sh as 6755. And that is FRIGHTENINGLY dangerous.
So not satisfied with this state of root, and especially now with a new unknown entity trying to control the world, we bring you the rebirth of the ORIGINAL Superuser:
https://github.com/phhusson/Superuser
https://github.com/lbdroid/AOSP-SU-PATCH (this one is mine)
From the history of THAT Superuser:
http://www.koushikdutta.com/2008/11/fixing-su-security-hole-on-modified.html
Yes, look at the Superuser repo above and see whose space it was forked from.
Note: This is a work in progress, but working VERY well.
Use my patch against AOSP to generate a new boot.img, which includes the su binary.
Features:
1) selinux ENFORCING,
2) sepolicy can NOT be reloaded.
3) It is NOT necessary (or recommended) to modify your system partition. You can run this with dm-verity!
The source code is all open for you to audit. We have a lot of plans for this, and welcome suggestions, bug reports, and patches.
UPDATE NOVEMBER 19: We have a new github organization to... "organize" contributions to all of the related projects. It is available at https://github.com/seSuperuser
UPDATE2 NOVEMBER 19: We have relicensed the code. All future contributions will now be protected under GPLv3.
*** Regarding the license change; according to both the FSF and the Apache Foundation, GPLv3 (but not GPLv2) is forward compatible with the Apache License 2.0, which is the license we are coming from. http://www.apache.org/licenses/GPL-compatibility.html . What this means, is that it is *ILLEGAL* for anyone to take any portion of the code that is contributed from this point onward, and use it in a closed source project. We do this in order to guarantee that this VITAL piece of software will remain available for EVERYONE in perpetuity.
Added binaries to my the repo at https://github.com/lbdroid/AOSP-SU-PATCH/tree/master/bin https://github.com/seSuperuser/AOSP-SU-PATCH/tree/master/bin
These are *TEST* binaries ONLY. Its pretty solid. If you're going to root, this is definitely the best way to do so.
The boot.img has dm-verity and forced crypto OFF.
The idea is NOT to use as daily driver, while I can make no warranties at all regarding the integrity of the software, I use it myself, as do others, and its pretty good.
What I would like, is to have a few lots of people try it out and report on whether things WORK, or NOT.
IF NOT, as many details as possible about what happened, in particular, the kernel audit "adb shell dmesg | grep audit". On non-*nix host platforms that lack the grep command, you'll probably have to have to add quotes like this in order to use android's grep: "adb shell 'dmesg | grep audit'".
How to try:
0) Starting with a CLEAN system.img, get rid of supersu and all of its tentacles if you have it installed, if it was there, it will invalidate the tests.
1) Install the Superuser.apk. Its just a regular untrusted android application. Yes, there is a security hole here, since we aren't (yet) authenticating the communications between the android application and the binaries, or validating the application by signature, or anything else that would prevent someone from writing a bad Superuser.apk. This is on the list of things to do.
2) fastboot flash boot shamu-6.0-boot.img
3) test everything you can think of to see if it works as expected.
Note: there are some significant visual glitches in the android application, but nothing that makes it unusable.[/quote] @craigacgomez has been working on fixing up the UI. Its really paying off!!!
How you can reproduce this YOURSELF, which we RECOMMEND if you feel like daily driving it (in addition, make sure that you UNDERSTAND everything it does before you decide to do that, you are responsible for yourself;
You can build it any way you like, but I do my android userspace work in eclipse, so that is what I'm going to reference. Import the project from phhusson's git, including SUBMODULES. Right click the Superuser project --> Android Tools --> add native support. The library name you choose is irrelevant, since it won't actually build that library. Right click project again --> Build configurations --> Build all. This will produce two binaries under "libs", placeholder (which we won't be using), and su. You need the su binary. Then right click project again --> run as --> android application. This will build Superuser.apk, install it, and launch it.
Next:
repo init -u https://android.googlesource.com/platform/manifest -b android-6.0.0_r1
repo sync
Then apply su.patch from my git repo.
UNFORTUNATELY, the repo command isn't smart enough to apply a patch that it created itself. That means that you are going to have to split up the patch into the individual projects and apply them separately to the different repositories. This isn't that hard of a step though, since there are only FOUR repositories I've modified... build/ (this just makes it possible to build with a recent linux distro that doesn't have an old enough version of openjdk by using oraclejdk1.7. The boot.img doesn't actually need the jdk to install anyway -- its just part of the checking stage, so its up to you.), device/moto/shamu/, external/sepolicy/, system/core/.
After applying the patches, copy the su binary you generated with eclipse into device/moto/shamu/
Then ". build/envsetup.sh; lunch aosp_shamu-userdebug; make bootimage". That should take a minute or two to complete and you will have a boot.img built from source in out/target/product/shamu/
NEW UPDATE!!!!
While I haven't yet gotten around to running a complete cleanup (very important family stuff takes priority), I *HAVE* managed to find a half hour to get on with the Android-N program. If anybody takes a peek at the AOSP-SU-PATCH repository on the AOSP-N branch, you should find some interesting things there.
One warning first though... I updated the patches to apply against the N source code, and then updated some more to actually compile, and compiled it all. BUT HAVE NOT HAD THE OPPORTUNITY TO TEST IT YET.
Nice thing you came up. Sounds awesome.
We should have an alternate to all LLC thing, no matter how much respect (I owe you Chainfire thing) we got for the man who created CF Root (since Galaxy S days) and SupeeSU.
wow, tyvm for this! Will definitely test for ya and let you know.
I already applied your patch, built my own binaries and the boot.img but won't have a chance to test anything until tomorrow. Would love to get this %100 working fine and yeah, will use this from here on out instead of supersu.
Thanks again and yeah, will post when I have something ^^
I will be following progress closely, as should others. Without something like this, many in the community may naively let a corporate entity control root access on their devices. This is extremely frightening, it may not happen right away but if you believe the an entity will not monetize or exploit the current situation I believe you are sadly mistaken.
I could be wrong, however, it's not a risk I will take lightly and no one else should either.
Thanks for this.
Nice work!! Will be following this thread closely.
Time for me to learn eclipse. And do a heck of a lot more reading.
Larzzzz82 said:
Time for me to learn eclipse. And do a heck of a lot more reading.
Click to expand...
Click to collapse
Just note that I use eclipse because I'm used to it. Its become the "old" way for android dev.
i just paid for superSU is this the same people?
TheLoverMan said:
i just paid for superSU is this the same people?
Click to expand...
Click to collapse
I'm not sure what you are asking... are you asking if I am in any way affiliated with supersu, then you probably failed to read the first post in this thread altogether.
Charging money for a binary blob to use root on your device is borderline criminal, and unquestionably immoral. I'm sorry to hear that they got something out of you.
This is pretty great. I'll be watching this as well.
Perhaps this is not the place to take the tangent but why does root behave as it does and not more similar to a standard linux distro? It seems like it would be much more secure to have a sudo function as opposed to an all encompassing root. I'll admit I'm not that familiar with the inner working of the android OS but off hand I can't think of any program that absolutely needs to be automatically granted root every time it wants to run (I'm sure there are but even in this case the power user could chown it to standard root).
Wouldn't it be much more secure if you had to go in to developer options (which are already hidden by default) and turn on the option for sudo. This would then require a sudo-user password (perhaps even different than the standard lock screen password). Need to run a adblock update? Enter the password. Need to run Titanium backup? Enter the password... etc. Much more secure than a push of "accept".
Sorry for off topic but it's always made me wonder and seems like it would be root done right (see how I tied that back to the topic ) If elevating programs/tasks to a superuser was more secure perhaps it would not need to be such an issue...
^ Some root functionality is just too common for a Linux like sudo password to be usable at all. I'll give 2 examples:
1. Since Lollipop Google disabled access to mobile network settings for third party apps. Now it's only possible with root. I have an app that together with Tasker automates my network changing. That network app needs root access EVERY time there is any changes to the connected network and when it wants to change the settings.
Phone connects to a different cell tower? Root needed to detect this and determine the mobile network status.
You can figure how many times this is required per day.
2. I use Greenify to force some misbehaving apps to sleep after the screen goes off. It needs to request root every time it wants to sleep one of those apps. In other words every time I use them, after my screen goes off and I turn it back on I'd be facing both my secure lockscreen and the sudo password.
There's are plenty of other apps that need to request root access on a regular basis. These were just a few examples. If you only need root for TiBu then a sudo password type of security measure would work. In my case all I'd be doing with my phone would be typing that password again and again.
Beyond what is said above, to my understanding... What "root" is is just a way to install the "su" binary to your phone, with a nice GUI to make it more friendly for phone/tablet use.
Being rooted, if memory serves, is being able to access and change any file in your root directory, at least that's a simplified way to see it. The SU app is a GUI that is mostly used to control the ability of apps to access and change the root directory.
Sent from my Nexus 6 using Tapatalk
Interesting thread. Thanks for your work....subscribed
doitright said:
There are precisely two motives I can imagine for buying up all the root control software for Android;
1) monetizing it, which is contrary to the user's best interests,
2) something very frightening and dangerous involving the potential exploitation of everybody's devices.
Click to expand...
Click to collapse
I would suggest that there is a third potential motive here - that having control over the "only" way of rooting Android devices might be attractive to Google.
I've read a few articles suggesting that they would prefer to prevent people from rooting their phones (partially so that they can monetise Android Pay - which requires a Trusted Computer Base, which means unrooted - as well as controlling Ad Blockers, which affect a revenue stream). I also suspect that only a tiny minority of Android users - and most of them are probably on here - actually root their devices.
Regardless of the motives, having a technological monoculture is never a good thing, especially when it is delivered as a binary owned by an unknown organisation.
(No disrespect to Chainfire - I have had many years of root access to my devices thanks to his efforts.)
scryan said:
Beyond what is said above, to my understanding... What "root" is is just a way to install the "su" binary to your phone, with a nice GUI to make it more friendly for phone/tablet use.
Click to expand...
Click to collapse
Not quite.
"root" is the *name* of a privileged user, with user id of 0.
The "su" command (short for substitute user), is used to substitute your current user for another user, but most particularly root.
Every application and many subsystems in Android are granted each their own user, which are very restrictive, hence the need to escalate to root to obtain necessary privileges.
Philip said:
I would suggest that there is a third potential motive here - that having control over the "only" way of rooting Android devices might be attractive to Google.
Click to expand...
Click to collapse
What does that have to do with the third party? I doubt very much that Google would appreciate the security of their users being compromised by a 3rd party.
urrgevo said:
Being rooted, if memory serves, is being able to access and change any file in your root directory, at least that's a simplified way to see it. The SU app is a GUI that is mostly used to control the ability of apps to access and change the root directory.
Click to expand...
Click to collapse
Nope. The root directory can be setup to be accessible by specific users just by applying the appropriate permissions to the files.
The root directory and root user are not specifically related.
doitright said:
What does that have to do with the third party? I doubt very much that Google would appreciate the security of their users being compromised by a 3rd party.
Click to expand...
Click to collapse
Because the "third party" might actually be Google (or an organisation funded by them).
---------- Post added at 15:05 ---------- Previous post was at 15:02 ----------
doitright said:
Every application and many subsystems in Android are granted each their own user, which are very restrictive, hence the need to escalate to root to obtain necessary privileges.
Click to expand...
Click to collapse
Shouldn't need to su to root to do this - that's what setuid and setgid are for.
Thread Closed
Thread Closed
We all know that, we need a Wireguard Account and its application to use Wireguard VPN(AzireVPN) services.
Click to expand...
Click to collapse
I should clarify that WireGuard ≠ AzireVPN. WireGuard is an open source VPN protocol and implementation project I started. AzireVPN is one of many providers selling commercial service to their particular WireGuard servers. Beyond that, they are pretty separate and unrelated.
With that out of the way, I'd encourage people not to use the attached zips of the original post here. They contain private keys -- which are evidently no longer private -- which means that if any other XDAers are using it, you'll be kicked off by each other and the thing will basically be unusable. More obviously, this also means there are grave security issues, since anybody can impersonate you, since your private key is shared with the world. It's sort of like if a stranger on the street gave you a microphone with an antenna attached and said, "you can trust this microphone with all your secrets, I swear", and then walked away with no further explanation. Don't talk into microphones given to you by strangers.
zx2c4 said:
I should clarify that WireGuard ≠ AzireVPN. WireGuard is an open source VPN protocol and implementation project I started. AzireVPN is one of many providers selling commercial service to their particular WireGuard servers. Beyond that, they are pretty separate and unrelated.
With that out of the way, I'd encourage people not to use the attached zips of the original post here. They contain private keys -- which are evidently no longer private -- which means that if any other XDAers are using it, you'll be kicked off by each other and the thing will basically be unusable. More obviously, this also means there are grave security issues, since anybody can impersonate you, since your private key is shared with the world. It's sort of like if a stranger on the street gave you a microphone with an antenna attached and said, "you can trust this microphone with all your secrets, I swear", and then walked away with no further explanation. Don't talk into microphones given to you by strangers.
Click to expand...
Click to collapse
Hi @zx2c4
Thank you for clarifying certain things. As per your post there are several security issues which is a matter of concern. I thought its a great idea to use wireguard vpn because this just works fine. Since *Public Key* resides in the *.conf files whenever i use world-writable permission for *.conf files and setup the VPN connection. It warns me at the time of execution of script not to use *world-writable* permission. So i changed the permission to *owner* only and make them sticky. After this everything seems working fine.
TheHitMan said:
Hi @zx2c4
Thank you for clarifying certain things. As per your post there are several security issues which is a matter of concern. I thought its a great idea to use wireguard vpn because this just works fine. Since *Public Key* resides in the *.conf files whenever i use world-writable permission for *.conf files and setup the VPN connection. It warns me at the time of execution of script not to use *world-writable* permission. So i changed the permission to *owner* only and make them sticky. After this everything seems working fine.
Click to expand...
Click to collapse
Your irrelevant response here isn't at all related to the security issue at hand, which probably indicates you don't understand the security issue. If you tell the world your private keys, those private keys are no longer secure. Your zip files contain static private keys. Hence, they are no longer private.
I'd strongly recommend you take down this post before others use it and find themselves in a dangerous situation. It looks like you put a lot of hard commendable work into this release, and so I'm very sorry to deliver the bad news to you.
Regrettably I won't have the time to field additional follow-ups on the matter. However, I'd encourage those reading not to use the zips attached to the original post.
zx2c4 said:
Your irrelevant response here isn't at all related to the security issue at hand, which probably indicates you don't understand the security issue. If you tell the world your private keys, those private keys are no longer secure. Your zip files contain static private keys. Hence, they are no longer private.
I'd strongly recommend you take down this post before others use it and find themselves in a dangerous situation. It looks like you put a lot of hard commendable work into this release, and so I'm very sorry to deliver the bad news to you.
Regrettably I won't have the time to field additional follow-ups on the matter. However, I'd encourage those reading not to use the zips attached to the original post.
Click to expand...
Click to collapse
I really appreciate the time you gave here to clarify certain useful thing. I am going to take these downloads and this thread down. @zx2c4 thanks for your work. The VPN Protocol is amazing and works without any problem :good::good: .
Thread closed on OP request
Thread re-opened at OP's request.