I have a request for an Android developer. I use Zotero for references, and would like to read my journals on my nook color.
Zotero uses an sqlite database to store all the information within zotero. Additionally it attaches pdf's and other documents to the citations in individual directories defined by a unique hashtag for each entry.
I am thinking about copying the entire reference directory, including all the pdf's and sqlite database from my computer to sdcard. Once there we could parse through the database, find articles with search based on the author name, publication year, and journal title. The file path location can be parsed directly from the database information and if integrated properly, should allow you to open the pdf with quick office or any other app just by clicking on it.
I would be able to willing to pay $10-20 for this kind of functionality depending on how difficult it would be to set up. Currently, I am setting up syncs with Evernote and Dropbox, but it just isn't the same.
Someone has already made clients for linux and windows which does basically what I mentioned previously, however it is designed in python. I know python, and would be able to integrate that with android if android-scripting had more advanced functionality, but I don't know java at all.
The linux / windows python based client : http://www.cogsci.nl/gnotero
Am also pretty interested in this. Seems odd to do it in python though, considering that zotero itself is written in java. But you can run python on android, you know. Check out http://code.google.com/p/android-scripting/
Hi all,
I'm sure this is in the forums somewhere, but due to the billion mentions of "registry" I haven't been able to locate it.
Is there a tutorial anywhere for programming the reading and writing of registry keys? I'd like to develop a UI to provide XDA members to adjust the Bluetooth services that are associated with each paired device to enable dual pairing on unlocked phones (I.E. a UI for this: http://forum.xda-developers.com/showthread.php?t=1517029)
Thanks,
Ben
It can't be done directly with C#, because there's no managed (.NET) API for registry access on the phone. Instead, you either need to call into a native DLL that you wrote and exposed through COM, or you need to call into an OEM DLL that calls an OEM driver for you. The first approach requires writing, or at least having access to, a native library written in C++. It will also run only with the permissions of the app, which is insufficient for writing to the registry on stock ROMs (unless elevated with something like HtcRoot or WP7 Root Tools 0.9). The second approach requires device-specific code and the ID_CAP_INTEROPSERVICES capability in its manifest.
For a simple app that uses the second approach, see my MultiTaskToggle app (linked in my sig). Note that this app only needs to read or write a single registry value, so that's how I wrote it. If you want to enumerate registry keys and values, you'll need to use the COM library approach for reading. There used to be a great set of COM libraries for "hybrid" managed/native apps, but most of them were never updated for Mango compatibility. The only one I know of that currently support registry access is used in Schaps' apps, Registry Editor and Advanced Config, and those tools are closed-source (although, with a .NET decompiler, you could probably figure out their APIs easily).
GoodDayToDie said:
It can't be done directly with C#, because there's no managed (.NET) API for registry access on the phone. Instead, you either need to call into a native DLL that you wrote and exposed through COM, or you need to call into an OEM DLL that calls an OEM driver for you. The first approach requires writing, or at least having access to, a native library written in C++. It will also run only with the permissions of the app, which is insufficient for writing to the registry on stock ROMs (unless elevated with something like HtcRoot or WP7 Root Tools 0.9). The second approach requires device-specific code and the ID_CAP_INTEROPSERVICES capability in its manifest.
For a simple app that uses the second approach, see my MultiTaskToggle app (linked in my sig). Note that this app only needs to read or write a single registry value, so that's how I wrote it. If you want to enumerate registry keys and values, you'll need to use the COM library approach for reading. There used to be a great set of COM libraries for "hybrid" managed/native apps, but most of them were never updated for Mango compatibility. The only one I know of that currently support registry access is used in Schaps' apps, Registry Editor and Advanced Config, and those tools are closed-source (although, with a .NET decompiler, you could probably figure out their APIs easily).
Click to expand...
Click to collapse
Perfect, that was all the info I needed. Thanks.
Ben
Hi folks,
I have just started exploring the prospect of Android Malware Analysis recently. As of now I have mostly done Static Analysis using tools like APKTool, APKManager, Dex2Jar, Jd-GUI. Cheers to people in the forum who have contributed with these tools and cleared the initial questions, that was really helpful.
Recently I was trying to analyze a malware that sends SMS to the C&C individuals, using the above mentioned tools I changed the C&C number which was hardcoded in the code to the port number of an emulator on my system. I was able to se the SMSes being diverted to the emulator.
I wanted to try something at the next level now, I was thinking of loading the apk in eclipse and putting breakpoints in the code so that I can catch the different activities. A scenario would be before the SMS is sent out of the app the code stops executing at my breakpoint so that I can view what is going on. Hoping that this feels similar to debugging an exe in OllyDBG. I hope I got my point right.
Right now I followed a number of tutorials online and imported the apk code onto eclipse. I have been following a tutorial highlighted here
http://kkinder.com/2011/11/27/so-you-want-to-reverse-engineer-an-android-app-apk/
So right now I have .smali code as well as java code ( which I am getting by opening the apk as a jar file in JD GUI and saving from there as mentioned in the tutorial). The problem is I am getting errors in every java file that I import in eclipse.
Is there a better and easier way to debug apk files on eclipse, or rather is there a tool which I can use to do something like adding breakpoints before an app sends out an sms for instance.
Pardon me for the long post but i thought ill provide as much information as possible so that you guys can help.
Thanks in advance :good:
Bump
skeptre said:
Hi folks,
I have just started exploring the prospect of Android Malware Analysis recently. As of now I have mostly done Static Analysis using tools like APKTool, APKManager, Dex2Jar, Jd-GUI. Cheers to people in the forum who have contributed with these tools and cleared the initial questions, that was really helpful.
Recently I was trying to analyze a malware that sends SMS to the C&C individuals, using the above mentioned tools I changed the C&C number which was hardcoded in the code to the port number of an emulator on my system. I was able to se the SMSes being diverted to the emulator.
I wanted to try something at the next level now, I was thinking of loading the apk in eclipse and putting breakpoints in the code so that I can catch the different activities. A scenario would be before the SMS is sent out of the app the code stops executing at my breakpoint so that I can view what is going on. Hoping that this feels similar to debugging an exe in OllyDBG. I hope I got my point right.
Right now I followed a number of tutorials online and imported the apk code onto eclipse. I have been following a tutorial highlighted here
http://kkinder.com/2011/11/27/so-you-want-to-reverse-engineer-an-android-app-apk/
So right now I have .smali code as well as java code ( which I am getting by opening the apk as a jar file in JD GUI and saving from there as mentioned in the tutorial). The problem is I am getting errors in every java file that I import in eclipse.
Is there a better and easier way to debug apk files on eclipse, or rather is there a tool which I can use to do something like adding breakpoints before an app sends out an sms for instance.
Pardon me for the long post but i thought ill provide as much information as possible so that you guys can help.
Thanks in advance :good:
Click to expand...
Click to collapse
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 tried to post this in the development forum, but I am not allowed.
I am tinkering with ARM architecture and Android device development and low level OS stuff. I am currently using QT C++ for Android for app development. This works great for all of my standard Android app development, but now I am digging deeper. I am doing an experiment where I have a small binary blob (64k) of ARM code that I want to load into memory at run time using mmap(). In order for this code to work, it needs to be loaded at address 0x22000000. In my C++ code i call mmap(0x22000000, ...) which would map the binary file to that address only if it were not in use already, which it is on a couple different android devices that I have tried, so it maps to another address, as it should by design. I tried using MAP_FIXED as a flag to mmap() and the application crashes, as expected, since mmap() overwrites memory that is already in use.
In order for mmap() to map the binary file to the address I want, I believe that I can do some sort of advanced Android / Kotlin / gradle level compile time linking modifications in order to make sure that the area of memory (the whole page at least I imagine) that I want to mmap() to is unused when execution reaches my C++ code that calls mmap(). I don't know the android build system very well though, so I hope some Android experts can help me. I am not trying to access real physical RAM though, only address 0x22000000 in the processes virtual address space. Because of this, I believe that with some custom hackery can be done during linking to modify the areas of RAM that are assigned for program/stack/etc use. I believe I am looking for the equivalent of LD script customization for standard GCC C/C++ compiled software, and possibly some direction on how to manipulate.
I have successfully done this on a raspberry pi running raspbian via a command line C++ application, as well as an x86_64 Fedora system using an x86_64 binary blob. In both cases I got lucky that the area of memory was not in use, so mmap() succeeded and I was able to execute the code as desired.