Ok, so from what I gathered is that all HTC's new RUU's for JellyBean has a new zip protection. This thread is for some ideas to try to find a way to get around and/or fix this problem.
From the EVTARE 1.15.502.9 RUU, I get this output trying to unzip:
Code:
unzip 'rom.zip'
Archive: rom.zip
warning [rom.zip]: 384 extra bytes at beginning or within zipfile
(attempting to process anyway)
file #1: bad zipfile offset (local header sig): 384
(attempting to re-compensate)
file #1: bad zipfile offset (local header sig): 384
file #2: bad zipfile offset (local header sig): 939275
(attempting to re-compensate)
file #2: bad zipfile offset (local header sig): 939275
file #3: bad zipfile offset (local header sig): 939844
file #4: bad zipfile offset (local header sig): 940066
inflating: recovery_signed.img
error: invalid compressed data to inflate
inflating: system.img
error: invalid compressed data to inflate
inflating: userdata_16g.img bad CRC 04e7f027 (should be de5e140e)
inflating: userdata_32g.img
error: invalid compressed data to inflate
inflating: splash1.nb0
inflating: tp.img
inflating: ramdisk.img
inflating: wlan.img
inflating: rawpt_16g.img
inflating: rawpt_32g.img
inflating: pg3fs_spcustom.img
inflating: mdm9k.img
error: invalid compressed data to inflate
inflating: u64g.hdr
inflating: u32g.hdr
inflating: u16g.hdr
inflating: u32gr.hdr
inflating: bct.img
inflating: userdata_64g.img
inflating: userdata_32g_resv.img
inflating: rawpt_64g.img
Here's from the VILLEPLUS 1.14.709.16 RUU:
Code:
unzip 'rom.zip'
Archive: rom.zip
warning [rom.zip]: 384 extra bytes at beginning or within zipfile
(attempting to process anyway)
file #1: bad zipfile offset (local header sig): 384
(attempting to re-compensate)
file #1: bad zipfile offset (local header sig): 384
file #2: bad zipfile offset (local header sig): 408146
(attempting to re-compensate)
file #2: bad zipfile offset (local header sig): 408146
file #3: bad zipfile offset (local header sig): 408689
inflating: rcdata.img
inflating: boot_signed.img
inflating: recovery_signed.img
inflating: system.img bad CRC 35922281 (should be 9a30ea6e)
inflating: splash1.nb0
inflating: dzdata_16g.img
error: invalid compressed data to inflate
inflating: dzdata_16g.hdr
inflating: sbl2.img
inflating: sbl3.img
inflating: tz.img
inflating: rpm.img
inflating: adsp.img
inflating: pg2fs_spcustom.img
inflating: wcnss.img
error: invalid compressed data to inflate
file #18: bad zipfile offset (local header sig): 651011233
inflating: sbl1-1.img
inflating: sbl1-2.img
inflating: sbl1-3.img
inflating: dzdata_64g.hdr
inflating: cs_cypress_smart.img
inflating: dzdata_64g.img
error: invalid compressed data to inflate
So at a glance it seems they're using an offset or something that makes the zip corrupt.
Hopefully you guys can help and we can get this problem fixed. I won't even start on how this tactic is stupid on HTC's part.
so far i have tried using DD to strip bad bits / bytes out of the file and it still is corrupted
you can strip the first ammount of bytes
Code:
Today I had to remove the first 1131 bytes from an 800MB mixed text / binary file, a filtered subversion dump I'm hacking for a new repository. What's the best way to do this?
To start with I tried
dd bs=1 skip=1131 if=filtered.dump of=trimmed.dump
but after the skip this copies the remainder of the file a byte at a time, i.e. very slowly. In the end I worked out I needed 405 bytes to round this up to three blocks of 512 which I could skip
dd if=/dev/zero of=405zeros bs=1 count=405
cat 405zeros filtered.dump | dd bs=512 skip=3 of=trimmed.dump
which completed fairly quickly but there must have been a simpler / better way? Is there another tool I've forgotten about? Thanks!
got past alot of the bad header files
but i think there is an algorithm inside the .exe that will tell us what we want
also when trying to flash these RUU's it looks on your device for a sigcheck
if you are able to successfully run the RUU
does the system cache the system.img somewhere?? or does it extract it to the unit
same with CYGWIN
same with CYGWIN
with ext2explore only system files folder/ apps extracted
467 MB (490,099,471 bytes
516 Files, 2 Folders
second folder bin is empty
carl1961 said:
same with CYGWIN
with ext2explore only system files folder/ apps extracted
467 MB (490,099,471 bytes
516 Files, 2 Folders
second folder bin is empty
Click to expand...
Click to collapse
its looking right now as if we need to figure out how to repack the CRC and remove those 384 misc byte?
Beyond Compare Failed too
Yeah. It looks like they're purposely corrupting the zips. The only thing I find common is 384 offset.
Sent from my HTC One XL using Tapatalk 2
i think its a set of data to be stripped from the actual file
if we find the data to strip i feel it will resolve the other unzipping problems
now
where to find this data to strip
Maybe extract the exe and the cab to find out
Sent from my HTC One XL using Tapatalk 2
I uploaded what cygwin un ziped if you can use it
http://d-h.st/QQS
romcygwin.zip
I copyed rom.zip to phone and tryed with term console and busybox complained
are these still with corrupted System.img?
Zarboz said:
are these still with corrupted System.img?
Click to expand...
Click to collapse
yes thats what was unziped
carl1961 said:
yes thats what was unziped
Click to expand...
Click to collapse
jw did any one else have success with dd if=
and removing the first 384 bytes in the file?
I don't really think that "corrupted" is good name for that. They are not corrupted, because device can read and extract it properly. I think this is a mechanism of faked checksums inside or maybe HTC wrote some small app for Linux and a password or special keyfile might be required.
mike1986. said:
I don't really think that "corrupted" is good name for that. They are not corrupted, because device can read and extract it properly. I think this is a mechanism of faked checksums inside or maybe HTC wrote some small app for Linux and a password or special keyfile might be required.
Click to expand...
Click to collapse
Yeah. It would make sense
Sent from my HTC One XL using Tapatalk 2
Did have a quick look, HTC have messed with it, they've done their own thing to it. If it was a normal corrupt zip afaik it would still start with Pk showing its a zip file
but this doesnt start with pk
Also you have this [email protected] & RUU version number 1.14.709.16 within the zip
They clearly messed with the file.
Think diamondback/flemmard/chainfires needed for this one
I could get most of it extracted, 4 failed due to data error and the only 1 failed due to CRC error was the main system.img
Shaky156 said:
Did have a quick look, HTC have messed with it, they've done their own thing to it. If it was a normal corrupt zip afaik it would still start with Pk showing its a zip file
but this doesnt start with pk
Also you have this [email protected] & RUU version number 1.14.709.16 within the zip
They clearly messed with the file.
Think diamondback/flemmard/chainfires needed for this one
I could get most of it extracted, 4 failed due to data error and the only 1 failed due to CRC error was the main system.img
Click to expand...
Click to collapse
Yeah. The offset of 384 is constant throughout all the zips. But yes, we'll need some real help.
Sent from my HTC One XL using Tapatalk 2
mike1986. said:
I don't really think that "corrupted" is good name for that. They are not corrupted, because device can read and extract it properly. I think this is a mechanism of faked checksums inside or maybe HTC wrote some small app for Linux and a password or special keyfile might be required.
Click to expand...
Click to collapse
i agree
i feel as tho it does a sig check on the device and decrypts the .zip with the coresponding "pub" / "priv" key on the device
Tried extracting it yesterday and the only solid thing I got was /system/app/ through cygwin. None of the other /bin/ or /framework/ files or anything for that matter other than app succeeded.
Why would they even do it in the first place is beyond me.
usaff22 said:
Tried extracting it yesterday and the only solid thing I got was /system/app/ through cygwin. None of the other /bin/ or /framework/ files or anything for that matter other than app succeeded.
Why would they even do it in the first place is beyond me.
Click to expand...
Click to collapse
to stop custom roms of JB, also to increase people upgrading there phone $$$
I was able to extract the app folder but the the rest of the folders in the system.img gave me errors and I couldn't look in the build.prop it froze up the application that I was using. I think the answer to our problem is in the build.prop. Just throwing out and idea.
Does anyone know how to extract the exe with out running it?
Related
So, as the title says a simple bash script to convert a dream rom to a sapphire rom.
To make this work you need unpack / repack boot img utilities from here:
http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images
testsign.jar from here:
http://forum.xda-developers.com/showpost.php?p=4008431&postcount=15
mkbootimg from here:
http://forum.xda-developers.com/showpost.php?p=3387504&postcount=26
since I'm a nice guy I've included these in the attached zip file.
extract the attached zip file into a folder (warning: make sure there's no spaces in the folder name!!) then run:
Code:
./convert.sh your_dream_rom.zip
this will:
extract the boot.img from the zip
unpack the boot image
rename init.trout.rc to init.sapphire.rc
repack the boot image
put the boot image back into a copy of the dream rom zip
NEW!! in v3: add anything in the 'addin' folder into the zip (see below)
resign the new zip
you'll be left with your_dream_rom-sapphire.zip which should (hopefully) work on the sapphire.
v3: new addin folder. Anything in this folder will be added to the resulting zip, overwriting if needed. So if you want to replace (for example) /system/etc/AudioPara4.csv just put the file in /addin/system/etc and it will automagically be merged in.
Deicist said:
So, as the title says a simple bash script to convert a dream rom to a sapphire rom.
To make this work you need unpack / repack boot img utilities from here:
http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images
testsign.jar from here:
http://forum.xda-developers.com/showpost.php?p=4008431&postcount=15
since I'm a nice guy I've included these in the attached zip file.
You'll also need to compile the mkbootimg executable that (I think!) comes with the android source.
extract the attached zip file inot a folder then run:
Code:
./convert.sh your_dream_rom.zip
this will:
extract the boot.img from the zip
unpack the boot image
rename init.trout.rc to init.sapphire.rc
repack the boot image
put the boot image back into a copy of the dream rom zip
resign the new zip
you'll be left with your_dream_rom-sapphire.zip which should (hopefully) work on the sapphire.
attached is a zip file containing everything you need except mkbootimg, since that needs to be compiled for your system.
Please note, I don't have a compiled copy of mkbootimg for my system, so I haven't been able to try the full process... but extracting and repacking the zip works, signing seems to work... and it's a pretty simple script so I can't see why it wouldn't work.
Enjoy!
Click to expand...
Click to collapse
Thanks! Do I need a boot.img and wlan.ko for pvt32A if I want it to work?
it won't work for 32a, but I'm sure you can mod the script to add in a new boot.img and radio thingy.
updated initial post with new attachment:
added mkbootimg to zip file
changed script slightly.
in case anyone was wondering, I tried this script on Drizzy's "superlight hero" rom from the dream forum and it worked perfectly.
[email protected]:~$ /home/ubuntu/Desktop/a/convert.sh Personal.zip
unzip: cannot find or open ./Personal.zip, ./Personal.zip.zip or ./Personal.zip.ZIP.
/home/ubuntu/Desktop/a/convert.sh: 3: ./unpack-bootimg.pl: not found
rm: Entfernen von „boot.img“ nicht möglich: No such file or directory
mv: Aufruf von stat für „./boot.img-ramdisk/init.trout.rc“ nicht möglich: No such file or directory
/home/ubuntu/Desktop/a/convert.sh: 6: ./repack-bootimg.pl: not found
cp: Aufruf von stat für „./Personal.zip“ nicht möglich: No such file or directory
zip warning: name not matched: boot.img
zip error: Nothing to do! (update.zip)
/home/ubuntu/Desktop/a/convert.sh: 9: java: not found
rm: Entfernen von „./boot.img-ramdisk“ nicht möglich: No such file or directory
rm: Entfernen von „boot.img-kernel.gz“ nicht möglich: No such file or directory
rm: Entfernen von „boot.img-ramdisk.cpio.gz“ nicht möglich: No such file or directory
rm: Entfernen von „update.zip“ nicht möglich: No such file or directory
Click to expand...
Click to collapse
What do i wrong ... ?
No idea, according to the error message it says it can't find 'Personal.zip'... is that file present in the same directory as 'convert.sh' ?
yes it is ...
can anyone convert this boot.img ... so that i can use on 32b?
you need to actually change directory to the directory containing the utility to run it.
try:
cd /home/ubuntu/Desktop/a/
./convert.sh Personal.zip
is ist possible that it doesn't work because i'm using the live cd now?
now it says
Archive: ./Personal.zip
inflating: ./boot.img
kernel written to ./boot.img-kernel.gz
ramdisk written to ./boot.img-ramdisk.cpio.gz
472 blocks
extracted ramdisk contents to directory ./boot.img-ramdisk/
472 blocks
sh: mkbootimg: not found
repacked boot image written at ./boot.img-ramdisk-repack.img
zip error: Nothing to do! (update.zip)
Click to expand...
Click to collapse
but mkbootimg is in this directory
This is what I end up getting. I ended up using a precompiled binary of mkbootimg for OSX since it didn't work on my Linux box.
./convert.sh NewVision_2.8.zip
Archive: ./NewVision_2.8.zip
inflating: ./boot.img
kernel written to ./boot.img-kernel.gz
ramdisk written to ./boot.img-ramdisk.cpio.gz
extracted ramdisk contents to directory ./boot.img-ramdisk/
usage: cpio -o [-aABcLvVzZ] [-C bytes] [-H format] [-O archive]
[-F archive] < name-list [> archive]
cpio -i [-bBcdfmnrsStuvVzZ6] [-C bytes] [-E file] [-H format]
[-I archive] [-F archive] [pattern...] [< archive]
cpio -p [-adlLmuvV] destination-directory < name-list
repacked boot image written at ./boot.img-ramdisk-repack.img
updating: boot.img (deflated 1%)
Exception in thread "main" java.lang.UnsupportedClassVersionError: testsign (Unsupported major.minor version 50.0)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:539)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:251)
at java.net.URLClassLoader.access$100(URLClassLoader.java:55)
at java.net.URLClassLoader$1.run(URLClassLoader.java:194)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274)
at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
Hello,
MarcoNieddu said:
extracted ramdisk contents to directory ./boot.img-ramdisk/
472 blocks
sh: mkbootimg: not found
Click to expand...
Click to collapse
You have to modify the script repack-bootimg.pl at line 19 :
replace : system ("mkbootimg ...
by : system ("./mkbootimg ...
Note the ./ before mkbootimg
Scargoll.
Got everything working.
1. Add ./ to the repack script before mkbootimg
2. make sure you have a 32bit OS, as the binary provided was compiled for it. I made an Intrepid machine on my VM server.
3. Use the latest version of Java. Even Karmic Koala Ubuntu doesn't have it. The class file in the jar was compiled with a very recent version of Java, so you'll error out since the jre version isn't equal to or above whats needed. You can simply do "export JAVAHOME=pathtojava" if you don't want to keep that version permanently.
4. Have fun!
Bugfixes:
removes boot.img when script is done
added ./ before mkbootimg (sorry!)
the provided mkbootimg *should* work on a 64bit machine, it does on my 64 bit arch linux box...as with all things linux though, YMMV.
I ve tried to convert a dream rom but it didn't work, does this method can be applied from a windows command shell ?
EDIT: can I take a dream rom, flash it, and push a boot.img from a hero 32B rom ?
EDIT2: Ok now that I have read the name of the topic I understand it wont work in windows. So here's my new question...
Is there a way to adapt this script (or to create something similar) so it works with windows ?
updated with 'addin' feature
ElChouch said:
Is there a way to adapt this script (or to create something similar) so it works with windows ?
Click to expand...
Click to collapse
A windows version would be great!
Nice work Deicist. Thanks for sharing.
some facts:
- i'm running Windows 7 RC (64-bit)
- i installed Cygwin and executed it as administrator
- i browse out to the correct folder where the rom zip file is located
i get the following errors. any suggestions?:
$ ./convert.sh modaco_hero.zip
unzipping...
./convert.sh: line 3: unzip: command not found
unpacking boot image
./convert.sh: ./unpack-bootimg.pl: /usr/bin/perl: bad interpreter: Permission de
nied
moving trout to sapphire
mv: cannot stat `./boot.img-ramdisk/init.trout.rc': No such file or directory
repacking boot image
./convert.sh: ./repack-bootimg.pl: /usr/bin/perl: bad interpreter: Permission de
nied
re-zipping
./convert.sh: line 12: zip: command not found
rm: cannot remove `boot.img': No such file or directory
Addin files found....
./convert.sh: line 18: zip: command not found
Re-signing zip (this may take a while)
tidying up
rm: cannot remove `./boot.img-ramdisk': No such file or directory
rm: cannot remove `boot.img-kernel.gz': No such file or directory
rm: cannot remove `boot.img-ramdisk.cpio.gz': No such file or directory
all done
Make it work on Fedora
Was having problems with this script working at the java part on a FC10 box.
Was able to get it to work by installing java-1.6.0-openjdk:
Code:
$ yum install java-1.6.0-openjdk
just posting that here in case anyone who needs it stumbles by.
Thanks for your great script Deicist
I'm getting this error. What am I doing wrong?
Exception in thread "main" java.lang.NoClassDefFoundError: testsign
at java.lang.Class.initializeClass(libgcj.so.90)
Caused by: java.lang.ClassNotFoundException: sun.security.x509.AlgorithmId not found in gnu.gcj.runtime.SystemClassLoader{urls=[file:testsign.jar], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
at java.net.URLClassLoader.findClass(libgcj.so.90)
at gnu.gcj.runtime.SystemClassLoader.findClass(libgcj.so.90)
at java.lang.ClassLoader.loadClass(libgcj.so.90)
at java.lang.ClassLoader.loadClass(libgcj.so.90)
at java.lang.Class.initializeClass(libgcj.so.90)
Hi Expert
I am using the following script to extract initramfs from zImage of a samsung galaxy GT19000
Here is the zImage , i untar it
http://www.multiupload.com/UIYD3X6SHF
and here is the script
http://forum.xda-developers.com/wiki/index.php?title=Extract_initramfs_from_zImage
but when i run it , got error
[email protected]:~/android/samsung/initramfs$ ./initramfs_extractor.sh zImage
-I- Extracting kernel image from zImage (start = 16541)
5712415+0 records in
5712415+0 records out
5712415 bytes (5.7 MB) copied, 100.88 s, 56.6 kB/s
gzip: stdin: decompression OK, trailing garbage ignored
-I- Extracting compressed cpio image from kernel image (start = 777014)
gzip: stdin: invalid compressed data--format violated
-I- Extracting initramfs image from /tmp/cpio.img (start = , end = 11)
dd: invalid number `'
Using this method http://forum.xda-developers.com/showthread.php?t=777380
works , i guess somehow script thought initramfs is in compress format when it is not .
Thanks
Hi,
Newbie question for the TF101G. I just installed the OTA 9.2.2.4 update.
I am trying to obtain the blob (or update.zip) from the tablet itself. I tried:
dd if=/dev/block/mmcblk0p4 of=/sdcard/blob_9.2.2.4_extract bs=4096
That pulls out a 555,220,992 byte file ( similar to the 546,812,660 of the official 9.2.2.3 blob extracted from the update.zip).
But this blob doesn't seem to be a valid blob that blobunpack can unpack:
$ ./blobunpack.exe blob_9.2.2.4_extract
Unsupport blob file format
The blob from the update.zip can be unpacked fine.
I can even do with any pointers on how to get the recovery.img file from the partitions. I see that the following is the partition information:
9.2.2.4:
mmcblk0p1 - 536 MB, 536870912 bytes - System
mmcblk0p2 - 555 MB, 555220992 bytes -
mmcblk0p3 - 2 MB, 2097152 bytes -
mmcblk0p4 - 555 MB, 555220992 bytes - Blob (?)
mmcblk0p5 - 5 MB, 5242880 bytes- Recovery (?)
mmcblk0p6 - 0 MB, 524288 bytes
mmcblk0p7 - 29.2 GB, 29249503232 bytes - Data
Should this command give a valid recovery.img?
dd if=/dev/block/mmcblk0p5 of=recovery.img bs=4096
I can then create the recovery blob from this recovery.img file.
Basically I am trying to take a backup of the recovery partition before I flash CWM to it.
Thanks in advance.
The blob will be zipped in /cache/dlpkgfile, although I think it gets deleted after the update.
If the blob is still in staging, then you might have copied too much from the staging partition. A valid blob will start with something like msm radio update with some letter and numbers to indicate where all the blob pieces are located. Decypher those to calculate the end of the blob file and snip snip snip.
sent while running with scissors
Lastly, keep in mind the blob parts in the update will usually be the kernel, boot.img, and recovery. The actual rom is in the update as either patches to existing files or replacements.
sent while running with scissors
Success
gee one said:
The blob will be zipped in /cache/dlpkgfile
Click to expand...
Click to collapse
Thanks for that piece of information. I downgraded to 9.2.2.3 just to grab this file. Unzipped it and extracted the 9.2.2.4 blob from it.
Then I extracted the recovery.img from this blob and converted it to a standalone blob.
Then I applied this blob using:
dd if=/sdcard/blob_9.2.2.4_recovery of=/dev/block/mmcblk0p4
That did the trick. Stock recovery now.
Hello
I'm trying to make a custom rom (for a Pomp C6) and need to adapt the bootclasspath.
Plenty of tutorials etc, so thats not the problem.
The problem i have is that none of the tools are able to correctly extract the ramdisk from my boot.img
I get errors like:
Code:
./unpack-bootimg.pl boot.img
Could not find any embedded ramdisk images. Are you sure this is a full boot image?
splitboot.pl apparently can extract at least something, but the resulting ramdisk image is not a gz
Code:
./split_bootimg.pl boot.img
Page size: 2048 (0x00000800)
Kernel size: 4376464 (0x0042c790)
Ramdisk size: 636685 (0x0009b70d)
Second size: 0 (0x00000000)
Board name: Release.V2.03
Command line:
Writing boot.img-kernel ... complete.
Writing boot.img-ramdisk.gz ... complete.
gzip -dc ../boot.img-ramdisk.gz | cpio -i
gzip: ../boot.img-ramdisk.gz: not in gzip format
cpio: premature end of archive
I already searched for a solution but cannot find any (All tutorials seem to have no problem extracting the ramdisk)
Am i overlooking something?
UPDATE: This version of the tool is now deprecated. Please use the updated version!
(and thank @nkk71 while you're at it!!)
[TOOL][LINUX|WINDOWS][64bit][20-MAY-2016]Universal HTC RUU/ROM Decryption Tool 3.0.0
----------------------------------------------------
Original Post:
First of all, I want to state that I deserve credit for none of this - all I did was aggregate some of the great work done by the fantastic devs here on XDA.
BIG Thanks @nkk71, for his idea to make this work universally on all encrypted HTC RUUs and all his hard work to make it happen! All I really did was post the thread.
Prerequisites:
- A system running a 64-bit Linux distro (tested on Ubuntu 15.10 & 16.04 LTS)
- At least 5GB of available disk space (ROMs are big)
readme.txt:
Code:
*** Captain_Throwback & nkk71's RUU decryption scripts for HTC Devices ***
INSTALLATION STEPS:
Extract files into folder of your choice, being sure to preserve the folder structure. The decrypt-htc binary and this readme file should be the only files in the root folder.
Download the encrypted RUU or encrypted rom zip of your choice from HTC (or wherever).
Place RUU.exe in the "place_ruu_here" folder or the ROM.zip in the "place_rom_zip_here" folder.
Run ./decrypt-htc and wait for script to complete (you may be prompted for input if there are issues).
The script will output 3 files (to the "out" folder): boot.img, system.img & the encrypted rom zip you started with (or was extracted from the RUU), named for SD card flashing on your device (if your device has an SD card). There will also be a folder with the extracted firmware for your device that can be used however you see fit :).
NOTE: For the A9, for example, the rom.zip will be named 2PQ9IMG.zip. Each device has a specific filename which will be reflected.
Below is a script of the expected output of the script when processing a RUU.exe.
Code:
Welcome to the RUU extraction and decryption script!
Extracting temporary files...
Extracting rom zip files...
Extracting rom.zip...done.
Extracting android-info.txt...done.
Cleaning up...
Done!
Extracting ZIP files
LargeZip format detected, using ruuveal
ruuveal
-------
Large zip format detected containing 7 zipfile(s)
Dumped (copied) zip file to: 01_dmp.zip
Dumped (copied) zip file to: 02_dmp.zip
Dumped (copied) zip file to: 03_dmp.zip
Dumped (copied) zip file to: 04_dmp.zip
Dumped (copied) zip file to: 05_dmp.zip
Dumped (copied) zip file to: 06_dmp.zip
Dumped (copied) zip file to: 07_dmp.zip
Finished: Successfully extracted zip files to '/home/throwback/android/decrypt/tool/working/extract'
Model ID found by extracting android-info.txt from RUU. Model ID identified as: 0PJA
Looking for keyfile: 0PJA_keyfile_2.bin
Found matching keyfile! Using keyfile: 0PJA_keyfile_2.bin
Decrypting ZIP files
Decrypting 01_dmp.zip
Encrypted zip detected, running ruuveal...
ruuveal
-------
Decrypted RUU (zip) written to: /home/throwback/android/decrypt/tool/working/decrypt/decrypted_zips/dec_01_dmp.zip
Decrypting 02_dmp.zip
Encrypted zip detected, running ruuveal...
ruuveal
-------
Decrypted RUU (zip) written to: /home/throwback/android/decrypt/tool/working/decrypt/decrypted_zips/dec_02_dmp.zip
Decrypting 03_dmp.zip
Encrypted zip detected, running ruuveal...
ruuveal
-------
Decrypted RUU (zip) written to: /home/throwback/android/decrypt/tool/working/decrypt/decrypted_zips/dec_03_dmp.zip
Decrypting 04_dmp.zip
Encrypted zip detected, running ruuveal...
ruuveal
-------
Decrypted RUU (zip) written to: /home/throwback/android/decrypt/tool/working/decrypt/decrypted_zips/dec_04_dmp.zip
Decrypting 05_dmp.zip
Encrypted zip detected, running ruuveal...
ruuveal
-------
Decrypted RUU (zip) written to: /home/throwback/android/decrypt/tool/working/decrypt/decrypted_zips/dec_05_dmp.zip
Decrypting 06_dmp.zip
Encrypted zip detected, running ruuveal...
ruuveal
-------
Decrypted RUU (zip) written to: /home/throwback/android/decrypt/tool/working/decrypt/decrypted_zips/dec_06_dmp.zip
Decrypting 07_dmp.zip
Encrypted zip detected, running ruuveal...
ruuveal
-------
Decrypted RUU (zip) written to: /home/throwback/android/decrypt/tool/working/decrypt/decrypted_zips/dec_07_dmp.zip
Unzipping decrypted zips
Archive: decrypted_zips/dec_01_dmp.zip
inflating: decrypted_all/android-info.txt
inflating: decrypted_all/aboot_signed.img
inflating: decrypted_all/radio.img
inflating: decrypted_all/splash1.nb0
inflating: decrypted_all/adsp.img
inflating: decrypted_all/rfg_1.img
inflating: decrypted_all/rfg_2.img
inflating: decrypted_all/ramdisk.img
inflating: decrypted_all/android-info2.txt
inflating: decrypted_all/sensor_hub.img
inflating: decrypted_all/emmc_appsboot.mbn
inflating: decrypted_all/persist.img
inflating: decrypted_all/dt.img
inflating: decrypted_all/bootloader
inflating: decrypted_all/gpt_main_32g.img
inflating: decrypted_all/pg2fs_ship_signkey.img
inflating: decrypted_all/apppreload.img
inflating: decrypted_all/cota.img
inflating: decrypted_all/gpt_main_64g.img
inflating: decrypted_all/sbl1-8994-1.img
inflating: decrypted_all/sdi.img
inflating: decrypted_all/hosd_signed.img
inflating: decrypted_all/rpm-8994-1.img
inflating: decrypted_all/pmic-8994-1.img
inflating: decrypted_all/boot_signed.img
inflating: decrypted_all/recovery_signed.img
inflating: decrypted_all/cpe.img
inflating: decrypted_all/tz-8994-1.img
inflating: decrypted_all/hyp-8994-1.img
inflating: decrypted_all/tp_SYN3351.img
inflating: decrypted_all/tp_MXM11876.img
inflating: decrypted_all/cir.img
inflating: decrypted_all/backup_android-info.txt
Archive: decrypted_zips/dec_04_dmp.zip
inflating: decrypted_all/system.img_02
Archive: decrypted_zips/dec_03_dmp.zip
inflating: decrypted_all/system.img_01
Archive: decrypted_zips/dec_07_dmp.zip
inflating: decrypted_all/dzdata_16g.img
inflating: decrypted_all/dzdata_32g.img
inflating: decrypted_all/dzdata_16g.hdr
inflating: decrypted_all/dzdata_32g.hdr
inflating: decrypted_all/dzdata_64g.hdr
inflating: decrypted_all/dzdata_64g.img
Archive: decrypted_zips/dec_06_dmp.zip
inflating: decrypted_all/system.img_04
Archive: decrypted_zips/dec_02_dmp.zip
inflating: decrypted_all/system.img_00
Archive: decrypted_zips/dec_05_dmp.zip
inflating: decrypted_all/system.img_03
7 archives were successfully processed.
Move system img files to system folder
‘decrypted_all/system.img_00’ -> ‘decrypted_system/system.img_00’
‘decrypted_all/system.img_01’ -> ‘decrypted_system/system.img_01’
‘decrypted_all/system.img_02’ -> ‘decrypted_system/system.img_02’
‘decrypted_all/system.img_03’ -> ‘decrypted_system/system.img_03’
‘decrypted_all/system.img_04’ -> ‘decrypted_system/system.img_04’
Finished: Successfully decrypted RUU to '/home/throwback/android/decrypt/tool/working/decrypt'
/home/throwback/android/decrypt/tool/working/decrypt/decrypted_system
/home/throwback/android/decrypt/tool/out
Attempting to create system.img
Multi-part system images
Sparse Image detected, using simg2img
Please be patient, this can take several minutes...finished.
Testing system.img...
e2fsck 1.42.12 (29-Aug-2014)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/home/throwback/android/decrypt/tool/out/system.img: 4685/286720 files (0.0% non-contiguous), 1041188/1146880 blocks
Finished: Successfully created system.img in '/home/throwback/android/decrypt/tool/out'
Renaming and moving files...
Rom.zip has been renamed for your device.
Boot image extracted from firmware.zip. boot.img & system.img can be used as base for building a new ROM.
Script complete! Files can be found in the 'out' folder. Enjoy your decrypted system!
(above output is from M9 RUU)
Important Notes:
If decrypting a rom.zip that is "combined" (meaning the first zip isn't encrypted), you will see the following error message at the top of the ruuveal section:
Code:
invalid htc aes encrypted zip file!
This just indicates that the first zip file isn't encrypted. The script will continue and complete with no issues, so this isn't a concern.
You may also see these messages:
Code:
caution: filename not matched: system.img*
Code:
1 archive had fatal errors.
These errors indicate that the first zip doesn't contain a system image to be extracted, which is fine (that's the zip that contains the firmware). This isn't a concern either.
The last issue you might notice is this:
Code:
warning [../out/firmware.zip]: 256 extra bytes at beginning or within zipfile
(attempting to process anyway)
The extra 256 bytes is HTC's signature on the unencrypted firmware zip. This also is nothing to worry about.
As long as you have all of the output files at the end of the script, everything should be fine.
Thanks:
twogood for unshield
@kmdm for unruu & ruuveal
@Flemmard for bruutveal
@osm0sis for Android Image Kitchen
@A.S._id for ANDROID_IMG_REPACK_TOOLS
Additional Info
Change Log:
January 11, 2016 - v2.0.0
Complete overhaul of existing script and process
Now works on any encrypted RUU/ROM for any HTC device with a known decryption key
For devices with unknown keyfile, user can provide hboot or hosd image (based on same software version is preferable) and a new keyfile will be created. You can share the new keyfile so that it can be added to our database.
Improved script output and error handling
January 1, 2016 - v1.5.3
Fixed the binary problem - should now work on PCs other than mine
January 1, 2016 - v1.5.2
Back to bash script (for now) to ensure compatibility with other PCs
January 1, 2016 - v1.5.1
Some script and binary cleanup (back end stuffs)
December 31, 2015 - v1.5
Compile script into binary format (back end stuffs)
December 31, 2015 - v1.4.1
Back-end cleanup to use "working" folder for zip processing
December 31, 2015 - v1.4
Added code to handle "combined" zips where first zip file is already decrypted
December 31, 2015 - v1.3
Can now handle encrypted rom zips!
Kill script if no files found
Script renamed from decrypt.sh to decrypt-htc.sh
Renames rom.zip from ruu (or provided rom.zip) to 2PQ9IMG.zip (or whatever corresponds to that for other applicable devices) automatically and puts in "out" folder
December 31, 2015 - v1.2
Added unshield and libunshield to zip so manual compilation is no longer necessary (thanks @nkk71)
December 30, 2015 - v1.1
Added version number
Modified script to allow for usage on multiple HTC devices
December 30, 2015
Initial version
Mine [emoji6]
Sent from my HTC One M9 using Tapatalk
Updated this (just now) to allow for handling of other devices which use the same type of encrypted RUU (like the Desire 626s, for example).
v1.2 is up! No more compilation of libunshield is necessary, thanks to @nkk71's help! Seriously, give that guy some love!
v1.3 is up!
Now there are provisions for handling encrypted ROMs that are zipped, and not just those from an RUU.
Can someone please try this thing out and provide feedback!!!!
v1.4 added.
Now "combined" zips can be extracted/decrypted as well.
Hello. Have tried it. I get the three files. But in Terminal i get the Message
"21 archives were successfully processed"
"2 archives had fatal errors"
Can i ignore the 2 archives fatal errors?
comibined zip first not encrypt
AntikerTa said:
Hello. Have tried it. I get the three files. But in Terminal i get the Message
"21 archives were successfully processed"
"2 archives had fatal errors"
Can i ignore the 2 archives fatal errors?
Click to expand...
Click to collapse
Yes you can, the error is not really an error, it just doesn't find a system.img_xx in 2 zip files, that's all
Sent from my HTC One M9 using Tapatalk
AntikerTa said:
Hello. Have tried it. I get the three files. But in Terminal i get the Message
"21 archives were successfully processed"
"2 archives had fatal errors"
Can i ignore the 2 archives fatal errors?
Click to expand...
Click to collapse
If you look in the "expected script output" in the OP, you'll see the same message (which is why I posted it there).
Though with the latest version, there will only be one archive with a "fatal" error.
If you have good files in the "out" folder, then assume everything went fine.
bl4ckluna said:
comibined zip first not encrypt
Click to expand...
Click to collapse
Was there a point to this post?
Followed instructions...
~/ruudecrypt$ ./decrypt-htc
./decrypt-htc: }u2n��ɢ
No worky, that is the output. Took the HTC RUU from their site. renamed ruu_a9.exe put it in the folder. Nothing else in root. Run decrypt script and that is what it does above.
Also, extracted the rom.zip out of the RUU, placed it in the folder ruu_a9.zip same error.
techlogik said:
Followed instructions...
~/ruudecrypt$ ./decrypt-htc
./decrypt-htc: }u2n��ɢ
No worky, that is the output. Took the HTC RUU from their site. renamed ruu_a9.exe put it in the folder. Nothing else in root. Run decrypt script and that is what it does above.
Also, extracted the rom.zip out of the RUU, placed it in the folder ruu_a9.zip same error.
Click to expand...
Click to collapse
What are you running this on? Where are the details to help troubleshoot? "No worky"? Really?
Is anyone else having issues with the latest version? I can go back to the previous format, but as long as the Linux distro can handle a bash script, it shouldn't matter whether the script is used or the binary is.
Followed your instructions, not much more to explain. For kicks, installed VMWorkstation Pro 12, installed a fresh Ubuntu 15.10, updates etc. Java/ADB and the usual basic stuff. Nothing special going on here, plain vanilla Ubuntu.
Again, downloaded your script in a folder. Copied ruu over to the working folder, renamed it to ruu_a9.exe
Ran the ./decrypt-htc script
Now, it gives this message, but similar:
./decrypt-htc: 8��������y����Y'��w������W�+Ɣ?�has expired!
Please contact your provider [email protected]
What more do you want for diagnosis?
techlogik said:
Followed your instructions, not much more to explain. For kicks, installed VMWorkstation Pro 12, installed a fresh Ubuntu 15.10, updates etc. Java/ADB and the usual basic stuff. Nothing special going on here, plain vanilla Ubuntu.
Again, downloaded your script in a folder. Copied ruu over to the working folder, renamed it to ruu_a9.exe
Ran the ./decrypt-htc script
Now, it gives this message, but similar:
./decrypt-htc: 8��������y����Y'��w������W�+Ɣ?�has expired!
Please contact your provider [email protected]
What more do you want for diagnosis?
Click to expand...
Click to collapse
Try the version I just uploaded and see if that works any better.
Tried that one, more of the same:
[email protected]:~/decrypt$ ls
bin decrypt-htc keyfile lib place_rom_zip_here place_ruu_here readme.txt
[email protected]:~/decrypt$ ./decrypt-htc
�N��<Z"��@i�?|�w���U>I�t��k �*��TN� 8'B��8�m?�"w$�[email protected]�['��
bF��#��
[email protected]:~/decrypt$
techlogik said:
Tried that one, more of the same:
[email protected]:~/decrypt$ ls
bin decrypt-htc keyfile lib place_rom_zip_here place_ruu_here readme.txt
[email protected]:~/decrypt$ ./decrypt-htc
�N��<Z"��@i�?|�w���U>I�t��k �*��TN� 8'B��8�m?�"w$�[email protected]�['��
bF��#��
[email protected]:~/decrypt$
Click to expand...
Click to collapse
Alright, 1.5.2 should take care of it. I'll have to figure out why only I can run the binary. But until then, might as well have a usable version available .
Captain_Throwback said:
Alright, 1.5.2 should take care of it. I'll have to figure out why only I can run the binary. But until then, might as well have a usable version available .
Click to expand...
Click to collapse
That worked. Thanks.