Related
android hacking tool was released at Defcon's hacker conference, on friday. it was, in order to warn OEM.... that hackers can easily hack into.. read this
https://www.defcon.org/html/defcon-18/dc-18-speakers.html#Percoco1
It's a rootkit
We have developed a kernel-level Android rootkit in the form of a loadable kernel module. As a proof of concept, it is able to send an attacker a reverse TCP over 3G/WIFI shell upon receiving an incoming call from a 'trigger number'. This ultimately results in full root access on the Android device.
Click to expand...
Click to collapse
Always a way
Is that really that easy to root an android device? Even from a remote point? That means I should never be worried about updating my phone, there’s always a way to obtain root access after that.
So I know pretty much how my jailbreak is going to work from end to end, except with regard to PatchGuard. I don't need to burn my "Holy Grail" exploit in order to release a jailbreak, but it means that I have to deal with PatchGuard.
In Windows 8.1, Microsoft modified the kernel and ci.dll so that PatchGuard protects the signing enforcement mode variables. This means that if you modify the variables that were modified by 8.0's jailbreak, some random time in the next hour from that point, your system will bugcheck (bluescreen) because PatchGuard detected something tampering with the kernel. It is very obvious that the addition of these variables to PatchGuard's protected list was a deliberate attack against the RT jailbreak, because there is little other reason to care about enforcing these variables' integrity after startup.
I need to get around PatchGuard somehow. PatchGuard itself is designed to be an obfuscated mess, deliberately difficult to modify in a stable manner. It does a lot of nasty tricks, things that you would typically find in copy protection systems. Obviously, disabling it would be nice, but quite difficult. So is stopping it from bugchecking.
I can load kernel drivers, so I know of a way in which I can hook parts of the system that would not anger PatchGuard such that arbitrary unsigned DLLs and drivers could be loaded without hassle. For things like the lockdown in WinDbg, VBScript and PowerShell, I can hook NtQuerySystemInformation in the user-mode ntdll.dll and intercept the request to check the lockdown setting. Even though the system lockdown state would still be active, as long as user mode programs don't know about it, it won't be enforced. (The kernel doesn't care at all.)
However, this leaves one thing to be desired: executing ARM code. I already know how we can patch the kernel so that ARM code can execute without the CPU being switched back to Thumb2 all the time. However, patching the kernel definitely will get PatchGuard's attention, so there's no way to pull that off without defeating PatchGuard.
The optimal solution is definitely to defeat PatchGuard, but I don't know how. I'm not an expert in the field of low-level NT kernel stuff.
please release your jailbreak so that other people can help you.
If i got it correctly, it will BSOD in a hour of running, so releasing it to public is not a good idea. Maybe via PM to other devs, but that depends on OP.
why not change the variables back after you launch your unsigned exe?
windowsrtc said:
why not change the variables back after you launch your unsigned exe?
Click to expand...
Click to collapse
I think about doing this too. Can we discard hacked? If it can done. Will it have problem with running unsigned exe? And did we know exactly when did PatchGuard notice about hack?
Myriachan said:
However, this leaves one thing to be desired: executing ARM code.
Click to expand...
Click to collapse
Perhaps I'm missing something, ... why do you want to do this? The reason I ask is because this seems to be your motivation for wanting to "defeat" patch guard.
WRT simply running native applications/driver - If you can successfully load a driver, even once, then there are a few easy ways to support this without a patch guard defeat.
Cheers!
bfosterjr said:
Perhaps I'm missing something, ... why do you want to do this? The reason I ask is because this seems to be your motivation for wanting to "defeat" patch guard.
WRT simply running native applications/driver - If you can successfully load a driver, even once, then there are a few easy ways to support this without a patch guard defeat.
Click to expand...
Click to collapse
That it's currently impossible to execute ARM code reliably on Windows RT is a major reason that Firefox hasn't been ported. Fixing that would require patching two context-switch routines in ntoskrnl.exe.
You're right that there are various ways of loading unsigned executables and drivers once the initial driver is bootstrapped. ci.dll and ntoskrnl.exe have so many variables that aren't protected by PatchGuard that this is pretty much inevitable. Ironically, removing the lockdown from WinDbg, PowerShell and VBScript is actually harder than running unsigned code when using this attack.
Defeating PatchGuard would be the optimal experience for users.
...
...
Myriachan said:
That it's currently impossible to execute ARM code reliably on Windows RT is a major reason that Firefox hasn't been ported.
Click to expand...
Click to collapse
Actually, I don't agree. There is no hard requirement for ARM code that I can see. The major reason for a lack of FF port is that the native RT community is too small to get behind the port to sort out re-writing parts of the code base. There is also the large build system/process that needs to be shifted to VS. Throw in the lack of a public RT 8.1 JB.. and there is little motivation for this community to invest the time/effort in making FF work.
Don't get me wrong, FF will likely come to RT (even 8.1) eventually.. but I don't see the lack of ARM code being the roadblock. Its time and effort along with a new JB.
bfosterjr said:
Actually, I don't agree. There is no hard requirement for ARM code that I can see. The major reason for a lack of FF port is that the native RT community is too small to get behind the port to sort out re-writing parts of the code base. There is also the large build system/process that needs to be shifted to VS. Throw in the lack of a public RT 8.1 JB.. and there is little motivation for this community to invest the time/effort in making FF work.
Don't get me wrong, FF will likely come to RT (even 8.1) eventually.. but I don't see the lack of ARM code being the roadblock. Its time and effort along with a new JB.
Click to expand...
Click to collapse
The javascript JIT engine is to ARMv7 not THUMB_2 though.
SixSixSevenSeven said:
The javascript JIT engine is to ARMv7 not THUMB_2 though.
Click to expand...
Click to collapse
I gathered as much. I'm suggesting a re-write of that as part of the port.
Cheers!
Possible, but not easy. The result would likely be significantly less efficient... but better than no JIT at all. It substantially increases the effort required for porting, though.
As for PatchGuard... I don't know as much about it as I'd like, but the fact that it only checks periodically suggests something that we can anticipate and head off, assuming we can get our own drivers loaded... hmm. This is a pretty "out there" solution, but is there any chance that the version of PG from RT8.0 could be substituted in? That may assume a greater degree of encapsulation of PG functionality than is actually warranted, but it does seem to me that, if we can't modify it, we might be able to just replace (or possibly remove) it. Another option: rather than modifying the value itself, modify the code that checks it? I mean, if they were smart, that's under PG as well, but it *might* not be. Either bypassing the check for the values, or the signature check, or just spoofing the signature check, or taking it a level even further and replacing the whole loader function with a clone that lacks the check (which allows the original to remain intact, aside from however the shim is injected).
Any which way, a lot of binary RE... ick, but that's life.
A few ideas:
1) Put a memory read breakpoint on the memory addresses you wish to change, check the context reading it and change it to what it should be if it's PatchGuard, and what you want if it's not.
2) Hook BugCheck to make it just return if PatchGuard calls it (I seem to recall reading something about PG wiping the stack/any context before calling BugCheck, so this may not work)
3) Forcibly enable Debug mode VIA setting the required kernel flag/calling the proper function (kdStartDebugger? something like that; I had found it at one point) to enable the debugger. I have no idea if PG will sense this on pre-existing threads or not, but if it does then it should shut itself down.
4) Check if THIS approach works in 8.1 (I suspect not, since it was published for 8.0 previews)
5) (This would work for g_ciOptions, but not patching the interrupt handlers), hook the usermode function that queries the state of the signing, make it call a driver that changes the bit back, check, then call the driver to set it to default again. You would only get a BSoD if you were really unlucky and PatchGuard happened to run during the 30ms that the flag was changed.
I'd like to play with some of these ideas, but without access to the current prototype (hint hint), and not having a PC I want to upgrade to 8.1 right now, it's difficult.
netham45 said:
A few ideas:
1) Put a memory read breakpoint on the memory addresses you wish to change, check the context reading it and change it to what it should be if it's PatchGuard, and what you want if it's not.
2) Hook BugCheck to make it just return if PatchGuard calls it (I seem to recall reading something about PG wiping the stack/any context before calling BugCheck, so this may not work)
3) Forcibly enable Debug mode VIA setting the required kernel flag/calling the proper function (kdStartDebugger? something like that; I had found it at one point) to enable the debugger. I have no idea if PG will sense this on pre-existing threads or not, but if it does then it should shut itself down.
4) Check if THIS approach works in 8.1 (I suspect not, since it was published for 8.0 previews)
5) (This would work for g_ciOptions, but not patching the interrupt handlers), hook the usermode function that queries the state of the signing, make it call a driver that changes the bit back, check, then call the driver to set it to default again. You would only get a BSoD if you were really unlucky and PatchGuard happened to run during the 30ms that the flag was changed.
I'd like to play with some of these ideas, but without access to the current prototype (hint hint), and not having a PC I want to upgrade to 8.1 right now, it's difficult.
Click to expand...
Click to collapse
1. You can't set a read breakpoint because PatchGuard is also checking the contents of the interrupt vectors/registers. It would notice that someone is using the hardware breakpoints before it tried to read kernel memory.
2. Yes, PatchGuard overwrites KeBugCheckEx with a pristine copy among other tricks.
3. PatchGuard knows that the debugger was not enabled at boot, and will not allow it to be enabled. It will bugcheck if you try to enable it.
4. It's possible that the approach where you look for the self-decryption code at the beginning of the DPC handlers would work.
5. There is a better way, closely related to how I'm writing my installation program, to allow unsigned PEs to load. It would escape PatchGuard's notice. A user-mode hook would be required in order to neuter wldp.dll, though, since ntoskrnl.exe would still tell programs that the current policy was locked down.
I think I can do everything I need to do except execute ARM code reliably without harassing PatchGuard.
Melissa
As a plain user, I have a question:
Why do we have to use ARM Instruction Set? Isn't just Thumb-2 okay? I thought other part of Windows all runs with Thumb-2 fine.
sahack said:
As a plain user, I have a question:
Why do we have to use ARM Instruction Set? Isn't just Thumb-2 okay? I thought other part of Windows all runs with Thumb-2 fine.
Click to expand...
Click to collapse
There is a lot of software that we would like to port over that is written in arm assembly. We would have to rewrite it to THUMB-2 to use it on Windows RT, though. Porting software is (relatively) easy, rewriting it is difficult.
sahack said:
As a plain user, I have a question:
Why do we have to use ARM Instruction Set? Isn't just Thumb-2 okay? I thought other part of Windows all runs with Thumb-2 fine.
Click to expand...
Click to collapse
Common one that needs the ARM instruction set would be a javascript engine. V8 which is the javascript JIT used in chrome only has x86 and ARMv7 versions available, it doesn't have a THUMB_2 version. Although V8 itself can compile for THUMB2, that is only the JIT'er itself, it will only ever JIT to the full instruction set. So to port chrome we wouldnt be able to use V8, there might be a way to get it to compile using the windows javascript engine (which is slower than V8 but perfectly fine) or something but its still a significant obstacle.
The same applies to quite a few other softwares.
Then as netham says, we have software written in arm assembly which people have requested, thats great but it takes alot of effort to rewrite it in thumb2 assembly.
If you have software which can indeed compile for thumb2 and function on thumb2, yeah thats great. But there is some which doesnt.
netham45 said:
There is a lot of software that we would like to port over that is written in arm assembly. We would have to rewrite it to THUMB-2 to use it on Windows RT, though. Porting software is (relatively) easy, rewriting it is difficult.
Click to expand...
Click to collapse
Okay... I used to think that only JIT compilers and media decoders needed that...
But that gives another question.... Were we able to let the CPU stay in ARM mode in Windows RT 8.0?
(And if PatchGuard checks periodically, is it possible to just reset its timer once in a while?)
sahack said:
Okay... I used to think that only JIT compilers and media decoders needed that...
But that gives another question.... Were we able to let the CPU stay in ARM mode in Windows RT 8.0?
(And if PatchGuard checks periodically, is it possible to just reset its timer once in a while?)
Click to expand...
Click to collapse
First question, no.
Second question, thats what the thread is discussing although your suggestion is perhaps worth a look into (if myriachan hasnt already)
SixSixSevenSeven said:
First question, no.
Second question, thats what the thread is discussing although your suggestion is perhaps worth a look into (if myriachan hasnt already)
Click to expand...
Click to collapse
Sure, you could reset the timer on PatchGuard continuously, if you can find all its timers and perfectly distinguish them from those that were created by legitimate drivers. That's the harder part, unfortunately. =/
Hi,
I've buy from at lest one mont a surface rt, i've jailbreak it and install filezilla and notepad+++ so.... but i'd like anymore. Like many people i'd like to install a linux distribution on it but i dont really understand what is the problem...
I've know about:
Surface get a secure boot (EFI) and we can't disable the secure boot on surface RT caused windows need a valid key (?). I've read that linux got some distributions arm based (ubuntu, debian, fedora) and i think i've understand about ubuntu got a valid microsoft signature with a ssl provider that can bypass the useless verification... am i right?
So, if ubuntu (or another distro), got a valid sign for bypassing the limitation to due EFI why can't we normal install linux such like surface pro??
Best regards and sry for my bad english ^^'
----------------------------------------------
Some distros has keys to X86 UEFI. No one (other than Microsoft) has keys for ARM.
And (afair) due to some limitations of jailbreak we have no way to execute linux kernel.
This applies to any RT device.
kitor said:
And (afair) due to some limitations of jailbreak we have no way to execute linux kernel.
Click to expand...
Click to collapse
Is this true for sure? I figured especially since we have driver-level access we could possibly tear down the Windows kernel in reverse and start execution of arbitrary code. But I might have missed something.
The bigger issue about trying to port Linux to any device without official Linux support is usually in getting the kernel to boot and then making the hardware itself useful after that. This usually means you have to work "blind" and rely on some kind of low-level serial output to monitor the kernel boot to see where it panics. Only after getting a successful kernel boot can you even begin to think about drivers for the display, touch screen, etc.
So the prerequisites to even beginning to port to e.g. a Surface would be to find some way to kick out Windows and start arbitrary execution, enable some kind of low-level serial debugging for the would-be kernel, and then tediously poke and prod until it can successfully start. I'm not sure anyone knows of a dependable way to get serial debugging information.
Embedded devices on the whole are a lot more finicky and a lot less tolerant than normal PCs, generally due to their proprietary nature requiring a lot of hardware knowledge to initialize everything properly. About the only thing we'd have going for us is that it's a Tegra chipset, so if you can get the underpinnings working, you can probably at least get the basics like video and USB working without too much trouble.
I think the biggest thing about it is like the rest of RT ... there's just not enough interest in those with the skills to even attempt this because this is such an extreme minority platform. I imagine a Surface RT would make an excellent little Linux tablet, but I'm not holding my breath.
Well, If somebody would write something like WinKExec, or HaRET (haret allowed to analyse gpios and memory on WinCE/WM devices) then things may be possible. I own XPS10, so quite different device (as it has Snapdragon CPU), but I have some (small) experience on porting Linux on ARM devices - some time ago I was able to get Linux working on Bsquare Maui: http://pdasite.pl/kitor/maui_linux/ (including hardware reverse engineering - tracking gpios using multimeter - this way i found hidden usb host )
There's been talk of a WinKExec-like approach for months. Nobody has attempted it yet, though, or if they have they kept quiet about it.
One of the problems getting something like that working on RT is that it blocks kernel debugging, so you have to work pretty blindly. Then there's all the driver issues.
What about getting android to boot on it? There's drivers and such for tegra 3. I think its possible to build and deploy if we can get a kernel exploit. Am I wrong?
Android depends on Linux. If you can't get a Linux kernel booted, you won't be able to get Android to start up either.
skiman10 said:
What about getting android to boot on it? There's drivers and such for tegra 3. I think its possible to build and deploy if we can get a kernel exploit. Am I wrong?
Click to expand...
Click to collapse
The kernel by itself would be *relatively* easy (translation: still quite hard, but we could probably do it if people cared enough). However, getting all the other hardware (you know, things like the touchscreen, WiFi, and such) would likely be difficult, and without all that, it's pretty useless as a tablet. This is true for both Android and "desktop" Linux.
Where should I start to get a kernel to boot? I'm an android exploiter trying to dabble in Windows exploitation.
Sent from my HTC6500LVW using Tapatalk
Well, unless you think you can break Secure Boot, you should start by writing/porting a way to use the NT kernel to launch the Linux kernel. That probably means a lot of NT driver development stuff (done without the aid of a kernel debugger, just for extra fun).
There's a doc on internet from the blackhat usa 2013 seems to be interesting.
The man from the pdf get the exploit of injecting some code from the boot, so i think we can done this, no ?
If anyone tried and arrive he'll get amout of money from me
graphsys said:
There's a doc on internet from the blackhat usa 2013 seems to be interesting.
The man from the pdf get the exploit of injecting some code from the boot, so i think we can done this, no ?
If anyone tried and arrive he'll get amout of money from me
Click to expand...
Click to collapse
Can you PM me the article?
---------- Post added at 10:59 AM ---------- Previous post was at 10:57 AM ----------
GoodDayToDie said:
Well, unless you think you can break Secure Boot, you should start by writing/porting a way to use the NT kernel to launch the Linux kernel. That probably means a lot of NT driver development stuff (done without the aid of a kernel debugger, just for extra fun).
Click to expand...
Click to collapse
I think there is an exploit for Secure Boot, it just hasn't been shared yet...
If you mean the exploit I think you mean (discovered by an XDA member), it's a Windows bug, not actually a Secure Boot bug. It doesn't actually allow booting a different OS directly, just messing with Windows after bootup. We already have the jailbreak (for 8.0), which is pretty much equivalent.
GoodDayToDie said:
If you mean the exploit I think you mean (discovered by an XDA member), it's a Windows bug, not actually a Secure Boot bug. It doesn't actually allow booting a different OS directly, just messing with Windows after bootup. We already have the jailbreak (for 8.0), which is pretty much equivalent.
Click to expand...
Click to collapse
Im researching the doc i've found to provide you it.
Its not the jailbreak done by clockr ported by neman its another jailbreak who's available from the boot, but if remember they dont give sources... search in progress i'll post the link
There is one theoretical way to remove secureboot on a jailbroken device. It is rather easy: write a driver that reads/writes physical RAM. Find EFI_RUNTIME_SERVICES in memory and look for SetVariable function. Patch it so that it does not check for a valid signature. Than write your own certificates to UEFI with this patched function. Profit.
I've already done the first part - wrote a driver and found the table in memory (this is really an easy part). But my device died before I was able to successfully overwrite the certificates.
As far as I know similar method was once demonstrated for an x86 UEFI, just noone made it for ARM.
That... is a rather clever option too, although I'm tempted to avoid things which require modifying the firmware (too much option for future updates to break things). Still, a good option for those of us with gen1 devices who would like to be able to upgrade without losing the jailbreak, and also a good option for those who would like to install different OS images...
mamaich said:
There is one theoretical way to remove secureboot on a jailbroken device. It is rather easy: write a driver that reads/writes physical RAM. Find EFI_RUNTIME_SERVICES in memory and look for SetVariable function. Patch it so that it does not check for a valid signature. Than write your own certificates to UEFI with this patched function. Profit.
I've already done the first part - wrote a driver and found the table in memory (this is really an easy part). But my device died before I was able to successfully overwrite the certificates.
As far as I know similar method was once demonstrated for an x86 UEFI, just noone made it for ARM.
Click to expand...
Click to collapse
Can we get in contact? I'd love to get a more detailed plan that I can try. Gen 1 Surface RT on Windows 8 RT.
One demo about bypass: youtube.com/watch?v=i9ULYwRK1iU searching again the pdf mens
GoodDayToDie said:
Well, unless you think you can break Secure Boot, you should start by writing/porting a way to use the NT kernel to launch the Linux kernel. That probably means a lot of NT driver development stuff (done without the aid of a kernel debugger, just for extra fun).
Click to expand...
Click to collapse
About the only way you could possibly break secure boot is possibly by spoofing a key or potentially modify the UEFI to have secure boot disabled. While both are technically possible, you'd have to find an exploit to do it because I'm sure the UEFI probably can't be easily flashed
ThatGuy94 said:
About the only way you could possibly break secure boot is possibly by spoofing a key or potentially modify the UEFI to have secure boot disabled. While both are technically possible, you'd have to find an exploit to do it because I'm sure the UEFI probably can't be easily flashed
Click to expand...
Click to collapse
if you got a device with a jtag interface left open, that should be easy enough. The problem is that EPROM "fuses" are usually burned on the SOC. The secureboot check is hardcoded check that flag. You can't alter the bootloader without invalidating its signature, and it's practically impossible to unset an EPROM fuse.
I'm interested by the recently fixed path traversal vulnerability in the VolumeManager::createAsec() function.
Though it seems to be a well known issue for peoples in the field, my entry point was the article "Local root vulnerability in Android 4.4.2", available at blog.cassidiancybersecurity.com: as I'm learning, and know the right way to learn isn't to only read but also to practice, I felt it could be a good exercise to implement an exploit that leverage this vulnerability to get a "root shell".
AFAIK:
On Android 4.4+, to get a useful "root shell" does not mean just to acquire ruid=euid=0 and spawn /system/bin/sh, due to SE Linux restrictions: this requires to setup some kind of su system daemon, that will execute su client requests in a privileged context.
A common way to get this system daemon running privileged enough is to have it started by the kernel as a response to a hot plug event, which involves writing to /sys/kernel/uevent_helper
The API related to the vulnerability (VolumeManager/IMountService) isn't published to user applications, which should rather rely upon the StorageManager system service or the media framework
Getting the su daemon/client programs should be quite easy (a classic shell bind/reverse tcp daemon and a netcat client will be ok for the PoC, though local adb usage would benefit from using un*x domain sockets instead of inet ones).
But, starting from the beginning, I need to find a way to trigger the vulnerability, which I haven't achieved yet: that's why I'm here, hoping someone will be both clever and charitable enough to give a few clues.
The material at hand till now:
The article from cassidiancybersecurity.
The working exploit from jcase (Pie for Motorola devices): thanks to him, I can use a temporary root shell, which helps a lot to see what's happening; it's also there that I've borrowed the /sys/kernel/uevent_helper trickery
SDK/AOSP source code (notably VolumeManager.h/cpp, CommandListener.h/cpp, IMountService.java, MediaFormat.java)
SDK/NDK documentation
I've tried to access the IMountService API through a reference I fetch with something equivalent to:
Code:
IMountService service =
IMountService.Stub.asInterface(ServiceManager.getService("mount"));
I say "something equivalent to" because the API is not public and you have to use reflection.
The acquired proxy seems ok, but invoking the API leads to errors related to missing ASEC_CREATE or MOUNT_UNMOUNT_FILESYSTEMS system permissions/capabilities. Trying to directly write to the IPC un*x sockets also lead to permission errors, which is consistent.
Thus my first question: does exploiting the path traversal vulnerability involve another exploit to set the permissions that allow to access the vulnerable API ?
Reading the related thread, it seems to me that jcase's exploit (Pie for Motorola devices):
relies upon the setup being done under the shell user identity, perhaps to belong to the mount group: can someone confirm this ?
should work mostly for Motorola devices, but not for others: is this stated because successful exploitation also relies upon Motorola specific parts (drivers,customization,...), or because most other vendors have already backported the fix ?
The above questions will certainly sound naive to most of you, but some answers to these would greatly help me not running toward a completely wrong direction.
I'm neither waiting for another binary exploit (I have a Moto G that I boot on a KitKat 4.4.2 rom, and jcase's Pie greatly addresses my current user needs), nor expecting clean source code with build files. I'd just appreciate any relevant direction, pointer, snippet.
For example, I was not aware of the /sys/kernel/uevent_helper trick to execute privileged processes, and discovered it while trying to reverse engineer jcase's implementation. Later on, I've seen it at various places, including the public source of the Cyanide project, which tells me that this is not a secret that must remain secret, but a rather well known (and documented) kernel behavior. That's the kind of things I wish to learn, hopefully with community advice.
Thanks, have a good day.
thanks
I'm trying to find a root exploit for Fire HD 8 (2017) as many others are doing. I found a vulnerability by X-Ray, the Linux kernel exploit CVE-2014-4943 which allows privilege escalation by a flaw found in the implementation of PPP over L2TP sockets. When I searched in Google for it, I found that it is done by 'leveraging data-structures between an L2TP socket and an INet socket'. There MUST be a way to escalate privileges because there is a closed-source method used in Immunity CANVAS in Linux systems. Let's collaborate with this and we will be able to root those locked-out devices!
Resources and ideas are welcome!
Some links you might be interested in,
CVE-2014-4943 - PPPoL2TP DoS Analysis
CVE-2014-4943 - Red Hat Customer Portal
CVE-2014-4943 - (cve.mitre.org)
Linux Kernel 3.15.6 - PPP-over-L2TP Socket Level Handling Crash (PoC)