Related
So I wanted VoiceDialer on my stock ADP1. I grabbed VoiceDialer.apk from JFv1.31_ADP1.zip and installed it using adb (sdcard mounted on computer, so it wasn't mounted on the phone). It runs, and I was quite satisfied with its recognition abilities, but when it comes to clicking "OK" to dial, it always crashes with a "force close" dialogue. Holding the "send" button does bring up the VoiceDialer program. My guess is I'm missing some sort of configuration somewhere. Does anyone know?
Make sure you grabbed the VoiceDialer.odex too, if there is one.
Koush said:
Make sure you grabbed the VoiceDialer.odex too, if there is one.
Click to expand...
Click to collapse
I didn't find any odex files (unless they would be in recovery.img, which I haven't yet learned how to open). These files are not created automatically?
Unzip a RC30 update.zip and look in \system\app\
On ADP1, the dex is created at runtime by the dalvikvm from the classes file inside the zip. On RC30, the dex files for the builtin apps are created ahead of time and stored alongside the apk. This prevents the system from using up \data partition space with dex files (As the ADP1 build does).
jashsu said:
Unzip a RC30 update.zip and look in \system\app\
On ADP1, the dex is created at runtime by the dalvikvm from the classes file inside the zip. On RC30, the dex files for the builtin apps are created ahead of time and stored alongside the apk. This prevents the system from using up \data partition space with dex files (As the ADP1 build does).
Click to expand...
Click to collapse
I was able to find a copy of VoiceDialer.odex as per your description, but if I understand you correctly, that will not solve my problem.
If the dev phone uses dex files instead, and these are created at runtime, then I would expect to find a dex file for VoiceDialer if everything is working properly. Indeed, the file "[email protected]@[email protected]" exists.
Any other hints as to why the application might crash after clicking "OK" to dial a number?
Yeah just grab the VoiceDialer.apk from JF's modified ADP1 build. It contains the classes.dex file required to run on ADP1 build.
jashsu said:
Yeah just grab the VoiceDialer.apk from JF's modified ADP1 build. It contains the classes.dex file required to run on ADP1 build.
Click to expand...
Click to collapse
That's what I did initially. That part all seems to work.
Doh, went around in a circle ;-) I thought we were talking about the RC30 version.
Yeah you'll have to ask JF about this since I think he compiled VoiceDialer from source for his ADP mod build. There is no odex file to look for.
jashsu said:
Yeah you'll have to ask JF about this since I think he compiled VoiceDialer from source for his ADP mod build.
Click to expand...
Click to collapse
Yeah, I'm sure JF could see the problem real quick. I'm real timid about bothering people, though - I was hoping he might swing by this thread by chance. What's considered appropriate on this forum: PM? E-mail? IM? Visitor Message?
IMSargon said:
Yeah, I'm sure JF could see the problem real quick. I'm real timid about bothering people, though - I was hoping he might swing by this thread by chance. What's considered appropriate on this forum: PM? E-mail? IM? Visitor Message?
Click to expand...
Click to collapse
Your best bet is IRC. A lot of us hang out in #android on Freenode.
IMSargon said:
So I wanted VoiceDialer on my stock ADP1. I grabbed VoiceDialer.apk from JFv1.31_ADP1.zip and installed it using adb (sdcard mounted on computer, so it wasn't mounted on the phone). It runs, and I was quite satisfied with its recognition abilities, but when it comes to clicking "OK" to dial, it always crashes with a "force close" dialogue. Holding the "send" button does bring up the VoiceDialer program. My guess is I'm missing some sort of configuration somewhere. Does anyone know?
Click to expand...
Click to collapse
Your best bet is to remount /system and push the .apk directly into /system/app. I haven't tried installing it with adb install, so I'm not sure if that's what is causing your problems or what.
JesusFreke said:
Your best bet is to remount /system and push the .apk directly into /system/app. I haven't tried installing it with adb install, so I'm not sure if that's what is causing your problems or what.
Click to expand...
Click to collapse
Yeah, I had the same problem (I've installed voice dialer using adb install)
Uninstalled in application manager, rebooted, remounted, pushed voicedialer.apk to /systemp/app, rebooted again, and it worked )
JesusFreke said:
Your best bet is to remount /system and push the .apk directly into /system/app. I haven't tried installing it with adb install, so I'm not sure if that's what is causing your problems or what.
Click to expand...
Click to collapse
It worked! Great! Thanks a ton!
------------------------------
Steps taken:
1. copy VoiceDialer.apk to phone
# adb push VoiceDialer.apk /sdcard/VoiceDialer.apk
763 KB/s (51125 bytes in 0.065s)
#
2. enter shell on phone, and gain root
# adb shell
$ su
#
3. mount the system partition as rewritable
# mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system
#
4. copy VoiceDialer.apk to the proper system directory
# cat /sdcard/VoiceDialer.apk > /system/app/VoiceDialer.apk
#
5. make permissions match the other files
# chmod 644 /system/app/VoiceDialer.apk
#
6. reboot the phone
# reboot
------------------------------
For extra credit, does anyone understand why this happens? What does it tell us about how apps work and install?
adb pushing the apk directly bypasses the PackageManager. By using adb install, the package manager will run (as if the package was installed from the Market or Browser). There are various reasons the PackageManager might reject a package, including inability to run dexopt, incompatibility with existing data registered to an older version of an app, etc. A list of errors that would block an apk installation is here. Look at the constants starting with INSTALL_FAILED and INSTALL_PARSE_FAILED.
jashsu said:
adb pushing the apk directly bypasses the PackageManager. By using adb install, the package manager will run (as if the package was installed from the Market or Browser). There are various reasons the PackageManager might reject a package, including inability to run dexopt, incompatibility with existing data registered to an older version of an app, etc. A list of errors that would block an apk installation is here. Look at the constants starting with INSTALL_FAILED and INSTALL_PARSE_FAILED.
Click to expand...
Click to collapse
Interesting, but in this case the application did not fail to install. The installation went normally, and the application functioned normally up to the point where it attempted to interface with another application/subsystem (whatever dials the phone).
IMSargon said:
Interesting, but in this case the application did not fail to install. The installation went normally, and the application functioned normally up to the point where it attempted to interface with another application/subsystem (whatever dials the phone).
Click to expand...
Click to collapse
When you install it with adb install, it gets installed as a normal (non-system) application. This can be verified by checking /data/system/packages.xml:
Code:
<package name="com.android.voicedialer" codePath="/data/app/VoiceDialer.apk" [B]system="false"[/B] ts="1232083952000" userId="10029">
<sigs count="1">
<cert index="0" />
</sigs>
</package>
One of the permissions it requires is "android.permission.CALL_PRIVILEGED". Based on the info in frameworks/base/core/res/AndroidManifest.xml (in the git source):
Code:
<permission android:name="android.permission.CALL_PRIVILEGED"
android:label="@string/permlab_callPrivileged"
android:description="@string/permdesc_callPrivileged"
[B]android:protectionLevel="signatureOrSystem"[/B] />
You can see the protectionLevel is "signatureOrSystem", meaning that the application has to be a system application in order to use that permission. Since the voice dialer was not installed as a system application, it can't be assigned that permission.
To confirm this, I tried installing the voice dialer with adb install, and then took a look at the logcat output, which contains the following line:
Code:
01-15 23:32:32.903: WARN/PackageManager(56): Not granting permission android.permission.CALL_PRIVILEGED to package com.android.voicedialer (protectionLevel=3 flags=0x44)
However, when you copy the apk to /system/app, it gets installed as a system application, which can be verified again by looking at /data/system/packages.xml:
Code:
<package name="com.android.voicedialer" codePath="/system/app/VoiceDialer.apk" [B]system="true"[/B] ts="1232084484000" userId="10035">
<sigs count="1">
<cert index="0" />
</sigs>
</package>
So it is able to use the "android.permission.CALL_PRIVILEGED" permission. After coping the apk to /system/app, I checked the logcat output and there was no mention of not being able to grant the android.permission.CALL_PRIVILEGED permission, as expected.
Interestingly enough, copying the file to /system/app doesn't bypass the package manager. The package manager is watching both /data/app and /system/app for new files, and it automatically installs anything you copy into either location. It also does an uninstall when you delete an apk from either location.
JesusFreke said:
Interestingly enough, copying the file to /system/app doesn't bypass the package manager. The package manager is watching both /data/app and /system/app for new files, and it automatically installs anything you copy into either location. It also does an uninstalls when you delete an apk from either location.
Click to expand...
Click to collapse
I didn't know that. In that context it does make sense why it would disallow call permission if put into /data/app
Offtopic, but are you planning on creating a modified version of the newly released ADP1 "1.1" build?
Thanks, JF, your explanation makes the problem quite clear!
Does anyone have a working example of signing a system app like Phone.apk? I've found 2 certificates on my GT, one from Samsung and one from VZW, but neither seem to work. When I try to install the app, I receive a certificate invalid error -- invalid CERT.SF. Does anyone know exactly which certificate to use to sign system apps?
Thanks
Sent from my SCH-I800 using XDA App
You will need private key to sign, not certificate.
Sent from my GT-P1000 using XDA App
I did sign it with my private key and it didn't work. Hence the question about system apps and how to sign them so that they are usuable on a device. Isn't it possible to make changes to a system app, install it on a device to test it, and not need the private key used by Google or, in this case, Verizon Wireless (because they are using a modified Phone.apk along with 2 other non-Google apk's to control dialing)? Or, does every system app have to be reinstalled if one changes, because of the data sharing flag set in AndroidManifest.xml?
Sent from my SCH-I800 using XDA App
What did you try signing it with?
have you tried One Click APK Signer or APK Manager?
I've never heard of those apps. I'll definitely be checking them out. Thanks for heads up. But, will this allow me to change out a system app that shares data with other apps without an issue with the manifest signing problem?
Sent from my SCH-I800 using XDA App
You will need to sign the whole /system folder as well as the whole /framework folder
This will resign all files in order for it to work correctly.
This basically changes the private key to you.
How do you sign the entire folder?
Sent from my SCH-I800 using XDA App
How to sign Android app with system signature?
Hi !
I’m writing an user app, it should be possible to set some system settings (device without root), e.g. SystemTime/SystemDate. I've added some necessary permissions in my manifest, like:
Code:
...
android:sharedUserId="android.uid.system"
...
<uses-permission android:name="android.permission.SET_TIME" />
<uses-permission android:name="android.permission.WRITE_SETTINGS" />
if i try:
Code:
setCurrentTimeMillis (long millis)
i get from logcat:
Code:
Not granting permission android.permission.SET_TIME to package com.example.hellodatepicker (protectionLevel=3 flags=0x8446)
Unable to open alarm driver: Permission denied.
it seems that my app has to be signed with sys/platform key. but how to do that? did anyone already do this? I'm glad to see/hear some info about your experience getting this issue fixed.
Thank you in advance.
This patch is against framework.jar for Android 4.4 (KRT16M) and allows you to modify system packages without them being verified.
Why would you want this?
Re-signing isn't possible with many google packages as they check their own certificates at runtime (GooglePlayServices). This patch allows you to make any modifications you like to system packages, while keeping the original certificates.
Isn't it unsafe to not verify packages?
Yes. However, this patch only applies to system packages. Those downloaded from the market are still verified as usual. The /system filesystem is read-only by default. The only way for a package to be infected is if an application has root privileges (via SuperSU or similar). Of course you should assume that after giving an application elevated privileges it could infect packages with or without this patch.
How does it work?
Packages in android are loaded by PackageParser. The method collectCertificates attempts to read the file AndroidManifest.xml from system packages, which causes the underlying JarFile to verify it against the embedded signature. If everything was successful it returns the certificate. This patch changes collectCertificates to load and return the certificate directly, without trying to read AndroidManifest.xml.
You must delete META-INF/CERT.SF and META-INF/MANIFEST.MF from any package you modify. This patch doesn't change the underlying JarFile code, which by default uses those files to check entries as they're read from the archive. You should leave META-INF/CERT.RSA alone as that's the certificate this patch loads.
The patch was produced against framework.jar from the factory image KRT16M using baksmali v2.0 .
SHA1
Code:
433eeec32008015a1f54964bf036f4eaddb3864b framework-jar-KRT16M-raw-certificates.patch
75b5999203f355cf45387a424246e988440c3068 framework.jar
*reserved*
Thanks for this great mod.. Modify system packages works but when add new apk system (like sony apps to my CM 11 device), ktkat won't accept as app installed, even when I don't modify anything in apk.
Sent from my Xperia Mini Pro using Tapatalk
There is an interesting discussion on the Russian forum the-ebook.org (paste this link into Google and select the translation; item is on page 2) regarding those annoying invisible menu options in many apps. Although the translation is a little rough around the edges, the gist seems to be that the default text and background colors for the app menus are not exactly what the e-ink display has in mind, often resulting in light or near-white text on a white background--hence, invisible text.
The "solution" used is to change some background color settings in framework-res.apk. I have no idea what the outcome looks like but it seems like a really good idea, although beyond my abilities, and the example used is 1.10 firmware. I'm using 1.21. Any attempt I have made to modify apk files has always failed
Does anyone have a fool-proof set of steps for doing this?
I remember reading about what you're talking about somewhere on the forums but I could never get it to work either...
Here's what I'm talking about:
http://forum.xda-developers.com/showthread.php?t=1356514
http://forum.xda-developers.com/showthread.php?t=1512846
OK, well.....I've got the adjusted background images extracted from the framework-res.apk file that I got from the Russian site (I'm working with the lighter background option at this point). And...I've found the setting in WinRar to simply "store" (not compress) the updated png files. So far, so good. My altered apk file is the same size as the original.
The clincher is to get it back on the Nook without disaster ensuing. I'm going to follow Renate's method for pushing back framework-res.apk via ABD (from this thread):
C:\>adb shell
# stop
# mount -o rw,remount /dev/block/mmcblk0p5 /system
# ^C
C:\>adb push framework-res.apk /system/framework
C:\>adb shell
# reboot
Keep your fingers crossed. If it works, I'll report back with step-by-step and files.
[Report: in concept this "works". On reboot I could see the slightly grey background color in menu options and going to a few apps where I knew the menus were invisible, I could see white text on the slightly grey background. BUT...almost no apps will work. The B&N side seems to function OK, but the App drawer is useless. Back to the drawing board. The Russian site has a method for installation using RootExplorer. I'll try that next.]
OK...day 2. Here's what does NOT work:
1. method in post above using ADB
2. method using RootBorwser as adapted from Russian site and detailed below:
a. Change permissions in /system, /system/etc and /system/framework folders so that all users have write access
(note this is my kludge to get around not knowing how to "mount" the /system partition as r/w--maybe it's wrong?)
b. Use ADB wireless to move modified framework-res.apk into /system/etc
c. Use RootBrowser to check ownership of modified framework-res.apk (should be and was already owner: 0-root, group: 0-root)
d. Use RootBrowser to change permissions on modified framework-res.apk to rw-r--r-- (664)
e. Use RootBrowser to move (cut/paste) modified framework-res.apk into /system/framework (overwrite)
With Superuser permission, this all went off without a hitch.
f. Use RootBrowser to reset permissions of folders listed in (a)
g.Shut down Nook and restart.
The result is the same as the ADB-only method described before. The Nook starts up just fine. You can see that the background color of menus is slightly gray. Those changes have obviously worked. But the vast majority of apps will not run (ADW Launcher is an exception). At one point while I was fiddling with things the Nook spontaneously rebooted.
I guess that's better than spontaneously combusting
SIGH. Clearly, despite my best efforts, something I did in handling the framework-res.apk has damaged it in some subtle way, OR, my inability to properly "remount" the /system as R/W is causing the problem, although using ADB this is accomplished without difficulty and since the result is the same...it must be the modified apk file.
And this is why I have a dedicated SD card backup......
Method 3 that does NOT work:
1. Install Ninjamorph and BusyBox from Market
2. Follow instructions for altering framework-res.apk found here.
Two ways to Finish Project, with zip-align and without. Both yield the same result which is the same as the other methods above, i.e., the B&N stuff mostly works and the desired contrast of the menus is achieved so you can actually see what used to be invisible, but most apps will not run. Really frustrating.
I have to say that while this method seemed promising it is tedious in the extreme as each of the 28 png files must be replaced individually and that means each must be located in a much larger list (which reverts to the top after each replacement....). Ugh.
I simply don't believe anyone who says they can make these modifications with the instructions they have provided. It must be that people who are more familiar with this stuff are leaving out information which is so obvious to them that they don't even think to mention it
framework-res.apk is an apk and therefore it must be signed.
It's a system apk so it must be signed with the system signature.
Modifying a few things doesn't annoy the signature matching, other stuff does.
When you have problems, please quote from logcat because that tells you exactly what the problem is.
Using ADB:
Code:
logcat
Whatever.9.png are special files.
The are usually created thusly:
http://developer.android.com/guide/topics/graphics/2d-graphics.html#nine-patch
When they get packed into an apk they are turned into a PNG graphic with alpha channel.
aapt handles this.
If you take a PNG with sidebars and just zip it, it will not work.
Renate NST said:
When you have problems, please quote from logcat because that tells you exactly what the problem is.
Using ADB:
Code:
logcat
Whatever.9.png are special files.
The are usually created thusly:
http://developer.android.com/guide/topics/graphics/2d-graphics.html#nine-patch
When they get packed into an apk they are turned into a PNG graphic with alpha channel.
aapt handles this.
If you take a PNG with sidebars and just zip it, it will not work.
Click to expand...
Click to collapse
I just tried again and this time after pushing the amended framework-res.apk file (yes, all 28 amendations are nine-patch files) I typed in logcat before rebooting.
Whoosh!!! Lines of information went streaming by faster than I could follow, so much that some of the earliest disappeared from the top of the console window. I have no clue how to extract the text from the console window
The top-most complaint I saw was a reference to system error 1248 in association with the CleanMaster app. Then there seems to be a periodic (15 second) dhcpcd renewal. Eventually there is a section that says "Framework disconnected, eof, failed to read size, closing connection". Then comes a long list of notifications from the Service Manager about all the services that have just died. After that it just continues with the 15-second dhcpcd renewal cycle. Then I gave up and rebooted.
The result is the same as before. The new image backgrounds have been incorporated into the system, but most of the app drawer is just pretty icons. ADW runs--at least the drawer and home page appear. The B&N Home and Library pages load but you can't access any of the books shown. Wi-Fi can be accessed but no apps that use it will run. Occasionally the CleanMaster app throws up an error message.
Here's what I've learned so far:
1. In the original amended framework-res.apk file (for FW 1.10) viewing the archive reveals that the files which have been changed all have an "archive " attribute. None of the original files show any attribute. I don't know whether that is important. I've searched on this topic and have come up with nothing.
2. In moving the amended *.9.png files from the original Russian example for FW 1.10 into a copy of my own framework-res.apk for FW 1.21, those "archive" attributes came along for the ride and the resulting amended file does show "STORE" for the method so I think I got that part right and didn't recompress any files when moving from one apk to another (I dragged the files from one instance of WinRAR to another--I tried 7zip as well...).
But I have no idea why people report that this procedure works just fine. For me, it is predictable, but not successful.
I've just completed yet another restore from backup. I'm going to uninstall CleanMaster and try again. Perhaps it's background activities are driving the process into the ground. I have no clue.
Here's the logcat session file (learned how to get that done!) after a re-try, having removed CleanMaster first.
No change in the outcome but no bleating from the Nook about CleanMaster errors.
I wonder--is it the modified apk that is causing the system to malfunction, or....is it the way it is being pushed back to the Nook?
So..an experiment: I pulled a copy of the stock framework-res.apk from my Nook. I didn't do anything to it at all. Then I pushed it back to the Nook via wireless ABD:
C:\>adb shell
# stop
# mount -o rw,remount /dev/block/mmcblk0p5 /system
# ^C
C:\>adb push framework-res.apk /system/framework
C:\>adb shell
# reboot
This is supposed to work, yes? It does not. It leaves me in the same condition that all of the other attempts by this and other methods have. The Nook boots normally and displays Home but you can't access the "currently reading" book. I can get to the app drawer via the quicknav buttons, but very few apps will work (including ADB). There is no way to examine the file system because RootBrowser will not work (although ES File Explorer does, but it doesn't have root access).
So....whether the modified apk is OK or not, I would never know because all of the methods I have tried to get the framework-res.apk back onto the Nook have been unsuccessful.
That procedure should work fine.
Have you checked using the stock framework-res.apk ?
Renate NST said:
That procedure should work fine.
Have you checked using the stock framework-res.apk ?
Click to expand...
Click to collapse
Yes, that's what I just tried. Just pulled it via ADB and then pushed it right back. I also installed a copy of Root Explorer (I generally used Root Browser) because that's what was used in the original thread on the Russian site where I got started with the whole project. That also yields the same results. The Home screen loads but you can't access the book currently being read from it or from the little button at the top left. You can access any of the QuickNav options. The Library "functions". But you can't access books from their covers and the double-tap does not work.
In the app drawer, ADW seems to work fine but you can only run a very few apps, and none that require wi-fi (although wi-fi works). Too much fiddling around and the Nook spontaneously reboots.
When I have tried to move in the modified apk with the slightly gray background 9.png files I can see that the new image backgrounds have been used in the drop-down menus. This suggests to me that the problem is not in how the 9.png files have been moved from the FW1.10 apk obtained from the Russian site into my FW1.21 apk but rather in the integration of the modified apk into the system. I've checked permissions, etc. Everything is OK but the system is just screwed up.
I'm running FW1.21 which has been rooted using Nook Manager with Gapps added. I've done the multi-touch modification and have swapped in a modified internal.db file which seems to have solved the confusion of the "reading now" button. I have some apps that run along in the background, like Tasker and Clean Master (probably others that I don't realize). Do I need a completely clean system to make this change?
I saw the logcat and it showed that it's unhappy and killing the Android.
I couldn't see exactly where the problem is.
I think that you are doing too many things at once.
If there are specific things that do not work, a logcat when you do that should show.
Renate NST said:
I saw the logcat and it showed that it's unhappy and killing the Android.
I couldn't see exactly where the problem is.
I think that you are doing too many things at once.
If there are specific things that do not work, a logcat when you do that should show.
Click to expand...
Click to collapse
Yes, I was probably a little unclear. The ONLY thing that I did when I produced the logcat was attempt to push the modified framework-res.apk file back to the Nook. All those other things mentioned have long ago been successfully accomplished and included in my current backup (which I've had to use dozens of time in the last week or two as I struggle with this framework issue).
The ONLY change to the stock framework-res.apk is the overwriting of 28 *.9.png images with ones copied from another framework-res.apk which, unfortunately, is from FW1.10 (or I'd just use it "as is" without the copying). However, even pushing back an unmodified stock apk results in the same mess.
Like I say, based on what functionality remains when the modified apk file is pushed over, it is clear that the new images are being used, but the system function is severely degraded.
I don't know much about the process, but from what I've read I'm wondering if it would be better to use a zip via CM to deliver this modified file? That way the Android system is not even running (right?) during the replacement procedure.
When you say "stop" Android is no longer running.
Try clearing the cache:
Code:
rm -R /data/dalvik-cache/*
Renate NST said:
When you say "stop" Android is no longer running.
Try clearing the cache:
Code:
rm -R /data/dalvik-cache/*
Click to expand...
Click to collapse
Before pushing? After, but before rebooting?
Anytime that Android is stopped you can clear the cache.
I tried this with a copy of the stock apk:
Code:
C:\>adb shell
# stop
# rm -R /data/dalvik-cache/*
# mount -o rw,remount /dev/block/mmcblk0p5 /system
# ^C
C:\>adb push framework-res.apk /system/framework
C:\>adb shell
# reboot
It put me in an very long chase of the black and white dots that I almost thought would be endless but eventually it finished booting and is in the same condition as all the previous methods. Very crippled.
I can't figure it out
First, get the 1.2.1 update off B&N's website and unzip.
Get framework-res.apk out of that and push it.
The stuff in /system/framework should all be chmod 644.
An ADB push probably leaves it with wider access.
None of this should make any difference.
I'd guess that you are either missing a resource in your fw-r or else you modified something else.
Find an app that crashes. Get a logcat of just that crashing.
Renate NST said:
First, get the 1.2.1 update off B&N's website and unzip.
Get framework-res.apk out of that and push it.
The stuff in /system/framework should all be chmod 644.
An ADB push probably leaves it with wider access.
None of this should make any difference.
I'd guess that you are either missing a resource in your fw-r or else you modified something else.
Find an app that crashes. Get a logcat of just that crashing.
Click to expand...
Click to collapse
I got a copy of the FW 1.21 zip from B&N and extracted the framework-res.apk. I didn't try to push it yet. Instead I got the checksum for the current file on the Nook and compared it to the newly minted file. They were identical. I don't think there is any point in trying yet again with the same procedure. If my reasoning is incorrect, I'm certainly game to try anyway.
All files in /system/framework are chmod 644. The Framework folder itself (and the system folder) are something else, but the contents are all 644.
The only modifications I have made after rooting with Nook Manager are the installation of Google Apps, the implementation of multi-touch (I have to go back and look that up to see what all I did, but surely nothing with framework-res.apk or it never would have worked....), editing settings.db to relabel the QuickNav buttons after programming with NTMM, and pushing a modified copy of internal.db to fix the schizo "reading now" button. As i say, these are all long-established changes and the Nook has been stable with them. I think Google apps may modify framework.jar, but I'm not sure.
[I checked on multi-touch. I flashed a new kernal image and added one line to /etc/permissions/required_hardware.xml in order to enable multi-touch...have no idea what "flashed a new kernal" actually did, but it worked]
Two really noob questions: 1) how can I get a logcat of an app crashing when ADB will not run once a copy of framework-res.apk has been pushed? 2) if the Android system is actually stopped when I type "stop"in ADB shell, how does ADB continue to function?
And, actually, apps do not so much "crash" once I've attempted to put in a "new" framework-res.apk--most just refuse to run. But maybe there is something going on in the droid brain while the screen flickers a little and nothing else happens.
ADB runs under Linux, not the Android subsystem.
You should always be able to access ADB.
If ADB isn't running continuously and reliably you have problems.
If some app does not run, give the specific section in logcat where it doesn't run.
In various thread scattered around the Fire and Kindle forums here on XDA, I talked about the possibility of decompiling an Amazon system APK, modifying the contents such as settings for the framework or changing permissions in an attempt to escalate privileges to some degree, maybe even root. I ran into several issues when attempting such a thing:
1) Using a PC, I found it almost impossible to successfully recompile a modified APK. Many of the tools like APKtool are just too complicated and missing even the slightest step will cause it to fail.
2) Surprisingly, I've had the opposite outcome using two apps. Using APK Export, I was able to export an APK from the system and use APK Editor Pro to modify permissions. I have been able to, on a consistent basis, use APK Editor Pro to decompile the Android Live Wallpaper system APKs to add or remove any permission from the APKs manifest. Installing the APKs did not result in getting them into /system/priv-app on my HD 8, but all modifications held over and over. But every time the signature is ruined, and installing as a system app fails again.
Janus can help escalating permissions even further when using the above method and maybe others, to modify system APKs. The question is: Can we use Janus to modify an APK in some form, to install an update to an Amazon system app, which would on install, execute code that would install SU binaries? What about any other known exploit patched or not? Could we fake the system into thinking a one-click-root app is a system app and install it? Link to XDA article.
Janus takes advantage of the fact that extra bytes go unnoticed in APK files and DEX files. The GuardSquare report explains that an APK file is a ZIP archive which can contain arbitrary bytes at the start, before and between its ZIP entries. The JAR signature scheme only takes into account the ZIP entries, ignoring any extra bytes when computing or verifying the application’s signature.
It goes on to explain that a DEX file, on the other hand, can contain arbitrary bytes at the end – after the regular sections of strings, classes, method definitions, etc. Therefore, a file can be a valid APK file and a valid DEX file at the same time.
GuardSquare also mentions that a key element of the vulnerability is a “harmless” feature of the Dalvik/ART virtual machine. The report states that in theory, the Android runtime loads the APK file, extracts its DEX file and then runs its code. However, in practice, the virtual machine (VM) can load and execute both APK files and DEX files. The issue is that when the VM gets an APK file, it still looks at the magic bytes in the header to decide which type of file it is: DEX or APK. On finding a DEX header, it loads the file as a DEX file. If it doesn’t find a header, it loads the file as an APK file containing a zip entry with a DEX file. Thus, it can misinterpret dual DEX/APK files.
GuardSquare says that an attacker can leverage this duality feature of the VM to add a malicious DEX file to a normal APK file without affecting its signature. The Android runtime will accept the APK file as a valid update to a legitimate earlier app version, but the Dalvik VM will load the code from the DEX file, which has been injected with malicious code.
Click to expand...
Click to collapse
This is a good point. I brought up something similar a few months ago in another thread.
With all the exploits discovered this year where's someone trying these exploits on this hw sw combo we have with FireOS.
Where's the fuzzer for all the system calls while trying the known exploits?
Where is the systematic approach to testing these from the pedants on the forum?
Sure you can reply with the usual comebacks, but try a different approach instead of more of the same.
With
Sent from my iPhone using Tapatalk
Robius said:
Where is the systematic approach to testing these from the pedants on the forum?
Click to expand...
Click to collapse
Totally agree! Those selfish tech elitists who put real life above the desires of strangers. They should dedicate themselves (without compensation) and their community resources to methodically crack this very important nut. Ya know, because exploiting a $50 entertainment gizmo should rise to the top of THEIR priority list. Sorry sweetie, daddy won't becoming to any of your soccer games this year; he has important work to do.
My point exactly.
You spent enough energy to respond to this in a sarcastic manner. Thank you
Sent from my iPhone using Tapatalk
Robius said:
My point exactly.
You spent enough energy to respond to this in a sarcastic manner. Thank you
Click to expand...
Click to collapse
Time well spent; appreciate the opportunity to respond in kind.
I have seen a bunch of hashes running through the terminal last time. Amazon may compare the hashes of the apks against a whitelist.
All right, I am ready to take this exploit on my 5th Gen. What I have to do??
Adyatan said:
All right, I am ready to take this exploit on my 5th Gen. What I have to do??
Click to expand...
Click to collapse
I haven't sat down and looked into this too much so I'm not sure how to execute the exploit yet.
The idea I had been working on months ago was to somehow insert SU binaries into an Amazon system APK, and get it to install the modified APK as an update to an existing system app. The issue back then was the signature getting destroyed. If we can modify an Amazon system APK to contain a script to execute installation of SU binaries, the exploit might allow the APK to install as an update to an existing Amazon app and in theory install the SU binaries. Based on what little I've read, we would have to either 1) modify the existing DEX file of an Amazon system APK to contain code/script to install SU binaries or 2) create a new DEX file with the code and replace it with the original. My opinion is a better chance at the first method.
Now how to do all that using the Janus exploit? I do not yet know.
"An attacker exploiting the flaw could replace a trusted application that already has high privileges, such as a system app, with one of their updates to abuse the permissions that have already been granted. This could enable the attack to access sensitive information stored in the devices or enable the attacker to seize control over the device completely."
https://www.scmagazine.com/janus-vu...-android-50-devices-and-newer/article/713449/
So how would one go about updating a DEX file to contain 1) SU binaries that install upon 'updating' the app on installation? Or 2) clone a system app and edit or change the DEX file? 3) add an exploit script to a DEX file that would gain root (then you would install SU binaries and app)?
It seems the editing of the DEX file itself doesn't damage the signature and that's the nature of the exploit?
Hey is it possible to modify the permissions ota updater and remove the internet permissions so it can't update
I just found this https://github.com/odensc/janus don't have a computer anymore or would try it
Asadullah said:
Hey is it possible to modify the permissions ota updater and remove the internet permissions so it can't update
Click to expand...
Click to collapse
I cannot recall if I've ever tried with that APK. I have tried with others, unsuccessfully. Either the APK will fail to recompile into a proper installation file, or it would 'install', but with none of the modifications holding.
Android Flaw Lets Hackers Inject Malware Into Apps Without Altering Signatures
While installing an Android app or its update, your device checks APK header information to determine if the archive contains code in the compressed DEX files. If header says APK archive contains DEX files, the process virtual machine decompiles the code accordingly and executes it; otherwise, it runs the code as a regular APK file.
It turns out that an APK archive can contain DEX files as well as regular application code simultaneously, without affecting its validity and signatures.
Researchers find that this ability to add extra bytes of code due to lack of file integrity checking could allow attackers to prepend malicious code compiled in DEX format into an APK archive containing legitimate code with valid signatures, eventually tricking app installation process to execute both code on the targeted device without being detected.
In other words, the hack doesn't require attackers to modify the code of legitimate applications (that makes signatures invalid)—instead, the vulnerability allows malware authors to merely add some extra malicious lines of code to the original app.
Click to expand...
Click to collapse
So we would need to write a script or other code that would be placed into a Amazon System APK. Now would we be able to add SU binaries to an APK? What about a root script like DirtyCow. Although DC is patched, would that be different if the exploit was installed into the /system-priv-app and then executed? I really don't want to sound dumb here so please help me pout guys. Any feedback, negative or not is appreciated.
Maybe this tool can help https://forum.xda-developers.com/android/software/tool-dex-manager-v1-0-designed-to-play-t2988532
Robius said:
Maybe this tool can help https://forum.xda-developers.com/android/software/tool-dex-manager-v1-0-designed-to-play-t2988532
Click to expand...
Click to collapse
I can't find a working download link. Apparently it has been discontinued and i was directed to this: Uret Android Reverser Toolkit v1.6. I downloaded it.
I did find the other one but it says it's for a Galaxy Note. Not sure if that's really the case though.
DragonFire1024 said:
Android Flaw Lets Hackers Inject Malware Into Apps Without Altering Signatures
So we would need to write a script or other code that would be placed into a Amazon System APK. Now would we be able to add SU binaries to an APK? What about a root script like DirtyCow. Although DC is patched, would that be different if the exploit was installed into the /system-priv-app and then executed? I really don't want to sound dumb here so please help me pout guys. Any feedback, negative or not is appreciated.
Click to expand...
Click to collapse
It's beyond my knowledge but if you were to maybe add a script to the dex giving it the permisions I gotta look more into this
---------- Post added at 04:13 PM ---------- Previous post was at 03:54 PM ----------
DragonFire1024 said:
I can't find a working download link.
Click to expand...
Click to collapse
here's smali baksmali for editing dex files https://github.com/JesusFreke/smali I havent used it in a while but used to work good
Asadullah said:
It's beyond my knowledge but if you were to maybe add a script to the dex giving it the permisions I gotta look more into this
---------- Post added at 04:13 PM ---------- Previous post was at 03:54 PM ----------
here's smali baksmali for editing dex files https://github.com/JesusFreke/smali I havent used it in a while but used to work good
Click to expand...
Click to collapse
Editing DEX is pretty much out of my league too. I wouldn't know where to start. I don't even know how to install or use the tool you posted.
DragonFire1024 said:
Editing DEX is pretty much out of my league too. I wouldn't know where to start. I don't even know how to install or use the tool you posted.
Click to expand...
Click to collapse
https://github.com/JesusFreke/smali/wiki/DeodexInstructions
It's really pretty simple used to use it take out the ads from angry birds and what not when it first came out. But it's easier said than done. If you do try first thing I would suggest is that you decompile then recompile to see if it works right the dependencies sometimes will get you or we can try and beg another developer to make us a modified apk..... Please pretty please with sugar on topwe'll like all your posts???
Check this thread for root possibility:
https://forum.xda-developers.com/hd8-hd10/general/complete-guide-root-hd7-8-106th-gen-t3545411
Robius said:
Check this thread for root possibility:
https://forum.xda-developers.com/hd8-hd10/general/complete-guide-root-hd7-8-106th-gen-t3545411
Click to expand...
Click to collapse
FYI - nothing new in that thread. Same familiar tools/techniques targeting a different gen/suite of Amazon devices. Similar outcomes too. Vulnerability patched in FireOS 5.3.2.x as so far proven impenetrable by generic rooting tools of common origin (KingRoot, KingORoot, etc).
Davey126 said:
FYI - nothing new in that thread. Same familiar tools/techniques targeting a different gen/suite of Amazon devices. Similar outcomes too. Vulnerability patched in FireOS 5.3.2.x as so far proven impenetrable by generic rooting tools of common origin (KingRoot, KingORoot, etc).
Click to expand...
Click to collapse
Not sure if the following report is true: (HD10 7th Gen on 5.6.0.0)
https://forum.xda-developers.com/hd8-hd10/general/rooted-fire-hd-10-7th-generation-t3718629