Database Info

[Q] Custom Device driver / KernelLibrary

Good day,
I am new to the forum so please forgive me if this is not the right place to ask.
I have been reading through some of the threads on the forum and is curious to know if there is a way to load custom kernel libraries or device drivers onto the phone.
If there is a way, is there a correct procedure? For example to load a custom device driver / kernel library, do I also have to have an entry in the registry? Does the dll file have to be in /Windows?
Thanks in advance.

Good questions. There's been only a little research on this so far. I can tell you waht I've found, though:
For a stock ROM, nobody has managed it yet, but it might be possible. You'll need to have your DLL signed, and the certificate added to the Code Integrity store on the phone (just mailing yourself the .cer is insufficient! That will put it in the wrong store). You'll probalby want the DLL to be in \Windows, although I'm not sure it's needed. You almost certainly will need to add registry entries; the current drivers seem to have them.

Good day,
thanks for your reply. And thanks for all the good research you have done.
So at the moment, the software approach is not working but for custom roms, is it possible to include custom device drivers / kernel libraries in them?
Thank you.

mousefish321 said:
Good day,
thanks for your reply. And thanks for all the good research you have done.
So at the moment, the software approach is not working but for custom roms, is it possible to include custom device drivers / kernel libraries in them?
Thank you.
Click to expand...
Click to collapse
Well, it's possible. The HD2 Multitouch driver is an example that its somehow possible. Should be the same for the other devices (espacially HTC first gens)...
But don't know what you're getting at? Why would you need a custom driver?

Good day,
well, I just think that having a driver that acts like HTCUtility would make things convenient.
As for file operations, besides the application that Heathcliff has created (WP7RootTool), are there other applications that can do write operations to the /Windows folder?
What are the things that needs to be done before we can write to that folder?
Thank you.

Any app with Elevated or TCB privileges can write to \Windows, I think. Using HtcRoot project or WP7 Root Tools works (both elevate apps to TCB permissions, though using different methods). Also, using an OEM driver, such as HtcProvisionDrv or HtcFileUtility, works (although those two particular drivers were crippled in the 4.x firmware).

Good day,
thanks for the information. I tried the HtcRoot tool and it works. Thanks for the tool and the source that allows me to know how it works.
Can I assume that I would be able to have write access to the Certificate and Code Integrity store also?
I am also curious as to the workings of HTCFileUtility. A quick search on this turns up little information on its workings.
Furthermore, is there a guide to inserting custom certificates to the root Certificate and Code Integrity store? I have tried downloading the Certificates.zip file in http://forum.xda-developers.com/showthread.php?t=1236027 and test rom files in http://forum.xda-developers.com/showthread.php?t=1248799 hoping that they will shed some light but is unable to download them.
Any help is appreciated. Thank you.

Yes, installing your own cert into Code Integrity is possible (in several ways, actually, but I did it using HtcRoot just as an exercise). The certificates are actually stored in the registry, so any tool that can write to HKLM can add them. I believe that WP7 Root Tools will also let you choose the store for adding a certificate if you "open" the cert from the Root Tools filebrowser.
Although I don't know exactly how HtcFileUtility works, here's the basics. It's a software driver that exposes an interface - probably an IOCTL - which apps can use to perform filesystem operations. Since it runs with TCB permissions (it's probably kernel mode, though I haven't actually checked, but it's definitely in TCB) it can perform any operation that the filesystem supports. Of course, that doesn't mean that it exposes all those operations through the IOCTL... but it exposes enough of them for a pretty solid filebrowser implementation (that's how TouchXplorer and Advanced Explorer worked, although they used an OEM COM DLL that called into the driver rather than doing the IOCTL themselves).
The new version of it has very limited operations permitted; it will only list files in a few folders and so forth. It does still "work" within those limitations - Connection Setup, for example, uses it to check the folder that we use for interop-unlock on HTC - but it isn't useful for a general-purpose browser anymore.
It would be great to even figure out how to roll back the OEM drivers to earlier versions. For example, I've got WP7 Root Tools installed on my HD7, but I don't want to install HTC updates because they'll break my drivers such that if something ever goes wrong I won't be able to re-install Root Tools, or if a new hack is found (or developed; I'm working on some stuff with HtcRoot still) I won't be able to run it on my phone. Being able to use the advantages of the new firmware (Internet Sharing, compass in managed apps, hopefully an end to the damn music player freezing between songs...) while still having hackable OEM drivers would be reallllly nice...

Good day,
thanks for the information.
I noticed in the HTCRoot project thread where you mentioned that "It is not a true handle (no handle table, no handle data) but everything that checks for tokens also checks for this const value, and appears to pretty much skip all remaining permissions checks if it finds it".
Would you mind sharing some of the function names so that I could take a look at the code where the checking occurs?
Thanks.

[TOOL] ApkSpy v1.8 - Resurrected (APK: view manifest on PC and/or Install APK via PC)

APKSPY - RESURRECTED​
First:
I want to thank @ido for the original application -- It was his idea (and his code I've hacked :cyclops and modified.
Second:
Since Ido seems not to be active anymore I'll re-publish the application here.
Unless for some reason Ido will specifically ask me to remove it.
The original post
ido said:
ApkSpy is a simple tool I hacked up tonight which allows you to easily view the manifest of an APK (screenshots attached - not up to date though) just by double clicking it. (It can even associate with the .apk filetype, yay!)
ApkSpy relies on the aapt.exe tool from the android SDK, so you must have that installed (or just copy aapt.exe from somewhere, that's the only file needed to run ApkSpy).
Click to expand...
Click to collapse
Third:
Requires Microsoft©® .Net Framework v4
(Kind of since I've done it some time ago and waited for Ido [the orignal developer] to respond and allow or disallow me to re-publish... So, I don't remember all the changes I've already done...)
v1.8.19 CHANGELOG:
Fixed some Date parsing function (zipped file with no time stamp) in ZipStorer (by @Jaime Olivares) maybe causing some of the error reported here...
v1.8 CHANGELOG:
Changed Icon - CONTRIBUTED BY @Jarmezrocks
Removed unneeded tabs (System, Batch Rename, Log)
Minimize / Maximized restored back
v1.7 CHANGELOG:
(Actually 4.1.7.870, but the first and the last parts are internally used :fingers-crossed:)
Try to automatically find adb.exe and aapt.exe in ApkSPY directory or in PATH variable: If failed finding any of the executables, the user is asked to manually locate them
(★ Currently the location is not saved... ★).
Check if the ADB server is running and Start or ask if to Restart ADB server
Tidy up the code
Refining the original libraries written by Ido related to ADB and AAPT
Some more minor code updates
Revised most of the "General" tab (other tabs ware not touched) of the UI:
Grouped and ordered controls on form
Added DropDown of devices attached (★ Not automatically updating upon plugging... ★)
Added some control over ADB actions
Added status bar that some other details are shown, e.g. device type (Nexus, I9100...), OS version (4.1.2, 4.4.2...) and OS build (KOT49H, KVT49L...)
Added (nice looking) information panel with clickable links (for actions on the form) and coloring
Other changes (I can't recall right now, since I've done it some time ago and waited for a response from Ido for permission to republish)
(★ Maybe I'll add an option for this later, depending on my -- not to much -- free time and requested by users .... ★)
Known bugs:
Sometimes ADB fails to return build.prop property for the status bar (however it has not caused any critical problem, so (I think) it can be safely ignored) -- haven't been able (yet) to find the exact state it is happening
Please take the time to look at the application ABOUT tab
Any Other ideas are welcome!
If you like it, Don't forget to Thank me
If you enjoy using this application as much as I have enjoyed re-writing it
please donate to show your appreciation​

RESERVED

Nice
Sent from my SM-N900T using Tapatalk

Good news
Bug report, every time I open this program, this dialog pops up, after click OK, this program works well.
PS, aapt.exe is in the same dir with ApkSpy

I got this errors:
1:
2:
Error in property: [email protected]@usrdata

cmlx said:
Good news
Bug report, every time I open this program, this dialog pops up, after click OK, this program works well.
PS, aapt.exe is in the same dir with ApkSpy
Click to expand...
Click to collapse
Hey dude,
I am not sure what you are doing wrong on your PC but it's certainly not the app as it works perfectly fine on my computer? Out of interest and for the sake or helping the new dev I thought I would raise a few points just to eliminate any finger pointing. There's a wishy-washy area when it comes to building/hacking things that were originally someone elses work...so yeah one can easily make great improvements yet open the door to bugs at the same time too. Anyway...thought I'd ask this:
Does aapt sit on your path? I know you said it is in the same directory, however just like a batch script in Windows it needs to "CD" or change directories to the %~dp0 if it is to understand what an executable is that happens to be sitting in the same directory as it's self. So this is is kinda directed at the new dev now. What I think is happening is that aapt is assumed to be in the system path when quite often it is not (i.e. those on XDA who have not yet played with the Android SDK properly). Put simply unless the application knows it is in the same directory as your executable it won't at all understand what aapt is. Does that make sense?
@dmagician , I would make sure that the apkspy app can do a check (even if it is a string search for the first few lines returned from aapt.exe), a simple if statement before throwing that error ....actually it would likely be an 'if not' statement. I don't have any of the code in front of me atm but I can help you out if you like? I was hacking this app myself sometime ago when ido first released it just using reshacker.
Note: If you are stuck and don't have source code you technically could write a full AutoIT wrapper for this app that could do all the checks and more and then bundle everything up into the one exe still. Check out the newer WinAPI stuff for AutoIT and in particular "Run binary" (yes that's correct you can just about run anything repackaged now and not need to deploy the original exe's or even libraries....they can all be stream fed to AutoIT @Compile time and need not be typically "installed" like you used to have to do. Anyway...I am waffling on shoot me a PM man.
@cmlx, to overcome your ApkSpy woes, and until dmagician can put his finger on what the cause is or what ido did when building it ages ago.....then you will firstly need to be patient (props to dmagician to figuring sh!t out so far) but till then where ever you have dumped the ApkSpy and aapt.exe on your system; just copy the address and put it on your system path. To do this 1) right click on My Computer or Computer if you are on Win 7 or 8. 2) Choose properties. 3) Advanced System settings and then at the bottom of tab you will see 'Environment Variables', click it and you will see some "User" and "System" options. Depending on your User access rights on the system you are running on (hopefully you are running as Admin surely?) then you can choose to edit your main system path or create a new variable in your user settings called 'path' Note User variables are always postfix to system variables but should always work anyhow.
Disclaimer: cmlx, if however you have already got an aapt.exe already existing on your system path but it is dodgy then you have to ensure that the good aapt.exe in your app directory is placed on path BEFORE the dodgy one....just sayin. Cause your system searches till it finds what it wants and then doesn't search anymore. Simple but can stuff people up quite often....and likely your case. Nowdays we tend to work from the known application location and not from a "Global environment path" when we know that there are going to be conflicts...and I can assure you that aapt is possibly the worst and most modified binary out there LOL. Hence this is also a note to the dev to ensure that ApkSpy reads from the current directory.....or like I am suggesting, wrap aapt up in the main application as well and that way there is no confusion EVER.
And I am done.....
Oh wait no I am not....sorry bug reports LOL :good: you thought I was all praise eh? Got another thing coming man
OK....so um the red boxes should explain everything. A picture says a thousand words (and yeah I needed at least 1 picture for this god damned long arsed post - sry). Um why in gods name would you remove the minimise and expand buttons? WTF? Anyway...it works but errrm yeah it doesn't wrap the text anymore? and it cuts the words off lol.
Other than that....I only really have one suggestion and it isn't even really a suggestion as I have kind of already made it so I can just give it to you if you want it? And that is that most people (well I can't say most as I am not speaking for everyone) tend not to like how apps take over their system. This isn't your fault at all in anyway as the first dev thought it was a good idea back then.....and back then hardly anything in Windows knew what a freakin apk was so it was a GOOD thing.....However now, every man and his dog wants to steel .apk extension for himself. I myself tend to be all over the shop with apks so I tend not to want to have any particular Windows app take it away from my control. I use WinZip as the main app for simple double click open as I want to see the contents of apks without needing to decompile them (great for theming) however I have apk shell extensions displaying the apks main icon to explorer, so if I set WinZip as default I get a nice lumping hunk of gold turd/box running rampet all over my Windoze bro ......so if you like I can show you my code that allows me to have default apps for specific tasks without interfering with anyones existing sh!t It looks neat too as you can right click any apk and just choose from a dropdown list what particular app you want at the time. If one has the need to use more apps then they need only put those apps in a list. There is nothing worse than double clicking an apk to find that Bluestacks or some other rubbish Windoze crApp has taken offf with your apk.
Lastly I thought I'd ask, Why no config file? Why store everything in memory? I know it's only small....but seeking for things everytime it is executed is a pain in the arse and not good practice. At the very least if you have no idea how to make an exe totally portable then you could reference a config file in the same directory....Or do as most do and write entries to the registry all neat and tucked away. If we get paranoid about "portable-ness" then we write to temporary space in the registry and make sure we clean up upon closing and/or inspect at runtime. simple!
I have plenty of AutoIT scripts that do exactly that too, so if you are stuck for ideas let me know. Anyway I have rambled enough, good luck and I will keep reporting bugs haha
Edit: That's waaaay too many emoticons. Oooops someone is a little high aren't they?
PS: I have attached my PNG of the icon I used for this bugger waaaaaay back....it's less generic and feel free to take it and abuse it and do as you please.

cmlx said:
Good news
Bug report, every time I open this program, this dialog pops up, after click OK, this program works well.
PS, aapt.exe is in the same dir with ApkSpy
Click to expand...
Click to collapse
Yes, I know of this one (and I've specifically wrote about it in the OP), it is NOT related to AAPT executable but to the way ADB is acting (sorry, out of my hands... :angel:
Explanation
The error comes from the application when trying to query the "ro.build.id" property via adb ('ADB shell getprop "ro.build.id" ') command.
I've came across this one but cannot determine the exact situation it is happening (as it can occur when first launching of the app, but after the app is loaded, clicking on refresh does not show this error)...
[ I've tried it on with the (only) two devices I own (1st dev. is stock (only the kernel is changed) 4.4.2 Nexus 4, 2nd dev. is S2-i9100 with customized RR ROM)and it seems to happen ONLY on the S2...]
It looks that in times, the getprop is being executed before the whole "build.prop" is being processed by ADB (This one I cannot control since it is happening on the ADB shell side [running on the device] -- unless MAYBE doing some [UGLY] delay after first initialization of ADB, which is, by far NOT best practice of process handling according to the literature)...

CyberianIce said:
I got this errors:
1:
2:
Error in property: [email protected]@usrdata
Click to expand...
Click to collapse
Which came first, the "SpkSpy spy stopped working" or the "Error in property" (if anyways related)?
Was it on the same run or two different runs?
As of the 1st one:
I do not have enough information from your post to check it up...
I'll post a new version which shows the exception details
As of the 2nd one:
Can you send me a copy of your /system/build.prop (so i'll be able to dig trough it and check it)?
It looks like my name-value splitter character exist as part of a given value in your build.prop .

Wooow, Long one! But it is nice to know people are using (trying) it!
Jarmezrocks said:
Hey dude,
I am not sure what you are doing wrong on your PC but it's certainly not the app as it works perfectly fine on my computer? Out of interest and for the sake or helping the new dev I thought I would raise a few points just to eliminate any finger pointing. There's a wishy-washy area when it comes to building/hacking things that were originally someone elses work...so yeah one can easily make great improvements yet open the door to bugs at the same time too. Anyway...thought I'd ask this:
Does aapt sit on your path? I know you said it is in the same directory, however just like a batch script in Windows it needs to "CD" or change directories to the %~dp0 if it is to understand what an executable is that happens to be sitting in the same directory as it's self. So this is is kinda directed at the new dev now. What I think is happening is that aapt is assumed to be in the system path when quite often it is not (i.e. those on XDA who have not yet played with the Android SDK properly). Put simply unless the application knows it is in the same directory as your executable it won't at all understand what aapt is. Does that make sense?
Click to expand...
Click to collapse
Hi
As I've replied to @clmx, This error is not related to AAPT (either executable [location or whatever] or results), but to the ADB command being used...
Jarmezrocks said:
@dmagician , I would make sure that the apkspy app can do a check (even if it is a string search for the first few lines returned from aapt.exe), a simple if statement before throwing that error ....actually it would likely be an 'if not' statement. I don't have any of the code in front of me atm but I can help you out if you like? I was hacking this app myself sometime ago when ido first released it just using reshacker.
Click to expand...
Click to collapse
Sorry I did not understand... Check for what?
Jarmezrocks said:
Note: If you are stuck and don't have source code you technically could write a full AutoIT wrapper for this app that could do all the checks and more and then bundle everything up into the one exe still. Check out the newer WinAPI stuff for AutoIT and in particular "Run binary" (yes that's correct you can just about run anything repackaged now and not need to deploy the original exe's or even libraries....they can all be stream fed to AutoIT @Compile time and need not be typically "installed" like you used to have to do. Anyway...I am waffling on shoot me a PM man.
Click to expand...
Click to collapse
I do not need the Auto-IT to wrap these files (although I am using it for other automation in windows), as I can do it right in the C# code (on one of my early versions these files was embedded...)
BTW, I know there are some antiviruses out in the wild that do not like the embedded executables -- but it can be done -- and probably will save some time to anyone using this app...
If it will be required / asked, I'll embed the 4 binaries (AAPT.EXE, ADB.EXE, and two DLL's AdbWinApi.dll and AdbWinUsbApi.dll [I'm not sure both are required]) needed by the application.
Jarmezrocks said:
@cmlx, to overcome your ApkSpy woes, and until dmagician can put his finger on what the cause is or what ido did when building it ages ago.....then you will firstly need to be patient (props to dmagician to figuring sh!t out so far) but till then where ever you have dumped the ApkSpy and aapt.exe on your system; just copy the address and put it on your system path. To do this 1) right click on My Computer or Computer if you are on Win 7 or 8. 2) Choose properties. 3) Advanced System settings and then at the bottom of tab you will see 'Environment Variables', click it and you will see some "User" and "System" options. Depending on your User access rights on the system you are running on (hopefully you are running as Admin surely?) then you can choose to edit your main system path or create a new variable in your user settings called 'path' Note User variables are always postfix to system variables but should always work anyhow.
Disclaimer: cmlx, if however you have already got an aapt.exe already existing on your system path but it is dodgy then you have to ensure that the good aapt.exe in your app directory is placed on path BEFORE the dodgy one....just sayin. Cause your system searches till it finds what it wants and then doesn't search anymore. Simple but can stuff people up quite often....and likely your case. Nowdays we tend to work from the known application location and not from a "Global environment path" when we know that there are going to be conflicts...and I can assure you that aapt is possibly the worst and most modified binary out there LOL. Hence this is also a note to the dev to ensure that ApkSpy reads from the current directory.....or like I am suggesting, wrap aapt up in the main application as well and that way there is no confusion EVER.
Click to expand...
Click to collapse
The application IS searching for AAPT and ADB executables; The order is
Application directory (where ApkSpy.exe resides)
PATH environment variable
Jarmezrocks said:
OK....so um the red boxes should explain everything. A picture says a thousand words (and yeah I needed at least 1 picture for this god damned long arsed post - sry). Um why in gods name would you remove the minimise and expand buttons? WTF?
Click to expand...
Click to collapse
Mostly I like it this way, otherwise - No specific reason...
It will be back in the next version...
Jarmezrocks said:
Anyway... it works but errrm yeah it doesn't wrap the text anymore? and it cuts the words off lol.
Click to expand...
Click to collapse
This Tab was NOT changed by me in any way... To be honest, I've thought of removing it completely -- But -- out of respect to Ido's work -- I've left it in.
I assume it is not wrapping due to Font size changed by me globally...
I'm seriously giving it second thoughts -- if it should stay at all (It was originally meant for batch rename of multiple APK's... I haven't used it even once...)...
I'm Really, REALLY, think of removing it completely (unless someone is / will be using it -- then I'll fix it all)...
Jarmezrocks said:
Other than that....I only really have one suggestion and it isn't even really a suggestion as I have kind of already made it so I can just give it to you if you want it? And that is that most people (well I can't say most as I am not speaking for everyone) tend not to like how apps take over their system. This isn't your fault at all in anyway as the first dev thought it was a good idea back then.....and back then hardly anything in Windows knew what a freakin apk was so it was a GOOD thing.....However now, every man and his dog wants to steel .apk extension for himself. I myself tend to be all over the shop with apks so I tend not to want to have any particular Windows app take it away from my control. I use WinZip as the main app for simple double click open as I want to see the contents of apks without needing to decompile them (great for theming) however I have apk shell extensions displaying the apks main icon to explorer, so if I set WinZip as default I get a nice lumping hunk of gold turd/box running rampet all over my Windoze bro ......so if you like I can show you my code that allows me to have default apps for specific tasks without interfering with anyones existing sh!t It looks neat too as you can right click any apk and just choose from a dropdown list what particular app you want at the time. If one has the need to use more apps then they need only put those apps in a list. There is nothing worse than double clicking an apk to find that Bluestacks or some other rubbish Windoze crApp has taken offf with your apk.
Click to expand...
Click to collapse
The application is NOT taking over anything, Unless you've clicked the asterisk ("*") button on the System Tab...
Was it registered for you without clicking this button?
If so, I'll recheck the code (may be it's some residue from the original code).
BTW
As the previous part of the answer I've wrote -- this one was left in as of respect to @ido's work...
2nd BTW
I'd like to see that explorer extension (and [preferable] the code of it - if you are willing to share it) you ware writing about...
Jarmezrocks said:
Lastly I thought I'd ask, Why no config file? Why store everything in memory? I know it's only small....but seeking for things everytime it is executed is a pain in the arse and not good practice. At the very least if you have no idea how to make an exe totally portable then you could reference a config file in the same directory....Or do as most do and write entries to the registry all neat and tucked away. If we get paranoid about "portable-ness" then we write to temporary space in the registry and make sure we clean up upon closing and/or inspect at runtime. simple!
Click to expand...
Click to collapse
Yep, I've thought of it... But... I was thinking, that (at least) everyone is as geeky as me dauuh , and the most are setting the path correctly...
It'll be added in next version (I hope... TIME, TIME!!!! :cyclops...
Jarmezrocks said:
I have plenty of AutoIT scripts that do exactly that too, so if you are stuck for ideas let me know. Anyway I have rambled enough, good luck and I will keep reporting bugs haha
Click to expand...
Click to collapse
I prefer writing my own code (sorry, I'm a developer in heart and soul...) then using automation like Auto-IT...
Jarmezrocks said:
Edit: That's waaaay too many emoticons. Oooops someone is a little high aren't they?
Click to expand...
Click to collapse
Jarmezrocks said:
PS: I have attached my PNG of the icon I used for this bugger waaaaaay back....it's less generic and feel free to take it and abuse it and do as you please.
Click to expand...
Click to collapse
(@Jarmezrocks please see my PM to you.)
PHEW...
Long Answer, BUT HEY, I'm not the only one writing longies... :angel: (and i like referencing each and every part separately)...

dmagician said:
PHEW...
Long Answer, BUT HEY, I'm not the only one writing longies... :angel: (and i like referencing each and every part separately)...
Click to expand...
Click to collapse
Ahh yes. I write long messages sometimes when my medication has kicked in and I am high....not my fault I kinda need to get all the info out of my head in one go while I am awake.....or else there would just be zeds on the response zzzzzzzzzzzzzzzzzzzzzz lol :laugh: (ref narcolepsy).
I commend you on your efforts at responding to such gibberish and making good sense of it! :highfive:
I have responded to your PM accordingly, and hopefully covered all you need? I have attached all info and sources etc.....well most of it...actually a fair bit of it you will have to workout your self but that is part the fun. Shoot me any questions if you need to...although I have a feeling that you will have mostly all of it covered as you are streets ahead of my knowledge already. I may have misjudged a little in my previous post (although hopefully not to make you feel any less than you actually are? please excuse me if I had said anything that may offended - being naive or what ever....you ARE definitely on the right track). As for the middle menu....I think you could easily remove it and not offend the original dev. It wasn't being used as you mention...and I think it could make way for more/better functionality don't you think? (discuss). However I would ensure all the things I mentioned in my PM first before going too deep and releasing on here.
Good move on bringing the buttons back. They were functional. But I DO like the single button close GUI myself on just about everything else....It looks clean. We have similar taste in that regard. It just isn't functional for me to pressing the task notification desktop link everytime I want to minimise the app LOL.
The rest I we can discuss via PM, this is pretty much only posted here as an open area for other forum members to provide input and opinion (or complaint....like how often it usually is, eh?).

CyberianIce said:
I got this errors:
1:
2:
Error in property: [email protected]@usrdata
Click to expand...
Click to collapse
I'd got the same error!
For me it helped to copy two files to the install dir
"adb.exe" and "AdbWinApi.dll"
Both are installed with the well known MyPhoneExplorer into "Program Files\MyPhoneExplorer\DLL"
Hope it helps!

Feature Request
I use this tool for testing new APK builds on a project I am working on it. It allows me to quickly verify the version number and push to the device. However, since I am usually installing another version of an existing installed APK, I must manually uninstall before using APKSPY. Would it be possible to add a check box that would uninstall any previous versions? It would be really helpful.
Nevermind - I didn't fully read the message presented when it fail. It say uninstall/update and it allows the installation. HOWEVER, that brings up a question... Does it uninstall or does it update? There is a difference as you know.
Thanks,
Jonathan

Hi, I try to run this on Mac via Wineskin Winery, but no luck. Do I need something like .Net, or something else to run ApkSpy?
Thank you.

Ja_som said:
Hi, I try to run this on Mac via Wineskin Winery, but no luck. Do I need something like .Net, or something else to run ApkSpy?
Thank you.
Click to expand...
Click to collapse
The only requirement is the Microsoft .Net 4.
(I'll add this to OP)

jmo said:
I use this tool for testing new APK builds on a project I am working on it. It allows me to quickly verify the version number and push to the device. However, since I am usually installing another version of an existing installed APK, I must manually uninstall before using APKSPY. Would it be possible to add a check box that would uninstall any previous versions? It would be really helpful.
Nevermind - I didn't fully read the message presented when it fail. It say uninstall/update and it allows the installation. HOWEVER, that brings up a question... Does it uninstall or does it update? There is a difference as you know.
Thanks,
Jonathan
Click to expand...
Click to collapse
Yes I know there is difference between the two (update vs uninstall and install again).
It is updating the application (like using "adb install -r apk_file_name.apk"), not doing remove and install

Removed unneeded tabs (System, Batch Rename, Log)
Click to expand...
Click to collapse
The unneeded Batch Rename tab was the only tab I needed really. :laugh: Luckily I found Ido's original version. It's ideal for renaming all those apk's I downloaded and still have the package name when I back them up to my PC.
I have an Asus Memo Pad 10 and an Asus Memo Pad 7 and neither are recognised by APKSpy. Not that it's a problem as I have no problem copying to and from them with Windows Exploder or Total Commander.
Other than that, it's been a handy little app for this tablet/smartphone virgin newbie.
Martin.

wolrik said:
The unneeded Batch Rename tab was the only tab I needed really. :laugh: Luckily I found Ido's original version. It's ideal for renaming all those apk's I downloaded and still have the package name when I back them up to my PC.
I have an Asus Memo Pad 10 and an Asus Memo Pad 7 and neither are recognised by APKSpy. Not that it's a problem as I have no problem copying to and from them with Windows Exploder or Total Commander.
Other than that, it's been a handy little app for this tablet/smartphone virgin newbie.
Martin.
Click to expand...
Click to collapse
Hello.
1st:
I can -- if requested - re-add the Batch rename.
2nd:
I don't know why these two devices are not being recognized -- unless not being recognized by ADB itself -- since I'm spawning devices by parsing the resulting text of "ADB devices" command, So unless being unrecognized by ADB, there should be NO PROBLEM detecting ANY android device with ADB on...
if you have any exception messages thrown by the application, please post them here.

dmagician said:
Hello.
1st:
I can -- if requested - re-add the Batch rename.
2nd:
I don't know why these two devices are not being recognized -- unless not being recognized by ADB itself -- since I'm spawning devices by parsing the resulting text of "ADB devices" command, So unless being unrecognized by ADB, there should be NO PROBLEM detecting ANY android device with ADB on...
if you have any exception messages thrown by the application, please post them here.
Click to expand...
Click to collapse
No need to re-add the tab just for me, but thanks for the offer. As I get to know my way around Android I'll probably need such things less and less.
Sorry, but I know nothing about ADB other than APKSpy needing it. As you can see from the attached pic, the Asus is recognised by Total Commander
Martin.

Hi dmagician,
Nice work, and a shout-out to Ido who originally created it.
I have a feature request:
Could you add the option to remove certain permission(s) and save the modified APK file?
There are many apps which I feel allow themselves way too much permissions, and this option could be very useful to tame them apps.
One more thing:
I noticed that APKSpy v1.8.2 doesn't work with the latest version of AAPT.exe (1432KB), from the Android SDK r24.
So I had to use a previous version of AAPT.exe (833KB), which worked.
Thanks,
Eric

Hey does anybody know where the name of the apk is in the XML files inside the apk?

8.1 Jailbreak (not typical)

Salutations folks,
Before you get ready to get your flame on, I'm NOT asking about the STATUS of a RT Windows 8.1 Jailbreak. I'm posting about jailbreaks in general. I'm from a linux/android background. I got an Asus Vivotab RT LTE (AT&T version) for a steal off 1Sale. Before I even looked into doing anything with my tablet, I updated it to 8.1. Then I finally got around to looking into running desktop apps on Windows RT (not knowing how it all worked with RT vs desktop), I ran into the issue of not being able to run them (duh, right?). Then I found out about jailbreaking. So.. do you HAVE to jailbreak to run desktop apps? As I understand it, we currently have to run 8.0 to jailbreak/run desktop apps, yes? Well.. I obtained the Asus recovery files to downgrade my 8.1 to 8.0. On a whim, I updated my 8.1 with the 8.1 big spring update (basicly 8.1.1). I seem to be able to run some of the ported desktop apps without any problem. Am I missing something? How'd my tablet manage that without having run the jailbreak? And jailbreak doesn't work on 8.1 anyways? Before anyone says I'm full of it.. (you can click the thumbnail for full pic)
(windows rt 8.1 with 8.1 spring update installed)
(windows rt 8.1 running desktop 7zip)
(windows rt 8.1 running desktop putty)
(windows rt 8.1 running desktop notepad++)
Can anyone clarify if I'm missing something or I've come across an anomaly or even a blessed relief?
Thanks.

This is sure amazing
1. Can you run *any* unsigned application or only a few work (and the rest throw signature errors?)
2. Check the status of Secure Boot in PowerShell. Run as admin, "Get-SecureBootPolicy", press enter (http://technet.microsoft.com/en-us/library/jj603043.aspx)
3. Could you detail exactly your process? I understand that you did the following:
(On 8.1) Run unsigned desktop app, fail with digital signature error.
(Downgrade) Downgrade to 8.0 -> (On 8.0) Run Jailbreak -> Run Desktop Apps and they work.
(Upgrade) Upgrade to Windows RT 8.1 (via Store?) -> Upgrade to 8.1.1 (Spring Update) via Windows Update -> Run Desktop Apps and they work (partly or all of them?)
4. I'm not sure if it'd be any useful, but perhaps you could look in your EFI system partition (mountvol S: /s) as there has been a previous report of Asus leaving debug tools in VivoTab RTs before (http://forum.xda-developers.com/showthread.php?t=2477285). If you could retrieve a "debug" version of Secure Boot Policy from your EFI partition then it means that Secure Boot has just disabled itself on your tablet. It's highly unlikely, however, since you weren't able to run desktop apps in your original 8.1 install...

jimmielin said:
This is sure amazing
1. Can you run *any* unsigned application or only a few work (and the rest throw signature errors?)
Click to expand...
Click to collapse
I only grabbed the ported Putty, 7zip and Notepad++ desktop apps as those were the only ones that I was needing.. Oh I recently grabbed the FileZilla one too. All ran without any problems and never got any signature errors. Hell.. even my 7zip integrated into the shell and replaced archive icons with 7zip archive icons and opens my archives by default with the desktop app. Were there any particular applications you wanted me to try so that I can see if I can replicate any signature errors?
jimmielin said:
Check the status of Secure Boot in PowerShell. Run as admin, "Get-SecureBootPolicy", press enter (http://technet.microsoft.com/en-us/library/jj603043.aspx)
Click to expand...
Click to collapse
SecureBoot is enabled and it displays a Publisher GUID. Confirm-SecureBootUEFI confirms SecureBoot is enabled too.
jimmielin said:
3. Could you detail exactly your process? I understand that you did the following:
(On 8.1) Run unsigned desktop app, fail with digital signature error.
(Downgrade) Downgrade to 8.0 -> (On 8.0) Run Jailbreak -> Run Desktop Apps and they work.
(Upgrade) Upgrade to Windows RT 8.1 (via Store?) -> Upgrade to 8.1.1 (Spring Update) via Windows Update -> Run Desktop Apps and they work (partly or all of them?)
Click to expand...
Click to collapse
hmm
- Received clean OEM install Vivotab RT LTE with RT 8.0
- Upgrade to Windows RT 8.1 via Store
- (attempted to run some ported desktop apps, received error)
- was going to downgrade back to 8.0 after getting Asus recovery files but instead..
- Upgrade to RT 8.1.1 (Spring Update) via Windows Update
- (attempted to run some ported desktop apps, ran successfully, no errors)
NOTE: Not once had I ever gotten around to downloading or installing the Jailbreak. Is there some way to confirm if I have the jailbreak installed at startup or something?
jimmielin said:
4. I'm not sure if it'd be any useful, but perhaps you could look in your EFI system partition (mountvol S: /s) as there has been a previous report of Asus leaving debug tools in VivoTab RTs before (http://forum.xda-developers.com/showthread.php?t=2477285). If you could retrieve a "debug" version of Secure Boot Policy from your EFI partition then it means that Secure Boot has just disabled itself on your tablet. It's highly unlikely, however, since you weren't able to run desktop apps in your original 8.1 install...
Click to expand...
Click to collapse
I copied a SecureBootDebugPolicy.p7b (dated 02/13/2014 @ 3:19PM) file from there. From what I was reading, I take it that's a good thing? (click thumbnail for full pic)
SecureBootDebugPolicy in the certificate manager tool

what is the icon that next on the left of action center (bottom-right, triangle flag) and at the right side of OneDrive?

hisoft said:
what is the icon that next on the left of action center (bottom-right, triangle flag) and at the right side of OneDrive?
Click to expand...
Click to collapse
USB/SD eject (I have SD card I keep in the slot for extra storage)

thesawolf said:
USB/SD eject (I have SD card I keep in the slot for extra storage)
Click to expand...
Click to collapse
Good job ASUS :good:

If you were able to retrieve a SecureBootDebugPolicy.p7b that is functional, it probably means that there was a Debug policy on your device at some point? (ref. Original Thread on ASUS). I've just looked into my Surface RT and there's a file with that name too, but it cannot be opened (it's simply an empty 0-byte file) and probably you're another lucky one who has a debug policy. (However it can't be explained why Get-SecureBootPolicy shows that you're using a production policy? Does it show the production policy GUID that TechNet says is normal, or something else? Policies don't disable secure boot, Confirm-SecureBootPolicy showing true is perfectly normal even in debug.)
Would it be possible to share this SecureBootDebugPolicy.p7b and then we'd able to see if there is someone else with a VivoTab RT that could test it? I assume it's locked to your device but it's always worth a try.
Could anyone else with experience working with Secure Boot look into this? While it's probably a lucky isolated case, it's nevertheless promising...

Just to double check: does anybody else have a Vivo Tab RT with 8.1u1 they could check this against? It would be amazing / hilarious if the update disabled signature enforcement. The question would then be whether that was Microsoft's idea or Asus's...
Oh, and one other quick test: grab a built-in program (CMD.EXE or Notepad.EXE, for example) and make a copy of it to somewhere you can edit it (like the desktop). Open the file in a hex editor (if needed, copy it off the tablet first) and change something unimportant, like a few characters in a string (not a file path, more like "is not recognized as an internal or external command..." or some such thing) to some other value that has the same number of characters. Save the file and try running it on the tablet again. The idea is that this will be an EXE with an *invalid* signature (as opposed to just being unsigned) and that would be very surprising if it works... but this whole thing is surprising!

GoodDayToDie said:
Just to double check: does anybody else have a Vivo Tab RT with 8.1u1 they could check this against? It would be amazing / hilarious if the update disabled signature enforcement. The question would then be whether that was Microsoft's idea or Asus's...
Click to expand...
Click to collapse
Tried it on a VivoTab RT LTE (AT&T) with u1 -- ran 7z ARM and it failed on signature verification.

I would never run another update on that device. Don't want to patch up the botched update.
Sent from my Z10 using XDA Premium 4 mobile app

I wonder if there's some way to take a full image of your current installation (possibly using a backup utility?) that can be restored onto other peoples' tablets. Even better would be if the relevant bits could be extracted from your image and carried over to other tablets (such as Surface RTs, Surface 2s, Lumia 2520s, etc.) but that may be harder. Still, worth investigating more...

Was it new or used when you got it? And if it was used, is it possible the original owner JB'd it and it stuck through the update?
Sent from my HTC6600LVW using XDA Premium 4 mobile app

GoodDayToDie said:
I wonder if there's some way to take a full image of your current installation (possibly using a backup utility?) that can be restored onto other peoples' tablets. Even better would be if the relevant bits could be extracted from your image and carried over to other tablets (such as Surface RTs, Surface 2s, Lumia 2520s, etc.) but that may be harder. Still, worth investigating more...
Click to expand...
Click to collapse
Should be able to use dism.exe. Not sure if it will capture the online image, but you can definitely use it in recovery mode. Should be able to capture with new-windowsimage too. Going to try it out real quick and report back... I would choke puppies for this image.
---------- Post added at 11:24 AM ---------- Previous post was at 10:35 AM ----------
Okay it you can't capture the online image. You'll need to have a USB drive with enough space to capture the whole thing. Make sure you either suspend bitlocker or make sure you have a copy of the recovery key handy (It's 48 decimal digits).
Boot to the recovery partition (it doesn't matter if it's on the local storage or a USB key - it can even be the same USB key you will copy the disk image to if you have enough free space).
Choose language, troubleshoot, advanced, command prompt (I think - point is, you want a command prompt).
Verify the drive letters are what you expect them to be (internal storage is c, usb disk is d, ramdisk is x).
run: dism /capture-image /ImageFile:d:\winrt81u1.wim /CaptureDir:c:\ /Name:WinRT81U1vivotab
Let it finish. It will take a while. Probably a long time since it's writing to USB 2.0 flash storage. Bet on an hour. You probably want to make sure it's plugged in to power (but you're not writing anything to the local storage, so you won't break anything if it goes dead).
Upload that wim file to skydrive and share it with me!

Sjflowerhorn said:
Was it new or used when you got it? And if it was used, is it possible the original owner JB'd it and it stuck through the update?
Sent from my HTC6600LVW using XDA Premium 4 mobile app
Click to expand...
Click to collapse
That is impossible, the 8.0 jailbreak was performed in memory and it not written to the disk.

Toxickill said:
That is impossible, the 8.0 jailbreak was performed in memory and it not written to the disk.
Click to expand...
Click to collapse
Gotcha, I haven't JB'd mine yet, so I have no idea how it works. Apparently I'm Windows ShmeShmarted and can't make a bootable flash drive that contains the rollback. And coming from android devices where everything sticks except for some very select mods/devices I just figured it might be possible.
Sent from my HTC6600LVW using XDA Premium 4 mobile app

Sjflowerhorn said:
And coming from android devices where everything sticks except for some very select mods/devices I just figured it might be possible.
Click to expand...
Click to collapse
Believe me, that's what all RT owners would WANT to have. Although there's many reasons to jailbreak a device, I personally prefer feeling like I've gained full control of hardware I own. The in-memory jailbreak was good, but it didn't have that satisfying feeling of permanence you often get with an Android rooting / OS replacement.

southbird said:
Believe me, that's what all RT owners would WANT to have. Although there's many reasons to jailbreak a device, I personally prefer feeling like I've gained full control of hardware I own. The in-memory jailbreak was good, but it didn't have that satisfying feeling of permanence you often get with an Android rooting / OS replacement.
Click to expand...
Click to collapse
Until the carrier gets to your device and locks the bootloader (AT&T)

I actually preferred the in-memory jailbreak in many ways. It meant we couldn't modify system files or run unsigned code for a couple minutes after boot, but it also meant we could trivially easily "un-jailbreak" and we could install updates with no fear of them destroying anything. Even the huge 8.1 update, which broke the jailbreak *process*, could be started on a device which was already jailbroken without causing any harm (unlike, say, many iOS jailbreaks).

I agree. I liked that the 8.0 jailbreak wasn't permanent but also exceedingly simple to install at boot. It meant that sending my Surface RT back to my Microsoft under warranty had no problems at all.

Lumen_Melano said:
I agree. I liked that the 8.0 jailbreak wasn't permanent but also exceedingly simple to install at boot. It meant that sending my Surface RT back to my Microsoft under warranty had no problems at all.
Click to expand...
Click to collapse
The in-memory Jailbreak is great when you hard brick your Surface and take it to the Microsoft Store. They just gave me a new one with no problems at all.

WinDBG cannot debug desktop program?

If I don't run the jailbreak, I cannot attach or create desktop process using WinDBG.
However under jailbreak everything works fine. I'd like to know why this happen.

Reserved

I believe they tried to prevent using the debugger on desktop apps for 8.1. Not sure how thorough it is; most of the time it's not really relevant as it's pretty easy to bypass.

GoodDayToDie said:
I believe they tried to prevent using the debugger on desktop apps for 8.1. Not sure how thorough it is; most of the time it's not really relevant as it's pretty easy to bypass.
Click to expand...
Click to collapse
I just updated to 8.1 to see how that works out with a old version of WinDBG. It doesn't work either. It seems being related to jailbreak. Curious how that will affect WinDBG.

Its a good question
A year or two back when we were first looking at RT 8.0, the fact that the debugger couldn't start or attached to desktop programs was a big headache
We were having to used the visual studio remote debugger
Then someone discovered that cdb -pv or -pvr would attach, and the opportunities opened up
Presumably normal attaching somehow falls foul of the locked down nature of the system
although strange it cant start existing signed exe's like notepad
or do a normal attach to them
so implies some other check is going on
In RT8.1 its even further tightened down
no admin level VS remote debugger
debugger package (and debug kit policy) cant even -pvr to a process
CORRECTION: yes you still can-pvr to a process
but cant access csrss as it is now protected

xsoliman3 said:
Its a good question
A year or two back when we were first looking at RT 8.0, the fact that the debugger couldn't start or attached to desktop programs was a big headache
We were having to used the visual studio remote debugger
Then someone discovered that cdb -pv or -pvr would attach, and the opportunities opened up
Presumably normal attaching somehow falls foul of the locked down nature of the system
although strange it cant start existing signed exe's like notepad
or do a normal attach to them
so implies some other check is going on
In RT8.1 its even further tightened down
no admin level VS remote debugger
debugger package (and debug kit policy) cant even -pvr to a process
CORRECTION: yes you still can-pvr to a process
but cant access csrss as it is now protected
Click to expand...
Click to collapse
You also can't write to the memory on a process if you attach to it.

Own a Fire HD 8, 8th Gen, Want to be able to put any OS on it.

Ideally I'd like to actually be able to put an arbitrary OS on my tablet. Has anyone figured out how to do this with the Fire HD 8, 8th generation, yet? I'm willing to use soldering to do so. If this is not possible with this hardware, does anyone have a recommendation about what tablet options I have, to do this?

dc123123 said:
Ideally I'd like to actually be able to put an arbitrary on my tablet. Has anyone figured out how to do this with the Fire HD 8, 8th generation, yet? I'm willing to use soldering to do so. If this is not possible with this hardware, does anyone have a recommendation about what tablet options I have, to do this?
Click to expand...
Click to collapse
There is a hardmod to secure root but no custom roms. Consider a 3rd gen HDX if seeking a selection of Nougat based custom ROMs.

Davey126 said:
There is a hardmod to secure root but no custom roms. Consider a 3rd gen HDX if seeking a selection of Nougat based custom ROMs.
Click to expand...
Click to collapse
It shouldn't be possible to modify /system on the 8th generation as it ships with dm-verity enabled.

xyz` said:
It shouldn't be possible to modify /system on the 8th generation as it ships with dm-verity enabled.
Click to expand...
Click to collapse
Ok, interesting, but how are software updates possible on devices with dm-verity? Doesn't that change the file/partitions to the extent that they need a new key for it?

Essentially the firmware update includes a hash of the /system partition (a tree of hashes) signed with Amazon's private key. The boot image includes the public key so that the device can verify the /system integrity. The rest of the boot process already ensures that the boot image isn't tampered with. So to update they just need to generate another /system, generate another hash tree for it and sign it with the private key.

xyz` said:
Essentially the firmware update includes a hash of the /system partition (a tree of hashes) signed with Amazon's private key. The boot image includes the public key so that the device can verify the /system integrity. The rest of the boot process already ensures that the boot image isn't tampered with. So to update they just need to generate another /system, generate another hash tree for it and sign it with the private key.
Click to expand...
Click to collapse
https ---- source.android ---- .com/security/verifiedboot/dm-verity
Yeah this seems to indicate that the more of that partition that is accessed during the runtime, the more time and power are invested into verification during use. Lame.
Anyways, thank you very much, guys, for answering the questions.
I'm also interested in knowing why it isn't possible to just redo the system partition but modify it to match the hash... but I'll wiki that to find out why it doesn't work (SHA-256). I'm guessing that this isn't as simple as a checksum. Even if it meant making another file system to do it... I guess the other option is getting the private key.
W.R.T. building a tablet that doesn't suck, the project that I saw was basically someone who slightly dissassembled a SBC, so that they didn't have to design a mobo and find a chip for it. That makes sense but the SBC that I looked at (Orange Pi Zero ) don't actually seem to use all the options/connectivity provided in the datasheet of the SoC chip. For instance, it's capable of HDMI but there's no HDMI on the board, etc. Also, the project I read about ended up getting very expensive.

Another thing from that site:
"A public key is included on the boot partition, which must be verified externally by the device manufacturer."
What do they mean by verified externally? Like, I know with my tablet I needed to connect to the internet at least once to do anything with it.
This is the part that makes me think that we can mess with it:
" To mitigate this risk, most manufacturers verify the kernel using a key burned into the device. That key is not changeable once the device leaves the factory."
Also, I want to translate this into noob:
" And since reading the block is such an expensive operation, the latency introduced by this block-level verification is comparatively nominal."
Does that mean that the time spent reading the hash is small because there's a lot of calculation involved, such that the transmit time is small compared to the total time, or that the transmission of the next block info can happen during the calculation of the prior block info?

dc123123 said:
Another thing from that site:
"A public key is included on the boot partition, which must be verified externally by the device manufacturer."
What do they mean by verified externally? Like, I know with my tablet I needed to connect to the internet at least once to do anything with it.
Click to expand...
Click to collapse
It means that the boot partition (the boot.img) is verified by the bootloader, in our case that would be LK.
dc123123 said:
Also, I want to translate this into noob:
" And since reading the block is such an expensive operation, the latency introduced by this block-level verification is comparatively nominal."
Does that mean that the time spent reading the hash is small because there's a lot of calculation involved, such that the transmit time is small compared to the total time, or that the transmission of the next block info can happen during the calculation of the prior block info?
Click to expand...
Click to collapse
They're saying that there's no performance hit when enabling dm-verity because reading the actual data from the emmc is so slow you won't notice the additional slowdown introduced by hashing and verifying the block data.