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 all...
I was wondering if and how could be possible to port apks built for one tablet to another of different brand, i.e. I liked a lot the email client of the Samsung Galaxy 10.1 (with multiple email selector and recycle bin emptying feature), but many others are worth a try...
When I try simply to push the email.apk to my Iconia, it won't work (the icon diasppears from apps), if I try to install it I obtain an error (app not installed) probably due to a signing mismatch... I'd like really to learn how to do this, if possible. This knowledge will complete and accomplish any further request about personalization of our tablets, could be a great improvement being capable to get out the "system" you really want...
I tried to figure out how to use apk manager, but it's quite really difficult without some good suggestion, the thread is more than 200 pages long, and I got stoned before simply find out any usefull info about "system apks"...
TIA
I would like to know also. I want the Facebook account integration from the Galaxy.
Some apps are license by that manufacurer and would be considered wares.its a gray area please be careful. And make sure the Dec of all apps you use get paid
simple answer
couple of APK for galaxy are using CORE framework of the galaxy tabs firmware itself
that will not be possible to just install those apk.
such as
touchwizUI
status bar overlay (I mean the minimode menu with quick access), the quick access settings...
Email and Social things
It's their "Marketing Strenght" so they didn't make it easy to be "stolen" by other brands
I run just the dual clock, the memo, and eReader from samsung but I am running a custom firmware so that change many things
At this moment only 1 custom firmware does use Samsung as base, Virtuous Galaxy... but I have to warn that using custom firmware without following backup steps strictly or knowing the consequence is to AVOID.
sanaell said:
...
At this moment only 1 custom firmware does use Samsung as base, Virtuous Galaxy... but I have to warn that using custom firmware without following backup steps strictly or knowing the consequence is to AVOID.
Click to expand...
Click to collapse
first of all, thanks for your answer, and your warn...
I'd like to go deep in the question, as you correctly affirmed, virtuous galaxy's based upon Unity v5 kernel, but virtuous picasso also lays on the same structure, doesn't it?
right now I'm running m-dj's picasso 1.1.0 rom, wouldn't be possible, with any required modification, to run elsewhere coming apks?
I mean, think about having two different pcs, both with the same hardware and the same linux distro and kernel, wouldn't seem wierd that on one pc you could run an application that won't run on the other?
I'm thinking, if they wanted to protect their components why they didn't simply wrote hardware oriented kernels? Therefore, its a fact that on my iconia I can run either a Samsung or an Asus based rom, according to this, where is the cross-platform limit? I mean, is there some sort of documentation defining which part of these Android system is "really" open, under GPL, GNU or whatever structured property info list? I can't find any browsing the net... or maybe I've found too much, its almost impossible to understand what you can and what you can't...
I do not know the whole answer to this question.but I do know this much.if you have any.apk application that is for sale on the market or was installed for free on any device that it was not pre installed on. I would thing it would be considered pirated. As you did not buy it.nor did the developer give permission to run the API on your device.thou some apostle you buy can be installed across the devices you have registered with Googler
if im wrong people please correct me.I just think that developers that fallow rules and write great software MUST BE PAID.
erica_renee said:
I do not know the whole answer to this question.but I do know this much.if you have any.apk application that is for sale on the market or was installed for free on any device that it was not pre installed on. I would thing it would be considered pirated. As you did not buy it.nor did the developer give permission to run the API on your device.thou some apostle you buy can be installed across the devices you have registered with Googler
if im wrong people please correct me.I just think that developers that fallow rules and write great software MUST BE PAID.
Click to expand...
Click to collapse
Right and Wrong
if the application is a paid application and wasn't preinstalled on your tablet it is not really legal
if the application is free but cannot be installed from the market and you install it from other sources it's ok
if the application is from another tablet, and exclusively on this tablet do not expect run it on the stock firmware of your tablet, you have great chance to cannot run it simply, or get some random FC (such as from GALAXY because they use another structure on the file directory... so some application try to get the path and it's return an error, Or they are implemented and integrated with the kernel and that... you can't pass throught)
On my tablet I do run
ASUS widget
Galaxy widget (dual clock)
and some other application not from ACER.
now to get back to the OP
. you are on a virtuous... why not go on the virtuous Galaxy !!! if you want galaxy application... I don't get it...
sanaell said:
now to get back to the OP
. you are on a virtuous... why not go on the virtuous Galaxy !!! if you want galaxy application... I don't get it...
Click to expand...
Click to collapse
I agree to this explanation of yours, when I flash a rom different from the original, aware that's coming from a different brand, I'm more or less conscious that I'm doing something wrong. mmmf... that's philosophy... won't lose your time
The point is, I've tried the Galaxy rom, I don't like the interface, I don't like the extra bar functionalities, in short I mostly appreciated the Email.apk, most of all because it has a convenient "select all" function, even in the recycler bin (I can't stand with an email client stupid like the one embedded in the Acer version). In any case, given the impossibility to get the Galaxy Email, I'll buy a new one on the market...
It took us much longer than WP7 did, but the first Interop Unlock hack for WP8 is now available. It's currently limited to SAMSUNG phones, although we're trying to extend it to other phones, of course.
WARNING: Samsung is trying to break this hack! If you take the retail upgrade to GDR3 including the Samsung firmware update, it will not work!
A brief summary, for those unfamiliar with interop-lock: Windows Phone allows a number of high-privilege app capabilities, which can be used to make changes to the OS which are normally not possible for a third-party app. The limitation on whether we can use these capabilities or not is based on what "level" of developer unlock the phone has; standard "ISV" (Independent Software Vendor) dev unlock (max 10 apps or less) is what pretty much everybody gets; OEMs, however, get a special OEM Developer Unlock (300 apps or more) which gives them the ability to use much higher-privilege app capabilities than the standard ISV unlock permits. The name comes from ID_CAP_INTEROPSERVICES, the capability which was most important in WP7. In WP8, however, there are a great many interesting capabilities. Note that Interop-unlock by itself does not enable all of these. However, at least on Samsung phones, it is now possible to enable *all* the capabilities.
Guide for Samsung's ATIV phones:
The instructions are generally well-provided in @-W_O_L_F- 's app (direct link for updated XAP). You will also need the Diagnosis app, which is included (though hidden) on every Samsung WIndows phone.
The instructions are as follows:
Developer-unlock your phone. You will need the Windows Phone Developer Registration tool for this; it comes with the SDK.
Sideload the helper app using Application Deployment (included with SDK) or WPPT. It does not work to just copy the file to your phone, or similar.
Open the Phone dialer (the built-in one) and dial ##634# to install the Diagnosis app (if you hadn't already). You can exit it afterward.
Run the Interop Unlock Helper app and read the instructions, clicking Next until you get to Step 2.
Click the button to generate the toast notification for your phone's Diagnosis app, then tap on the toast to open the hidden registry editor.
Press-and-hold the Back button, and switch back to the helper app without closing the registry editor. Click Next to go to Step 3 in the helper app.
Copy the provided registry paths and values out of the helper app, use the Back-and-hold switcher to return to Diagnosis, paste the values into the registry editor, and write them.
Don't worry if the app says a write failed! Just hit Read afterward to verify the change.
Repeat the previous steps a few times, hitting Next after each set of instructions, until the Helper app says "Finish".
Once all the registry values are written, congratulations; you are interop-unlocked!
At this point, you probably want to run the EnableAllSideloading hack below.
If you want to enable sideloading even more high-privileged apps, you'll want the following:
Install the BootstrapSamsung app attached to this post. This requires having interop-unlock already, and will not work if you have Samsung's ships-with-GDR3 firmware update unless you unblock RPC.
Run the app once, and ensure it displays a success message. You may then exit and (optionally) remove the app.
Install the EnableAllSideloading app attached to this post. This requires the bootstrap step. However, it is not specific to Samsung (we just can't bootstrap anything else yet).
Run EnableAllSideloading once, and ensure it displays a success message. You may then exit and (optionally) remove the app.
At this point, you will be able to sideload any capability, even the ones used for built-in apps and services. However, there appear to still be restrictions, even with a capability such as ID_CAP_BUILTIN_TCB. Multiple XDA members, including @Heathcliff74 and myself, are working to overcome these restrictions.
It may be necessary to repeat these steps after a phone update.
Capabilities which will be enabled, without further modification, by using interop-unlock:
Note: This list is *just* the ones from Interop-unlock; it does not unclude the ones from EnableAllSideloading.
ID_CAP_CALLMESSAGING_FILTER
ID_CAP_CAMERA
ID_CAP_CELL_API_COMMON
ID_CAP_CELL_API_LOCATION
ID_CAP_CELL_API_OEM_PASSTHROUGH
ID_CAP_CELL_API_UICC
ID_CAP_CELL_API_UICC_LOWLEVEL
ID_CAP_CELL_WNF
ID_CAP_CSP_FOUNDATION
ID_CAP_CSP_MAIL
ID_CAP_CSP_OEM
ID_CAP_CSP_W4_APPLICATION
ID_CAP_CSP_WIFI_HOTSPOT
ID_CAP_DEVICE_MANAGEMENT
ID_CAP_DEVICE_MANAGEMENT_ADMIN
ID_CAP_DEVICE_MANAGEMENT_BOOTSTRAP
ID_CAP_DEVICE_MANAGEMENT_SECURITY_POLICIES
ID_CAP_DU_MIGRATOR_STATUS_OEM
ID_CAP_OEM_DEPLOYMENT
ID_CAP_INTERNET_EXPLORER_FAVORITES
ID_CAP_INTERNET_EXPLORER_SEARCH_PROVIDER_KEYS_HKCU
ID_CAP_INTEROPSERVICES
ID_CAP_KIDZONE_CUSTOMIZATION
ID_CAP_MAP_WRITE
ID_CAP_MEDIALIB_PHOTO_FULL
ID_CAP_NETWORKING_ADMIN
ID_CAP_OEM_ADC
ID_CAP_OEMPUBLICDIRECTORY
ID_CAP_PEOPLE_EXTENSION
ID_CAP_PEOPLE_EXTENSION_IM
ID_CAP_PEOPLE_EXTENSION_MOBILE
ID_CAP_PERSONAL_INFORMATION_IMPORT
ID_CAP_RUNTIME_CONFIG
ID_CAP_SMS_INTERCEPT_AGENT
ID_CAP_SMS_INTERCEPT_RECIPIENT
ID_CAP_SYNC_EXTENSION
ID_CAP_VOICEMAIL
ID_CAP_WALLET_SECUREELEMENT
ID_CAP_WIFI_BASIC
One of the goals of this thread will be to explore what we can do with interop-unlock, and look for ways to achieve full permissions. I think I've found one, but it requires the ability to write registry multi-string values. Basically, if we could add a "superuser" privilege, or enable the use of ID_CAP_BUILTIN_TCB, which already has it, this would allow the creation of "root" apps.
Aside from myself, credit for this hack goes to @cpuguy for the Native Toast Launcher tool which permits accessing otherwise-unreachable code, and @-W_O_L_F- for helping put the pieces together. I'm not actually certain which one of us achieved the interop-unlock first; we were both working on it. @Heathcliff74 continues to be a help on the quest for full-unlock.
The source code for the apps below is posted at http://forum.xda-developers.com/showpost.php?p=45606584&postcount=88
Questions and Answers
Can I install WP7 interop apps using this?
They will install, but there's no point. They almost certainly won't actually work. Interop-unlock enables access to parts of the OS which third-party developers were not intended to touch; consequently, there's no backward compatibility. Even the methods used for native code on WP7 (which is different from, but nearly essential to make use of, interop-unlock) won't work on WP8. However, it should be possible to port many of those applications to WP8.
Will this work on Lumia phones / How can I get this on my Lumia / Are you working on this for Lumia phones / What about HTC, or some other OEM?
The current hack relies on a Samsung-specific component. Adding support for other phones will require new hacks. We are looking into it, rest assured; at this time, however, there is no way to gain interop-unlock on any WP8 device other than a Samsung one.
EDIT: It looks like there should soon be a Huawei W1 custom ROM with interop-unlock included. I don't deal with custom ROMs, but you may be able to use homebrew apps on that phone too.
EDIT: Lumia phones *can* be interop-unlocked via JTAG. However, this requires some extra hardware and some phone disassembly. Not an online hack, and not for the faint of heart.
But what if we installed the Diagnosis app on a Lumia phone (using Fiddler proxy or similar) and then followed this guide?
I repeat, Samsung-specific component. Nokia doesn't put the required services/drivers for Samsung's Diagnosis app into their Lumia firmware, so the app would not work!
Can I upgrade my phone to GDR3 if I have this?
Yes. However, be aware: if you install Samsung's updates that come with the retail GDR3 update, it will break your ability to re-unlock, or to use some homebrew apps! (Developer preview updates are fine, as those are purely Microsoft code and don't mess with the Samsung components.)
EDIT: There's a way to unlock the Samsung services for full access again on GDR3. You still need to interop-unlock beforehand, though.
Can I re-lock my phone if I want to?
Yes, easily. The simplest method is to use the Windows Phone Developer Registration tool (the one that comes with the SDK) to de-register the phone (you can then re-register it if you want to get your normal dev-unlock back). This doesn't remove any changes that were made using the interop-unlock, though (for example, it won't undo the EnableAllSideloading hack, not will it set back the Full FS Access hack). Apps that require interop-unlock will still be installed, but may no longer run. To manually remove interop-unlock, you can reset all the registry values that were changed by the interop-unlock hack to their original values, and remove all the apps. There still may be a great many other changes that also need reverting, though, if you want to get back to stock settings. See next question.
Can I get my phone completely back to stock settings without knowing every little thing I changed?
Yes, a hard (factory) reset will undo all changes made by interop-unlock, or any apps (including ones that require interop-unlock), and will remove all apps. If you need to send your phone in for warranty servicing and are worried that they won't take it because you interop-unlocked it, this approach will fix that (they would probably tell you to hard-reset anyhow, if it's conceivably a software problem).
Will the interop-unlock survive a hard reset?
Not using this method! Read the question above. This unlock is purely in software, not firmware; it is reset along with everything else.
Can I upgrade my phone to WP8.1 if I have this?
Tentatively, yes! We're still working on figuring out exactly what WP8.1 means for the homebrew scene. The short version is that most apps and some (but not all) of the hacks they contain seem to still work, though. However, see next question...
Can I interop-unlock my phone on WP8.1?
At this time, I don't believe this is possible (unless you can use a custom ROM). One step of the process appears to have been "fixed" and we will need to find a different way. -W_O_L_F- has indicated that he has one, possibly coming soon...
Apps which use Interop Unlock
SamWP8 Tools Currently includes a basic registry editor and some tweaking tools, including an accent color editor.
Native Access Webserver that requires full capability unlock; still read-only at this time.
PDF to Office enables browsing and moving files.
WPH Tweaks allows easy access to a number of registry tweaks.
AppData Manager allows you to back up the data of an app so you can re-install it (possibly after a hard reset) and not lose its state.
Storage Cleanup allows you to list and delete space-wasting files on your phone.
Reserved for... whatever else is needed.
Awesome!
I suggest first app to the list: my SamWP8 Tools
Upd. I'm little bit late XD
well i ve got an ascend w1 bootloader unlocked if i can help let me know
It's awesome to have my phone Interop Unlocked. I hope to see something to clear my "Other Storage" soon. Its full with faulty Windows Store installation files.. But I guess even with this it will be a lost cause.
Sent from my GT-I8750 using Tapatalk
although the Samsung registry editor will install it will not run on my phone and I believe I was able to interop unlock any idea why it wont run?
@GoodDayToDie your wor is awesome and you are the man
Good luck buddy
@FricoRico: Actually, I'm pretty sure we can clear out those files. I've got a ton of stuff on my plate at the moment, but even if none of the capabilities that work with interop-unlock will natively allow access to the relevant folder (and I wouldn't be surprised if one does; what is the folder in question?) there's a function in the Samsung driver interface to move files; we can move them to a location where we have write access, and then delete them.
@noelito: No idea. If it installs, that means you're unlocked. Make sure your phone didn't re-lock, I guess - try deploying the app again, for example - and make sure you're using the official deployment tool (some of the unofficial ones for WP7 - which may or may not work on WP8 - strip interop capabilities) and then try again. If it still doesn't work, please give a more detailed error report.
I am using the official deployment tool, and I believe the interop unlock does work because I was able to side load operamini, Samsung photo studio, supreme shortcuts and couldn't before BUT that was it they're side loaded but do not work at all ? well actually supreme shortcuts does run but when I try to use a custom shortcut such as brightness it will crash
Sent from my SGH-T899M using XDA Windows Phone 7 App
Aha, an item for the FAQ...
WP7 INTEROP APPS WILL NOT WORK! Interop-unlock lets you develop high-privilege apps, but it's very OS-specific. This is all unofficial stuff; there's no reason for Microsoft to have maintained backward compatibility, and indeed they did not. New apps will need to be developed specific to WP8. That's why there isn't already a bunch of listed apps...
ohhh ok so this interop unlock
is paving the way for future wp8 homebrew apps?
Exactly. Things which I have in mind, beyond the obvious improvements to registry and file system browsing, include options such as sounds customizations, media library access, changing certain "restricted" file/URI associations (alter the default browser?), *possibly* better task management (not sure we have the permissions for that), cleaning up wasted storage space, and as much more as we can manage. There's also a lot of potential for future research which this enables: interop-unlocking more devices, getting even higher permissions, possibly even custom ROMs or at least custom kernel drivers (which is much the same, since once you've got that you can change anything).
Can you write anywhere on the file system?
I can write some places, certainly. We'll see. I've got a couple of ideas for exploits involving writing to System32, but if there's anywhere I *can't* write, it's probably there.
Maybe "test mode" from lumias work like diagnosis app from samsung, really don't know about WP8 because i went from android, but on my motorola some options in fastboot like "Factory Mode" are apk's. Maybe this is a dumb thing (because they are two diferent systems ) :silly: .
Really thank you for your work, u 're awesome.
Sry for my english
GoodDayToDie said:
I can write some places, certainly. We'll see. I've got a couple of ideas for exploits involving writing to System32, but if there's anywhere I *can't* write, it's probably there.
Click to expand...
Click to collapse
Might be able to port @Myriachan 's exploit.
Boss442 said:
Maybe "test mode" from lumias work like diagnosis app from samsung, really don't know about WP8 because i went from android, but on my motorola some options in fastboot like "Factory Mode" are apk's. Maybe this is a dumb thing (because they are two diferent systems ) :silly: .
Really thank you for your work, u 're awesome.
Sry for my english
Click to expand...
Click to collapse
Feature-wise, Test mode is heavily locked on Lumias. One has to authorize to use its the most sweet features.
Anybody else upset that you cannot root the device and install common linux shell utilities on it such as ssh, curl, etc? I created a petition for google to create a set of shell utilities for all android owners, regardless as root. Even without root, there is no reason we can't use ssh. This is common on most linux hosts. Please have a look and consider signing the petition, or give me feedback.
https://www.change.org/p/google-inc...utm_source=share_petition&utm_medium=copylink
nothing stops you from making this yourself, or using one of the existing ways to run a ssh server
Terminal IDE provides lots of GNU utilities, but hasn't been updated for 5.0 compatibility https://play.google.com/store/apps/details?id=com.spartacusrex.spartacuside&hl=en
SSHDroid provides a SSH server https://play.google.com/store/apps/details?id=berserker.android.apps.sshdroid&hl=en
Hi #Sual, while you are correct, SSHDroid provides an SSHd server, However it does not provide a native ssh client, I could run through the connected device. I have tried many things suggested by users, but none of them offer a set of shell utilities I can run from the android host shell itself. Did you have a chance to read through the petition and fully understand what I'm requesting. Similar functionality would come from dan drowns android ports, or lil debi, or busybox, but all require root. Finally the fact things aren't updated for 5.0 compatibility, underscores that There is a reason that people desire this functionality on the device itself. Thanks for your feedback.
Saul Goodman said:
nothing stops you from making this yourself, or using one of the existing ways to run a ssh server
Terminal IDE provides lots of GNU utilities, but hasn't been updated for 5.0 compatibility https://play.google.com/store/apps/details?id=com.spartacusrex.spartacuside&hl=en
SSHDroid provides a SSH server https://play.google.com/store/apps/details?id=berserker.android.apps.sshdroid&hl=en
Click to expand...
Click to collapse
There are ways to run Busybox without root. Here's an app that makes it dead simple: https://play.google.com/store/apps/details?id=burrows.apps.busybox. I've used it on my XT1528 (Verizon Moto E) with great success.
There are also ways to run Debian without root, like KBOX: http://kevinboone.net/kbox3.html
I couldn't read your petition because the link is bad.
But I don't know why this is something you feel is owed to you by Google. I agree that it'd be useful, but it's totally not something I'd expect to be part of a mobile platform at all. It's clearly something you could make on your own. If existing solutions require root, it's in part because that makes it easier or because their creators assume that everyone has root.
ecaslak said:
There are ways to run Busybox without root. Here's an app that makes it dead simple: https://play.google.com/store/apps/details?id=burrows.apps.busybox. I've used it on my XT1528 (Verizon Moto E) with great success.
There are also ways to run Debian without root, like KBOX: http://kevinboone.net/kbox3.html
Click to expand...
Click to collapse
Hi @ecaslak ,
I will try your suggestions. Most recently I've tried GNURoot Debian, which uses proot. However I was unable to use the open ssh server I installed on it. However, I will still stand by my petition.
A significant portion of the Android community spends great effort trying to root their devices, many with only the desire for common functionality that we have from any core linux distribution. While having root itself on a device would be great, it should be expected that google provide all device owners with basic functionality found in most core linux distributions for the last 20+ years. Not including an option for basic user utilities ( ssh / wget or curl / most of what is included in busybox, a fairly powerful common shell such as bash or similar ) , that most non-root accounts have on practically all systems, limits the freedom of expression and ability to create that users have come to expect from a GNU Linux distribution.
While root can be enjoyed on many devices, this is often only available to a small segment of the population who either pays a significant amount more for a unlocked device with a free bootloader, or spends a significant amount of time trying to root their device. Android does seem to provide a small set of simple userland utilities such as ls, cat, but not much beyond that. This is a request to provide a set of utilities similar to what is found on most any common Linux distribution.
While their is some concern for manufacturers or communication companies to lock their users devices down, there should be no concern allowing basic utilities on all android devices. To be specific, what harm does allowing somebody to download a file through a terminal using wget or curl, or to ssh into a host , or the phone itself? Similar functionality to these kind of operations are provided to developers in the form of the Android SDK, and or libraries and programs that can be installed on all android platforms. However having simple system shell utilities is quite different that writing an application. Then there should be no harm in making them more accessible to the Android community, in said form. Finally the communications companies will benefit from increased usage, and therefore data billings from providing these features.
This petition requests that Google compile / create / maintain / distribute a set of common linux shell utilities to be included with the device, or provided through the play store for all Android versions moving forward. The people who are signing this petition believe that any owner should be able to use common *nixy functionality on any personally owned android device, regardless of device manufacturer or communication company.
Furthermore, we believe that by creating a standard distribution for these tools will reduce the effort of many people doing the same thing in their own time. That a standard will improve the tools themselves, and improve the Android experience to the community at large.
Google Android has stood on the back of giants, and taken the Linux kernel and wrapped a nice system and SDK around it, with the exception of removing some of the core functionality included in most any Linux system. Thus Android is significantly limiting the freedom of users. This is a proposal for the middle ground, which will allow a better system for everyone, even people who have no root or unlocked device.
Finally I Had a look at the kbox project, I think this sentence from their site underscores the challenge users face:
"Android is not Linux, as Google repeatedly tells us — and getting ordinary Linux desktop utilities to work in Android can be a chore, to say the least."
Hi @sual, I believe change.org is having some issues with their servers the past few days. Sorry for the dead link. I re-posted above and found it working. I also pasted the petition arguments above. It is my belief that if enough people desire a feature, then it is reasonable to ask Google to provide such a feature. I think it's reasonable to create a petition for something you believe in. Finally I appreciate your feedback, and have considered your point of view.
Saul Goodman said:
I couldn't read your petition because the link is bad.
But I don't know why this is something you feel is owed to you by Google. I agree that it'd be useful, but it's totally not something I'd expect to be part of a mobile platform at all. It's clearly something you could make on your own. If existing solutions require root, it's in part because that makes it easier or because their creators assume that everyone has root.
Click to expand...
Click to collapse
Finally, another link in case the copy link from the change.org platform is broken.
https://www.change.org/p/google-inc...-linux-shell-comands-for-the-android-platform
Incredibly few Android users root. And Android is not a traditional Linux distribution; it's a mobile OS that happens to use the Linux kernel. GNU/Linux distributions contain all these common tools because large essential portions of them are written in scripting languages and because they are needed for operation of the system. These things are simply superfluous in Android.
Google hasn't removed any functionality from a Linux distribution in the building of Android. They build a totally different system using Linux as the kernel. and have no need to include other separate components that comprise a standard Unixlike environment Just like all kinds of other embedded devices do. In this sense, Linux is a commodity OS kernel that competes with other open-source and proprietary ones. Furthermore, Android in particular depends on non-POSIX mechanisms like wakelocks and SELinux and uses an unPOSIXlike approach to isolate different apps (different uid per app).
I suggest you start writing code or organize a project and recruit developers to build this.
@sual Developers have already built plenty of Android binaries. I can build em. Look here: http://dan.drown.org/android/ . There are busybox sets all over the play store. The problem remains that they are usually crippled if installed without root. Crippled beyond the point of what you can do with a user account in most Linux environments. I thought the desire for this would be greater, but maybe I'm just an odd fish. I should save up and look for a platform that meets my wants and needs.
If tools running as a non-root user on Android seem more crippled than a non-root user on a typical Linux distribution, it's because Android uses a different UID per app for isolation purposes. Which is a good thing. Hence the existence of the "system" user on Android, accessible via adb, which has many more permissions than available to any particular app. Making even this set of permissions more widely available to apps would be a security nightmare, there's a reason you have to deliberately turn on developer mode then again enable ADB, and a reason why you (afaik) have to have root if you want to enable ADB over wifi on the device itself.
With that said, you should be able to package your own tools and run them via the adb user on any Android device, no?
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.