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.
Hi,
I got a few spare androids' and i'm considering giving them to my kids (11 and 12) to play around with it and enjoy the android experience. however I don't want them being able to put 3rd party applications. how do i go about removing the option of "unknown sources" and maybe wifi from the settings.apk.
I'm not new to java and xml but sort of new to android development, I've tried several ways to remove it from the apk only (ark, ddx, baksmali, apksign) I did it in so many ways that i can't remember them all. I've also tried to decode the apk with apktool, ddx, baksmali, and creating a new project from existing source in eclipse, and I couldn't figure out what parts I have to modify to get it working (i kept on getting errors in eclipse so i wasn't even able to compile and test it in DDMS-eclipse).
Also i would like to know if maybe it is necessary to port the whole kernel source into eclipse?
I've searched all over the internet for a information for this specific thing and I couldn't find anything.
Btw, I'm using nix lucid.
Thanks In advance.
any help would be appreciated!
how about flash the supere rom without the google apps? that way they wont be able to access the market..
lagu805 said:
how about flash the supere rom without the google apps? that way they wont be able to access the market..
Click to expand...
Click to collapse
I know, the problem is not the market, i can pull it out from the phone with adb in a second w/o superE, but they can still install stuff on it with a sd card, and I would hate to not put in a file browser on the phone.
I think it would be a good idea to make a rom that's made for kids, for playing games and stuff without me worrying about it.
I'm sure that they will try to figure out a way to get around the "no market on the phone" and I should not underestimate a kid (even a 12 year old). I've seen him getting around lots of technological obstacle's.
I think that the world could use a kid's version of android, you know, get them hooked when they're young. The last thing i would like to hear from my kids is talking about iPhone or Windows. We're all linux in our house
Interesting. I too gave Magics to my 11 & 12 yr olds, one without a data plan and the other without a SIM at all. I think the right way might be multiuser like we already do on the desktops. Sudo would be a nice touch but I'd be happy to login as admin to install or whatnot.
Multiuser is something I'd like to see anyway with most or some settings on a per user basis. Or at least just for security, normal login can't do critical tasks that might cause issues. I think we'll hear about this again once we hear about some seriously dangerous apps/scams/viri on the phones.
In the meantime your best bet is education and rules about what can and can't be done. Then once per week or so you take the phone and check things out, update as needed, etc. So far my kids have little interest in breaking the rules and are happy browsing the market for fun things.
I think the only way to achieve this is to download the AOSP, edit the sources to remove the options and then compile your own ROM.
3rdcoast said:
Interesting. I too gave Magics to my 11 & 12 yr olds, one without a data plan and the other without a SIM at all. I think the right way might be multiuser like we already do on the desktops. Sudo would be a nice touch but I'd be happy to login as admin to install or whatnot.
Multiuser is something I'd like to see anyway with most or some settings on a per user basis. Or at least just for security, normal login can't do critical tasks that might cause issues. I think we'll hear about this again once we hear about some seriously dangerous apps/scams/viri on the phones.
In the meantime your best bet is education and rules about what can and can't be done. Then once per week or so you take the phone and check things out, update as needed, etc. So far my kids have little interest in breaking the rules and are happy browsing the market for fun things.
Click to expand...
Click to collapse
well, it is just a nix and SUDO should be possible, but setting this up is a quite a project and I don't think this is a one day project.
As for educating, I think they know right from wrong and I don't think that they will willingly break the rules, the market however is full of apps that are not meant for young kids..... what do you think they're going to do when they bump in to one of those apps? .
Actually what i wanted to do is to give them a phone with a line and no data plan so they can play games or watch movies, If the kids want to use the internet, there are more than enough boxes at home they can use. This phone is strictly for voice text and games.
What I want to accomplish in general, is having a child safe phone, and have the other parents here who want their kids to have to have an android, enjoy it. My way of giving back to the community.
But to have a phone that will be suitable for the purpose (not just for my kids) the data has to be completely disabled, and wifi is going to be the issue. putting on an encryption on wifi is a joke, ever heard of aircrack? I'm sure there are lots of determined horny 15 year olds that will get around that. (am i paranoid?)
Case_ said:
I think the only way to achieve this is to download the AOSP, edit the sources to remove the options and then compile your own ROM.
Click to expand...
Click to collapse
That's exactly what i want to do. The question is how do I do it?
Again, I'm not a complete noob, I just never played around with android as an OS. so if I can have the first push here here what I'm supposed to do to start this I would really appreciate it.
As I've said in my first post, I tried a few things and i couldn't get it right. what part of this don't i get??
Thanks a lot.
well your not even going in the right direction..
do you have an IDE with compiler and the android SDK all set up? then you can check on dferrera post on how to compile android from source... its listed in this forum.. please search
if your not a programmer or have no idea what classes - functions etc are then this might now be an option for you that is something you can be instructed on
you are going to need to learn to compile android from source and modify it, this is a very big task mate - be prepared, and no one can answer all the questions for u
alan090 said:
well your not even going in the right direction..
do you have an IDE with compiler and the android SDK all set up? then you can check on dferrera post on how to compile android from source... its listed in this forum.. please search
if your not a programmer or have no idea what classes - functions etc are then this might now be an option for you that is something you can be instructed on
you are going to need to learn to compile android from source and modify it, this is a very big task mate - be prepared, and no one can answer all the questions for u
Click to expand...
Click to collapse
Thanks for the reply, but i can't seem to get java5 working on 10.04 (the 10.04 repos have only java6 but i did add the old repos and ran in to some issues), I had it working on 9.04 though. anyone made it run on 10.04? or should I downgrade (or run it in VB) to 9.04/.10?
k50aker said:
Thanks for the reply, but i can't seem to get java5 working on 10.04 (the 10.04 repos have only java6 but i did add the old repos and ran in to some issues), I had it working on 9.04 though. anyone made it run on 10.04? or should I downgrade (or run it in VB) to 9.04/.10?
Click to expand...
Click to collapse
Add these 2 lines to the end of /etc/apt/sources.list file
Code:
deb http://pl.archive.ubuntu.com/ubuntu/ jaunty multiverse
deb http://pl.archive.ubuntu.com/ubuntu/ jaunty universe
then do:
Code:
sudo apt-get update
sudo apt-get install sun-java5-jdk
@k50aker
Hiding Wifi and other things should be quite easy task, but... how do you want to protect against system reinstallation? They could download any ROM from internet and install it in just 10 minutes. Backuping is easy too, so they could have 2 systems installed and switch between them when their dad comes home.
Android phones aren't desktops. You can't have root and don't give it to other users of a device.
Mod. edit: not dev related, moved to general
I wouldn't want to hide WiFI, the device is useless without connectivity, much cheaper toys out there for that if I wanted stand alone.
My two children each have a Magic and this is my experience, none of the worries that many parents seem to fear. They are well behaved and so far no problems and they are ready for 2.1 since 1.5 is just too confining even for them. Education goes a long way.
The best choice I made was to not put a SIM in one of the phones. WiFI is ideal since she is nearly always in a zone. This has gotten her used to IM instead of texting. Same effect but costs nothing. A SIP app works almost as well as SIM voice. Someday I'll do a data only SIM so she has total coverage, she'll understand that heavy data is to be done over WiFI and cell data is for VoIP and for times when it is really needed and can't wait.
However it would be nice if there was a limited setting requiring admin password for certain functions. But really, there hasn't been any problems but my kids might be grateful enough to not abuse the rights I give them. Best advice besides education if they are very young is to not SIM until after they get into the alternatives and not be addicted to texting. The older one has learned to watch her usage patterns and has to pay if she goes over budget.
Switch33 said:
Add these 2 lines to the end of /etc/apt/sources.list file
Code:
deb http://pl.archive.ubuntu.com/ubuntu/ jaunty multiverse
deb http://pl.archive.ubuntu.com/ubuntu/ jaunty universe
then do:
Code:
sudo apt-get update
sudo apt-get install sun-java5-jdk
Click to expand...
Click to collapse
those ropes are for jaunty not for lucid, and I have tried that before anyway and this is what i get:
Code:
desktop:~$ sudo apt-get install sun-java5-jdk
Reading package lists... Done
Building dependency tree
Reading state information... Done
sun-java5-jdk is already the newest version.
The following packages were automatically installed and are no longer required:
libwv2-4
Use 'apt-get autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 11 not upgraded.
1 not fully installed or removed.
After this operation, 0B of additional disk space will be used.
Setting up sun-java5-doc (1.5.0-19-0ubuntu0.9.04) ...
This package is an installer package, it does not actually contain the
J2SDK documentation. You will need to go download one of the
archives:
jdk-1_5_0-doc.zip jdk-1_5_0-doc-ja.zip
(choose the non-update version if this is the first installation).
Please visit
http://java.sun.com/j2se/1.5.0/download.html
now and download. The file should be owned by root.root and be copied
to /tmp.
[Press RETURN to try again, 'no' + RETURN to abort] no
Abort installation of J2SDK documentation
dpkg: error processing sun-java5-doc (--configure):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
sun-java5-doc
E: Sub-process /usr/bin/dpkg returned an error code (1)
Brut.all said:
@k50aker
Hiding Wifi and other things should be quite easy task, but... how do you want to protect against system reinstallation? They could download any ROM from internet and install it in just 10 minutes. Backuping is easy too, so they could have 2 systems installed and switch between them when their dad comes home.
Android phones aren't desktops. You can't have root and don't give it to other users of a device.
Click to expand...
Click to collapse
You are right, but one of the later steps I thought about would be a custom boot and custom or no recovery. But I will figure that out later in the project.
But i will probably change my direction on this (wifi etc.) based on what you guys say.
Hi guys,
I'm developing an app for a blog and wanted to implement pinch-tozoom on the image viewer but still support the app all the way back since 1.6.
In such a manner I was developing everyinthg in 1.6, and the moment I went to implement the pinch-to-zoom I changed to 2.1 and included the code that selects if API > 5 hide the ZoomControls and process pinch-to-zoom, else show zoom controls and do not process pinch-to-zoom.
My problem is that my manifest MinSDK is 4 and Eclipse keeps giving me the warning: Attribute minSdkVersion (4) is lower than the project target API level (7)
How do I fix that? what is the correct way to support multiple APIs?
thanks!
I believe this is a warning you should just ignore. If you right click it, and do delete, does it go away?
it does go away, but as soon as the app re-builts it comes back again.
yes, it is just a warning, it does compile and installs... but it's just weird, there should be away for the compiler to understand that I'm using multiple versions...
maybe submit as a bug to google?
It's not a bug, just ignore it. It's just warning you that you need to do things like not use code from the new SDK unless you've checked the user's SDK_INT
But you're already doing that so just ignore it.
well... I wish there was a way to better surround this, but Ok, I'll keep an eye on it.
Maybe I'll even comment out that part, finish the development on 1.6 and then re-enable it... just to be sure!
thanks!
Isnt that set in your manifest? what SDK version is set there?
rob17 said:
Isnt that set in your manifest? what SDK version is set there?
Click to expand...
Click to collapse
yes it is.
Min SDK 4 and Target SDK 7
but Eclipse still gives me warnings about it... I'll just have to live with it.
thanks.
ps.: if some forum moderator sees this and fancy closing the thread I guess it's ok.
Version Alpha 0.6.0 is now available
I'm back! Not dead yet, I promise. This is actually a relatively small update in terms of user-facing features, with only one really big new thing - support for file uploading - but that's a lot bigger than it might sound. It's the first write support I've implemented in the server, and it also required some fairly massive updates to the HttpServer component (support for binary requests, for POST parameters, for MIME multipart parsing). These will be built upon in forthcoming versions to add support for things like registry editing, in-browser file viewing (possibly editing), and so on. There are also a large number of small fixes and improvements that I've made over the last two-weeks-shy-of-a-year, which should make the server faster, more robust, better able to support concurrent connections, and lighter on device resources. Finally, while the app still targets WP8.0 and should run on 8.0, it now is designed for 8.1 compatibility (especially the AllCapabilities version).
Previous update (0.5.6): This version is mostly bug fixes and UI changes. The biggest changes are: clearer display of weird registry data types, the server now consumes fewer threads (it used to spawn them with wild abandon) and does faster string compares, the app version is now shown on the phone, error pages are now better, if you launch the app without a WiFi IP address it'll offer to take you to the WiFi settings page, connections are no longer closed as soon as the app starts sending a response, and the server now defaults to using the Connection: keep-alive header, with a two-minute timeout. The last change, combined with the second-to-last, should hopefully both do away with the tendency to have the app fail to display a page. However, I shouldn't have *needed* to switch it to "keep-alive" - using "close" should have worked - but it still veeeery occasionally would kill the connection early. Agh. Anyhow, this is better in the meantime.
DevDB offers me a support / Q&A thread. Please use that thread to ask questions; don't PM me unless it needs to be kept private for some reason!
ISSUES ON WP8.1:
It *should* work to deploy the app with "Application Deployment", but if you have a problem try deploying with "Windows Phone Application Deployment 8.1" instead.
Problems have been reported in the past when the app is installed to the SD card. It's small, though; putting it on internal storage shouldn't be a problem.
RESOLVED The AllCapabilities version included a few capabilities that were present in 8.0 but removed in 8.1. Those capabilities have been removed; the AllCapabilities version now deploys and runs on capability-unlocked WP8.1 phones.
IN CASE OF OTHER ISSUES: Please provide a *detailed* error report - what phone and OS version you have, what hacks you've installed, what Webserver version you're running, what you do to get the error to occur, and exactly *what* occurs - and I'll fix it as soon as I can! There's a DevDB section for posting bug reports, and you can also use CodePlex if you want.
I finally implemented file upload! I'll work on getting more stuff like that (file delete, possibly file rename/move/copy, various registry edits), hopefully soon! I also hope to add support for different areas, like an "Applications" path, a "Processes" path, a "Services" path... eventually. Many of those are really hard without good privileges. I'm also looking at moving the server to a background process and making the app just a control UI for it, adding support for authentication and/or HTTPS, adding some stylesheets to the web UI, adding caching, and much more. I did finally implement Connection header support.
Once again, the XAP is published twice. One is a fairly standard XAP that any phone can sideload, and the second has many exotic capabilities to enable viewing of (and writing to) slightly more of the file system and registry. The standard XAP has had its list of capabilities expanded to pretty much all of them that can be used without interop-unlock. The high-capability variant requires not just interop-unlock, but the additional capability-unlock hack available in the interop-unlock thread. The AllCapabilities version now works with WP8.1; sorry for the long delay on that!
An item of note: the AllCapabilities version (or either version, on WP8.1) can open other drives in the file system. On phones with an SD card, it is mounted at D: and you can browse it as normal. Credit to @hjc4869 for this discovery!
DESCRIPTION: This is a simple webserver app which can enumerate those files that are in folders readable from the sandbox, can download and upload (access permitting) files, can browse the registry, and can display the contents of registry values of any type. It runs on WP8.x (not yet tested on W10M). It is a spiritual successor to the Functional Webserver / WebServer (Mango) projects from WP7. This version is still missing a lot of functionality as I decided to implement it from scratch, but it is advancing swiftly. Note that there's no access controls implemented; use it on a public network only at your own risk!
Instructions are simple: sideload the XAP, connect to WiFi (required), run the app (called "WebServer Native Access"), point a web browser (on a PC or phone that is also on that local network) to the URL that the app displays. You should get a basic index page. Click on a Filesystem or Registry link to begin browsing the phone. There's a textbox near the top of all filesystem pages, type in a path there (for example, "C:windows" with no quotes) and hit Enter or click Get Files. You'll see a list of the contents of that folder. Click on a file to download it or a directory to open it. There's also a box for uploading files, one at a time, to the current directory. Navigating the registry is similar, except you'll need to specify the registry hive and then the path from that hive (or no path, to access the root of the hive).
As of v0.6.0, uploading files is finally supported! Other modifications (editing files, creating, deleting, or changing registry keys or values) are currently not supported. They will be "soon" although my personal testing suggests that basically the whole registry, and most of the file system, is off-limits for writing unless you use restricted capabilities.
You might see an error code (error 5 is "ACCESS_DENIED", you'll see it a lot; I should replace it with an appropriate 403 or whatever). Or you might see a status 500 message because of an exception in the server. Or the server may just crash (hopefully not so often anymore...). I'm making it more resilient, but there are still bugs. Please report any previously-unreported issues you find, including how to reproduce them, and I'll fix them if possible.
Also feel free to request features or changes; I'll implement them if reasonably possible. The app is a mixture of C++ and C# code; I could probably have done it all in one or the other but wanted to have a C++ component in case I ran into something that wasn't available in C#, and although it probably would have saved some time, I decided that hacking up a web server in C++ was maybe not the best idea.
The source code is on Codeplex, at the following projects: https://wp8webserver.codeplex.com/ for the server and the app (C#) and https://wp8nativeaccess.codeplex.com/ for the native access wrappers (C++). You may have to fix up the reference paths to get the C# component to see the C++ component correctly. The code is reasonably well documented, but let me know if you have any questions. Permission to re-use the code or components is granted under the MS-PL (Microsoft Permissive License) as posted on Codeplex.
Go forth and find cool stuff!
Version history (see the git commit logs for more detail:
07 July 2013 - 0.2.0: Initial release, FS only, 920 downloads (source: 652 downloads)
14 July 2013 - 0.3.2: initial registry, HTTP server and web app encapsulation, source on Codeplex, 225 downloads
0.3.3: bugfixes, 454 downloads
0.4.2: basic registry values display, 86 downloads
0.4.3: bugfixes, 326 downloads
0.4.6: multistring registry values, bugfixes, updated libraries, first AllCapabilities version (950 downloads), 453 downloads
25 Oct 2013 - 0.4.8: binary and long registry values, formatting and bugfixes, 451 downloads AllCaps, 201 normal
22 Dec 2013 - 0.4.9: all registry value types, better threading, proper resume, remembers port, 97 downloads AllCaps, 53 normal
24 Dec 2013 - 0.5.0: background operation using Location APIs. Downloads: 1011 AllCaps, 963 Normal
20 Jul 2014 - 0.5.1: More capabilities, better navigation. Downloads: 358 AllCaps, 352 normal
07 Aug 2014 - 0.5.3: .REG export, better traversal, bugfixes. Downloads as of 0.5.5 release: 260 AllCaps, 164 normal
10 Oct 2014 - 0.5.5: Bugfixes and back-end work. Downloads as of 0.6.0 release: 140 AllCaps, 113 normal
25 Oct 2014 - 0.5.6: Bugfixes and UI tweaks. Downloads as of 0.6.0 release: 1720 AllCaps, 1334 normal
12 Oct 2015 - 0.6.0: Binary requests, file uploads, bugfixes.
XDA:DevDB Information
WebServer Native Access, Tool/Utility for the Windows Phone 8 General
Contributors
GoodDayToDie
Source Code: https://wp8webserver.codeplex.com/
Version Information
Status: Alpha
Created 2014-10-17
Last Updated 2015-10-12
I'm going to use this space to mention something that's pretty cool:
J. Arturo of http://www.komodosoft.net is using a modified version of the HTTP server that powers this app in the ShareFolder app (http://www.windowsphone.com/s?appid=e2b9c82e-eaa1-4a3b-9d4a-8a2933a8bdb4) to support opening video files directly from Windows network shares! This was done to work around a limitation of the WP8 media control: it can only source from an isolated storage file or a HTTP URL. By running a server in the background and streaming the video file through it, and pointing the video player control at the localhost URL, it becomes possible to play the file on the phone without first copying it to the app's isolated storage. A very cool way to solve the problem! Also, reviewing the changes that were made to the network code of the server pointed me toward those threading fixes I made that have hopefully much improved version 0.4.9.
Please note that the updated version of ShareFolder with this feature may not yet be available, although it should be soon. It is a commercial (paid) app, but the author sought and received permission to use my code (although the license does not require such permission be received).
What exactly is the problem with sockets? I am battling myself with sockets atm too, maybe we can share knowledge?
Strictly speaking, the problem was with the phone's limited subset of the Sockets API forcing me to access it through functions I wouldn't normally use (asynchronous everything, SocketAsyncEventArgs and lambdas and AutoResetEvents and so on everywhere...) but I've got a pretty good handle on it now, at least for the System.Net.Sockets.Socket and its friends. The new .NET 4.x ones (using the async keyword and all) are in a different namespace; I didn't mess with them. They are more abstracted from the Bekeley sockets interface that I'm used to from C, but they are also (supposedly) more user-friendly, especially if you don't feel like writing all your own thread management code (and in fairness, I should re-write the webserver's threading to use threadpools; they're better for this type of work).
If you want to ask questions about the topic, I suggest starting a new thread (possibly in the Q&A subforum, although it's also dev related...) and I'll answer if I can.
GoodDayToDie, just an idea: how about sharing your source code via CodePlex or GitHub?
Oh man, this is pretty nice! GoodDayToDie does it again!
So far, I can read \Windows, the current install folder which you access just by typing "." with no quotes and the current application folder by typing ".." I can access the .dlls, .winmd and AppManifest.xml from the current install, but from everywhere else, it goes boom. This is a great step towards something awesome though!
EDIT:
I was wrong. For some reason, when you click on a folder it's trying to "download" it, rather than chdir. I can get pretty far into the Windows directory.
THAT's what you meant by "Click on a file (note: there's no current way to tell the difference between files and folders) to download it.
You might see an error code (error 5 is "ACCESS_DENIED", you'll see it a lot). Or you might see a status 500 message because of an exception in the server. It's getting a lot more resilient but there are surely still some bugs. ".
If you see a folder, just type the full path to it instead of clicking on it and you will be able to read the contents.
ANOTHER EDIT:
I just found a file inside of the \Windows\System32 directory named [guid].devicemetadata-ms (It's easier to just search for "devicemetadata-ms"). It's a cab file with some metadata about WP8 with a sign.cat and packagesign.cat file in the archive. I don't know what these files could potentially be useful for.
New version in a day or two (busy tonight). Features I plan to implement (not necessarily in the next version or at any particular time):
File upload (IsoStore and, of all crazy things, install directory are writable. I think I'll put a flag on each FS page that says whether the current dir is writable...).
File deletion (where possible, of course).
File and Directory distinction in the listing (clicking a dir should open it, not error out).
Filesystem index page with links to folders that can be accessed successfully (since the root isn't readable).
Some more file info (size, probably attributes, possibly permissions).
Possibly an option to preview a file (as plain text) without downloading it.
Some kind of background mode (the server uses minimal resources when not actively servicing a request, so I'll see if I can get it to work in the background, perhaps by abusing the music transfer agent...)
Some kind of offline mode (at least basic file browsing within the app, as an alternative to using the web interface, though I might just make a second app for that).
Source code changes: separate the server code from the webapp / phone app code (move it into its own project).
Source code changes: move to a hosted version control service, probably CodePlex (good suggestion sensboston).
Maybe add an icon and such...
Any other suggestions?
I also want to try experimenting with various non-standard capabilities and see if I can get access to more of the system . I've already added the ability to access removable storage, but I've also found a bunch of really weird and frequently undocumented capabilities in the OS's policy configuration files, and I need to look into those... The interesting (and possibly the uninteresting) ones are probably blocked for unsigned sideloaded apps, but it's worth checking on anyhow.
Yeah sorry, I should have been more explicit about clicking on dirs. not working in 0.2.0. Also, it's "unofficial" but if you check the URL bar you'll see a URL parameter called something like "pattern" (by default, it's *) and if you change that, you can filter the results. For example, "foo*.exe" (note: no quotes!) will search for EXE files whose names start with "foo". Among other uses, this makes it a lot faster to load large dirs like System32. This will be added to the UI at some point. Also note that URL decoding is applied correctly to querystring parameters (Probably already noticed with the path sometimes written using %5C for \) so you can add special characters that way if needed, though currently any of them but \ will probably just cause an exception.
...
Actually, does this filesystem support Alternate Data Streams? If so, you should be able to download them by appending a : and the ADS name to the filename in the download URL...
OK, so that was a new version in five days. Sorry, stuff takes time.
The source code is now on Codeplex. The native access portion is at https://wp8nativeaccess.codeplex.com/, and the web server portion is at https://wp8webserver.codeplex.com/. Both are licensed MS-PL and use Git for version control. The full XAP is also available for download from the Webserver project on Codeplex.
GoodDayToDie said:
OK, so that was a new version in five days. Sorry, stuff takes time.
The source code is now on Codeplex. The native access portion is at https://wp8nativeaccess.codeplex.com/, and the web server portion is at https://wp8webserver.codeplex.com/. Both are licensed MS-PL and use Git for version control. The full XAP is also available for download from the Webserver project on Codeplex.
Click to expand...
Click to collapse
You are a god. I'll be sure to post my findings .
Hmm. When I first load up WebServer File Access then access from my laptop, I get the main page then the program crashes on my phone. It seems to hold a lock on to the socket as i can no longer access port 9999 from any other device when re-opening the app. I can access it again when I reboot, but the same thing happens.
EDIT: I think it may be due to the WiFi at work... it's junky. I'll try again when I get home. I was just able to browse some directories.
Wow, that's completely unexpected... I can beef up the error chacking and handling around the listener port though. That part of the code is really straightforward, so I actually haven't hardened it very much. I can also put in a Finally block to close the socket and/or mark the socket as re-usable so that other apps (or the same one again) can listen on it in the future.
I also plan to add support for setting your own port, but that doesn't solve the underlying problem. I'll put in more error reporting as well, to enable better debugging. Thanks for the report! Always good to have users report problems so I know where to prioritize fixes.
GoodDayToDie said:
Wow, that's completely unexpected... I can beef up the error chacking and handling around the listener port though. That part of the code is really straightforward, so I actually haven't hardened it very much. I can also put in a Finally block to close the socket and/or mark the socket as re-usable so that other apps (or the same one again) can listen on it in the future.
I also plan to add support for setting your own port, but that doesn't solve the underlying problem. I'll put in more error reporting as well, to enable better debugging. Thanks for the report! Always good to have users report problems so I know where to prioritize fixes.
Click to expand...
Click to collapse
I tried the app at home and it DOES crash on the first hit of the home page, but I'm able to open it up again and it works fine.
The new version 0.3.3 should be more rebust; try it and let me know if you still have issues. If you do, let me know what the exception message is (and any other info you can provide) and I'll try to track it down.
Downloading really big files should also work now. The app will read and push files in smaller chunks (the code to do this existed in the NativeAccess library before, but wasn't used).
a simple SDK?
Dear Sir
Will it be possible for you to make some sort of SDK from this so other developers can integrate this into their apps and enable browsing isolatedstorage?
Sorry if it is a stupid question.
Bruce_X_Lee said:
Dear Sir
Will it be possible for you to make some sort of SDK from this so other developers can integrate this into their apps and enable browsing isolatedstorage?
Sorry if it is a stupid question.
Click to expand...
Click to collapse
With the restrictions in permissions, this app only allows browsing of the app's isolatedstorage locally. You are able to use the IsolatedStorage API within your app to browse files and directories already.
snickler said:
With the restrictions in permissions, this app only allows browsing of the app's isolatedstorage locally. You are able to use the IsolatedStorage API within your app to browse files and directories already.
Click to expand...
Click to collapse
That's right. What I want is to allow the end user to be able to browse the isolatedstorage. Imagine I have a video download app, I want the user to be able to transfer those downloaded videos from the app's isolated storage to, say, a PC.
One can do this by integrating the webserver code into the said app.
Bruce_X_Lee said:
That's right. What I want is to allow the end user to be able to browse the isolatedstorage. Imagine I have a video download app, I want the user to be able to transfer those downloaded videos from the app's isolated storage to, say, a PC.
One can do this by integrating the webserver code into the said app.
Click to expand...
Click to collapse
Ahh I see what you mean now. That sounds like a pretty nice idea. I think more research needs to be done to see whether it would even be allowed in the marketplace.
The webserver portion is stand-alone (builds to its own .NET DLL with no dependencies on the other parts) and has a pretty clean interface. You'd need to implement the web application portion of it yourself - the thing that generates the response pages for a given request - but the HttpResponse class in the server does a lot of the work of that for you; you basically just specify the content you want to send (as a String or byte array) and it sends it.
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.