I need to demonstrate this vulnerability being exploited for my mobile cybersecurity class.
It should be possible in the following Android versions: Android-10, Android-11, Android-12, Android-12L (with security patch levels older than June 5 2022)
The goal is to get access (up to 30 seconds it seems) to a password-locked user account in Android, in a device with "multiple users" option activated. (in short, this could be achieved by hitting "Home" multiple times while changing users)
I tried to emulate multiple devices following these specifications, an this is what I tried:
hitting the "Home" key in my keyboard
using ADB scripts with loops for clicking multiple times in the "Home" button. At first the clicks seemed too slow, so I tried to make the clicks in the script be like "command1 &", so they execute in background and don't keep the next one from being executed. The result is, I can make the emulated device crash, which is not the goal (maybe the processes in background are to blame, and not the many clicks?)
I know that it must be possible to emulate this. At least the guy in this article said he did it more than once.
I'm a beginner with these tools, so any idea would be appreciated, even if just redirecting me to a forum that is more specific on this, thank you
Related
I have an customer project where I have to make single task android device. Customer isn't able to escape the application which my company have developed. Also customer isn't able to start any other application and our application is started when the device is booted. Overall all the customer is able to do with the device is run our application.
Is there any other way to make this work than rooting the device, disabling all system buttons and making our application the launcher. I have something like 400 devices for this purpose so rooting all those would cost lot of time.
I also read Google's tutorial about COSU devices but found it very confucing https://developer.android.com/work/cosu.html#testing-plan
Androids own screen pinning is not good enough because customer can escape the app. Some may suggest to use some kiosk application like SureLock but my company's goal is to find clear solution for this without using any third party apps. Also running our app via some kiosk application is not our goal.
I found some posts on the Stack Overflow with similar question, but not the answer I'm looking for.
If someone has some tips for this question I would be very grateful.
Single purpose devices built on top of Android can get difficult to implement. There are a few different options, but each have trade-offs.
As you mentioned, rooting devices will functionally get you what you want - however it will be time consuming with hundreds of devices to root, difficult to maintain, and you will (potentially) introduce security issues to your devices and app.
Another option is using Google's Lock Task Mode for COSU devices[1]. The link there has a nice graphic showing the features of lock task mode:
1 app pinned to the home screen
only apps white-listed by the DPC (device policy controller) can be locked
Home and Recent buttons hidden
exit by calling stopLockTask()
There are some downsides to using Google's solution for this. First Google recommends creating (and therefor maintaining) an entirely separate DPC app to run as a device owner and set policies[2]. You'll also be dependent on Google Play to manage application updates and be required to have Play accounts associated with each device which "are used to identify a single device that is not tied to a single user for simplified, per-device app distribution rules in COSU-style scenarios"[3]. To automatically get your DPC app on devices your "DPC must be publicly availble on Google Play, and the end user can install the DPC from the device setup wizard by entering the DPC-specific identifier."[3] You'll also need to upload the user application to Google Play[4], which may be an issue for some who don't want their apps on Play. Going this route gives you features you need, but can be complicated and also ties you and your customer pretty tightly with Google/Play services and their workflow.
You can also look at enterprise mobile deployment platforms like Mason[5]. In your case, you can create a custom Android OS in a few minutes with your app locked in kiosk mode (+ other features like disable camera/sms, remove apps and hide settings, etc.) and then deploy it to all of your devices remotely. Mason also supports OS and app updates controlled by you if your requirements change.
DISCLAIMER: I work for Mason
[1] https://developer.android.com/work/cosu.html
[2] https://developer.android.com/work/cosu.html#create-dpc
[3] https://developers.google.com/android/work/requirements/cosu
[4] https://developers.google.com/android/work/play/emm-api/samples#push_install_an_app_on_a_device
[5] https://bymason.com/
I went to the same problem before. I spent at least 3 days doing research. I tried to find many solutions but I found zero.
How I solve is
1. Up To JellyBean
- Use System Alert Dialog (And make it transparent and small size like 2 * 2 And display in some corner(User can't see it)). User can't press home button If there is system Alert dialog
2. After JellyBean, This method doesn't work. The user can press the home button even though there is System Alert Dialog.
so what I did is, start the service on stop and start the same activity again and again(within sec). So user can't see any difference.Don't forget to make activity as single task so that even though you start same activity from service, again and again, new activity will not create (So Ugly way )
- You can simple make screen full screen. make sure in kiosk mode try to check if the screen is in full-screen mode. if not make it full-screen mode(its not hard to do)
- other way is to make launcher app but when ever you pressed home button it always asked to choose launcher app. if user mistakenly choose default/ other launcher app, this solution doesnt work
Good luck
Make your application as a launcher application by defining in manifest file.
After that go to setting of your mobile device and change default launcher application to your application.
I have an Android app in the Play Store. In the last couple of days I've started getting bug reports about "black blocks in the settings screen". Unfortunantely I haven't been able to reproduce the bug on my devices, so everything I know comes from user reports.
I've got the following screenshots from a helpful user:
http://madscientist.pl/temp/bug0.png
http://madscientist.pl/temp/bug1.png
There's supposed to be white text on the tab headers, on the buttons and next to the radio buttons and seek bars. There should also be white horizontal lines separating the options.
The sizes of those black boxes that are visible (the rest is on the black background) correspond to the sizes of letters that are supposed to be there. The text on the two columns of buttons reads "Save" and "Load".
My app can be opened in two modes: live wallpaper and as a "regular app". The problem apparently exists in both versions.
Almost all bug reports describe another characteristic: the settings screen sometimes works correctly and sometimes it doesn't. E.g., sometimes opening the settings activity of the live wallpaper for the second time fixes the problem.
Another person wrote that it works correctly on the first application run only. After that, he has to clear the app data and then again it fails on the second run. So it seems that the bug manifests itself rather unpredictably.
I admit to not being a very good dev and that all the text is put directly in the layout files instead of in strings.xml. It was never an issue before, but just in case I'm in the process of establishing if putting the strings in strings.xml helps with one of the users.
The problem seems to be independent of the device. I've got reports from Samsung, Motorola, LG and Nexus users.
From what I've established so far, for at least one of the users the problem happens on both current and previous version of my app. The previous version was in the store since January 2015. The current version is a month old. I've been getting bug reports for just over a week now so this doesn't seem to be (directly) caused by some change I made to the app.
This led me to believe that the new Android version that has been rolling out recently (at least I've got 5.1 a week ago) is the reason. However I've got bug reports from a user who runs the app on 5.0.2 and 4.4.4.
The app is moderately popular and has a stable amount of downloads, so the fact that in the last week I've got a dozen reports of this bug, and before that I've never heard of it, leds me to believe that it indeed started happening over a week ago. So apart from the bug itself, it's really beyond my understanding what made it appear just now, if neither application update nor system update seem to be related.
I could provide more data, but the question is already terribly long. Let me know what else you think could be helpful.
I'm working on my first (C++/IwNUI) Marmalade app, which so far works fine, but on Monday one of my devices (an HTC One Android phone, Credo Mobile) had a system update, after which my app, and only my app, now shows what seems to be a "settings" control on top of my app, which can be moved around, but does nothing but clock taps to the app where it is. It's a grey circle with three dots in it, which appears immediately when my app starts to load. Another Android test machine (Samsung Galaxy) does not show this control on my app.
Has anyone else seen this? How might I get it not to appear?
I have asked on the Marmalade forums with no response, and searched here and on the web but I haven't seen any reference to it, so I assume it may be limited to some combination of Marmalade apps, HTC One, and/or Credo Mobile Android phones.
Update: This control appears (on this phone only) on all of the Marmalade example apps I have built too, including IwUI, IwNUI, and plain demos like IwHTTPExample.
Even though this is very specific, I wonder if anyone knows a programmatic way in Marmalade C++ for me to at least get such a settings control to hide or go away?
I found a way to make it go away: "Add android:targetSdkVersion="11" (or higher) to your element." in the settings file which in my Marmalade project is called AndroidManifest.xml.
It seems like this may be a bug where it thinks there is an "overflow" of a title/menu-bar which isn't even there in these apps. By targeting a later version, it uses a newer "holo" menu, which doesn't do this.
If someone has a better explanation, I'll wait to mark that as the accepted answer.
In case it may help future people confused by all this, here's how I found this. Jared's answer led me to study my Marmalade config files, and the Android developer site where I found some general somewhat relevant info about what this is, and to search some different terms on the Marmalade forums, which got me to a relevant question I had missed on the Marmalade community answer pages, which led me to this page which had the suggestion which has the desired effect.
I am guessing you created a new project. Are you seeing this "settings"?
This is automatically added in every new app. Check your res -> menu folder. You can remove the "fake" options menu if you like.
Samsung will show this menu if you hit the menu button on the bottom left of the device.
HTC devices will show the options menu in the ActionBar/ToolBar.
As we all know, Android resolution is rather fragmented.
I (like many others) don't have all the screen resolution, or OS versions to test my app on.
Emulators give a solution to the resolution and OS problem, but it is getting rather tedious and annoying to run my app on each emulator (even if they are already running) just to see one layout.
So, my question is; is there any way to run my app on EACH emulator I have selected, not doing them individually?
For now, I am using a solution called Manymo, which allows me to launch emulators faster, but my ideal solution would be to start 1 app, and have a setting to be able to launch it simultaneously on several emulators.
I am surprised to see after many searches, that although people ask about running multiple, I can't seem to find anyone who would like to launch an app in multiple instances simultaneously.
Thanks!
Once you've got your emulators running, I believe in the Run Configurations control, you can select Launch on all compatible devices/AVD's and then select Active AVD's from the dropdown. I believe this should launch your app on all emulators you have running. Could be quite taxing on your system, though, unless you're swimming in RAM.
Im not sure if this is exactly, what you want but you dont even need to start an emulator to check how a layout will look like.
the ADT plugin in Eclipse allows you to check how a layout will look on different versions and devices without having to start each emulator every time.
Graphical Layout , allows you to select a device, the orientation and android OS version.
I'm looking for some help from developers who are know android development. We have a client who wants to use an Android tablet as a means of collecting data when someone walks into their office. The problem is that they don't want any of the background functions or access to the net on the device (it's there to log people in so it should not move from that function with out some other credentials to "unlock" the device.)
With apple I know you can lock the screen on to a page/app but not sure about android? Can't find any thing online that would tell me it can be done on android.
With Android you can replace the launcher (home screen) app, and if that app doesn't give you access to launching other things, then you cannot do other things. The first time you press the home key after installing another launcher candidate, Android asks you which home screen application to run (the original or your new one) and allows you to set your answer as the default, eliminating the question in the future.