I'm just wondering is anyone trying this yet? i mean is it even possible?
Just a thought for you big shot android devs out there JF, Haykuro, LucidREM
Google "android jni"
Well, a quick trip around google would have helped you.
Android is using java, and currently it's not possible to use anything else.
But anyway, would you rather compile all of your code for multiple architectures? J makes things easier here...
You can write cli-apps in C though... i heard something about that there was plans to make other languages available in android, but i wouldn't hold my breath
Also, why is this related to JF/Haykuro/LucidREM?
I think you can do this with JNI: http://en.wikipedia.org/wiki/Java_Native_Interface
Using an ARM native compiler (such as the ones at CodeSourcery, http://www.codesourcery.com/sgpp/lite/arm/portal/[email protected]=lite) you can compile your apps and run them fine on the G1
Code:
$ arm-none-linux-gnueabi-gcc -static foo.c -o foo
$ adb push foo /data/foo # we are pushing to /data as it is +rwx (read, write, execute) for a standard user.
$ adb shell /data/foo
a=1
b=2
foo=a+b
foo=3
^^^
OH I love when I stumble across a post like this and have something new to play with.
The problem is due to the different location of the linker and mainly the different libc you have to statically link everything.
I have been having a hell of a time getting DPKG to build statically.
I picked up a copy of the newly released book, Unlocking Android, at Barnes and Noble yesterday. There is a whole chapter devoted to writing native apps using C (and ARM assembler) with the CodeSourcery tools linked above. The author walks through the steps you need to do to dynamically link the libraries so you don't end up with enormous statically linked executables. Well worth the price.
It is surprising what you can do with C on the phone, its actually not too difficult. The method outlined below doesn't use the non native toolchains and if you use the sourcery toolchain (as mentioned above) you will end up with bigger binaries as you need to link in a standard glibc and not androids bionic libc. This may or may not be important for your project.
The other advantage of the steps below is that you will build and link against any library that is available to the android platform
The easiest way that I've found to start when porting or writing new applications is this method.
1) Check out the current git android source.
2) Build the entire tree, "make" in the top level directory.
3) Create a new directory in mydroid/external/packagename/
4) Copy one of the simple android Android.mk (Make) files from a "like" target.
(If doing a library, choose a library, if coding an executable , choose that).
5) source the mydroid/build/envsetup.sh in the users bashrc
6) cd to your directory, then instead of the usual "make" do an mm.
This should create a binary, which you can adb push to the phone and run at the console.
You can do all the usual things if linked properly, like write the framebuffer using sdl, play sounds, create network connections.
Just remember that you dont have a standard libc (glibc) to play around with you have "bionic". If you are missing your favourite glibc function , it is probably intention and not abug. You'll either need to port it or make do with the functions provided by bionic.
These instructions are for a "pure" C program. you can mix the java like dex calling by 'shelling' out to the C application when you need performance, however premature optimization is the root of all evil, you'll be surprised what performance you can pull from davlik (And I expect the VM guys to improve this even further).
I know that is a lot to digest. Will do the best I can to answer your questions. I'm by no means an expert in the area, but have learned a bit about C on android.
Well I don't know much about all this but what i know is that e.g.
ScummVM IS written in C++ , and so is g-arcade.
His FAQ says:
"How did you do this? Is it Java?
No. ScummVM is a C++ program. For this port, I turned it into a really big JNI library so Android still thinks it's running a Java program, but almost all of it is implemented in C++."
(http://sites.google.com/site/scummvmandroid/faq#TOC-How-did-you-do-this-Is-it-Java-)
So if some1 wanna port MAME, feel free to xD
Hi there, this is my first post on xda so forgive me if this is put in the wrong forum.
I am new to android and wish to play around with the emulator.
What I want to do is to create my own piece of virtual hardware that can collect OpenGL commands and produce OpenGL graphics.
I have been told that in order to do this I will need to write a linux kernal driver to enable communication with the hardware. Additionally, I will need to write an Android user space library to call the kernal driver.
To start with I plan on making a very simple piece of hardware that only does, say 1 or 2, commands.
Has anyone here done something like this? If so, do you have any tips or possible links to extra information?
Any feedback would be appreciated.
Regards
Has anyone done this?
Bump Bump
Im surprised this is left unanswered.
Yes, you can do this. There are several ways to do so, but I will explain 2 good options for you.
One: Use AndroidSDK. It's configured for android and simple to set up.
Two: Use virtualbox. If you have the android ISO, you can install it as a bootable image in this software. This gives more functionality than AndroidSDK, but it is not as simplistic. There are settings you will need to adjust to get it running. For a working Android ISO with limited functionality, you can download this: http://www.android-x86.org/download
If you have nothing to add to this discussion please do not post. Thanks
Im hoping that we can make a list of requirements for this jailbreak to happen. Please read along with us and if you have any ideas regarding any of the steps please help us out...
Thanks,
Toxickill.
In JB 8.0 we change a byte which indicates the sign level from "Microsoft" to "Unsigned".
Now this is protected by PatchGuard: you will get BSOD if you change it.
I think this is probably the only change.
LolitaPlus said:
In JB 8.0 we change a byte which indicates the sign level from "Microsoft" to "Unsigned".
Now this is protected by PatchGuard: you will get BSOD if you change it.
I think this is probably the only change.
Click to expand...
Click to collapse
Well can we bypass patchguard? Because people over at easy hook have written a c# patchguard 3 bypass driver maybe we can build off of that?
yeah patchguard has been bypassed I think https://twitter.com/standa_t/status/437972336705159169
master.peterm said:
yeah patchguard has been bypassed I think https://twitter.com/standa_t/status/437972336705159169
Click to expand...
Click to collapse
Ok so now that it can be done im going to fire up my surface and get working on a new jailbreak tool. If all succeeds then i will update accordingly. Hopefully bypassing patchguard is all that is needed to run old bypass methods. If patch guard stays bypassed then we can make the jailbreak persistent through sessions.
Well, the other problem is that you can't attach a debugger to CSRSS.EXE anymore. So you need a different way to change the relevant value (or a way to bypass the Protected Process restriction).
I think Myriachan already has a way to do that, though; she mentioned that she'd managed to jailbreak but Patchguard was causing the system to crash, so she was working on a way around that.
GoodDayToDie said:
Well, the other problem is that you can't attach a debugger to CSRSS.EXE anymore. So you need a different way to change the relevant value (or a way to bypass the Protected Process restriction).
I think Myriachan already has a way to do that, though; she mentioned that she'd managed to jailbreak but Patchguard was causing the system to crash, so she was working on a way around that.
Click to expand...
Click to collapse
Would patchguard bsod if we removed the protected process on csrss?
Also, would shell code be able to call ntdll.dll methods? We might be able to code arm shell code and call a method to temporarily revoke its protected process flag.
Edit:
Could we attach the debugger to a none protected process, execute shell code that removes process protection? Only problem is writing shell code is not my thing and especially for arm where its not documented as well.
Also could someone PM me with a cdb.exe thats signed for windows rt 8.1? the one provided with the old jailbreak is only signed for 8.
... You do realize the Protected Process flag is in the kernel, right? How do you plan to remove it when, in order to modify kernel memory, you would need to attach to a protected process? It's not like this is the RO flag on a file or something.
The whole point of Windows protected processes is to avoid letting somebody debug them even if they have full control over the machine (they were originally designed for DRM). In testsigning mode or with a kernel debugger, they usually won't launch at all (CSRSS will - it's critical for all Win32 processes, including stuff like Explorer - but the DRM ones won't). This isn't something Microsoft is going to just allow people to turn off. We could theoretically patch around the restriction with the aforementioned kernel debugger or with a testsigned kernel-mode driver, but if we could put RT into Testsigning or use a KD on it we wouldn't need anything else at all anyhow; either of those are sufficient for an easy jailbreak.
When thinking about breaking into the system, think about what you want to accomplish. Then identify attack vectors to get there. Then think about how those attack vectors might be blocked. Then think about how you might bypass those blocks. Etc... If you can't get at least as far as the fourth step, you won't accomplish much (certainly not against a target as hardened as Windows).
GoodDayToDie said:
... You do realize the Protected Process flag is in the kernel, right? How do you plan to remove it when, in order to modify kernel memory, you would need to attach to a protected process? It's not like this is the RO flag on a file or something.
The whole point of Windows protected processes is to avoid letting somebody debug them even if they have full control over the machine (they were originally designed for DRM). In testsigning mode or with a kernel debugger, they usually won't launch at all (CSRSS will - it's critical for all Win32 processes, including stuff like Explorer - but the DRM ones won't). We could theoretically patch around this with the aforementioned kernel debugger or with a testsigned kernel-mode driver, but if we could put RT into Testsigning or use a KD on it we wouldn't need anything else at all anyhow; either of those are sufficient for an easy jailbreak.
Click to expand...
Click to collapse
So just to clarify we can not use this undocumented API call that works in Win8.1 x64 on RT:
Code:
[DllImport("ntdll.dll", SetLastError = true)]
internal static extern int NtSetInformationProcess(IntPtr hProcess, int processInformationClass, ref int processInformation, int processInformationLength);
int enable = 0;
NativeMethods.NtSetInformationProcess(CSRSS.exe HANDLE, 29, ref enable, sizeof(int));
C# code of course but you could easily code in any language.
I don't see any way you can set the Protected Process flag this way... ProcessBreakOnTermination is not, so far as I know, in any way related (although CSRSS should have that flag set anyhow, and should have had it since before protected processes were even added to NT at all). If you could *set* the ProcessBasicInformation you could in theory overwrite the PEB, but supposedly that one is query-only (according to undocumented.ntinternals.net, which may be wrong). Also, you may find that you can't call OpenProcess with PROCESS_SET_INFORMATION on CSRSS, at least on RT 8.1. Worth trying though, perhaps...
GoodDayToDie said:
I don't see any way you can set the Protected Process flag this way... ProcessBreakOnTermination is not, so far as I know, in any way related (although CSRSS should have that flag set anyhow, and should have had it since before protected processes were even added to NT at all). If you could *set* the ProcessBasicInformation you could in theory overwrite the PEB, but supposedly that one is query-only (according to undocumented.ntinternals.net, which may be wrong). Also, you may find that you can't call OpenProcess with PROCESS_SET_INFORMATION on CSRSS, at least on RT 8.1. Worth trying though, perhaps...
Click to expand...
Click to collapse
Well apparently when passing an int (29) as the ProcessInformationClass value that indicates a protected process, and it does work for enabling it and disabling it on other processes so far, process acts like csrss once enabled. We have to make sure to set the SeDebugPrivilege flag on the current process in order to make OpenProcess open a process with the flag PROCESS_ALL_ACCESS which is required for NtSetInformationProcess.
Looking into this, might be worth a shot.
Interesting. MSDN for NtQueryInformationProcess (http://msdn.microsoft.com/en-us/library/windows/desktop/ms684280(v=vs.85).aspx) says that value is ProcessBreakOnTermination and indicates a "critical" process, which I interpreted to mean one that cannot be safely exited (there are a few of these, and have been since XP or before, while protected processes were introduced in Vista and "lightweight protected processes" (the kind that CSRSS is, apparently) were introduced in 8.1. Still, worth a shot.
Administrator should have SeDebugPrivilege, and *probably* have it enabled by default. I'm still not sure you will be able to open the handle to CSRSS - it's explicitly not supposed to be possible to mess with it even if you *are* Administrator (or otherwise have debug privs) - but it's worth trying.
EDIT: There's a policy in Local Security Policy Editor (secpol.msc, yes it's present on RT at least 8.0, if not on 8.1 it's in the registry anyhow), under Local Policies -> User Rights Assignment. You can control what privileges (in the NT Se*Privilege sense) processes owned by given users have. For example, "Debug programs" (This user right determines which users can attach a debugger to any process or to the kernel. Developers who are debugging their own applications do not need to be assigned this user right. Developers who are debugging new system components will need this user right to be able to do so. This user right provides complete access to sensitive and critical operating system components.). You can add "ALL APPLICATION PACKAGES" to the assignees. In theory, this would mean that app packages now have SeDebug. They *might* not be able to use it anyhow (because of the lowbox restrictions) but if they are, that removes the need to use a debugger to inject code into a desktop process running as Admin; just write a native app that calls the relevant APIs.
Great find, i'm away from my dev box until later today but i will try this out. I'm not use to finding the exploit, how ever i'm perfectly capable of writing code for one once its found. But ill dig deeper maybe powershell could still be a possibility.
Edit: Found a spreadsheet that documents all of the security registry keys for 8.1! I found Debug Programs flag for User Rights Assignment in the document for 8.1 and it says minimum requirement is Windows XP! So its most likely on 8.1, my dev box and surface are both on 8.1 so I can verify later I also have the registry key.
Also found load and unload device drivers flag, not sure if thats of any use.
Second Edit: "User Rights security settings are not registry keys" there is no registry key to edit so we would have to either use secpol.msc or figure out where these values are stored.
Is there any way for us to figure out how csrss is being flagged as a protected process? Is that done in the kernel, with its createprocess params or is it done by the process itself?
Also has anyone checked if they modified Powershell's exe to prevent unsigned C# code from executing? And if so we also should check if we can use an 8.0 copy on 8.1 worth a shot as well but i'm almost positive it will not execute because of the "Windows cannot verify the digital signature of this application."
It would help if we could at least get cdb or WinDbg working on 8.1 even if we can't attach it to csrss.
I PMd netham45 about how he got cdb working on 8.1 but he has not replied yet. I've checked the WDK 8.1 release and everything is there even for arm except cdb.
Edit:
Also i'm working with Spazzarama over at EasyHook to see how he wrote his Patchguard disabler. If I can get unsigned code running even if it means we need to use a dev id just to start the jailbreak like the original version of nethams tool it would be worth it if it means we can disable patchguard. I have a few ideas on how to go about this, possibly creating a blank app and compile it. Then disassemble the exe with ildasm and replace the entry point with code that includes desktop code, then stitch it back up with ilasm (command line args allow arm code creation and toggling app containers, as long as the tools that create an app package don't test command line args it should work ok and be valid because it wont load any desktop dll's if they are not called i've tested this on normal environments. Then we might be able to get desktop code running that will allow us to disable patchguard, modify the value and then remove the app.
Lots of me rambling on about that, hopefully we get somewhere.
Toxickill said:
Is there any way for us to figure out how csrss is being flagged as a protected process? Is that done in the kernel, with its createprocess params or is it done by the process itself?
Also has anyone checked if they modified Powershell's exe to prevent unsigned C# code from executing? And if so we also should check if we can use an 8.0 copy on 8.1 worth a shot as well but i'm almost positive it will not execute because of the "Windows cannot verify the digital signature of this application."
It would help if we could at least get cdb or WinDbg working on 8.1 even if we can't attach it to csrss.
I PMd netham45 about how he got cdb working on 8.1 but he has not replied yet. I've checked the WDK 8.1 release and everything is there even for arm except cdb.
Edit:
Also i'm working with Spazzarama over at EasyHook to see how he wrote his Patchguard disabler. If I can get unsigned code running even if it means we need to use a dev id just to start the jailbreak like the original version of nethams tool it would be worth it if it means we can disable patchguard. I have a few ideas on how to go about this, possibly creating a blank app and compile it. Then disassemble the exe with ildasm and replace the entry point with code that includes desktop code, then stitch it back up with ilasm (command line args allow arm code creation and toggling app containers, as long as the tools that create an app package don't test command line args it should work ok and be valid because it wont load any desktop dll's if they are not called i've tested this on normal environments. Then we might be able to get desktop code running that will allow us to disable patchguard, modify the value and then remove the app.
Lots of me rambling on about that, hopefully we get somewhere.
Click to expand...
Click to collapse
Have you tried the latest WinDBG that came with SDK 8.1? I'm using RT 8.0 so I cannot verify it, however it should work on RT 8.1 since it came with the 8.1 SDK
C\Program Files (x86)\Windows Kits\8.1\Debuggers\Redist
cdb is part of WinDBG
It's a flag passed to CreateProcess (presumably therefore also in NtCreateProcess), CREATE_PROTECTED_PROCESS. Only usable on binaries with a special Microsoft signature. It blocks most access to the process, causing an OpenProcess specifying those permissions to fail. http://msdn.microsoft.com/en-us/library/windows/desktop/ms684880(v=vs.85).aspx
EDIT: Creating a sideloadable app with desktop code is easy; we managed that over a year ago. The fancy/complex way of doing involves scanning the system libraries that are loaded into memory (using an allowed API, such as GetSystemTime() as a starting point) for the entry point of LoadLibrary, then calling that using a function pointer. The simple and straightforward way is to either modify the header files (which #ifdef out the relevant prototypes when compiling for WinRT) or just copy-paste those prototypes and definitions into our own headers, and then link against the relevant libraries (it's easy to extract .LIB files from DLLs). The latter approach has more initial time investment, and is probably easier to detect, but is "cleaner" (the source code looks exactly the same as would normally be used, aside from removing some checks in the headers) and slightly more performant on startup.
@LolitaPlus: The public debug tool downloads don't include ARM debugger binaries, so they won't run on RT...
They can debug ARM programs, but that's not sufficient for this purpose. Microsoft (and OEMs) have debugging tools that run on the devices directly, and they have leaked in the past; that's what's needed.
GoodDayToDie said:
It's a flag passed to CreateProcess (presumably therefore also in NtCreateProcess), CREATE_PROTECTED_PROCESS. Only usable on binaries with a special Microsoft signature. It blocks most access to the process, causing an OpenProcess specifying those permissions to fail. http://msdn.microsoft.com/en-us/library/windows/desktop/ms684880(v=vs.85).aspx
EDIT: Creating a sideloadable app with desktop code is easy; we managed that over a year ago. The fancy/complex way of doing involves scanning the system libraries that are loaded into memory (using an allowed API, such as GetSystemTime() as a starting point) for the entry point of LoadLibrary, then calling that using a function pointer. The simple and straightforward way is to either modify the header files (which #ifdef out the relevant prototypes when compiling for WinRT) or just copy-paste those prototypes and definitions into our own headers, and then link against the relevant libraries (it's easy to extract .LIB files from DLLs). The latter approach has more initial time investment, and is probably easier to detect, but is "cleaner" (the source code looks exactly the same as would normally be used, aside from removing some checks in the headers) and slightly more performant on startup.
Click to expand...
Click to collapse
Thats what i figured, for csrss, with the sideloadable app I was just wondering if it would be easier to do il modifications. But we are trying to get unsigned code anyway. Im home now and ill look into secpol.msc on my 8.1 tablet. It IS on my dev pc 8.1.
Edit:
Ok secpol.msc is available on my surface, and Debug programs is set to Administrators, what should I try modifying it to?
GoodDayToDie said:
@LolitaPlus: The public debug tool downloads don't include ARM debugger binaries, so they won't run on RT...
They can debug ARM programs, but that's not sufficient for this purpose. Microsoft (and OEMs) have debugging tools that run on the devices directly, and they have leaked in the past; that's what's needed.
Click to expand...
Click to collapse
I'm not talking about VS remote tools. I'm talking about WinDBG (version 6.3.xxxx, not the 6.2.xxxx) and it is on my Surface RT now.
Please correct me if you are not talking about this(WinDBG). If indeed that is what you want, give this link a try (I just uploaded it):
https://mega.co.nz/#!Rthz1aCC!chur33IsRLASnysWQOgNY9LJaeyv8oIsPaHDnwbuWCE
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