Thread Closed

[UTIL][08.12.11] Apktool v1.4.3 - a tool for reverse engineering apk files

14th July 2010, 01:54 AM   |  #501  
Daneshm90's Avatar
Recognized Developer
Thanks Meter: 636
 
3,309 posts
Join Date:Joined: Jun 2009
Quote:
Originally Posted by raidzero

same thing, here is an updated logcat: http://pastebin.com/6MdHgiWt

K try taking the original AndroidManifest.xml and putting it in 2 ur modified apk.
14th July 2010, 01:57 AM   |  #502  
Senior Member
Thanks Meter: 50
 
133 posts
Join Date:Joined: Dec 2008
Quote:
Originally Posted by Daneshm90

K try taking the original AndroidManifest.xml and putting it in 2 ur modified apk.

I wil have to get back to you tomorrow, I am off to bed right now.. thanks for your help!
14th July 2010, 08:27 AM   |  #503  
OP Recognized Developer
Thanks Meter: 336
 
1,467 posts
Join Date:Joined: Jul 2009
More
About size differences: no magic here, you could easily compare two files and find by yourself, what is going on. Apktool doesn't compress resources.arsc file - that's all. I have an issue about that: http://code.google.com/p/android-apk...s/detail?id=67

About certs issues: I'm not an expert of system modifications, but I always replace framework-res.apk file through update.zip method. This is only way I know, that works.
14th July 2010, 12:43 PM   |  #504  
Senior Member
Thanks Meter: 50
 
133 posts
Join Date:Joined: Dec 2008
Quote:
Originally Posted by Brut.all

About size differences: no magic here, you could easily compare two files and find by yourself, what is going on. Apktool doesn't compress resources.arsc file - that's all. I have an issue about that: http://code.google.com/p/android-apk...s/detail?id=67

About certs issues: I'm not an expert of system modifications, but I always replace framework-res.apk file through update.zip method. This is only way I know, that works.

Thanks for the info. I have never applied a framework-res.apk through update.zip, I just use adb to push it in recovery. Looks like I will be turning to the old hex-editor.
14th July 2010, 01:51 PM   |  #505  
Daneshm90's Avatar
Recognized Developer
Thanks Meter: 636
 
3,309 posts
Join Date:Joined: Jun 2009
Quote:
Originally Posted by Brut.all

About size differences: no magic here, you could easily compare two files and find by yourself, what is going on. Apktool doesn't compress resources.arsc file - that's all. I have an issue about that: http://code.google.com/p/android-apk...s/detail?id=67

About certs issues: I'm not an expert of system modifications, but I always replace framework-res.apk file through update.zip method. This is only way I know, that works.

Hmmm, cool so its just a compression issue.

As for the certs for system apks, i think core only cares about the signatures being the same and the manifest.xml being the same, other than that u can change everything else as long as u include the original META-INF folder and AndroidManifest.xml. Now im speaking not from technical knowledge but experience, so dont take my words literally. I still don't get why update.zip method is working for u guys but pushing it and restarting doesnt. Like when u sign an update.zip ur not signing the apks within it and all update.zip's do is push the file to ur phone, so the only plausible explanation i can think of is that pushing framework-res while core is running is a lot riskier than pushing when core is not.

As a test if u want to try, pull /system/app/Contacts.apk. Decompile it, modify something in androidmanifest.xml and recompile it. Include the original META-INF folder and push it to ur phone. In the log u'll see "digest for manifest.xml doesnt match or w/e". Now u can change essentially anything else in the apk (xmls,images...) and recompile and as long as u include the META-INF folder and AndroidManifest.xml, it wont complain.

Now brut heres my question, does the update.zip method work if u edit the manifest.xml of a system apk ?
14th July 2010, 02:20 PM   |  #506  
OP Recognized Developer
Thanks Meter: 336
 
1,467 posts
Join Date:Joined: Jul 2009
More
Quote:
Originally Posted by raidzero

Thanks for the info. I have never applied a framework-res.apk through update.zip, I just use adb to push it in recovery. Looks like I will be turning to the old hex-editor.

Apktool really doesn't do anything unusual. It just builds apk file in the similar way as Android SDK does. I don't understand, why apktoold' apk would behave differently than hex-edited one.

Ahh and I can't push framework-res.apk file after hex-editing as well - certs problems.

Quote:
Originally Posted by Daneshm90

I still don't get why update.zip method is working for u guys but pushing it and restarting doesnt. Like when u sign an update.zip ur not signing the apks within it and all update.zip's do is push the file to ur phone, so the only plausible explanation i can think of is that pushing framework-res while core is running is a lot riskier than pushing when core is not.

Some time ago I was talking about this with JesusFreke: he said that if you replace framework-res.apk file and new file will have exactly the same modify time as original one, then system won't even look at certs. update.zip method keeps all meta data of a original file - simple pushing overwrites them.

People use this update.zip trick because it's easy to use and you don't need any tools on recovery side, so it's platform-independent.

Quote:
Originally Posted by Daneshm90

Now brut heres my question, does the update.zip method work if u edit the manifest.xml of a system apk ?

Yeah, it works perfectly ok.

I think you may be right that Android checks only manifest digests. This would explain, why apktoold' apk would be treated differently than hex-edited one - after using apktool AndroidManifest.xml will always differ, even if you didn't modify it.

I want to fix these issues in apktool, but first I must know, what is going on exactly. If you're right, then apktool could copy original AndroidManifest.xml file if it wasn't modified. And if it was, then it will warn you, that you can't just push resulting apk, but use update.zip method.
Last edited by Brut.all; 14th July 2010 at 02:22 PM.
14th July 2010, 02:38 PM   |  #507  
Daneshm90's Avatar
Recognized Developer
Thanks Meter: 636
 
3,309 posts
Join Date:Joined: Jun 2009
Quote:
Originally Posted by Brut.all

Some time ago I was talking about this with JesusFreke: he said that if you replace framework-res.apk file and new file will have exactly the same modify time as original one, then system won't even look at certs. update.zip method keeps all meta data of a original file - simple pushing overwrites them.

Damn that dude knows way too much Finally some technical info that make sense.

Ok so now update.zip makes sense, so essentially even mounting in recovery/pushing file would work.

So wht it comes down to is if ur modifying anything besides AndroidManifest.xml, ur free to push it to ur phone, but if ur editing that xml then u have to resort to alternatives.

I know theres one more way i remember seeing someone use.

U can "adb shell stop"
Push the file to ur phone
Then "adb shell start"

This should stay true to wht Jesusfreke said as it stops core, so modify time will remain same when u start it again.

Hmm yea so it could check whether manifest was changed, if it was warn the user that simply pushing this wont work, he must create an update.zip/push it in recovery. Also perhaps u cud introduce a new parameter "-s" where if used it signifies that u are modifying a system apk and hence apktool will preserve the META-INF folder ?
14th July 2010, 03:44 PM   |  #508  
Junior Member
Thanks Meter: 0
 
29 posts
Join Date:Joined: Mar 2010
More
Ok...so putting the manifest.xml AND the META INF folder from the original framework-res into the recompiled framework-res worked!! It booted. Now just need to solve the resources compression issue.

Thanks guys, you have been great and very responsive.
14th July 2010, 11:52 PM   |  #509  
dully79's Avatar
Recognized Themer
Flag Durham/Liverpool
Thanks Meter: 3,194
 
2,728 posts
Join Date:Joined: Apr 2010
Donate to Me
More
Does anyone have an idea how to resolve these errors?

"C:\Documents and Settings\Mark>apktool d C:\org.fagod.wfc_widget.apk C:\wfc
I: Baksmaling...
I: Loading resource table...
I: Decoding resources...
I: Loading resource table from file: C:\Documents and Settings\Mark\apktool\fram
ework\1.apk
S: Could not decode file "drawable/panel_background.9.png" to "drawable/panel_ba
ckground.9.png"
S: Could not decode file "drawable/widget_bg_normal.9.png" to "drawable/widget_b
g_normal.9.png"
S: Could not decode file "drawable/widget_bg_pressed.9.png" to "drawable/widget_
bg_pressed.9.png"
S: Could not decode file "drawable/widget_bg_selected.9.png" to "drawable/widget
_bg_selected.9.png"
I: Copying assets and libs..."
15th July 2010, 01:00 AM   |  #510  
Junior Member
Thanks Meter: 0
 
29 posts
Join Date:Joined: Mar 2010
More
Quote:
Originally Posted by dully79

Does anyone have an idea how to resolve these errors?

"C:\Documents and Settings\Mark>apktool d C:\org.fagod.wfc_widget.apk C:\wfc
I: Baksmaling...
I: Loading resource table...
I: Decoding resources...
I: Loading resource table from file: C:\Documents and Settings\Mark\apktool\fram
ework\1.apk
S: Could not decode file "drawable/panel_background.9.png" to "drawable/panel_ba
ckground.9.png"
S: Could not decode file "drawable/widget_bg_normal.9.png" to "drawable/widget_b
g_normal.9.png"
S: Could not decode file "drawable/widget_bg_pressed.9.png" to "drawable/widget_
bg_pressed.9.png"
S: Could not decode file "drawable/widget_bg_selected.9.png" to "drawable/widget
_bg_selected.9.png"
I: Copying assets and libs..."

I have seen that when the 9patches being decompiled were not properly formed (i.e. missing the stretch ticks). Usually happens when someone just changes the color of a 9patch and doesn't redraw the ticks and recompile. When the decompiler runs, it can't find the ticks so it can't decode them

That's my theory and I'm stickin to it....

Thread Closed Subscribe to Thread

Tags
apk, apktool, reengineering, resources, xml
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes