yashsingh1/xdaforums huggingface dataset:
[Android] BigCountry907:
Did you unpack the HBOOT and get the file that is actually the file you need.

It's in the ramdisk.
[Android] Captain_Throwback:
No, it isn't. You're confusing hosd with hboot. You probably have a newer device than the user having this problem.

While we appreciate you trying to help, please don't comment unless you know what you're talking about. Thanks!
[Android] BigCountry907:
Sorry, I been so into HTC Development that I got stuck on the HOSD thinking.
[Android] nkk71:
The tool will automatically unpack, if it detects an hosd.
[Android] BigCountry907:
What I found when I was trying to decrypt the 526 RUU.

I had to pull the hosd from the device and unpack it.

Then I used the downloadzip file from the ramdisk sbin folder in place of the hosd.img.

Using the hosd.img did not decrypt the ruu for me.

I had to use the downloadzip file.

Not sure why but thats how it worked out.
[Android] Captain_Throwback:
Without your terminal output, there's no way to know what your issue was...:rolleyes:.
[Android] nkk71:
[B]RUU_Decrypt_Tool "<name of some ruu>" "<name of some hosd.img>[/B]

example from the OP:

Attempting to find suitable keyfile
Find First Encrypted ZIP
Encrypted zip to be used for testing: 'zip_0.zip'
User supplied hosd...
Android Image Kitchen - UnpackImg Script
by osm0sis @ xda-developers

Supplied image: my_hosd_signed.img

Setting up work folders...

Splitting image to "split_img/"...
BOARD_KERNEL_CMDLINE console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 user_debug=31 ehci-hcd.park=3 lpm_levels.sleep_disabled=1 cma=20M@0-0xffffffff androidboot.hardware=htc_pme
BOARD_KERNEL_BASE 80000000
BOARD_NAME hosd:0
BOARD_PAGE_SIZE 4096
BOARD_KERNEL_OFFSET 00008000
BOARD_RAMDISK_OFFSET 01000000
BOARD_TAGS_OFFSET 00000100

Unpacking ramdisk to "ramdisk/"...

Compression used: gzip
19567 blocks

Done!
Attempting to generate keyfile
bruutveal
---------

SUCCESS!rcing key[loop 1]: 575968/786208...
Successful bruutveal run, key written to: /media/nkk71/RUU/testruns/OUT/tmp/use_keyfile.bin
bruutveal keyfile has been successfully generated '/media/nkk71/RUU/testruns/OUT/tmp/use_keyfile.bin'
Working directory cleaned.
Finished: Successfully found decryption key, copied to 'tmp/use_keyfile.bin'

Unless if you're saying the tool failed to unpack hosd, which would be something else, and I would need a copy of that particular hosd.
[Android] beaups:
I suggest you study Qualcomm's secure boot implementation before wasting any (more) time. Even if you could flash unsigned or improperly signed bootloaders to your s-on device (you can't), they'll never boot and your device will be permanently bricked.
[Android] BigCountry907:
Yes qualcomms secure boot.

It all depends on what keys they used to sign the bootloader.

If it is signed cause it might not be.

At a minimum the factory bootloader and such can be used.

In the end I think it might take a few steps but if you flash the whole gpt .

Once in you replace keys with your own.

Everything past the LK Bootloader is fine anyway. After you unlock the boot loader it stops checking signatures.

The flash will have to be done with qfil.

And of cource the proper .xml file as well as others need prepared for the specific device.

It just depends on what qualcomm board support tools you can get.
[Android] beaups:
No. The chain of trust begins with PBL (burned into the SOC) authing SBL with HTC's keys that are permanently burned into OTP memory. You won't be able to switch to an unsigned SBL without a brick. SBL will refuse to execute/jump to any bootloader image not signed with keys matching the certs contained in SBL (which you can't change because ^^).

The tools you use mean nothing for this.

You can keep spending time on this, but its a deadend.

I guess the bright side is you won't manage to brick your device, because you won't get the loaders to flash in the first place. HTC is saving you from yourself.

--beaups

--beaups
[Android] BigCountry907:
Ok I agree with you that the bootloaders need to have HTC Signature.

My question is at what level in the boot-chain is verification bypassed due to S-OFF.

My theory........

One device that is unlocked and s-off with functioning boot-loaders.

Can be block by block flashed to the emmc by re-writing the whole gpt.

Once gpt is re-written with copy of s-off device (Block by Block) new device is at same state as donor.

Only need to flash qcn file to restore NV items when completed.

No way to flash all partitions wile s-on.

Other than qpst / qfil.

With device in QDL 9008 EDL " Easy to make Cable to force 9008"

Once 9008 switch to 9006 using correct msm.bin.

Flash using partition tools or Qfil.

Why won't that work? " Partition.xml " ( not a problem !! )

Anyway heres where I ended up last night.

And just a side note.

There Currently is no way to Root, Bootloader Unlock, or S-Off Verizon HTC Desire 526.

I just need to built twrp now.

Even I cannot save me from myself :)~
[Android] beaups:
You can not copy partitions from s-off device to s-on device to make the s-on device s-off. 1.) There is write protection. (yes, even in the various download modes) 2.) even if you defeat #1, the data is device specific and the device will still be s-on (I will not elaborate on this).

On s-off device, PBL still authenticates sbl or xbl. After that, sbl/xbl determines if the device is s-off or s-on and decides whether or not to enforce signature checking on aboot and the other loaders.

also I'm not sure what the screen shots and comment about desire 526 are about. That device is supported by javacard/xtc solutions. You aren't trying to imply that you made that device s-off/unlocked on your own, are you?

--beaups
[Android] BigCountry907:
No I'm not implying that. I unlocked it with a card.

I was just saying that I'm in and not worried about the write protect.

I have a few of the 526's.

I needed a donor s-off device to test this out on a s-on device. the 526 is only $35.00. ( Making bricking not so painful )

Identical chipset to the 626s, the only difference being the touchscreen and sensor.

Now I will compare partition for partition or actually bin for bin what flags have been set.

If the flag for s-off is on any partition I think my idea will work.

I have not confirmed it but read several places that the s-off flag is in the radio.

No problem to flash the radio. With qpst anyway.

I don't know if It will work or not. I haven't got that far yet. But I will try and then I will have the answers.

Any reference to work that you have done could be helpful.

Any files you have to share?

I believe that it comes down to having the right files to start.

Then having the ability to write the master partition.xml file by hand.

Once having a good partition.xml the python scripts can be used to generate some of the other necessary files.

Like the singleimage.

The firehose is going to be the same for all the msm8909 chips.

Really we need the whole gpt table to make the partition.xml.

Knowing that the RUU packages can flash all,

And that the carrier of the RUU makes no difference,

Provided super cid.

We should be able to do the same.

There is a gpt.bin file in the RUU packages.

I phrased that file to get the full gpt table using a python script.

Soon as i find time I will write the partition.xml.

I'm not saying that we can build our own boot-loaders or radios.

But I do not see any reason why we cant take those from the RUU.

Package everything back up and flash with qfil.

Maybe s-off won't keep, IDK. But we should at least have a good unbrick rom (QDL9008 - QDL9006)

Yes I know that the download mode is turned off in the kernel.

It's easy enough to compile the kernel. (But not necessary)

A simple usb cable with a switch to short D+ to ground and your in QDL9008.

If I can create the correct singleimage should be able to get it to open up the emmc.

I'm going to keep going as far as I can. The learning is the fun part and what is most important to me.

My only purpose of doing this is to learn and to have something great to share with the community.
[Android] Captain_Throwback:
Not to stifle your enthusiasm here, but all your posts (besides the one keyfile you posted) are really off-topic for this thread. Can you create a Dev thread somewhere for your project and post there please? Or ask a mod to move the relevant posts to a new thread? Thanks!
[Android] beaups:
You need signed tools (by htc) to do anything in the QDL modes. There are links to my work in my signature.

--beaups
[Android] BorderlinerSTORM:
Any chance of getting a 32bit Windows version of this tool?

I sadly lack the tools/knowledge to compile the source myself.
[Android] nkk71:
just checked, for ubuntu, it should just be:

sudo apt-get install libssl1.0.0

thought that was pretty much always included, but I guess I'm wrong.
[Android] syntropic:
I am running Debian (or Kali Linux dual boot).

I believe the current stable Debian version of openssl is openssl (1.0.1t-1+deb8u5). But as luck would have it I have openssl (1.0.2j-1) installed, which means I have libssl-dev 1.0.2j-1 and therefore libcrypto.so.1.0.2 installed.

root@crypts3c-[1565]:/media/root/My Book/HTC 10 Work # find /usr/lib -name 'libcry*'
/usr/lib/i386-linux-gnu/libcrystalhd.so.3
/usr/lib/i386-linux-gnu/libcrystalhd.so.3.6
/usr/lib/i386-linux-gnu/libcrypto.so.1.0.2
/usr/lib/x86_64-linux-gnu/libcrypt.a
/usr/lib/x86_64-linux-gnu/libcrystalhd.so.3
/usr/lib/x86_64-linux-gnu/libcrystalhd.so.3.6
/usr/lib/x86_64-linux-gnu/libcrypt.so
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2
/usr/lib/x86_64-linux-gnu/vlc/plugins/codec/libcrystalhd_plugin.so
/usr/lib/x86_64-linux-gnu/libcrypto.a
/usr/lib/x86_64-linux-gnu/libcrypto.so
/usr/lib/x86_64-linux-gnu/pkgconfig/libcrypto.pc

I have never coded in C (or any compiled languages....and Java doesn't count obviously).. Is there anyway of downloading libcrypto.so.1.0.0 and making it available to this tool without ending up in dependency hell?? I imagine Kali uses bleeding edge libraries because pentesting or whatever.

I will use windows if necessary, but the kitchen is in linux. What all is involved in statically compiling this? [Mostly asking because I don't know much about the subject.]

Could I compile this from source... using "configure --enable-static"? Or am I completely confused?

Thank you!!
[Android] nkk71:
Let's not forget the "origins"; this tool and all tools used by it are mostly linux based.... for linux (in particular Ubuntu), I was able to rely on quite a few "commonly used dependencies", so there was no need to statically compile

everything

.

For the Windows build, on the other hand, pretty much none of those libs would be part of a standard OS (don't even look at e2fsck ;) ), so I had to manually and statically recompile each and everyone from source (using cygwin) to be completely self dependant.

So for linux I only statically compiled unruu and simg2img

(pretty much due to the 2GB limit and the progress in simg2img)

The same can be done for all the other tools, and I even once had a thought of calling them directly, so that it would just be one 1 program.... but I kinda like the original programs to be there in case they're wanted and/or needed individually.

Let me see in the next couple of days.... if I have time, I'll recompile them statically. I'm pretty sure I wont be able to completely integrate them into 1 program, as I'm "working on" (well playing around with) other stuff too :angel:
[Android] syntropic:
Wow... that sounds like a nightmare. Well, you have opened the tool up to the world by doing this I guess.

Don't bother statically compiling it if it is a mess just for my atypical library versions. I am actually

surprised Debian—given their unbelievably conservative package review and release protocol, had libcrypto.so.1.0.0 in their "stable" repository... With some other packages (where Kali doesn't need to worry about bleeding edge), I am sometimes looking at "stable" versions from 2014 or 2015!

I will use Windows and copy the files to my external after everything unpacks so I can use them in Linux later. It is the least I can do considering all the time you put into it!

[
[Android] Captain_Throwback:
HTC Bolt keyfile. Will be linked on 1st page.
[Android] hohassan444:
key file for desire 828 ....2PREIMG
[Android] nkk71:
I think we should start looking into web upload/download modes ;)
[Android] ckpv5:
I got this on my first try using the tool to decrypt M8s 2.10.61.2 RUU

Maybe it will be useful to someone.

Thanks for the tool
[Android] blueberry60:
Here is new 0PJA Key File for last M9 Developer Edition Nougat 4.14.617.6 :
[Android] blueberry60:
I upgraded my M9 3.35.617.31 MM to 4.14.617. 6 Nougat and pulled out hosd.img and at the same time system.img for developers ( [MENTION=1186202]baadnewz[/MENTION] )-rom builders ( [MENTION=4445238]Golv[/MENTION] ) from my device with adb and I created 0PJA_keyfile_4.14.617.6.bin file from hosd.img in RUU Decrypt Tool. Decrypt Tool created 0PJAIMG zip file properly without any problem after created 0PJA Key file. I have controlled the size of my system.img and the other one of Decrypt Tool, they are same size as 4,697,620,480 bayt, but my testers who flashed it with 0PJAIMG method reported an error like that "FAIL 12 RU_ZIP ERROR ". I've been trying to solve the reason .Could you help me about that issue?

EDIT:

I solved this issue. I think there is a security or signature verifying protect while upgrading MM to Nougat, there is no issue for users on firmware 4.14.617.6, if users are on MM base and they want to upgrade their devices to Nougat, they have to flash 4.14.617.6 firmware.zip first and then 0PJAIMG zip file via download mode with 0PJAIMG method.
[Android] nkk71:
If the decryption key has changed then anybody on pre 4.14.617. 6 cannot flash an encrypted zip (at least usually, the exception would be if the first zip inside the ruu is unencrypted).

Update firmware first, then the ruu zip can be flashed.
[Android] blueberry60:
I was on pre 4.14.617.6 (updated with OTA to Nougat before) and took the risk but I flashed 0PJAIMG file successfully.
[Android] nkk71:
Yep, the ota would contain signed but unencrypted firmware, so it would have updated hosd for you, which would contain the new decryption key, and you can successfully flash an encrypted RUU.

I'm sure it's been mentioned somewhere, but here goes (this applies to encrypted RUUs including the first zip):

When trying to flash an encrypted RUUs, they obviously need to be decrypted during the flashing process.

.

This is handled by host or hboot (depending what the device uses).

.

hboot/hosd would contain HTCs decryption key that will be used to decrypt the ruu during the flash process.

.

if the decryption key contained in hboot/hosd is not the correct one

(as would be the case when you're on 3.xx.xxx.x firmware and trying to flash 4.xx.xxx.x RUU),

then hboot/hosd will not be able to decrypt the ruu during flash and report any number of errors

.

so the only way to get the encrypted RUU to flash, is to update firmware, so that hboot/hosd is updated (and now contains the proper key), and then the encrypted RUU will flash properly.

Hope that makes sense to you.
[Android] blueberry60:
Many thanks for your detail information. As you mentioned hosd.img contains HTC Decryption Key. After updating OTA, I pulled out hosd.img to SD Card with adb pull method. Decrypt Tool created 0PJA key successfully.

Thanks again for your great effort and support.
[Android] santod040:
Delete...
[Android] Captain_Throwback:
That's already posted here....
[Android] santod040:
Ah, so it is.

Back to sleep I go... :cyclops:

That's what I get for not reading the entire discussion about making them auto downloadable through the tool.

I was thinking all available ones were auto downloaded, my bad.
[Android] santod040:
Unlocked M9 Nougat 4.19.617.1 keyfile inside attached zip.
[Android] nkk71:
Thank you :)

Same as 4.14.617.6

keyfiles>sha1sum *
6886eff242b2ab0f9f0fc448d639b0c885fae1c0 *0PJA_keyfile_4.14.617.6.bin
6886eff242b2ab0f9f0fc448d639b0c885fae1c0 *0PJA_keyfile_4.19.617.1.bin

I should either update the tool, and/or need to get that download option going, my bad :(

Though cross-platform downloads, aren't too obvious to me tbh, looks like curl could be an option, not sure atm

btw, any *file*.bin in your local keyfiles folder, should get picked up, and no matter what you called it, should not report "this is new, please upload", if it does then, bug alert :angel:
[Android] santod040:
I probably didn't copy the previous keyfile from its output location, to the keyfile folder, causing it to look for a new one.

One thing I did notice, was the output boot.img in system folder is bogus.

Real one is in firmware though, so no biggie, just found it curious.

Thanks again for your efforts on this.
[Android] nkk71:
Interesting, haven't tried myself, I've noticed many RUUs have boot.img in both first and last zips, though they are usually the same... but things keep changing so thanks for pointing it out.

I will definitely check it out, and if you have anything to add please do so!

Many thanks mate :good:
[Android] CSnowRules:
Keyfile for A9 Nougat (2.18.617.1)
[Android] Captain_Throwback:
EDIT: Ninja'd!
[Android] Captain_Throwback:
You just beat me, lol.
[Android] CSnowRules:
Lol, sorry Captain.
[Android] Captain_Throwback:
No need to apologize, lol.

I hear that the next version of this tool will support automatic downloads of additional keyfiles and may even support uploading new ones once they're generated by users :). That'll make all the posting here unnecessary.
[Android] CSnowRules:
That will be pretty awesome, not to mention MUCH more efficient :D
[Android] Wonders_Never_Cease:
Disregard post..mod please delete if possible...
[Android] nkk71:
And those issues would be?
[Android] CSnowRules:
The uploaded keyfile works for me with both Linux (LMDE2 x64) and Windows (W10 x64) with RUU Decryption Tool 3.1.0. [MENTION=5345690]Wonders_Never_Cease[/MENTION], can you post the output?
[Android] Wonders_Never_Cease:
Me having a brainfart@ 6 a.m., Sorted...Sorry
[Android] mlecho:
I'm trying to get my device to 100% stock MM (1.57.617.60) so i can do a proper OTA and bring back Android Pay. Boot/System is no problem thanks to this tool. Recovery is my issue. Is the "./firmware/recovery_signed.img" file supposed to be it? When i reboot to recovery after flashing said file, i get the "red triangle w/ !" but can not volume up or really do a thing.
[Android] nkk71:
yep, that is stock recovery.
[Android] mlecho:
attached is the image i get when i boot into recovery after flashing that recovery_signed.img file. It stays like that for a few minutes, and eventually reboots to system. Pressing Volume up (or even down) does nothing...as does power. It's certainly from the same decryption, but does not want to give me proper recovery.
[Android] nkk71:
that is stock recovery, don't expect it to look like a custom recovery
[Android] mlecho:
huh...for whatever reason i thought there was at least a UI to reboot, or wipe. NO?

I am NOT referring to download mode....
[Android] Captain_Throwback:
Read step 4 here: https://developers.google.com/android/ota#instructions

P.S. [MENTION=2605798]nkk71[/MENTION] knows what he is talking about. Why don't you just try to install the OTA and see what happens?
[Android] nkk71:
Yes, I have a small idea of what you are NOT referring to. The answer is still, that is stock recovery,

Here are some images from the STOCK RECOVERY on the HTC 10 (just to be a bit device specific, so we don't need to keep guessing stuff all the time, though I don't know which version exactly :rolleyes::eek::( )

Those will also be found in DOWNLOAD MODE, but it has these additional ones too:

and this is by no means an extensive list, nor what mode does what.

So to conclude:

If you got a recovery*.img from your [official] RUU, then yes, that is your stock recovery... it is not supposed to look like a custom recovery like TWRP.
[Android] mlecho:
ha - i don't doubt all you guys know your stuff. Wayyy better than i do!

Yeah, the main reason i'm on this thread is i am trying to get my device back to stock marshmallow (MM), so i can get a working nougat OTA. I've flashed recovery,boot, and system to stock...and locked the bootloader so i can have Android Pay. I get the OTA modal, download, install, and it boots to the green arrow we see in that attached recovery from [MENTION=2605798]nkk71[/MENTION]. At 25%, it craps out to recovery, and then boots back to MM . Hence my first post to identify if i do indeed have the correct recovery. Any thoughts?
[Android] Captain_Throwback:
I think your issue doesn't belong in this thread.
[Android] ShinySide:
I can't wait til xda labs support hide tags lol

Your answer is right there
[Android] arindambag:
You are right bro, that is the missing link, but from where can I get the key or how to retrieve the hosd or recovery file?

Since you people are expert in these, I sought help from you all.
[Android] ShinySide:
I just noticed your error after splitting image too. You're probably missing gzip on your system. Fix that and you'll probably be good to go considering above your other error mentions not being able to access the zip
[Android] nkk71:
And we need shorter outputs... next version...

It's mentioned in the first pages (sometimes referred to as the OP), where/how you get your hboot or hosd... recovery does not come into play here.
[Android] nkk71:
That's probably just an "attempted" and failed "force extraction", first zip looks encrypted, so 99.99% of the time it wont work unfortunately.