I've installed the app Screen Time on my son's devices.
I'm happy with its functionality, except, he's hacked it.
He must have found out that the application is only active once it's loaded.
That means he has this time window right after booting his device in which he can set the time in order to manipulate what he's allowed and what he's not.
I'd like to prevent him from doing that.
That prevention has to happen quite early on during/after the boot process in order to be effective.
My idea was to write an init.d script that disables touch input until well after all startup applications are loaded and started.
I've found out that the digitizer inputs are accessible on his device through /dev/input/event0.
If I delete it, there's no touch input. Unfortunately, if I reinstate it, touch inputs don't come back. I figure, removing event0 is just to harsh for the layers above to cope.
So I'm wondering, does anyone have an idea if and how it's possible to temporarily disable events being sent through the /dev/input/eventX interface. I looked around in /proc and /sys but couldn't find anything that fits.
If that's not possible, does anyone have another idea how I might be able to solve my problem?
Related
I'm wondering how the second display is implemented - is the support built into WM5, or is it handled by a proprietary HTC app?
Would be great if we could display our own data on it - does anyone know if there is a standard API for controling secondary displays on WM5?
Got it - partially. It is possible to manipulate the framebuffer directly. Still need to figure out if there's an elegant way not to conflict with HTCs own Subdisplay service.
Update: Looks like the magic happens in SubDisplay.dll
Zone-MR said:
Got it - partially. It is possible to manipulate the framebuffer directly. Still need to figure out if there's an elegant way not to conflict with HTCs own Subdisplay service.
Update: Looks like the magic happens in SubDisplay.dll
Click to expand...
Click to collapse
Hi Zone-MR,
I'm not able to go so deep, but it may be of some help knowing that there is another user which may help:
http://smartphone.kleinweder.ch/downloads/index.php
He has the same device and many themes for it, some of them with images (even if not "control") of external device.
Writing this message I realized that it is of no use, but... I'm too lazy to cancel it... ;-)
Is there anyway to keep the secondary display alive by reg tweak? If so, can someone share the process?
FYI-I did try, HKLM>Software>HTC>Secondarydisplay and tried to change the display timeout value w/o any success. :x
Thanks
Zone-MR, any more info on using the external display? I found the subdisplayDLL.dll, which appears to be a driver? Couldn't find any documentation as to what the corresponding device is called, or any API for it.
Changing the external display
Guys, I have posted details at modaco of how to change the resources in the subdisplay.dll file, so you can have custom clocks, and change any icon you like.
See http://www.modaco.com/index.php?showtopic=243525&st=0&gopid=764669&[/url]
Ever since I got my Droid 3 I wanted to be able to control games using the keypad, but sadly most games won't support it, so I figured, it would be cool if I could make an app that catches all the keyboard events and triggers fake MotionEvents for preset regions of the touchscreen (kindof how it's done on the iControlPad).
I believe I've found a way to fake the touches, but when searching for a way to read keyboard events when my app doesn't have the focus all lead to dead ends.
Does anybody have a clue how I could do that?
If anyone cares: I not only managed to find a way to read out all the touches and keystrokes that should go to other apps (though some android-coworker said it was impossible), but I can also filter which one of those I let through. I can even block the back- and home-buttons. And it's runnable without any running service or activity, so invisible and unkillable. I don't need most of that for my app, so I won't use what I don't need, I just stumbled across it by accident.
Every threat on this topic ended with "It's impossible to read out keystrokes destined to another app, because it would be too much of a security issue." Well, it is possible.
Sent from my XT860 using xda app-developers app
Dakkaron said:
If anyone cares: I not only managed to find a way to read out all the touches and keystrokes that should go to other apps (though some android-coworker said it was impossible), but I can also filter which one of those I let through. I can even block the back- and home-buttons. And it's runnable without any running service or activity, so invisible and unkillable. I don't need most of that for my app, so I won't use what I don't need, I just stumbled across it by accident.
Every threat on this topic ended with "It's impossible to read out keystrokes destined to another app, because it would be too much of a security issue." Well, it is possible.
Sent from my XT860 using xda app-developers app
Click to expand...
Click to collapse
I do care! I would appriciate to hear how this works, because I would need it for my ongoing development.
Besides Camara button, which is of cause easy due to the broadcast event, and the volume keys (which are more tricky, since you have to inject an own BroadcastReceiver to the AudioManager), how do you handle other keys?
Ok, it's been a while since I did this, and I had a lot of work on other projects in between so, I hope I get everything right.
To do the whole trick you need root access.
1) Get the android.permission.SYSTEM_ALERT_WINDOW permission
2) Open up a system alert window with no content. There is a setting somewhere that lets you catch all keystrokes and touches. This blocks them all from going through
3) This one is tricky. I had to analyse nonsense for days to get it right, and I fear it's still not very good. Go to /dev/input on your phone. There are files named event1, event2, ...
Each of those correspond to one input device, so one is your touchscreen, one is the keyboard and so on. What you do now is you perform the action you want to recreate on the phone (e.g. press a key) and monitor the event files through adb (there is a linux command, that I forgot, that lets you view a file in real time. Also you can copy that real time view to your harddrive by typing "adb shell [command] > record.txt").
Once you know every event that you want to recreate, you can go to the next step.
4) This is what your app has to do to let a keystroke through: The user presses a key, your app catches it. Then it changes it's mode (see 2) ) to not catch any keystrokes at all, posts the corresponding event for that key in the fitting /dev/input/eventX-file, and sets itself to catch keystrokes again.
Before the whole thing make sure, your /dev/input/eventX-file has a chmod of 666 or therelike, since you can't write into it from your app. You only need root for that, after that you don't need root. The OS resets the chmod on each reboot.
It is a hell of a lot of work. Calculate about a week or more for just that (at least that was what it took me to figure it all out). Good luck
PS: If you get your app system privileges, there is also the android.permission.INJECT_EVENTS, which allows you to inject key- and touch-events to another app using a simple function (can't remember it, but Google does). For your app to be able to get system privileges you need to copy it to /system/app, which requires root and a mounted /system. Catching the keystrokes still works the same way as above.
Dakkaron said:
Ok, it's been a while since I did this, and I had a lot of work on other projects in between so, I hope I get everything right.
To do the whole trick you need root access.
1) Get the android.permission.SYSTEM_ALERT_WINDOW permission
2) Open up a system alert window with no content. There is a setting somewhere that lets you catch all keystrokes and touches. This blocks them all from going through
3) This one is tricky. I had to analyse nonsense for days to get it right, and I fear it's still not very good. Go to /dev/input on your phone. There are files named event1, event2, ...
Each of those correspond to one input device, so one is your touchscreen, one is the keyboard and so on. What you do now is you perform the action you want to recreate on the phone (e.g. press a key) and monitor the event files through adb (there is a linux command, that I forgot, that lets you view a file in real time. Also you can copy that real time view to your harddrive by typing "adb shell [command] > record.txt").
Once you know every event that you want to recreate, you can go to the next step.
4) This is what your app has to do to let a keystroke through: The user presses a key, your app catches it. Then it changes it's mode (see 2) ) to not catch any keystrokes at all, posts the corresponding event for that key in the fitting /dev/input/eventX-file, and sets itself to catch keystrokes again.
Before the whole thing make sure, your /dev/input/eventX-file has a chmod of 666 or therelike, since you can't write into it from your app. You only need root for that, after that you don't need root. The OS resets the chmod on each reboot.
It is a hell of a lot of work. Calculate about a week or more for just that (at least that was what it took me to figure it all out). Good luck
PS: If you get your app system privileges, there is also the android.permission.INJECT_EVENTS, which allows you to inject key- and touch-events to another app using a simple function (can't remember it, but Google does). For your app to be able to get system privileges you need to copy it to /system/app, which requires root and a mounted /system. Catching the keystrokes still works the same way as above.
Click to expand...
Click to collapse
Thank you for your innovative solution
I do not understand two points:
1. How does your app will stay on top and its windows receives events, when the user opens another app, a game for example.
2. How does the background app, the game, keep running? Isn't the game onPause() when you are running your app in front?
Thanks you.
Dakkaron said:
2) Open up a system alert window with no content. There is a setting somewhere that lets you catch all keystrokes and touches. This blocks them all from going through
Click to expand...
Click to collapse
Can you please try to remember and elaborate " a setting somewhere" part?
For a research I am doing, I need to some way to track user touches when they are using the phone in general daily basis. The user will be fully aware about what they are recording. Any method to do would be great.
What have I tried so far?
Method 1. Create an service with overlay transparent view.
Problem Due to obvious security flaws this is prevented starting with ICS. The input touches on the transparent view is not transferred to background and hence user is not able to interact with phone normally. I tried various methods with overlay view defining as type phone or type system alert or switching between them during program execution.
Method 2. View with 1% screen size make with touch outside model
Problem As problem as previous. Touch outside only returns the if touch event happened outside without even initial x, y coordinates.
There are other methods I tried but those are highlighted. Currently, I am thinking about other options:
Option 1 - The pointer location option in developer options: In settings there is this pointer location option that I can utilize. When that option is on, all the info about touch are shown in the top panel. If I can have access to those data afterwards that would be fine too, despite the fact that there will be drawings on the screen when user is using the phone. I have traced the source code of ICS and found the core class that is making that tracking possible. I recreated that class into an service. The logcat shows all the info about touch when I am running it from app. Only problem is the same as problem 1. I cannot track it outside current app. So, if it logs the tracking info even when pointer option is turned on, how will be able to get the information later to use?
This option seems the easiest.
Option 2 - Android NDK If above method is not possible is it possible to do so using NDK? Right direction to this route is also great.
Option 3 - Custom ROM Do I really need to go for Custom ROM while doing this? I am pretty sure this is 100% sure way to do it. But it is seeming very impractical in this particular research and would like to avoid as much as possible.
I would appreciate any suggestion to the path that I can follow. Thank you all in advance.
Hi,
I try to be as brief as I can but I'm known to write "walls of text". Please, I really try to write differently but it always ends up with at least one A4...
I need some input from you who have vastly more knowledge then me, I have a few pondering's that I need to ask if they hold or not.
As you know I'm "rusty" in my knowledge so I have been reading up. Especially on SELinux.
I have a Note 3 that is plain vanilla and 2 days ago I got an "SELinux rules update #16". Didn't know how to take a screen pic of it. Sorry.
Did anybody else get that? I didn't even saw that there was a way to turn it on/off.
I know that SELinux is a bunch of text-files. It's making a MAC-solution for the kernel and can hinder you from accessing parts in system-space.
If can control all vital functions in user-space, including fs, files, sockets, network, processes and run own processes without disclosing them to
you as a user. They are simple text-rules. Pretty straight forward.
Made a "wall of text" -- > http://forum.xda-developers.com/showpost.php?p=48287600&postcount=1392 again.
I'm sorry if I c/p some from that, you can just sift it through if you feel for it
This is from their own White-paper on Knox:
Secure Boot requires the device boot loader, kernel, and system software to be cryptographically signed
by a key verified by the hardware. Secure Boot uses X.509 certificates and public keys which are embedded
into the boot loader of the device. A secure hash of the certificates is fused into hardware Read-Only
Memory (ROM) at the time of manufacture. The Secure Boot loader will only continue if the authorized
secure signed binaries are present. Next, Secure Boot verifies the cryptographic signature of the Linux
kernel and system image before handing control to the OS.
So they boot-loader contains the SELinux and it won't boot if it's not verified for a cert in your phone.
This has been planned for a long time.
Since I don't have any I9505 but and I9506 (that only has one bootloader so far. Knoxed) I need to ask a few questions to see if my assumptions hold or not.
Q1: Is it true that if you upgrade to a Knox-bootloader never can downgrade?
Q2: If you trip the Knox-flag can you do that or is it still impossible?
Q3: Can you while already having a Knox-bootloader downgrader WITHIN the Knox-bootloaders?
Good and bad
Bad: They can have your Prog->serial that you signed in your store->You. Sinister, as I think Knox is this is bad.
Good: It's still a PROM. There might be some way to read from it. Next year Knox is totally integrated on a chip, black boxed, WITH E-FUSE.
Then we are toast and can all buy a HTC...
If Q1 holds then you always have a boot with SELinux. The bootloader fit's a kernel just fine, right?
I get a strange error on my phone. It's saying I have space left on my device but when I try to download from Play it says I'm out of space.
Q4: Is this a know bug? Is this software? Have anyone had it before Knox?
I took and started to read a bit on Wikipedia. It's good sometimes for quick info: Selinux,
So it's a container basically. I also stumbled over this baby: NSA SEAndroid
So this leads me to some other questions.
Q5: Could it be possible that the device is virtualized?
Q6: Do we have some programs that can go deep into the system and pick up system info?
Q7: Does all custom kernels work after the Knox (with the flag tripped of course). Where are they loaded? The bootloader or somewhere else?
It's hard to know if you ARE virtualized but not impossible so there need to be some comparison between a pre-knox and knoxed device. I don't own any.
So I ask here is anyone does?
Q7: Has someone verified that it refuses to boot the pre-Knox bootloaders with or without trippning the flag?
Because it would make perfect sense. We have the hardware for it for sure. They are still chit-chatting about their bootloaders and warranty and that is
something I don't have to care about since I have written permission to flash away, as much I want from my cell-provider.
So I don't know if this is just a wild theory of mine or not but I started to wonder why the enforcement and the total lockout when it comes to the bootloader.
If what they also say in the White paper is true then there is no way that we CAN make a non-Knox boot, can we?
Privacy wise this is also a catastrophe. They can connect the device directly to you, with targeting, for instance, a grouping of some kind. Good or bad.
Up to the ones that controls the phone, right?
So sorry for maybe obvious questions but I though that here, if anywhere, if the place to asked them.
Oh, another thing, I stumped over this one when I was researching why my Windows was desperately making contact with the standard 6to4 replay
that there is a written about. I see that it does that over and over (among trying to make a tunnel through ICMP when you turn on Skype). Caught them on that.
This one: Geoip Locator
How does it show at your place? I've turned off all my localisation platforms. Hard. I even run behind a VPN.
But when I run it in Chrome (where I should have it turned off and are behind a VPN it's waaay to close).
In FF you can turn it off with the about:config --> geo.* and put the value to false the the address to localhost.
But I did the same in Chrome but it's still leaking.
When it comes to IE. If you have your "Localisation policy" set to "ON" you can turn it off in IE. If you disable it it's greyed out (I have Win 8.1).
Think I'll soon move to BSD totally....
All the best,
Abs
Lets say I want to enable disk access to "drives" (a great software product to display dive space utilization), I can not do so there is no way to do so as I get a message "Screen Overlay detected", of course it is detected I have over 10 apps that require it, if I disable it they do not work PERIOD. so I need to have it enabled, nut then I have many apps that simply do not support Marshmallow (6.0) at all as a result. I can not understand why there are not more complaints and fixes for this as I'm basically stuck I have apps that require overlay including my dialer and I have apps I need that I can not use if overlay is enabled!
One work around I heard of was to boot into safe mode and run the apps there, but in safe mode I can not run any third party apps (so I can not execute those that I need to overlay disabled to set a permission.
I need help, either to fix the overlay prompt (simply put at this point security be damned I'll live without it I need the software to function), but searching and searching I've yet to see any solution or even suggestion beyond safe mode, which does not let me execute the software I need to fix, other than down grading (which does not help since at some point I'll need to move to 6.X), how does one fix the very annoying and Android breaking issue of overlay?
I just do not understand how Overlay a very necessary feature is also able to break many apps, including a few that require overlay themselves. I'm completely confused and sick of wasting time (hours at this point trying to figure out how to get around this).
Thanks,
ERIC