crypt back

[Falseclock]

Hi,

could you please add option to crypt back zip rom?

[kmdm]

...to what?

[Falseclock]

you mean for what? Want to customize stock rooms, crypt back and install through hboot

[kmdm]

HBOOT should be able to install unencrypted rom.zip files - Is that not the case?

[Falseclock]

no, it does not install unencrypted

[kmdm]

Is your device unlocked and/or S-OFF?

[Falseclock]

We tried on unlocked and S-ON, later can try other combinations, cause I have S-OFF

[bgcngm]

Yes, my device is S-ON an I tried to install the encrypted RUU with unlocked bootloader. Also tried to relock bootloader to no avail.

[Falseclock]

Tried to flash stock unencrypted rom

UNLOCKED + S-OFF - SUCCESSFULL

think crypting is required for S-ON devices

[Falseclock]

With S-ON, only stock (crypted) RUU can be installed via HBOOT (relocked, off course). That is why we are asking for such feature.

[kmdm]

Hmmm. Ok, I'll add encryption support.

Falseclock notifications@github.com wrote:

With S-ON, only stock (crypted) RUU can be installed via HBOOT (relocked, off course). That is why we are asking for such feature.

---

Reply to this email directly or view it on GitHub: https://github.com/kmdm/ruuveal/issues/8#issuecomment-13054594

Sent from Kaiten Mail. Please excuse my brevity.

[kmdm]

Please test/try:-

https://github.com/kmdm/ruuveal/tree/encrypt

[Falseclock]

if I decrypt rom and then encrypt it again, should MD5 signatures be identical?

--encrypt, -E Set encryption mode --mainver MAINVER, -m Set the mainver when encrypting --key KEYINDEX, -k Set the encryption key index --chunks CHUNKS, -c Set the number of encryption chunks

What are the 3 last options?

[kmdm]

I'm planning to add an --info option that'll display that data for an encrypted zip.

The former of the 3 is the mainver/version of the ROM, the latter two control how the encryption is done.

[kmdm]

(I would expect ruuveal to be able to decrypt what you encrypt - Have you actually tried flashing a re-encrypted zip yet?)

[Falseclock]

yes, it decrypts what I encrypted

now trying to flash encrypted and decipted back rom, will report later

[Falseclock]

flashed re-encrypted rom.

having UNLOCKED and S-OFF

seems re-encryption works well

thanks )))

[Falseclock]

created update file with splash screen, encrypted, putted on sdcard, flashed!

You are awesome!!! Million thanks!

[kmdm]

Should now be --info.

E.g: $ ruuveal --info

[Falseclock]

1. Which values I should use with --key and --chunks? DEC of HEX?
2. Main ver without minor release number. Is it correct?

encrypted zip info:-

keyindex: 0x0012 chunks: 0x0a mainver: 1.05.1402.

--info, -I Displays info about an encrypted zip --encrypt, -E Set encryption mode --mainver MAINVER, -m Set the mainver when encrypting --key KEYINDEX, -k Set the encryption key index --chunks CHUNKS, -c Set the number of encryption chunks

UPD: I decrypted (file1), then encrypted and then decrypted (file2) back

then compared unzipped files file1 and file2 and they are identical.

Here is log

root@304007:~/ruuveal-encrypt# ./ruuveal --info --device cp2dug ../RUU_CP2DUG_ICS_40_HTCCN_CHS_CU_1.05.1402.3_Radio_6.1212.14.12_release_286043_signed.zip

ruuveal

encrypted zip info:-

keyindex: 0x0012 chunks: 0x0a mainver: 1.05.1402.

root@304007:~/ruuveal-encrypt# ./ruuveal --device cp2dug ../RUU_CP2DUG_ICS_40_HTCCN_CHS_CU_1.05.1402.3_Radio_6.1212.14.12_release_286043_signed.zip CP2DUG-1.zip

ruuveal

Decrypted RUU (zip) written to: CP2DUG-1.zip root@304007:~/ruuveal-encrypt# ./ruuveal --encrypt --mainver 1.05.1402. --key 18 --chunks 10 --device cp2dug CP2DUG-1.zip CP2DUG_tmp.zip

ruuveal

Encrypted RUU (zip) written to: CP2DUG_tmp.zip root@304007:~/ruuveal-encrypt# root@304007:~/ruuveal-encrypt# ./ruuveal --device cp2dug CP2DUG_tmp.zip CP2DUG-2.zip

ruuveal

Decrypted RUU (zip) written to: CP2DUG-2.zip root@304007:~/ruuveal-encrypt# unzip -o CP2DUG-1.zip -d CP2DUG-1 Archive: CP2DUG-1.zip inflating: CP2DUG-1/hboot_0.74.0000_2434016a_0925_signed.img extracting: CP2DUG-1/android-info.txt inflating: CP2DUG-1/radio.img inflating: CP2DUG-1/rcdata.img inflating: CP2DUG-1/boot_signed.img inflating: CP2DUG-1/recovery_signed.img inflating: CP2DUG-1/system.img inflating: CP2DUG-1/splash1.nb0 inflating: CP2DUG-1/wifi.img inflating: CP2DUG-1/spcustom.img inflating: CP2DUG-1/ramdump.img inflating: CP2DUG-1/dzdata_4g.img inflating: CP2DUG-1/modemfs.img inflating: CP2DUG-1/b2_xloader.img inflating: CP2DUG-1/meminit.img inflating: CP2DUG-1/prcmufw.img inflating: CP2DUG-1/merge_xloader.img inflating: CP2DUG-1/ramdisk.img inflating: CP2DUG-1/dzdata_3g.img inflating: CP2DUG-1/imc.fls inflating: CP2DUG-1/dzdata_4g.hdr inflating: CP2DUG-1/dzdata_3g.hdr inflating: CP2DUG-1/itp.img inflating: CP2DUG-1/tp_HM8526A.img root@304007:~/ruuveal-encrypt# unzip -o CP2DUG-2.zip -d CP2DUG-2 Archive: CP2DUG-2.zip inflating: CP2DUG-2/hboot_0.74.0000_2434016a_0925_signed.img extracting: CP2DUG-2/android-info.txt inflating: CP2DUG-2/radio.img inflating: CP2DUG-2/rcdata.img inflating: CP2DUG-2/boot_signed.img inflating: CP2DUG-2/recovery_signed.img inflating: CP2DUG-2/system.img inflating: CP2DUG-2/splash1.nb0 inflating: CP2DUG-2/wifi.img inflating: CP2DUG-2/spcustom.img inflating: CP2DUG-2/ramdump.img inflating: CP2DUG-2/dzdata_4g.img inflating: CP2DUG-2/modemfs.img inflating: CP2DUG-2/b2_xloader.img inflating: CP2DUG-2/meminit.img inflating: CP2DUG-2/prcmufw.img inflating: CP2DUG-2/merge_xloader.img inflating: CP2DUG-2/ramdisk.img inflating: CP2DUG-2/dzdata_3g.img inflating: CP2DUG-2/imc.fls inflating: CP2DUG-2/dzdata_4g.hdr inflating: CP2DUG-2/dzdata_3g.hdr inflating: CP2DUG-2/itp.img inflating: CP2DUG-2/tp_HM8526A.img root@304007:~/ruuveal-encrypt# diff -r CP2DUG-1 CP2DUG-2 root@304007:~/ruuveal-encrypt#

[kmdm]

"mainver: 1.05.1402."

That is a bug which should be fixed by the latest commit: 921635b

[Falseclock]

1.05.1402.12 - 12 chars, in you commit 11

[kmdm]

Gah, Consistency would go a long way! :/ Leave that with me (again!) sigh

[kmdm]

Infact, what device is that?

[kmdm]

ok, CP2DUG :P

[kmdm]

(Yes, I'm half asleep)

[Falseclock]

)))

[triaqu]

i have a problem to flash recrypted zip on cp2dtg.

I zip a recovery.img and recrypted it.

triaqu@ubuntu:~/android/ruuveal/ruuveal$ ./ruuveal -I cp2_dtg_1.24.1403.2.zip

ruuveal

encrypted zip info:-

keyindex: 0x00a4 chunks: 0x0a mainver: 1.24.1403.2

triaqu@ubuntu:~/android/ruuveal/ruuveal$ ./ruuveal -E -m 1.24.1403.2 -k 0x00a4 -c 0x0a --device cp2dtg rom.zip rom2.zip

ruuveal

Encrypted RUU (zip) written to: rom2.zip triaqu@ubuntu:~/android/ruuveal/ruuveal$ ./ruuveal -I rom2.zip

ruuveal

encrypted zip info:-

keyindex: 0x00a4 chunks: 0x30 mainver: 1.24.1403.2

---

my t528t is s-on,i filed to flash in whether hboot is unlock or relock, info is "signature fail".

it means S-on is can't be flash in a recrypted zip or other issues.

[kmdm]

Fixed mainver stuff I hope now - please re-test. :-)

Also fixed a bug highlighted by triaqu regarding chunks option parsing.

[triaqu]

I tried again,the chunks is right,but can't flash in the encrypted zip whether unlocked or relock on my S-on cp2dtg.

[kmdm]

If your device won't flash unsigned zips there's nothing I or ruuveal can do to change that.

[Falseclock]

I'm very interesting, why when I re-encrypt zip, md5 summ not equal to stock zip

[kmdm]

Well....

You have the source and the files to compare ;)

But... I'm feeling nice: There are five bytes that appear unused by HBOOT that I don't know the purpose of so they are left as ff and not set!

[Falseclock]

Yes, i compared source and recrypted files. 99.9% files are the same, but there are some differences.

Difference 1.source contains 256 bytes of information in the beginig. recrypted does not have

79 25 cf c5 2c b9 d8 7d a0 80 1d 28 a9 a9 7d 35 77 5b b3 67 fc 81 6b 5a e4 6a 55 fe e6 de 19 33 86 49 8c 14 a0 71 2f 20 85 02 44 41 46 ea 00 a2 b9 7b dc f7 a2 1b b6 78 db 60 39 e3 99 7d f0 41 1c 66 f0 c2 96 e4 70 82 76 5c 18 5b f5 ea 99 f6 f0 60 1d 43 19 d5 21 43 c1 5d 35 04 84 ea 25 81 7b bb 55 91 35 cc 25 b7 58 f3 d9 d0 c2 e4 69 3e c1 05 99 e5 51 c4 d6 fc 8f 0f 5e 7c 9b 53 1f 07 ea f4 e4 d5 5e 61 54 bd bf 12 30 df b4 ce b4 6d 70 22 c1 c2 c8 0c a9 5d 34 98 91 d8 13 69 03 2f d7 cf 6f a8 d4 38 c0 c1 31 16 92 67 66 f0 3b f6 10 28 63 f5 f7 2f 8b f4 f2 28 f9 b4 7e 0f 2e c3 cb ee 03 e5 1e 51 1b 9c 3d ec 75 44 30 ba c4 bb 0a 09 08 9f 27 52 23 6b 13 0c ab 52 a3 ed d1 f8 ca 9d 94 30 53 e7 6a 59 08 13 0a 22 fa b3 f8 00 6f 92 17 c4 c6 23 60 4d 11 a8 97 8a 62 44 7d b6

Difference 2. difference after first 256 bytes source is

48 74 63 40 65 67 69 24 00 12 0a ff ff ff ff ff ff ff ff ff 31 2e 30 35 2e 31 34 30 32 2e 33 17 56 c9 8a 22 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

recrypted is

48 74 63 40 65 67 69 24 00 12 0a ff ff ff ff ff ff ff ff ff 31 2e 30 35 2e 31 34 30 32 2e 33 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

Difference 3. recrypted file has some data in the end, source file does not have such

48 ff a5 3f 96 5f 42 42 97 b8 b5 31 ce 39 04 89 72 54 27 78 77 64 5d ac cf 4d b4 73 8b f0 2e 6f c7 db 01 23 38 4c 41 5f 7d a9 6c 0d e9 59 60 9a 2d 59 fb 6a d0 5f 45 5e 50 34 ab 9a 3c 88 95 e6 d1 c9 46 89 3d 3a 20 58 e4 85 79 4e 5e 38 45 46 90 58 41 75 68 ba d9 63 14 2f 9c 22 7d d2 d1 9f f7 f4 7a d8 94 2d 8a 56 d7 fe 7c 8a 70 0b d6 24 3c db 3d dc 5a f4 14 d1 bd 71 8b 7a 48 56 da 48 8b 62 18 8f 44 e9 e9 d1 2e ce b5 fa 40 8b b6 25 ba d8 ec 2e 7d 7a 32 1a 4f da 12 b7 33 de 8f 35 15 9e af de bf 77 c3 d8 b5 2e 93 85 b6 f4 86 7e 1d 5f e9 b5 d7 63 af 77 47 b1 b3 6f 8b f8 a9 01 87 60 34 53 f0 b6 79 41 0b c6 d3 8e dd bb b1 62 af 1d 0c d1 e0 e7 a9 fc 4a 88 21 ee df 55 f0 de a0 c7 06 42 8f cd 33 e5 48 3d d6 0c f6 8d e7 41 03 8f 77 76 88 b6 8d a3 1d d5 c4 12 37 89 b5 86 3c 0c bc fa e0 48 db a9 89 c5 f5 b7 2f 3d 5b 35 ed 6a 62 a7 bb 8f 9c 6a a2 fd 0e 7c e9 dd ca 05 13 1d b1 51 13 e3 35 b4 98 66 38 aa 51 d5 ac 6e 11 db c0 35 76 14 3a 05 da c9 e2 42 34 53 7d c2 7b 0a 9a e2 dd 3e 4b 92 eb fb ed f1 46 25 b1 d7 bb 7a 35 9d 46 62 af b3 20 19 c6 81 bd ee da 96 38 17 33 d1 4d 14 36 a5 9b 6e 82 21 4b 89 6e e2 d5 ae 00 5b dc 1d b2 8c d8 e2 8a 2b 74 13 0c cb 95 fa ad 02 6c 71 32 66 8a ef 82 c6 5f d9 c6 53 50 88 ca 61 8b f7 fd ea 3c cc 81 ae 01 fb 6a ab 27 58 2b 03 f6 fc 58 a2 59 4f 95 35 04 41 5b df 54 39 7e af 6e ef 80 dd 14 eb b0 bd f3 01 93 01 fb c2 d8 84 8b 1a 62 2d 18 a1 47 0e 07 d3 8d 61 82 b6 33 82 a7 9b 74 bc 2f d0 97 23 f1 f1 dc d7 2e fb f2 ec 5d f6 3c e3 2e 7b ae d1 d3 16 d4 31 60 57 12 98 82 af 24 39 0d ce 73 e4 34 17 2d e2 31 7f 0c 1b e8 dd aa bd b5 e7 82 6c 03 76 61 1e 59 1d 6a f0 6e 08 02 4e f1 8d 64 fa a2 22 13 06 2f d6 87 81 85 ac eb 60 86 bc e9 01 7b ef 3c 11 37 c7 d8 ae 21 7a 48 98 30 09 ca 6a 7f 23 d1 ae f6 a2 5b 82 6c 3e 4e 1b 17 85 a3 c1 4f ea 1d 31 17 a3 39 82 ac 45 d7 b1 bc 7a c0 5e 33 8f 86 1c 1d b9 e5 3b 73 e3

[kmdm]

Hmmm... Interesting.

1. The leading 256 bytes is the signature of the zip file, you'll need to disregard it. There's no way we can sign the zip correctly without HTC's private key.
2. The differing 5 bytes are the bytes I talked about.
3. The trailing bytes are probably a bug - I'll investigate further when I get some time but it's not a priority since it's not causing HBOOT to fail to flash the zip.

Thanks for the detailed analysis/comparison :+1:

I'm going to merge the encrypt branch onto the master branch in the next few days since it seems to be working okay.

[Falseclock]

do you know how they sign their files? something like crypting MD5 sum of the file and put in the begining?

[kmdm]

It's a RSA signature.

If I remember correctly (and HTC haven't changed anything) - it's an exponent of 3 crypting a PKCS padded SHA-1 digest.

[kmdm]

Merged to master a couple of days ago - closing off this task.