I am trying to implement a simple system call hook. My method was the same method used by standard linux rootkits like adore. this method worked for hooking sys_open and other file IO system calls. but when i tried to hook sys_fork and other process related system calls my android phone crashes (Nexus one, Motorola Milestone, and emulator). Something inherently different about Android either ARM or android kernel is different from basic linux machines which wont allow me to use the same method to hook the system call fork. Basically my method is below, this is implemented via a LKM on a phone that i have root access on.
//save pointer to original function
orig_fork = sys_call_table[__NR_fork];
//point sys_fork to my fm_fork function
sys_call_table[__NR_fork] = my_fork;
//call original fork call (simplest case)
asmlinkage int my_fork(struct pt_regs *regs)
{
pid_t pid;
pid = (*orig_fork)(regs);
return pid;
}
Some how i think the stack is getting messed up. I looked at the source code for the kernel and found that the sys_fork isnt actually in the system call table. Instead it is a sys_fork_wrapper. This wrapper is an assembler function with two commands which lead it to branching to sys_fork. Sys_fork in turn calls another function called do_fork. Through debugging methods i was able to confirm that my call to the original fork function was returning correctly, but when i try to return the pid within my own function the crash occurs. Now whats interesting is that I was able to confirm that do_fork is called many times without calling sys_fork for many processes on the phone. So when i do the simplest process i can think of by starting up a shell the phone didnt crash. But it wont open up a shell. The terminal locks up when i try to open the shell. Starting up a shell will call a sys_fork_wrapper->sys_fork->do_fork like expected. Starting up another more complicated process such as calculator it will call sys_fork_wrapper->sys_fork->do_fork->do_fork->do_fork->do_fork.... so bacially i am left with lots of questions about why hooking sys_fork is not working.
Related
Root Tracker is source code for a super-simple Android 2.2+ device tracking system that responds to SMS messages with embedded control passwords.
Root Tracker is designed to be installed on a rooted device in /system/app, so it can survive a hard reset. Root Tracker has no user interface, all the better for hiding it from a thief. The code must be customized for the particular user and device, as passwords and other configuration items are hard coded, and each user should change the package name and other details to make it sound like a system package, in order to even better hide the package from a thief. Don't use the current values in the source, as a smart thief (there aren't many, I expect, but there may be some). Plus, I expect that different users will have different requirements.
After customizing and installing, go to your system Settings and set Root Tracker's device admin class as a Device Administrator.
Actions available:
gps
wipe
lock (locks screen [if set as Device Administrator; otherwise, sets screen timeout to a very short value to make device very hard to use], turns off adb, disables NoLock)
unlock
root shell command (output returned via SMS).
I wrote Root Tracker because I was uncomfortable about having my phone tracked and potentially wiped by a closed source app, like the various anti-theft trackers currently available. A crucial design principle was to make RT simple enough that one can easily verify from the source code what exactly it is doing.
The passwords are plain text in the apk. You can replace this with hashing if you like, but I didn't bother.
Also, instead of invoking the Android system's data wiping, which is known to be of problematic quality on some devices, it uses dd to overwrite the data partition, which may be more reliable (but of course, you have to ensure RT is installed in /system/app). Moreover, this means that the wipe works even if the thief is clever enough to go to the device settings and revoke Root Tracker's device administrator status. I don't know how well this works. This is a feature I did not test since I don't want to deal with restoring a backup. I worry that wiping the data partition will cause a reboot at some point. (Still, I have deleted the contents of /data before, and restored them via tar, and the device did not reboot while deleting.)
The gps command responds instantly with last cached GPS and Network location, then turns on GPS (even if disabled) and Network location (this one may show a dialog, so I recommend keeping Network location on in your Settings, or else disabling the Network location code). Then it waits for a GPS fix. If while waiting for a GPS fix, it gets a new Network location value, it sends that, but keeps on waiting for a GPS fix. If it gets a GPS fix before getting a Network fix, it quits looking for the Network fix (you can change that in the source code).
Note: Installing this on a device that isn't yours (unless you're law enforcement with an appropriate warrant) is likely illegal and is certainly not nice. This is designed for one's own use.
The Nexus 5 turn to be asked this hehe
I've just now experienced this in the course of fixing another issue.
Normally in spite of how much i change ROMS whenever I set time manually and uncheck network derived time the date/ time maintains across restarts, now it doesnt.
It looks like a 4.4.4 issue? Dunno
Any help / ideas welcome.
What I did so far:
clean ROM not dirty flashed
switching between stock OMNI and Minux OMNI
all combinations of option in date/ time settings while
Each and everytime after reset the date time is 13 Aug 1970. Even if is set to automatic that date briefly appears before a connection to the net is made.
Did you find the solution?
Could be related to the RTC not storing the time. The qpnp-rtc-write device tree option controls whether the time can be set with hwclock. If set to 0 or omitted, you will not be able to set the RTC time through the standard RTC interfaces (hwclock -w). Now, apparently these Qualcomm devices have a proprietary time_daemon program which is supposed to store these values permanently. It is invoked through the TimeService.apk program which is some thin glue that calls into libTimeService.so which invokes the time_genoff_operation function. I guess that this function should ultimately update the RTC time, but have not investigated further.
TL;DR check whether your TimeService.apk is working. It should contain a classes.dex file (deodexed). For Android 5.1, note that the files from the factory images are ART-optimized. You can undo that using Riddle's oat2dex.jar tool.
Edit: apparently these Qualcomm RTCs cannot be written from software (at least, not directly). A Qualcomm consultant mentioned this during patch review:
Anirudh Ghayal (Qualcomm consultant) said:
In some of our MSM/QSD designs, we have a single RTC shared by multiple
processors (other than the ones running Linux). Thus, the need to have a
non-writable RTC using this pdata.
Click to expand...
Click to collapse
Someone already tried to patch the property in the kernel, but writing via hwclock was still not possible. I can confirm this for a Nexus 5 (rev_11, tested with this recovery image patching tool):
Code:
~ # /system/xbin/hwclock -w
hwclock: RTC_SET_TIME: Operation not permitted
<3>[ 25.821247] spmi_pmic_arb fc4cf000.qcom,spmi: pmic_arb_wait_for_done: transaction denied (0x5)
<3>[ 25.821338] qcom,qpnp-rtc qpnp-rtc-ee162000: SPMI write failed
<3>[ 25.821408] qcom,qpnp-rtc qpnp-rtc-ee162000: Write to RTC reg failed
In the end, I decided to accept this problem and be stuck with a RTC set to 1970. Note that this device has not been network-connected since I started experimenting.
As for the TimeService.apk/time_genoff/time_daemon functionality, all these components do is maintaining an offset in the /data/system/time/ats_X files. These are read on startup and applied as offset. Nast hack, and there are alternative opensource alternatives. Really, the only functional thing that this daemon does is reading the RTC time and then applying the offsets over it. It has no code to write back the actual time to the RTC. It is no magic. (Found by reverse engineering the binaries and libraries.)
Lekensteyn said:
Could be related to the RTC not storing the time. The qpnp-rtc-write device tree option controls whether the time can be set with hwclock. If set to 0 or omitted, you will not be able to set the RTC time through the standard RTC interfaces (hwclock -w). Now, apparently these Qualcomm devices have a proprietary time_daemon program which is supposed to store these values permanently. It is invoked through the TimeService.apk program which is some thin glue that calls into libTimeService.so which invokes the time_genoff_operation function. I guess that this function should ultimately update the RTC time, but have not investigated further.
TL;DR check whether your TimeService.apk is working. It should contain a classes.dex file (deodexed). For Android 5.1, note that the files from the factory images are ART-optimized. You can undo that using Riddle's oat2dex.jar tool.
Edit: apparently these Qualcomm RTCs cannot be written from software (at least, not directly). A Qualcomm consultant mentioned this during patch review:
Someone already tried to patch the property in the kernel, but writing via hwclock was still not possible. I can confirm this for a Nexus 5 (rev_11, tested with this recovery image patching tool):
Code:
~ # /system/xbin/hwclock -w
hwclock: RTC_SET_TIME: Operation not permitted
<3>[ 25.821247] spmi_pmic_arb fc4cf000.qcom,spmi: pmic_arb_wait_for_done: transaction denied (0x5)
<3>[ 25.821338] qcom,qpnp-rtc qpnp-rtc-ee162000: SPMI write failed
<3>[ 25.821408] qcom,qpnp-rtc qpnp-rtc-ee162000: Write to RTC reg failed
In the end, I decided to accept this problem and be stuck with a RTC set to 1970. Note that this device has not been network-connected since I started experimenting.
As for the TimeService.apk/time_genoff/time_daemon functionality, all these components do is maintaining an offset in the /data/system/time/ats_X files. These are read on startup and applied as offset. Nast hack, and there are alternative opensource alternatives. Really, the only functional thing that this daemon does is reading the RTC time and then applying the offsets over it. It has no code to write back the actual time to the RTC. It is no magic. (Found by reverse engineering the binaries and libraries.)
Click to expand...
Click to collapse
Hi, great explanation.. I didn't have this issue in stock Marshmallow, but now I have it in custom ROM.. maybe it's something related to some permissions?
bart.found said:
Hi, great explanation.. I didn't have this issue in stock Marshmallow, but now I have it in custom ROM.. maybe it's something related to some permissions?
Click to expand...
Click to collapse
There is a SELinux policy that must allow access, you can check your kernel logs (dmesg or maybe even logcat) for SELinux denials. The /data/system/time/ location must also be accessible for the time daemon.
Hi There,
I want to start off by saying I hope I am not crazy and I apologize from the get go if I misrepresent my issue in error. :angel:
I believe someone has flashed MDM software to my android device. I would like to know if I am either going crazy over nothing or would like some assistance in diagnosing what the possible issue could be. I believe it to be something similar to Murata Ayla Cloud software kit. This person would have had access to all of my Cell phones, Raspberry Pi's and Computers.
I started to suspect something when applications would become installed on my device(ones I did not install obviously). I Started to notice XML /*.SH files appearing, Samsung Knox (which I have been on a custom rom such as AICP, DU, literally the day I get any new device so I have never had Knox or any Samsung apps). My device also started to download apps for another mobile carrier and in my CSC information now shows the incorrect carrier code. My root seems to always stop working (literally just locks up when I open it, even if I remove and reinstall it works briefly) and my Wi-Fi mac address suddenly became 00:02:00:00. So I decided to flash back to stock firmware and try a different rom. Long story short, I compared the Rom files and original backup to the files on my device several days later after minimal use. I noticed a lot of .sh files loaded in the root DIR as well as container agents, MDM agent running, MDM enrollment app.
I then noticed odd things on my PC's, like windows firewall always allowing Xbox service, media server, Miricast and a bunch of other things. I can see UPNP is enabled on the routers and is what is configuring my win RM. So I did some wiresharking and found a Fortinet server with a Murata mac oui on layer 3. I also ran some logs to see devices plugged in to my USB ports and found several samsung CSC/Modem drivers + a log that implied something about serial port /EMMC programming. I also found several apps that I have never used or even heard of. (QLAtool, ReadnWrite tool, GN Qcom download tool). I also checked several of my other phones and it appears that they all have the same serial number and device name. I have never flashed my devices with the incorrect backups. The home network is not mine but I asked the other people wthin the house but they state they do not know anything........
No matter what I do (flash/factory reset etc), the XML files/sh files slowly download after I leave my device connected to the internet. Several of them reference open sim alliance/virtual usb-BT proxies/media server and virtual devices. There are so many MDM apps/embedded controllers/KVM's/Hypervisor/HCE - Knox dev kits I can't determine which it is.
I would desperately like to have my privacy back or know that I am not crazy. Is there anyone who could help me identify what is happening or how to better investigate.
Thank you very much,
For a while now I have known that you can attach a terminal emulator to /dev/ttyACM0 while in download mode and send AT commands directly to the modem.
All the commands that I pulled out of /system/bin/atd (the daemon that your dialer, SMS app, etc talk to) were pretty useless while booted into laf. However, this changes all that.
These guys figured out how to toggle the USB configuration while booted into the OS so that you can send AT commands directly to the modem. Here is a video of what can be accomplished with this exploit: link.
I have tested this on the V20 (both H910 and H918), and the modem firmware is still vulnerable.
My H910 is not rooted, and is encrypted, and I was able to unlock it, when only a PIN code or pattern was used. I was NOT able to unlock it if a fingerprint had been setup. However, I WAS able to pull any file I wanted to off the phone even though I could not unlock it. I was also able to make and receive calls.
Code:
/dev/ttyACM0 > AT%KEYLOCK=0
+CIEV: 1,3
+CIEV: 1,4
+CIEV: 1,3
AT%KEYLOCK=0
[0]KEYLOCK OFF
OK
Dialing 611 with the phone locked:
Code:
/dev/ttyACM0 > ATD611
+CIEV: 1,3
ATD611
/dev/ttyACM0 > ATH
NO CARRIER
TL;DR: Make SURE you use the fingerprint sensor if your are even remotely worried that someone might get into your phone. Even if you do, use a fingerprint, someone can still make calls / send text messages.
Also, I will not provide simple instructions on how to recreate this for the simple fact that THIS exploit has NO value other than to F**K someone ELSE over. Unlocking a bootloader helps YOU. Bypassing security even on a non-rooted phone helps NO ONE.
EDIT: Just to be clear, this is not YET known to be a remote exploit. It requires the phone to be connected to a PC.
Also, a link to their official research.
-- Brian
That was really fun to watch.
I'm really hoping that someone out there can help me out with this mess I have stumbled into.
Here's the not-so-short version of a long rabbit hole I had no idea I would be travelling down:
In the new Pokémon games there is a 1/4096 chance of encountering a rarer version of said Pokémon (by default). In order to obtain one of the "starter" Pokémon in this rare form, it takes about 110 seconds of sitting through loading screens and pushing the 'A' button repeatedly, per attempt. Assuming that I am guaranteed the rare version of this Pokémon after 4096 attempts, I would have to continue this for roughly 125 hours. Unfortunately That is not how statistics actually work. Needless to say 30 to 40 hours in, I have had enough of manually pushing 'A'.
I had the bright Idea to emulate a controller, record inputs, then replay them over and over, which could connect to the actual Nintendo Switch, and so I attempted to find solutions for both my PC as well as android phone. Unfortunately without hacking my Switch, it is technically impossible to do this with the PC. The phone was a different story. An app exists currently on the play store which allows one to emulate a pro-controller and connect to the console. Perfect.
Except that app requires particular functionality which my normal phone does not have, or might have but I do not wish to root that one. My solution wound up to me attempting to emulate an android device, and connect to my switch through the emulator, using Bluetooth.
I was able to successfully set up a VM, and get android x86 running on it, but that is where my success ended. I have reached a road block in terms of getting Bluetooth to pass through my computer to the emulator. In collaboration with VirtualBox's forums, we have reached the point of believing that installing the drivers from the Bluetooth dongle may resolve our issue.
I think I have all the resources needed to do it, I just don't know the method of how. Android, VMs, and Linux are just barely outside my realm of knowledge. Can someone help me sort my puzzle pieces and figure out what I need to get it to work?
------
To be proactive, here are some of the resources and details I figure might be helpful.
VirtualBox thread I created explaining this situation (in a more professional tone):
https://forums.virtualbox.org/viewtopic.php?f=3&t=104894
Potential solution found in a few google discussions:
https://groups.google.com/g/android-x86/c/9DTec9mTo5A
https://groups.google.com/g/android-x86/c/g6XkeDnATbg
GitHub/potential Bluetooth driver link:
https://github.com/winterheart/broadcom-bt-firmware
https://github.com/winterheart/broadcom-bt-firmware/blob/master/brcm/BCM20702A1-0a5c-21ec.hcd
------
Android version: android-x86-8.1-r6
Bluetooth Dongle Version: Kinivo Bluetooth receiver/transmitter (Broadcom BCM20702)
------
In my attempts to install the driver that I believe is correct, I was able to download the .hcd file listed in the GitHub link above. However my attempt to move it to /lib/firmware/brcm/ is denied, telling me that the file is Read-Only. Attempting to chmod, chown, along with other commands which I have since forgotten has resulted in no further progress. At this point my current problem is this:
How the heck do I move this .hcd file into /lib/firmware/brcm/ ? Will this even solve my issue?
tldr; I want a slightly-different colored grass turtle. I'm completely over-engineering a solution by setting up an android vm to do the work for me while I watch. Bluetooth ain't working, and I have no idea how to fix it.