yashsingh1/xdaforums huggingface dataset:
[Android] nkk71:
I'm sure you'll like this one :p

and since I'm only half German, I'm only half stubborn :p
[Android] Sneakyghost:
[emoji23] true story
[Android] Captain_Throwback:
Keyfile for Desire 530
[Android] BigCountry907:
Add Encrytion Option For ruuveal

Great Work Here

I'm working with a HTC Desire 626s " ro.product.device=htc_a32eul

The ruuveal does not support the a32eul

I want to use the ruuveal option

--encrypt, -E	Set encryption mode

To re encrypt the extracted ruu for flashing with S-ON.

Can you add the -E option to your scripts.

The way you use ruuveal successfully extracts the ruu files.

I guess you are using the generated keyfile instead of --device??

How can I generate the keyfile to use with ruuveal to replace --device?

Thank you for your help.
[Android] nkk71:
You can't re-sign, for S-ON. You would need HTC signature for that, and AFAIK, nobody has those. (well except HTC)
[Android] BigCountry907:
I figured that.

I'm counting on the Android Rom to use the same signing scheme that I have dealt with before.

Fairly Easy Fix !!

Heres how basically.

Generate a new set of keys.

Both the .pem and the .pk8.

Unpack the recovery.img to Ramdisk and kernel.

Dump the private key using dumpkey.

patch the new key to the /res/keys file in the ramdisk.

re-pack the recovery

Fastboot flash the recovery to the device.

Make new encrypted RUU.

Sign RUU with new pk8

run the ruu by loading on sd card and renaming to 0PM9IMG..zip and reboot phone to download.

A wile back i wrote a pile of shell script to do this.

We could probably even incorporate the routine into your package.

It replaces the private key in the rom.

Our ruu signed by our key will pass verification.

I just need to know how to encrypt the ruu. Your package de-crypts it so it should be able to use the -E to Re-Encrypt.

I look forward to working with you to make this work.

I'll test it if you help.
[Android] BigCountry907:
Ya the scheme is about the same.

the /res folder in the ramdisk has the keys that are used for verifying rom signature.

Normally there is only one "keys" file but there are 5 in this recovery.

I'm thinking that there are seperate keys for verifying signed files and signed zips.

At any rate I can make theese keys so signature verification is not a problem.

Maybe the RUU won't need encrypted if the signature is fixed. I am going to do some test.
[Android] nkk71:
RUUs don't need to be encrypted, even for S-ON. We've seen various RUUs which are signed but not encrypted and they work fine on S-ON devices; just like the firmware.zip inside an OTA.zip, those are typically just signed and not encrypted.

So encryption isn't an issue, however the signature is. And if I understand you correctly, you want to patch the keys in stock recovery, but the problem is that RUU (or firmware) flashes are taken care of by hboot or hosd, and those can't be patched unless S-OFF (even then I don't recommend patching them).
[Android] BigCountry907:
Thank you for your help, I'm trying to grasp how the whole RUU verifies itself upon flash.

My device is a HTC Desire 626s

ro.product.device=htc_a32eul

My device is S-on

Currently I have upgraded to Marshmallow and want the ability to downgrade to Lollipop and or Flash RUU for a different carrier.

In order to do that I need to edit the asserts in the meta-inf.

For Example

# Htc Script Version: M60QCT.02.003.021

ui_print("M60QCT.02.003.021");

getprop("ro.product.device") == "htc_a32eul" || abort("This package is for "htc_a32eul" devices; this is a "" + getprop("ro.product.device") + "".");

ifelse( is_ship_bootloader(getprop("ro.bootloader")) == "t" ,

assert(check_cid("00000000", "11111111", "22222222", "33333333",

"44444444", "55555555", "66666666", "77777777", "88888888", "99999999",

"METRO001") == "t");

);

ifelse( is_ship_bootloader(getprop("ro.bootloader")) == "t" ,

assert(check_mid("full", "0PM911000") == "t");,

assert(check_mid("simple", "0PM911000") == "t");

);

ui_print("Verifying current system...");

getprop("ro.build.fingerprint") == "htc/a32eul_metropcs_us/htc_a32eul:5.1/LMY47O/637541.3:user/release-keys" ||

getprop("ro.build.fingerprint") == "htc/a32eul_metropcs_us/htc_a32eul:6.0.1/MMB29M/774853.1:user/release-keys" ||

abort("Package expects build fingerprint of htc/a32eul_metropcs_us/htc_a32eul:5.1/LMY47O/637541.3:user/release-keys or htc/a32eul_metropcs_us/htc_a32eul:6.0.1/MMB29M/774853.1:user/release-keys; this device has " + getprop("ro.build.fingerprint") + ".");

So to accomplish this I have to De-Crypt and unpack the RUU.

Make the Edits

When I make the edits / when I re-zip the package the original HTC Signature will be invalid.

I understand that RUU (or firmware) flashes are taken care of by hboot or hosd

I don't plan on modifying the RUU other than passing CID MID and MainVER.

I see that the following files in the RUU are Signed.

aboot_signed.img

boot_signed.img

hosd_signed.img

recovery_signed.img

So during a flash with the RUU it's safe to assume that the H-Boot or HOSD process verifies the signature on these files.

If those files are left untouched there should be no problem.

In the OTA Update for Marshmallow

the following files are signed.

aboot_signed.img

hosd_signed.img

The recovery.img and boot.img are not signed. I find that a little interesting.

At any rate here is my signature workaround.

This is for the Whole Zip signature.

When you flash the zip or ruu it is signed by a Private Key. The Whole Zip.

The recovery that exist on the device " Not in the RUU " has a folder in the ramdisk called /res.

The public half of the private key is located in /res and named keys

The recovery is not patched but rather the /res/keys file is replaced with my own keys file.

When you flash a file the zip signature is matched up to the key in the /res folder and the verification passes.

I will test this and let you know how it goes.
[Android] nkk71:
I dont fully understand your post (especially the part about messing with the OTA), but

Changing anything in an RUU will break HTC signature -> no go -> and you cannot "fake it", stock recovery has nothing to do with it

Changing your phone's MID or CID is also impossible without S-OFF, and you cannot edit the android-info.txt because of point 1 above

You

can

change version-main, by editing the misc partition... in theory, that could allow you to flash a CID+MID compatible RUU of lower version.

In the hboot days, that would need the hboots to be of the same version to downgrade RUU, but on hosd based devices, I'm not sure that check is still in place.

One thing, I'm pretty certain of, RUUs will go through (at least) the following checks:

MID -> if wrong -> MODEL ID NOT ALLOWED

CID -> if wrong -> CID NOT ALLOWED

version-main -> if not properly edited before -> Main version NOT ALLOWED
[Android] nkk71:
I have no idea about xtc2 clip, and other hardware solutions. I'm not in that field, this is just a hobby :o

So I'm not the person to ask about the pros and cons of these things.

As to your (I think) main question, first off OTA.zip and RUU.zip, are completely different entities, I'm going to make this a little short, so please don't mind the non-elaborate detailing of this:

RUU

A ruu.zip is a fastboot flashable zip.

It's processed directly by hboot / hosd (typically in a mode called "oem rebootRUU")

it does contain the android-info.txt, and if it's official is HTC signed.

This signature cannot be faked nor reproduced.

Recovery (stock or other), does not come into play at any time during an RUU flash. So whatever you think you can get from stock recovery isn't going to work here, these are RUU/firmware signature not script.zip signatures.

OTA

Contains two parts:

The first is a software update which is handled by recovery (stock or other, doesnt really matter "too" much)

Can the updater-script be modified: sure thing, it's just a text file,

but

those checks are there for a reason

let's say the MID and CID ones of minor interest,

and if you insist, the fingerprint is easily changeable as well

okay, the sha1sums on the system partition (yeah, they're using block update now, and i wont be reposting something i posted some 2 years ago about OTAs) are going to be a bit more tricky, but "can" they be changed, sure.... will the ROM boot after those modification, i'm quite confident that it wont

PS: oh forgot, you're going to need to change both the pre and post sha1 sums of the system partition, not that it would matter much since it's not going to boot anyway :eek:

and let's go on with this "modified" OTA, it has passed all checks, did a block based update on a system partition which isnt supposed to be what it is, next step is:

.

The second part is a firmware.zip inside the OTA.zip, this one is signed by HTC.... once the OTA has successfully finished the "software" part, it will prepare the firmware.zip and then hand over to hboot / hosd for further processing.

The same rules as RUU.ZIP apply at this point (HTC signature, proper android-info.txt, etc)

... oops, the firmware.zip has it's own android-info.txt, which you cannot modify without breaking the signature, it wont pass hboot / hosd signature check

... poof :cyclops:

EDIT: regarding your previous post:

that has nothing to do with the RUU signature, the RUU/firmware signature is in the first 256 bytes of the file, and "sign" / "verify" the entire package, the

names

of the individual files therein, is irrelevant to this signature
[Android] BigCountry907:
This is sweet!!

You really know the HTC-System very well.

Thank you

I think together we will come up with some really great stuff.

I admit my approach here is a bit abstract but worked for me before.

It's time to do some testing.

I appreciate your knowledge and willingness to share it.
[Android] nkk71:
this is what this place is about ;)

PS: good luck with the testing
[Android] BigCountry907:
I have a question because curiosity just kills me.

During your decryption process you unpack the Hosd_signed.img

The reason being is to get the file needed from the unpacked image to generate the RUUVEAL key for devices that aren't supported by RUUVEAL.

Using the -k flag instead of --device

This file is used with Bruutveal to generate the needed key file for decryption.

What file is it? From the unpacked Hosd_signed.img / Ramdisk
[Android] Captain_Throwback:
It's a secret ;).

P.S. It really isn't - just look at the source :)
[Android] BigCountry907:
Thank You

Found it. Never expected it to be the file that it is.

Forgot all about the source code. It's the simple things that cause me the most trouble.

There is another file in the Hosd.img I find very interesting.

cwkeys

It's definitely the public half of a key certificate.

The question is what signature is it used to verify?

It appears in the recovery.img ---->>>>Ramdisk as well.

In the /res folder along with the usual keys file.

Man HTC goes signing crazzy on there roms !!!!

My guess is that could be the bugger verifying the signed image files like recovery_signed.img boot_signed.img ect.

I don't know yet.

More testing to do.
[Android] nkk71:
Just FYI, I just downgraded my M9 (currently S-ON with UNLOCKED bootloader), from 3.35.401.10 to 1.40.401.8

I edited misc, then was able to flash the 1.40.401.8 RUU

It's not something I would recommend to be perfectly honest, so people should do that at their own risk, it worked for me on the M9, but I wouldn't do it usually unless I'm S-OFF... too many things could go wrong!
[Android] BigCountry907:
That's good news.

So my question is where can I find the info on how to edit the Main-Ver in the misc partition? Got A Link>?

On a second note too:

If you do

adb reboot oem-78

It puts your phone into

c:\HTC-DEV>htc_fastboot -s FA5BTB005699 getvar boot-mode

boot-mode: RUU

finished. total time: 0.003s

htc_fastboot finished. total time: 0.149s

Then you can

fastboot flash zip firmware.zip

RESULT

target reported max download size of 725000000 bytes

sending 'zip' (59730 KB)...

OKAY [ 5.417s]

writing 'zip'...

(bootloader) HOSD CL#774853

(bootloader) GPT is up-to-dated. [17408]

(bootloader) start@11

(bootloader) aboot_signed.img@100%

(bootloader) boot.img@100%

(bootloader) hosd_signed.img@100%

(bootloader) pg2fs_ship_signkey.img@100%

(bootloader) rcdata.img@100%

(bootloader) recovery.img@100%

(bootloader) rpm-8909-1.img@100%

(bootloader) sbl1-8909-1.img@100%

(bootloader) tz-8909-1.img@100%

(bootloader) wcnss.img@100%

(bootloader) radio.img@100%

(bootloader) Update zip file OK

(bootloader) end@Done

OKAY [ 13.338s]

finished. total time: 18.758s

The firmware image was taken from the OTA.

I expect the Firmware.zip itself is signed

I am also aware that the files with ( _signed ) are also signed.

Both I think are using standard RSA Keys.

But I haven't proven that yet.

My next step is to modify the firmware.zip and get it to flash.

I know i'm totally crazy.

But i'm having fun and purely doing this project just for fun.

And to keep learning.
[Android] nkk71:
I'll get back to you on that, it's really not a secret, but trying to mess with a downgrade, using HTC signed things (do you even have an RUU?) can be very dangerous these days.

looks like "htc_fastboot oem rebootRUU" to me

Yes, the firmware.zip inside the OTA.zip is signed, the signature is the first 256 bytes of the firmware.zip... that's why many "unzip" programs think those are sfx files.

That HTC signature verifies the

entire

firmware.zip, not individual files therein.

I think that part is beyond my knowledge... to me personally, the "extension" _signed (or not) means pretty much nothing... hboot / hosd will check the img file against whatever parameters it sees fit and either accept, ignore, reject it.

That's why many firmwares have several touch panel variations... only one get's flashed,

or, if you look at the M7 as an example, it has several SBL1-x (either 3 or 4, if i remember correctly), only one of them would get flashed, the others ignored.

Have fun anyway :)
[Android] BigCountry907:
Yes I have a Stock RUU and few TWRP Backups

.

What worries me is how to recover from a bad Hosd.img or Radio.img Flash when the phone is S-on.

But whatever happens I am willing to accept the consequences.

My sadness will be only Not Having the Device to Test.

Only $80 to replace.

The reason I'm looking at the xtc2 clip is because it can s-off + change CID + change MID.

And hopefully unbrick my device if I fry the Hosd Bootloader. The clip is $100 and works on all HTC Devices.

My goal is to find a way to copy the S-off from one Device to Give another device with S-on the s-off.

Therefore I need to have ability of flashing modified Hosd and the Radio I'm guessing.

Hence the primary reason to overcome the signature barrier.

The main question is weather the Hosd Ramdisk or the Recovery Ramdisk is loaded on the phone when in boot-mode: RUU ( Which One certainly one of them is loaded. )

The signature verification " Public Half of the Private Key" is in the Ramdisk of Hosd and in the Ramdisk of the Recovery.

The recovery Key file is the Releasekey.x509.pem --->>>>> Public Half of Key. ------>>>>>>> Dumped with DUMP-Key to make the /res/keys file in the recovery ramdisk

The Hosd Key file is the cwkey.x509.pem --->>>>> Public Half of Key. ------>>>>>>> Dumped with DUMP-Key to make the cwkey.key located in the root of the Hosd ramdisk.

To properly sign ZIP files we need Releasekey.x509.pem & releasekey.pk8 ( The pk8 is the HTC Private Key. )

To properly sign Hosd_signed.img / or Aboot_signed.img files we need cwkey.x509.pem & cwkey.pk8 ( The pk8 is the HTC Private Key. )

To overcome this we generate a complete set of keys that match the exponent used in the .x509.pem files.

We take the new .pem and .pk8 and we use DUMP-KEY to generate the files located in the ramdisk.

Lastly we flash the hosd_signed.img with the new key in the ramdisk and the Recovery.img with the new key in the ramdisk.

If we get that far were in business.

I have done this on other devices before and it worked.

I don't know if it will work in this case.

One step at a time.

My biggest concern is the Re-Packing of the Hosd.img.

There's only one chance to get that right. If I pack it wrong and it manages to flash that's a problem.

I would expect my phone will no longer boot to bootloader mode for sure.

Without the bootloader I would expect to have no download mode either.

With no fastboot I don't have a clue how to re-flash a good hosd.img back. Rendering My Device a true BRICK.

At any rate I'm working away at this. But the more information the better.

One of 2 things will happen. I'll will get it figured out.

Or I will brick my device. True Brick

Cause I probably won't give up until one or the other happens.
[Android] ChronoReverse:
Excellent tool. Just used it to extract a firmware for my HTC 10: "RUU_PERFUME_WL_M60_SENSE80GP_VZW_NA_Gen_Unlock_1.91.617.1.exe"

Wish I had found this before trying a bunch of other things to extract it (got stuck at the encrypted zip_x.zip files within rom.zip).
[Android] nkk71:
As mentioned in the OP, the "force-extraction" is likely to fail most of the times.

But how about this one perhaps: http://xdaforums.com/showpost.php?p=67614373&postcount=46

unzip and place the 2PST_keyfile_1.08.401.2.bin file in the keyfiles folder
[Android] Captain_Throwback:
I thought I posted that, lol. You need to add a feature to the tool that allows me to push new keyfiles to "somewhere" and have the tool download the updates automatically.

Or, people should at least look in the thread before saying there's no available key ;).
[Android] nkk71:
Well I could add it to the OP (guess you could as well), but there's this beautiful looking post, where you could add all sorts of stuff :D

And since the tool does need a small revision ;) , I could look at "internet" access... though that's probably not going to be very portable, but no clue really

... Have a bigger fish to fry atm :cool:
[Android] Captain_Throwback:
I forgot about that post....I'll add links to new keyfiles there, and you can refer to it in the OP, if you'd like :). That should suffice for now while you fry your "fish" :).
[Android] ShinySide:
Annnnnd that's what I get for xda'n at 2 am lmao thanks
[Android] blueberry60:
I decrypted ruu.exe (HTC10 Developer Edition 1.91.617.1) in your tool with "RUU_Decrypt_Tool -z ruu.exe" command succesfully and it created 2PS6IMG file in OUT Folder,but when I open this file it includes 24 zip files:

View attachment 3862561
[Android] nkk71:
Yep, that's correct. that's how the newer ruu.zips look like

(rompack v2, I think they're called)

Which is also one of the reasons this tool came to be, since [MENTION=1162986]Captain_Throwback[/MENTION] didn't like having to deal with 23 zips :p:o
[Android] blueberry60:
Sorry,it's a little bit off topic,Could it be possible to make a RUU.zip from device-specific files (e.g."pmeuhl-3.18.20-perf-gd016204.tar") called as kernel.tar.gz and platform.tar.gz when extracted that are existing in HTCDev Download Servers?
[Android] nkk71:
Those are kernel source codes, they won't do you any good, unless you're trying to compile a kernel from source.
[Android] nkk71:
Small Update: Version 3.1.0 is now in the downloads section

Changelog

29 September 2016 (version 3.1.0)
---------------------------------
* Rename OUT folder to include MID and mainversion
(nice when you're decrypting multiple RUUs)
* Support RUUs with multiple "systemimg" files
* Improve keyfinder performance

Enjoy :)
[Android] :
Support for T-Mobile?
[Android] Captain_Throwback:
What?
[Android] :
I was asking if T-Mobile HTC 10; can be added to the list of supported devices.
[Android] Captain_Throwback:
I don't understand. Do you understand what this tool does? You did see the word "universal" in the title, right?
[Android] :
I understand but I did get the "Sorry, T-Mobile is not supported" message at the end.
[Android] Captain_Throwback:
At the end of what? I have no idea what you're talking about, and you haven't posted any output to give me a clue. Until you do, there's nothing I can do to help you.
[Android] nkk71:
This tool

will never ever

say that.... how do I know? because that text "Sorry, T-Mobile is not supported" is nowhere to be found in the code,

Perhaps you're looking in the wrong thread??

EDIT: for reporting errors, you can check the FAQs
[Android] :
I an terribly sorry! This was indeed the wrong thread. Sorry for unnecessary trouble.

---------- Post added at 02:31 AM ---------- Previous post was at 02:30 AM ----------

I was in the wrong thread just like you said. I had to check the thread title.
[Android] Gandalforce:
Guys, I'm terribly sorry, but I have no idea how to run the commands for this.

I was looking at the test outputs, to try and learn.

I just need stock boot and system images from the RUU.

Noob status achieved....
[Android] Captain_Throwback:
On what OS?

On Windows, drag the RUU onto the tool .exe file and it'll just run...seems pretty easy to me :rolleyes:.
[Android] Gandalforce:
Wish that was in the instructions...
[Android] nkk71:
It's not supposed to be ;)
[Android] Captain_Throwback:
This wouldn't be much of a development forum if it had to be...:rolleyes:
[Android] Gandalforce:
Agreed, I should have known better
[Android] BigCountry907:
[MENTION=2605798]nkk71[/MENTION]

New keyfile for HTC Desire 526.

Thanks For your work.
[Android] Gandalforce:
Which one of these would by the system image? Or is did it not output from the tool?

[IMG="Output files"]https://1drv.ms/i/s!Aq72YnEWgqMAkfpa8MIgLz6Ac7V5-w[/IMG]

EDIT: All set, successfully extracted RUU.

Now, could I use the boot.img and system.img as a TWRP backup? or they have to be .win?

Thanks guys,
[Android] Captain_Throwback:
You can't use them as a TWRP backup, but you can flash the images in TWRP, yes. The effect is the same.
[Android] Gandalforce:
So not the restore option, but just the install option, and zip up both images, stick on on SD, correct?
[Android] Captain_Throwback:
I didn't say anything about zipping up anything, did I?

You can flash the images as-is - no need to zip them up (as that won't make them flashable anyway).
[Android] Gandalforce:
kk
[Android] mirosaw2:
Thank you sir for your efforts making such great tool,

But it'd be much appreciated if you can make a keyfile for Desire 820 (A51_UL | 0PFJIMG),

As i need to decrypt and extract the hboot from the MM zip,

Thanks in advance
[Android] nkk71:
I don't have that device, nor the keyfile, nor the ruu(s), etc. That's the whole point of the tool, so people can "do it by themselves" without having to rely on 3rd party.

From the OP:
[Android] mirosaw2:
Extracted the hboot from OTA and tried to decrypt the zip again,

It failed to get the decryption key, and here is the output,

Now what ?
[Android] Captain_Throwback:
Where's the rest of the output? Did you add the hboot.img file to the commandline when running the tool?
[Android] mirosaw2:
Here is the command i used:

RUU_Decrypt_Tool.exe -f 0PFJIMG_A51_UL_M60_DESIRE_SENSE70_MR_HTC_Europe_3.17.401.3_Radio_01.01.010_U10305041_08.01.50512_release_476105_signed_2_4.zip hboot.img

That hboot file extracted from ota firmware, for the same device.
[Android] nkk71:
That is still not a complete output, you can check the OP for a proper copy/paste of

all

the output.

You were correct, logging and more detailed descriptions are needed :crying:
[Android] mirosaw2:
Ok, as long as output txt file is 95mb, i've deleted the Bruteforcing lines and paste it in pastebin (HERE),

And here is all details i have for you,

RUU Name (full filename): 0PFJIMG_A51_UL_M60_DESIRE_SENSE70_MR_HTC_Europe_3.17.401.3_Radio_01.01.010_U10305041_08.01.50512_release_476105_signed_2_4.zip

the version number: RUU Decrypt Tool 3.0.7
[Android] Captain_Throwback:
Looks like you don't have a suitable keyfile, meaning the hboot you provided doesn't have the key to decrypt the zip you're trying to decrypt. Just because an hboot is from the sme device doesn't mean that the key is the same across Android versions - in fact, that's often when the key is updated. You'll need someone that's on the firmware/RUU you're trying to decrypt to pull the hboot.img from their device using dd and a root shell. Or you need to find an already extracted hboot for that same Android version.