Is there any way to prevent firmware modification in android aosp rom? The rom is to be flashed into Nexus One and unauthorized users will not be able to make any modification including flashing another rom. Thanks.
Handset manufacturers have been trying to do just this for a long time - almost all have failed.
Most attempts are software based an usually have flaws that can be exploited to enable local root access. At that point, you've already lost the battle.
Just flashing a new ROM will never allow you to prevent unauthorised modifications since an attacker can just boot to the bootloader and have unrestricted access from there. Your best bet may be to write a custom bootloader, but this is beyond what most people can achieve, plus, there's no guarantee that even this is secure from tampering.
Off the top of my head, the only people who have come close to achieving this is Motorola with their electronic fuse that blows if the loaded ROM is detected to be unauthorised (using digital signatures, I believe).
In short, there is probably nothing you can reasonably do to prevent unauthorised modification - once the handset is in somebody else's possession, you can't trust that it is unmodified.
Since the nexus one comes with an unlockable bootloader (that you would use to install your firmware) the short answer is that you can't.
However what you can do is write an application that validates that your phone is in the state you expect but that too could be reverse engineered.
Related
We are the software development department of a company that makes industrial equipment and we have some Samsung Galaxy-Tab 4 tablets that we use as "remote controls" for the manufacturing equipment, using an app we wrote ourselves for the purpose and installed directly from Android Studio. This app is not distributed to other devices. We bought these tablets online, right out of the box from Samsung, i.e., there is no phone company or common carrier involved. These tablets are not registered with Google, i.e., there is no gmail account associated with them; in fact we can't even access Google Play with them. I unboxed these tablets myself and never registered them with with Google or Samsung.
So I was surprised when I came in this morning and saw a notice on the screen of one that a scheduled software update has been downloaded and was ready to go. It says it's 876.87 MB and it wants to do an OS upgrade to Lollipop.
I have no idea where the upgrade is coming from or how it's initiated. My concern is that if this happens at a customer site or trade show an unexpected upgrade could break our software or cause other mischief. Is there a way I can programmatically disable software upgrades?
As an app developer, no you cannot control firmware upgrades. They come from either the carrier, or if it's a wi-fi tablet, the manufacturer.
Your only option is to control the firmware. That means building your own firmware dist of Android for your chosen hardware. You can then disable (or otherwise control) the firmware update schedule / process my making changes in the firmware.
Owning the firmware is a very big deal compared to deploying an app.
I was surprised when I came in this morning and saw a notice on the screen of one that a scheduled software update
as a software developer I cannot understand your surprise. It's a very well known (and often criticise feature due to slow/delayed roll out) feature of the OS
I have no idea where the upgrade is coming from or how it's initiated
Those come from the device manufacturer (you said Samsung, right?) and do not need a login or account of any type. It's coded somewhere deep inside the OS to check the manufacturer server for updates. Same that happens with Windows, Mac OS, Linux or iOS.
There is absolutely nothing an app can do to disable the OS update from an API point of view. This would be a major security flaw. One can easily imagine a malicious app exploiting a known OS vulnerability and blocking the OS from update itself that would patch the vulnerability.
possible solutions for your case
Apart from creating your own custom OS to control the process the only possible way that I can think of, is to host your own VPN server that blocks the update server (or blocks the whole internet expect the resources you want to access from your app) and configure the device to this VPN under Settings -> WiFi.
ps.: I saw the mentioned link and I would advise against disabling system services (or at least test A LOT after you diable it) because that could cause other issues.
I am creating a new type of security application that sits at OSI Layer 2/3 and encrypts packets of data flowing between devices. With this proven technology, I can create apps such as Secure Skype, Private Messenger and so forth and I can do things such as blend Triple DES and AES 256 bit encryption (this will eventually be an open source encryption platform) on the same communication channel. We run underneath higher level, more limited, options such as SSL and VPN and we have been working on desktops for years.
The problem is that I cannot figure out how to port my Linux version over to Android due to the need to have admin rights for my app. I do NOT want to try to force people to root their phone and I am looking for some legal option.
In Windows and Apple, you can get your code verified - in Windows it is called Windows Logo verification. In those case, your code is run through a whole series of tests, the source code is signed and that cert is then authorized for admin rights.
Given how Android works, it would seem that a similar option should exist but I cannot find anything.
Can somebody please point me in the right direction?
Thank you very much for your time.
I'm pretty sure the only way to get "admin" rights on Android is through having rooted the phone, unfortunately.
If you decide to go ahead with this despite that (I know that isn't what you wanted), I'd recommend libsuperuser. Just using Runtime.getRuntime().exec("su ...") may not work consistently across all versions of Android and this library provides a way that will work across them (source). You should first check if root exists before running anything, otherwise you may end up just crashing at runtime because the su binary doesn't exist.
This is a security measure in Android. If you have low level access to all the packets like that, you can do incredibly evil stuff. Therefore, the OS deliberately makes that access impossible to user apps.
As far as I can tell, the closest equivalent to the Windows Logo Program is convincing an OEM to sign your app with their key or include it in the system partition.
I have brought one plus one and tried to install an app. But then it says your phone it's rooted.. Finally it didn't install. I'm aware that if a phone is rooted, then there are two disadvantage . One your phone warranty will not work if the phone is damaged while rooting. And two.. You will get support user acces .
My question is what is the problem from an application perspective, if a phone is rooted.? Why few apps are blocked to get installed on rooted phon . ?
Functions of some apps require root access to the operating system. For example, they might require tuning the kernel options, writing to a raw device or accessing privileged resources.
Android apps typically run in a closed "jail" to protect the system and other apps from contamination of a malicious or poorly written app.
By rooting your phone, you take the risk of this contamination on yourself. It is why carriers will often not honor the warranty after rooting.
That being said, there are often methods of flashing back to a non-rooted version if you do need to claim a warranty. It really depends on your skill level and patience. If you are interested in rooting, there are many resources out there. If it sounds scary, it probably isn't for you, and the app that requires root probably isn't something you should mess with.
How to take a screenshot of other app programmatically without root permission, like Screenshot UX Trial?
I know I can capture the bitmap of the root view in my app. But I can't get the root view of the other app when my app is running in background
bitmap = Bitmap.createBitmap(rootview.getDrawingCache());
There is a permission for capturing current frame buffer in Manifest: android.permission.READ_FRAME_BUFFER. But some website says it's for signature app only.
Check Android Permissions - Protection Levels
After trying Screenshot UX Trial, I read the permission:
INTERNET: for connect to localhost screenshot server for rooted phone.
SYSTEM_ALERT_WINDOW: for topmost camera button.
VIBRATE: for vibrate feedback.
WRITE_EXTERNAL_STORAGE: to save the screenshot.
GET_TASKS: for detect foreground Develoment setting activity for non rooted&non preloaded capture method.
It seems either SYSTEM_ALERT_WINDOW or GET_TASKS allow the app to take screenshot.
I have two guess of how it works:
It may be able to access the Activity of the foreground activity, it gets the root view of the Activity, capture its screenshot.
Calling glreadpixels
If you try one of my guess, please let me know the result.
This is extremely difficult. I spent several years trying to do it. I eventually succeeded, but any solution will involve commercial as well as technical effort.
Update March 2015
Most of the stuff below is no longer up-to-date. There's now, after all these years, an android.media.projection package
https://developer.android.com/reference/android/media/projection/package-summary.html
which finally allows what you need!
Capturing the screen image of your own application
For completeness, I want to include your own comment that you can capture an image of your own application using Bitmap.createBitmap(rootview.getDrawingCache()); and similar mechanisms.
Capturing the screen of another application whilst you're in the background
Using the READ_FRAMEBUFFER permission
Firstly, you're right that a normal application can't make use of the READ_FRAMEBUFFER permission, because it's "signature"-level. That means you must be signed by the same key as the Android system ROM in order to be able to take such a screenshot.
I thought this was a bit sad, so back in 2009 I made an Android open-source project submission to ask that it be opened up1. The response from Dianne Hackborn, the Android architect was:
Um, no. Absolutely positively not.
So, that went well, then! Hence this permission is still signature-level to this day.
If you had this permission, however, you could call the captureScreen member of ISurfaceComposer2. You'd need to write some native code to access this function, using the Android NDK and also some undocumented APIs. However, it's possible.
Internally within the Android graphics subsystem, this uses a glReadPixels call to retrieve the pixels from the GPU back to the CPU. (The GPU is used for most of the compositing on Android. In fact Android 4.0+ supports extra hardware compositors, and the Surface Flinger has to do even more work to pull those pixels back to the CPU.)
This call works beautifully, except for a few small problems:
The risk of using an unsupported API which might break at any moment;
The hassle of calling it in C++
It causes the GPU pipelines to stall, which can upset the GPU designers but doesn't really cause problems in reality
It relies on a large bandwidth from the GPU back to the CPU. This is sometimes problematic because memory architectures are designed to send data in the opposite direction. However, I seem to recall that all modern Android chipset architectures directly share memory between the GPU and CPU, except for one (it may be Broadcom? - I can't remember) where this may cause this mechanism to be very slow.
... and one large problem ...
Most importantly, as a normal application writer, you can't even call this API due to the signature-level permissions required.
Still, on most Android devices, you can get 10 frames per second out of this. Better still, this API actually supports scaling the resulting image in hardware on the GPU, so if you're clever you can pre-scale the image to just the size you need, before the pixels even hit the CPU. So it can be extremely high performance.
Note, of course, that you as an application writer can't call glReadPixels because you don't have access to the relevant OpenGL context. It's owned by the surface flinger.
Using /dev/graphics/fb0 and similar
Some are tempted to try to read these Linux device files which represent the framebuffer. However, there are three problems:
You need root.
Sometimes they're not even there.
Often, they don't represent the real screen image. Remember on Android that the graphics are composited on the GPU. So there's no reason why the CPU should have access to a copy of the full composited screen image, and it often doesn't. This file sometimes contains tearing (at best) and a garbage image (at worst). Interestingly, some of the tools for rooted phones do use this method, which I think is a mistake. If you've got root, you by definition have all Android permissions and can therefore call the above captureScreen API to get a correct image.
Using hardware partners
Now we get into the solutions which require commercial action.
Talking to the Android chipset makers often presents a solution. Since they design the hardware, they have access to the framebuffer - and they often are able to provide libraries which entirely avoid the Android permissions model by simply accessing their custom kernel drivers directly.
If you're aiming at a specific phone model, this is often a good way forward. Of course, the odds are you'll need to cooperate with the phone maker as well as the silicon manufacturer.
Sometimes this can provide outstanding results. For example I have heard it's possible on some hardware to pipe the phone hardware framebuffer directly into the phone hardware H.264 video encoder, and retrieve a pre-encoded video stream of whatever is on the phone screen. Outstanding. (Unfortunately, I only know this is possible on TI OMAP chips, which are gradually withdrawing from the phone market3).
Using security holes
Android rigidly enforces its permission model, and has few security holes. However the Android OEMs can sometimes be more careless.
For example a major OEM whose name begins with S has implemented a way to capture the screen using a keystroke. It saves it to a world-readable file on the SD card. Hypothetically you might be able to find what intercepts those keys and see how it works. Perhaps you could do something similar.
And perhaps there's a way for another major OEM whose name also begins with S.
No, I'm not going to go into any more detail on this section. To work out how to do those things, I'd need to have reverse-engineered software, and that might be illegal. Good luck, though.
Working with the phone makers
As described previously, the phone makers have ready access to an API which does work. And the phone makers have the signature-level permissions required.
So, all you need to do is to arrange to get your software signed by the phone maker.
This is, however, hard. By signing the software, the phone maker is guaranteeing its quality - so they should want to audit your source code. Also, due to the nature of Android - if they sign the software, they need to be the ones distributing it. You can't put it on the Market if it is signed by someone else's signature.
However, the OEM need not include it on the ROM - they can still distribute it on the Android market. But you can't.
A good solution would be if each vendor signed a small library which then could be accessed by a common SDK. Which leads me onto...
Work with software partners who have solved this already
I know a lot about this because I used to work at RealVNC. We worked with all the major Android phone vendors to get access to these signature-level APIs. I cannot overemphasise the many, many man-years of effort (commercially and technically) required to achieve this. Some of the OEMs have publicised this work - for example 4.
I do not work at RealVNC any more, so I have nothing to gain from advertising their software. But if you really really want to be able to capture the screen on multiple Android devices, you may wish to approach them about re-using their Remote Control Service or Android VNC SDK 5. It is not open-source so you should expect to pay, and believe me this is fair enough given the epic effort involved in working with all these Android OEMs.
In the interests of balance I should point out that other vendors have also worked with the phone makers on this - e.g. Soti. But I believe they all offer specific device management solutions, rather than a general remote control/event injection SDK.
Over USB
Another option - the adb daemon which listens for debugging connections over USB has slightly more privileges than a normal application, which is why it's able to grab the screen (you can see its image using the ddms tool). If you're able to run any command using adb then you too can gain those privileges (as per the android-screenshot-library linked previously).
Contribute to the Android open-source project
Eventually this problem reduced me to dust, and I left for greener pastures which didn't involve trying to squeeze pixels out of Android phones.
Before I left RealVNC though, we tried again to contribute these APIs to the Android open-source project. This time we got a more positive reaction6. In short, it was suggested that our security approach was almost right, but that the graphics system was in too much turmoil to accept our patches. Well, the great news is that the graphics system is no longer in turmoil - in fact it now has that captureScreen API which means no graphics system changes are needed whatsoever. It may therefore be possible to submit a new security mechanism to AOSP around this API which finally solves this problem.
Maybe the android-screenshot-library can help. But well in their Usage page it says that it needs a native service started with adb (from the android sdk).
PS: Remember that Screenshot UX does not work for every unrooted phone.
I don't think Android will allow you to access another app's frame buffer. This is just part of the security of Android. Each app should keep to its own resources.
If you really need to get a screen capture of any app, I would suggest using the native screen grab "gesture". For the the Nexus 7 for example, simply "... hold the power button and the volume down button at the same time for approximately 2 seconds."
A Google search will usually find the trick with your device.
I'm wondering if is possible to install/use Android with other phones? Will be nice to have it on such a piece of hardware like the new SH004.
Mobile phones are generally very hardware independent of each other and require a serious amount of hacking in order to do any sort of "moding".
I can barely find any information on the SH004, but I think it will have to be out for a few months before you will even start to hear people of moding it, yet alone installing another Operating system.
Your best bet is to find specialised forums such as CellPhoneHacks, (There are better around, but not sure if I should link to).
Android is actually designed to be portable, and to provide source code for most of the generic pieces. However, the possibility of running it on a consumer device intended for a different operating system/framework depends on three things:
1) The hardware must have sufficient capability - likely meaning it was originally designed to have comparable capabilities under whatever OS it shipped with.
2) Sufficient low-level documentation must be published or reverse engineered to adapt a Linux kernel, flash memory driver, user I/O drivers (touchscreen, etc), and anything communication related (wifi, mobile, etc) and optionally any extras (accelerometer, gps, etc)
3) It must be possible, either by design or by finding an exploit, to run arbitrary code on the device - ie, boot an image which has not been signed by an approved party such as the OEM.