Re-signing the system

Search This thread

ApokrifX

Senior Member
May 23, 2011
468
50
Well, you seem to have a handle on all this.
I've never heard of pkcs7 or any of its friends.
You try it once, next time you know it all. Just in case, it’s all here: http://www.openssl.org/docs/apps/openssl.html

Deleting packages.xml will result in the non-shared user ids to be assigned in order as the APKs are discovered by the PackageManager.
I.e. it won’t work in the case I mentioned?
Or it does check /data/data to see if a user was assigned already and reassigns it?
I guess, I should try it on emulator...

User ids are only used for file permissions on /data/data as far as I know.
And /data/dalvik-cache too:
ls -l /data/dalvik-cache/*apk*

BTW: Some permissions are assigned in /system/etc/permissions/platform.xml, but for uid only.
dumpsys package shows some gids too,
I was wondering where are uid assigned to gids and can we use them too?

---------- Post added at 04:01 AM ---------- Previous post was at 03:48 AM ----------

I.e. it won’t work in the case I mentioned?
Or it does check /data/data to see if a user was assigned already and reassigns it?
Oops... Apparently, well known BugOrFeature: http://xdaforums.com/showthread.php?t=522935
 

ApokrifX

Senior Member
May 23, 2011
468
50
From packages.xml
Code:
UserID	CertIndex
1000	13	com.google.android.providers.subscribedfeeds	/system/app/GoogleSubscribedFeedsProvider.apk	
1000	13	com.google.android.server.checkin	/system/app/GoogleCheckin.apk	
1000	4	android	/system/framework/framework-res.apk	
1000	4	com.android.providers.settings	/system/app/SettingsProvider.apk	
1000	4	com.android.providers.subscribedfeeds	/system/app/AccountAndSyncSettings.apk	
1000	4	com.android.settings	/system/app/Settings.apk	
1000	4	com.bn.app.crypto.server	/system/app/CryptoServer.apk	
1000	4	com.bn.authentication.svc	/system/app/BnAuthenticationService.apk	
1000	4	com.bn.demomode	/system/app/DemoMode.apk	
1000	4	com.bn.devicemanager	/system/app/DeviceManager.apk	
1000	4	com.bn.nook.quickstart	/system/app/QuickStartActivity.apk	
1000	4	com.bn.syschecksum	/system/app/SysChecksum.apk	
1000	4	com.bn.waveformdownloader.svc	/system/app/WaveformDownloader.apk
Apparently, (1000, 13) and (1000, 4) should be two different uses, right? :confused:
But according to "dumpsys package" output, they are same:

Code:
SharedUser [android.uid.system] (49e7f2a0):
    userId=1000 gids=[1015, 3003, 3002, 3001, 1007]

Code:
  Package [com.google.android.providers.subscribedfeeds] (49ee7390):
    userId=1000 gids=[]
    sharedUser=SharedUserSetting{49e7f2a0 android.uid.system/1000}
    pkg=Package{49f73f88 com.google.android.providers.subscribedfeeds}
    codePath=/system/app/GoogleSubscribedFeedsProvider.apk
    resourcePath=/system/app/GoogleSubscribedFeedsProvider.apk
    dataDir=/data/data/com.google.android.providers.subscribedfeeds
    targetSdk=7
    supportsScreens=[medium, large, small, resizeable, anyDensity]
    timeStamp=1292347460000
    signatures=PackageSignatures{49e403a0 [49eb4fd8]}
    permissionsFixed=false pkgFlags=0x1 installStatus=1 enabled=0
Code:
  Package [com.android.settings] (49ee50f8):
    userId=1000 gids=[]
    sharedUser=SharedUserSetting{49e7f2a0 android.uid.system/1000}
    pkg=Package{49eff728 com.android.settings}
    codePath=/system/app/Settings.apk
    resourcePath=/system/app/Settings.apk
    dataDir=/data/data/com.android.settings
    targetSdk=7
    supportsScreens=[medium, large, small, resizeable, anyDensity]
    timeStamp=1217592000000
    signatures=PackageSignatures{49ea84c8 [49ed6f38]}
    permissionsFixed=false pkgFlags=0x1 installStatus=1 enabled=0
Code:
# ls -l /data/data/com.google.android.providers.subscribedfeeds
drwxr-xr-x system   system            2012-01-22 17:34 lib
drwxrwx--x system   system            2012-07-01 00:03 databases
drwxrwx--x system   system            2012-01-22 20:00 files
drwxrwx--x system   system            2012-07-01 00:03 shared_prefs
Code:
# ls -l /data/data/com.android.settings
drwxr-xr-x system   system            2000-01-01 02:28 lib
drwxrwx--x system   system            2011-06-18 20:55 cache
drwxrwx--x system   system            2011-06-18 20:55 databases
drwx------ system   system            2012-01-22 17:46 files
drwxrwx--x system   system            2012-01-22 21:01 shared_prefs
 
Last edited:

rob.power

Member
Oct 31, 2012
22
6
I dunno, they are trivially convertible, try for yourself:
Unzip CERT.RSA from stock Reader.apk
Obviously (or not), CERT.RSA is pkcs7 and certs in packages.xml are hex strings x509
Let’s convert pkcs7 -> x509
Code:
openssl pkcs7 -inform DER -in CERT.RSA  -out CERT.PEM -print_certs
openssl x509  -inform PEM -in CERT.PEM -outform DER -out CERT.x509.DER

Now open CERT.x509.DER is any hex editor:
Code:
0000000000: 30 82 04 96 30 82 03 7E │ A0 03 02 01 02 02 09 00
0000000010: CF 3F 93 2A 95 18 91 A5 │ 30 0D 06 09 2A 86 48 86
...
0000000480: BF 46 EB 99 2F F8 A8 9A │ 1F 66 2D 91 4F 0C 93 FE
0000000490: 44 7D 2F D0 C2 CC DC F7 │ 5E 84
And compare with packages.xml
Code:
<cert index="5" key="308204963082037ea003020102020900cf3f932a951891a5300d06092a864886
…
bf46eb992ff8a89a1f662d914f0c93fe447d2fd0c2ccdcf75e84" />

In the case of resigning in order to let a modified ReaderRMSDK.apk to run still using the B&N sharedId, I have a couple of doubts to clarify:

  1. Do I have to resign only the system apk that uses the same sharedId (10000, cert n. 4) or the whole system folder+framework?
  2. Would it work, instead of deleting packages.xml, if we change the B&N certs reference with the hex string output from the above commands obtained using our new CERT.RSA?

EDIT: I'm gonna give my theory a try and prepare a script to make the whole process automated in case it works fine. I'll write more tomorrow if it succeed.
 
Last edited:
N

NOOK!E

Guest
In the case of resigning in order to let a modified ReaderRMSDK.apk to run still using the B&N sharedId, I have a couple of doubts to clarify:

  1. Do I have to resign only the system apk that uses the same sharedId (10000, cert n. 4) or the whole system folder+framework?
  2. Would it work, instead of deleting packages.xml, if we change the B&N certs reference with the hex string output from the above commands obtained using our new CERT.RSA?

EDIT: I'm gonna give my theory a try and prepare a script to make the whole process automated in case it works fine. I'll write more tomorrow if it succeed.

That sounds great.

Let's hope that the people who made this thread 2 years ago are still interested in this topic! :laugh:
 

rob.power

Member
Oct 31, 2012
22
6
That sounds great.

Let's hope that the people who made this thread 2 years ago are still interested in this topic! :laugh:

A brief update:
I still need to fix a few things. I'm quite conviced it should work well, but I'm still having invalid digest errors which lead to the apparent boot loop.
Code:
[...]
W/PackageParser(  992): Exception reading /system/framework/framework-res.apk
W/PackageParser(  992): java.lang.SecurityException: META-INF/CERT.SF has invalid digest for res/drawable-es-mdpi/c_quicknav_shop_normal_sm.png in /system/framework/framework-res.apk
W/PackageParser(  992): 	at java.util.jar.JarVerifier.verifyCertificate(JarVerifier.java:370)
W/PackageParser(  992): 	at java.util.jar.JarVerifier.readCertificates(JarVerifier.java:273)
W/PackageParser(  992): 	at java.util.jar.JarFile.getInputStream(JarFile.java:416)
W/PackageParser(  992): 	at android.content.pm.PackageParser.loadCertificates(PackageParser.java:327)
W/PackageParser(  992): 	at android.content.pm.PackageParser.collectCertificates(PackageParser.java:461)
W/PackageParser(  992): 	at com.android.server.PackageManagerService.collectCertificatesLI(PackageManagerService.java:2080)
W/PackageParser(  992): 	at com.android.server.PackageManagerService.scanPackageLI(PackageManagerService.java:2113)
W/PackageParser(  992): 	at com.android.server.PackageManagerService.scanDirLI(PackageManagerService.java:2051)
W/PackageParser(  992): 	at com.android.server.PackageManagerService.<init>(PackageManagerService.java:563)
W/PackageParser(  992): 	at com.android.server.PackageManagerService.main(PackageManagerService.java:336)
W/PackageParser(  992): 	at com.android.server.ServerThread.run(SystemServer.java:120)
I/PackageManager(  992): Failed verifying certificates for package:android
D/PackageManager(  992): Scanning app dir /system/app
I/PackageManager(  992): /system/app/AFfileDownloadService.apk changed; collecting certs
W/PackageParser(  992): Exception reading /system/app/AFfileDownloadService.apk
W/PackageParser(  992): java.lang.SecurityException: META-INF/CERT.SF has invalid digest for classes.dex in /system/app/AFfileDownloadService.apk
W/PackageParser(  992): 	at java.util.jar.JarVerifier.verifyCertificate(JarVerifier.java:370)
W/PackageParser(  992): 	at java.util.jar.JarVerifier.readCertificates(JarVerifier.java:273)
W/PackageParser(  992): 	at java.util.jar.JarFile.getInputStream(JarFile.java:416)
W/PackageParser(  992): 	at android.content.pm.PackageParser.loadCertificates(PackageParser.java:327)
W/PackageParser(  992): 	at android.content.pm.PackageParser.collectCertificates(PackageParser.java:461)
W/PackageParser(  992): 	at com.android.server.PackageManagerService.collectCertificatesLI(PackageManagerService.java:2080)
W/PackageParser(  992): 	at com.android.server.PackageManagerService.scanPackageLI(PackageManagerService.java:2113)
W/PackageParser(  992): 	at com.android.server.PackageManagerService.scanDirLI(PackageManagerService.java:2051)
W/PackageParser(  992): 	at com.android.server.PackageManagerService.<init>(PackageManagerService.java:569)
W/PackageParser(  992): 	at com.android.server.PackageManagerService.main(PackageManagerService.java:336)
W/PackageParser(  992): 	at com.android.server.ServerThread.run(SystemServer.java:120)
I/PackageManager(  992): Failed verifying certificates for package:com.bn.nook.affiledownloadservice
I/PackageManager(  992): /system/app/Accessories.apk changed; collecting certs
W/PackageParser(  992): Exception reading /system/app/Accessories.apk
W/PackageParser(  992): java.lang.SecurityException: META-INF/CERT.SF has invalid digest for res/drawable/s_icon_recommend.png in /system/app/Accessories.apk
[...]
By the way, when checking on my pc using "jarsigner -verify -verbose" I don't get any errors, just the same warnings I get if I check the original apks.
Code:
[ ... ]
This jar contains entries whose certificate chain is not validated.
This jar contains signatures that does not include a timestamp. Without a timestamp, users may not be able to validate this jar after the signer certificate's expiration date (2037-11-20) or after any future revocation date.
I've read around the internet that this could be due to a problem when signing using jdk7, as with this version they changed the default signing algorithm.
I will give it a try installing jdk6 to see if it works. ;)

If somebody has more suggestions about the error, they are welcome. :)
 

rob.power

Member
Oct 31, 2012
22
6
Really good news: I got it working! :victory:

I found how to correct the signature bug in JDK7. Then I had a few problem with packages.xml; I was trying to patch the old one directly with new signatures instead of just deleting it, but at first boot it underwent some weird changes becoming unable to load the UI.
Then just I changed the script to delete the file and it worked like charm, even if with some UID changes. Eventually, to avoid permissions errors, I pushed again the patched version, and now it's perfect. :cool:

Let me a day or two to review and debug the code, and hopefully before weekend it will available for download! I also want to add an option to completely automate even the previous steps of alternative dictionaries installation and maybe a way to automatically resolve any unmet dependencies.

Script is in bash, it will work on Ubuntu (and I'm quite sure any Debian-like distro, maybe even other Linux systems). Before anyone asks, I'm sorry but I'm not thinking about porting it to Windows; by the way, I'll release source code so anyone interested is welcome to port it. ;)

Stay tuned!
 
N

NOOK!E

Guest
Really good news: I got it working! :victory:

I found how to correct the signature bug in JDK7. Then I had a few problem with packages.xml; I was trying to patch the old one directly with new signatures instead of just deleting it, but at first boot it underwent some weird changes becoming unable to load the UI.
Then just I changed the script to delete the file and it worked like charm, even if with some UID changes. Eventually, to avoid permissions errors, I pushed again the patched version, and now it's perfect. :cool:

Let me a day or two to review and debug the code, and hopefully before weekend it will available for download! I also want to add an option to completely automate even the previous steps of alternative dictionaries installation and maybe a way to automatically resolve any unmet dependencies.

Script is in bash, it will work on Ubuntu (and I'm quite sure any Debian-like distro, maybe even other Linux systems). Before anyone asks, I'm sorry but I'm not thinking about porting it to Windows; by the way, I'll release source code so anyone interested is welcome to port it. ;)

Stay tuned!

Hooray! \o/

Staying tuned for sure!
 

rob.power

Member
Oct 31, 2012
22
6
It took a lot more than my prevision as I had an hard week at work.

By the way, here goes the script.
https://github.com/robpower/NookResigner
Maybe's not a coding masterpiece, but it seems to work quite well. I might have forgot some dependencies, so feedback is appreciated. Please let me know if you find any error; if possible, use github issue tracker .
PS: I will add more detailed explanation soon, even if I hope running 'NookResigned.sh -h' would be quite self explanatory.

I tried to make the script modular:
- running with no options will just resign the system;
- to add Reader patch, add -p option;
- to add dictionary conversion add the -d option
- the -r option is used to restore from backup
- the -c option will simply try to resolve dependencies.

Enjoy it! Cheers ;)

EDIT: as stated in readme, many thanks to RenateRST and ApokrifX; this "user-friendly" script is based on their previous work and suggestions.
 
Last edited:
  • Like
Reactions: ApokrifX and Thor55
N

NOOK!E

Guest
It took a lot more than my prevision as I had an hard week at work.

By the way, here goes the script.
https://github.com/robpower/NookResigner
Maybe's not a coding masterpiece, but it seems to work quite well. I might have forgot some dependencies, so feedback is appreciated. Please let me know if you find any error; if possible, use github issue tracker .
PS: I will add more detailed explanation soon, even if I hope running 'NookResigned.sh -h' would be quite self explanatory.

I tried to make the script modular:
- running with no options will just resign the system;
- to add Reader patch, add -p option;
- to add dictionary conversion add the -d option
- the -r option is used to restore from backup
- the -c option will simply try to resolve dependencies.

Enjoy it! Cheers ;)

EDIT: as stated in readme, many thanks to RenateRST and ApokrifX; this "user-friendly" script is based on their previous work and suggestions.

Good work! :D

I'll test it out tomorrow if I have time.
 

ApokrifX

Senior Member
May 23, 2011
468
50
It took a lot more than my prevision as I had an hard week at work.
By the way, here goes the script.
EDIT: as stated in readme, many thanks to RenateRST and ApokrifX; this "user-friendly" script is based on their previous work and suggestions.
It's been a while since I visited NST forums. It's nice to see, it's alive and kicking still! :good:
 

Aqq123

Senior Member
Aug 27, 2009
291
353
Google Nexus 4
Nexus 7
[Q] Resigning revisited, re-simplified

Thank you for this very interesting thread and discussion. I've simplified the problem for myself a little. Namely:
  1. I'm patching the APKs before they're even installed. At that time there's no /data/system/packages.xml (in fact there's no /data anything), so the whole endeavour to fix the metadata there is moot. I just let Android create it with whatever values it is happy with.
  2. I sign all the APKs with the same key. I guess it's probably not a great idea security-wise but then so is running Android 2.1 in 2015 in the first place, so if it's just this, I find the associated "risks" acceptable.
  3. I use the Android debug testkey.{pk8,x509.pem} so that I don't need to bother creating my own keys.
So far it appears to work and the logcat seems clean but I didn't debug it extensively. I'd appreciate some feedback on the above. Are there any caveats I have failed to notice so far?

Plus two minor questions:
  • What is this JDK7 "bug" thing? Is it about JDK7 using SHA256withRSA by default, or is there something else?
  • Perhaps not too important in terms of advancing the topic but why does everyone here seem to use Jarsigner and not SignApk?
Comments are appreciated.
 

Renate

Recognized Contributor / Inactive Recognized Dev
What is this JDK7 "bug" thing? Is it about JDK7 using SHA256withRSA by default, or is there something else?
I believe that the real problem was in the dx.bat conversion of JVM 7 code to Dalvik code.
It appears that the current build tools can now do that without a problem.
Newer Android can accept signing with SHA256.
Older versions still can only use SHA1.
I don't know where the dividing line between old and new is.
 
  • Like
Reactions: Aqq123

Top Liked Posts

  • There are no posts matching your filters.
  • 2
    Various aspects of the Nook system are signed with a signature from Barnes & Noble.
    There are a few places where signatures are compared.
    Various system apps used a single "shared id" and they must all have the same signature.
    /system/framework/framework-res.apk must have a correct signature with respect to AndroidManifest.xml.
    In any case, it's your Nook, what are you going to do?

    Re-signing the system

    • make a full backup and make sure that it is good
    • create your own signature http://developer.android.com/tools/publishing/app-signing.html
    • make a directory for your patch
    • create the subdirectory META-INF\com\google\android\
    • put a copy of update-binary in there
    • write a updater-script and put it in there
    • create the subdirectory system\app
    • create the subdirectory system\framework
    For each of your APKs in /system/app and also /system/framework/framework-res.apk:
    • unzip them somewhere
    • delete the whole directory META-INF from them
    • zip the directory
    • jarsigner them with your own personal signature
    • zipalign the APK (optional if you are lazy and don't see the point)
    • put it in the appropriate patch directory
    Then:
    • zip the patch directory
    • copy it to your SD card
    • make sure that your WiFi is turned on if you are using ADB over WiFi!
    • recovery boot using ClockworkMod
    • install the patch from SD card
    • reboot
    updater-script
    Code:
    # Replace signed components
    mount("ext2", "/dev/block/mmcblk0p5", "/system");
    package_extract_dir("system/app", "/system/app");
    package_extract_dir("system/framework", "/system/framework");
    unmount("/system");
    
    # Delete packages.xml
    mount("ext3", "/dev/block/mmcblk0p8", "/data");
    delete("/data/system/packages.xml");
    unmount("/data");

    Flies in the ointment, caveats, etc...

    The packages.xml contains some form of certs that have all changed.
    Right now, the simplest way I know to deal with this is just to delete packages.xml.
    The problem is, this will break most user applications since the user IDs will no longer agree.
    The easiest thing to do is just to reinstall them.
    For applications with a lot of data, it would be best to back up the configs or data.

    When you first boot up, you may think that you are in a "boot loop".
    The boot animation will run continuously.
    If you have ADB connect still (and you had better!) you can fix this.
    Your launcher application is probably causing lots of error on startup.

    There are two ways to fix the problem with the launcher (or any other app)
    • uninstall and reinstall it
    • go into /data/data/com.myapp.whatever and chown everything to the user id of the application.
      Code:
      busybox chown -R 10011: databases
      Don't chown the lib directory if there is one.
    Then you should have a device that boots up normally.

    Good luck, Mr. Phelps. :D
    2
    It took a lot more than my prevision as I had an hard week at work.

    By the way, here goes the script.
    https://github.com/robpower/NookResigner
    Maybe's not a coding masterpiece, but it seems to work quite well. I might have forgot some dependencies, so feedback is appreciated. Please let me know if you find any error; if possible, use github issue tracker .
    PS: I will add more detailed explanation soon, even if I hope running 'NookResigned.sh -h' would be quite self explanatory.

    I tried to make the script modular:
    - running with no options will just resign the system;
    - to add Reader patch, add -p option;
    - to add dictionary conversion add the -d option
    - the -r option is used to restore from backup
    - the -c option will simply try to resolve dependencies.

    Enjoy it! Cheers ;)

    EDIT: as stated in readme, many thanks to RenateRST and ApokrifX; this "user-friendly" script is based on their previous work and suggestions.
    1
    What is this JDK7 "bug" thing? Is it about JDK7 using SHA256withRSA by default, or is there something else?
    I believe that the real problem was in the dx.bat conversion of JVM 7 code to Dalvik code.
    It appears that the current build tools can now do that without a problem.
    Newer Android can accept signing with SHA256.
    Older versions still can only use SHA1.
    I don't know where the dividing line between old and new is.