yashsingh1/xdaforums huggingface dataset:
[EVO 4G Android Development] davidlightle:
I wondered whether part of the 256 byte header was related to the filesize as well. I talked with Joey and got the exact file sizes and converted them to hex, and I don't see anything like them in the header bytes. I'm really starting to think it's an HTC signature header.
[EVO 4G Android Development] joeykrim:
this is worth a try if its a simple filesize check? will need to test this?

ah, thats a good idea, too bad the file size in hex isnt part of the mysterious 256 bytes.

going with that logic, have you tried converting any other values to hex and looking for them in the 256 bytes? file names like recovery.img or versions? anything else worth searching for?

i unzipped ud-PC36IMG.zip and then, in windows, used winzip and 7zip each to create a .zip of all the exact same files of ud-PC36IMG.zip into a separate .zip with no compression. added back the 256 bytes at the front of the file taken from the original ud-PC36IMG.zip and didnt work.

file sizes were different in both cases.

basically i did this:

dd ibs=256 count=1 if=PC36IMG.zip of=headerbytes

cat headerbytes > ud-PC36IMG-winzip-final.zip

cat ud-PC36IMG-winzip-part.zip >> ud-PC36IMG-winzip-final.zip

and

cat headerbytes > ud-PC36IMG-7z-final.zip

cat ud-PC36IMG-winzip-part.zip >> ud-PC36IMG-7z-final.zip

neither one works in the bootloader, it checks the files then returns to the bootloader menu
[EVO 4G Android Development] numus:
How exactly did you check for filesize?

I use to do the BML4 conversions to zImage (kernel) on the samsung moment. Learned the hardway that the hex data isn't always in a linear fashion.

Use to find the header byte and then after that was the size in hex. Problem was say the size is 123456 in hex, it would be displayed in the hex data as 563412...
[EVO 4G Android Development] davidlightle:
I took the filesizes given (for the ud and eng versions) and converted to hex; I took a single hex pair and searched through both of the two strings of 256 hex pairs posted previously.

So this isn't a 100% guarantee on the check, as if they did some byte reordering, I didn't account for that as much, though a search of a single pair might/should account for this, I think.
[EVO 4G Android Development] EtherealRemnant:
Actually, the interesting thing is that after removing those bytes, if you create a new zip with WinRAR on normal compression, you get the EXACT same file size as the original file that had those bytes.

I can't seem to find a way to make a zip that has the 256 bytes of space open. I've tried 7zip and winrar with different settings to no avail. 7zip compresses it by about 2MB too much or 1MB too little.

Is it possible it is some sort of a binary 256 byte checksum?

When I put the image on my phone, both with and without the checksum, but with mainversion modified, it checked it, acted like it was going to go through but then got to the second Checking... screen and then without error, took me back to the main hboot screen.
[EVO 4G Android Development] JasjarMan:
This may help someone

I updated and lost root. I was able to get root back downloading the unrevoked.apk. but Im was not able to get the right recovery going so I can flash roms.

Anyway, what I did next was I downloaded the file RUU below.

I than plugged my evo to the pc and ran the RUU.

It read the phone and installed the new rom without the updates.

When it installed and phone turned on, it gave me the "new update, would you like to download and install (not word for word). I of course said NO WAY!

I installed the unrevoked.apk and it rooted the phone.

Now Im just trying to figure out how to get the recovery thingy so I can flash roms again. Any suggestions? I tried rooting the way its mentioned here in the forums but cant get it to work.

Maybe im still stuck because of the update? But my phone asked me if I wanted to install the NEW update so it seems the update cleared no?

RUU_Supersonic_1.32.651.1_Radio_1.39.00.04.26_release_171253
[EVO 4G Android Development] TMartin:
Sorry...Please Delete.
[EVO 4G Android Development] EtherealRemnant:
People, keep the discussion about losing root and trying to regain it **out** of this thread! This thread is only for trying to hack the new firmware to regain root and your posts are just cluttering the thread!
[EVO 4G Android Development] salmanaman:
what if we make the phone think its has another ota update and ruu a rooted zip file to it.
[EVO 4G Android Development] JasjarMan:
i wrote that i updated and lost root. Than i used the unrevoked.apk and got root again, so whats your problem? The apk rooted the phone with the new firmware!
[EVO 4G Android Development] david7586:
have you guys tried using the same root method as the htc incredible? it involves having a certain set of conditions met that will allow you to get su working.

http://xdaforums.com/showthread.php?t=699088
[EVO 4G Android Development] numus:
This isnt good.. Sounds like an issue Joeykrim and I know very well with the Samsung M900 Moment. Sounds like it is a special zip compression. With the moment we had to utilize retar-moment.c to make a tar file that ODIN (the flasher we used) would recognize and open, if you attempted to make a standard tar file it wouldn't work..... Sounds like the same exact situation
[EVO 4G Android Development] CYBERxNUKE:
im thinking you did have a custom rom?

i did the same thing, you should beable to downgrade via RUU..

same thing happened to me.

download an older RUU and downgrade. you will be down back to original stock rom, but you should beable to get back to full root.

please open up a new thread next time. not to sound rude, but most people in here are talking about signing zips on fully stock phones to try to downgrade or to find new exploit.

if you need more help, we are glad to help.
[EVO 4G Android Development] gx1400:
FYI - I ordered my phone through Bluefish Wireless (they run Sprint Corporate accounts). It was mailed to me in unopened retail packaging. It arrived Tuesday (6/29) afternoon.

I charged it and called to have it ported over. I didn't see what it was running before but when I turned it on and it prompted me for the OTA (I stupidly accepted), it did not come preloaded.
[EVO 4G Android Development] EtherealRemnant:
Even if we could "fake" the phone into thinking it has a new OTA, it would still fail when it rebooted and checked the signature.
[EVO 4G Android Development] EtherealRemnant:
I'm kind of leaning towards the same conclusion at this point. HTC must be utilizing a special zip tool to compress and sign the files.
[EVO 4G Android Development] joeykrim:
i think its great winrar creates an exact duplicate! i only tried winzip and 7z here at work cuz its all im allowed to have installed.

i remember reading the zip standard format stores information in these 256 byte header fields. what can be added onto winrar? does winrar do digital signatures? could this be a type of encryption from winrar? 256 bit encryption? could they just use a simple passphrase which is then encrypted in stored in the 256 byte header? can we attempt to brute force it?
[EVO 4G Android Development] numus:
Question is can we modify the container and add files to it, then using a hex editor resize the container to report the same file size?

I posted in cyanogen's forum to see if they know of a special zip compression for the nexus one... I am wondering if they might have the source for this in the kernel source...

http://forum.sdx-developers.com/development-84/attempting-to-get-the-source-part-2-(or-is-it-3-now)/

You can follow the results there

I am at work (regulate radioactive materials) so cant do any coding since i cant access my desktop for those functions and i have none of the proper tools on my netbook. But taking this from a chemical concept and trying to adapt it.

Has anyone tried this?

1) Strip 256 byte off the zip

2) amend the zip (should be able to open with standard unzip now)

3) add 256 byte header back on

4) resize with hex
[EVO 4G Android Development] webs05:
Saw this link posted earlier and didn't see any comments on it...

http://www.unrevoked.com/rootwiki/doku.php?id=public:adb_in_recovery

Has anyone looked into trying something similar on the Evo that Unrevoked did for the Incredible in that link. As it states right away in the link,

Essentially isn't that what everyone here is trying to do, deploy an unsigned zip that will allow us to root? Or is that Unrevoked link just deploying the zip post root and I am too noob with all of this?
[EVO 4G Android Development] numus:
http://twitter.com/unrevoked

Note: We have an EVO with the stock Sprint OTA now. Thanks for all the offers.

7:25 PM Jun 29th via Tweetie for Mac

I would imagine they have thought about and/or tried to modify this to work...
[EVO 4G Android Development] EtherealRemnant:
I've done through part three. How do you resize with hex? I'm at work but I have my personal laptop, I just have never heard of resizing something with hex.
[EVO 4G Android Development] joeykrim:
had another idea, instead of having 256 bytes of space open, could you overwrite the first 256 bytes of the winrar created .zip which has the exact same file size as the original ud-PC36IMG.zip with the extra 256 byte info from the original ud-PC36IMG.zip? im not sure what is kept by default of winrar in the first 256 bytes header but perhaps its not important or just winrar non essential data.

once i get home with winrar, i can start experimenting since this tool is the only one so far to produce something identical!
[EVO 4G Android Development] EtherealRemnant:
If you overwrote that data, it would break the archive. WinRAR starts off with the PK signature right in the very beginning of the file, as does every other archiver I tried.
[EVO 4G Android Development] numus:
Credit goes to leshak @ samdroid

get the program Hex Editor Neo (it is what i am familiar with) main menu "Edit->Change File size" simple enter size

Hard part will be getting the size (exact size) in hex or decimal i would think
[EVO 4G Android Development] EtherealRemnant:
So would it be better to go in and shrink the archive and then expand it using the hex info?
[EVO 4G Android Development] numus:
Not sure i am following
[EVO 4G Android Development] unknown_owner:
What could they mean by adopting the signature, then checking it? Checking against what?

<T021142><DEBUG><OUT>writing 'zip'... INFOadopting the signature contained in this image...</OUT>

</DEBUG></T021142>

<T021142><DEBUG><OUT>INFOsignature checking...</OUT>

Scratch this question. DOHH!!
[EVO 4G Android Development] joackie27:
Based on the RUU log above it perfoms the following checks:

1. Signature

2. Header

These checks pertains to the ROM

3. Model ID

4. Custom ID

5. Mainver
[EVO 4G Android Development] unknown_owner:
I'm just going to make some observations; maybe they might help someone see something. Looks like the log shows that actions that are being performed. In the log below the time of my laptop was noted where you see <T021142>: this is 2:11:42 AM. Notice that the signature checking takes some time to perform (about 36 seconds- all my logs show the same time, everytime). I'm not sure how a digital signature is read, but when you guys are reading the signature from the rom.zips, does it take that long as well? If it takes you just a couple seconds, could it be possible that something else if being done to establish this signature that they refer to in the log?

<T021142><DEBUG><OUT>INFOsignature checking...</OUT>

</DEBUG></T021142>

<T021218><DEBUG><OUT>INFOzip header checking...</OUT>

I want to just say, the s**t you guys know is staggering. I have to read ya'll post several times to tell myself: I think I got that.
[EVO 4G Android Development] joeykrim:
sweet. the log was very interesting to understand the process.

i went and did all those commands manually

E:\android\android-sdk-windows\tools>fastboot devices

<PHONE SERIAL #> fastboot

E:\android\android-sdk-windows\tools>fastboot -s <PHONE SERIAL #> getvar boot-mode

boot-mode: FASTBOOT

finished. total time: 0.000s

E:\android\android-sdk-windows\tools>fastboot -s <PHONE SERIAL #> getvar battery-status

battery-status: good

finished. total time: 0.000s

E:\android\android-sdk-windows\tools>fastboot -s <PHONE SERIAL #> getvar version-main

version-main: 1.47.651.1

finished. total time: 0.000s

E:\android\android-sdk-windows\tools>fastboot -s <PHONE SERIAL #> getvar boot-mode

boot-mode: FASTBOOT

finished. total time: 0.000s

E:\android\android-sdk-windows\tools>fastboot -s <PHONE SERIAL #> oem rebootRUU

... OKAY [ 0.031s]

finished. total time: 0.031s

E:\android\android-sdk-windows\tools>fastboot -s <PHONE SERIAL #> getvar boot-mode

boot-mode: RUU

finished. total time: 0.000s

E:\android\android-sdk-windows\tools>fastboot -s <PHONE SERIAL #> erase cache

erasing 'cache'... OKAY [ 1.125s]

finished. total time: 1.125s

E:\android\android-sdk-windows\tools>fastboot -s <PHONE SERIAL #> flash zip e:\android\evo\troot\ud-PC36IMG.zip

sending 'zip' (172069 KB)... OKAY [ 26.875s]

writing 'zip'... INFOadopting the signature contained in this i

mage...

INFOsignature checking...

INFOzip header checking...

INFOzip info parsing...

INFOchecking model ID...

INFOchecking custom ID...

INFOchecking main version...

FAILED (remote: 43 main version check fail)

finished. total time: 56.563s

E:\android\android-sdk-windows\tools>

pushed my own modified ud-PC36IMG.zip just to test how it handles it

E:\android\android-sdk-windows\tools>fastboot -s <PHONE SERIAL #> flash zip e:\andro

id\evo\temp\ud-test.zip

sending 'zip' (172090 KB)... OKAY [ 26.922s]

writing 'zip'... INFOsignature checking...

FAILED (remote: 12 signature verify fail)

finished. total time: 50.281s

E:\android\android-sdk-windows\tools>

seems it performs, signature checking, zip header checking, zip info parsing, then it starts reading actual data out of the zip, model ID, custom ID and main version.

the consistent point we see between this and the PC36IMG.zip method is in both methods, the bootloader does all the verification. the RUU .exe only executes the fastboot commands. its basically a fancy .bat file.

at the very least, this is a much quicker method to testing custom PC36IMG.zip then rebooting into bootloader and letting it auto check the PC36IMG.zip on the sdcard!
[EVO 4G Android Development] unknown_owner:
glad to see at least it helped for something.
[EVO 4G Android Development] joackie27:
Has anyone tried tweaking the Incredible rooting process to apply to this OTA?
[EVO 4G Android Development] joeykrim:
tried this, winrar using normal compression and default options for everything.

ud-PC36IMG-wr.zip - 176,199,680 bytes

ud-PC36IMG.zip - 176,199,552 bytes

am i missing something on how to create the .zip using winrar so the byte size is identical?
[EVO 4G Android Development] EtherealRemnant:
It came out identical for me... weird.

Maybe I'm on crack. It was late last night but I swear the byte compare was exactly the same... I'll check later.
[EVO 4G Android Development] swatspyder:
ud-PC36IMG.zip - After using ghex to remove the header someone posted earlier in this thread, I unpacked the archive and changed MainVer in android-info.txt to 1.47.651.1. I packed the archive in WinRAR, telling it to use the same archive date and time, and came out 2 bytes off.

Original: 176,199,296 bytes

WinRAR: 176,199,298 bytes

I have not added the header back into the newly created archive.
[EVO 4G Android Development] EtherealRemnant:
I did not modify any files. I extracted with 7zip, then re-archived with WinRAR with no changes.
[EVO 4G Android Development] swatspyder:
Well... I will do that here in a moment.

After adding the header back in, like expected, it is still 2 bytes off.

Original: 176,199,552

After adding header (from WinRAR packed file *look 2 posts up*): 176,199,554
[EVO 4G Android Development] CYBERxNUKE:
what you can do is check each individual zip file and check if all the files have the same compression.

that is what is probably giving you the incorrect size when zipping.

the RUU reads more than just the .txt file for the version number.
[EVO 4G Android Development] numus:
If someone can give me a link to the ruu and other files (i did dev for another device and am brand new to htc so not sure about their programs and everything) want to try something..

Has anyone simply removed the header from the zip file

extracted the files.. rezipped those files exactly as they were, put the header back in and then resized the zip file with a hex editor and tried to flash?
[EVO 4G Android Development] swatspyder:
Other than the 2 byte offset from when I changed that txt file, it seems like everything will come out the same when you remove the 256 byte header and then unpack the .zip with 7z. Package the files into a new .zip using WinRAR with a setting of Normal compression and in my case change the archive settings to use the original date and time, not current computer time. Then add the 256 byte header back into the .zip with a hex editor and it will be the same as the original .zip.
[EVO 4G Android Development] swatspyder:
Yes, see my post on pg 9 (post 90). It came out with a 2 byte offset because i modified the text file. I can't flash though. My phone hasn't come in from Sprint. Just checked and it will arrive tomorrow!... :D
[EVO 4G Android Development] CYBERxNUKE:
in order to verify the info, i think we might need to have someone with a non updated evo try to update to the unsigned rom.zip.

im thinking maybe its not the zipfile that it checks.

maybe it checks the CRC of the the files and the header has the encrypted crc's.

just a wild guess
[EVO 4G Android Development] unknown_owner:
I've never done what you guys are doing, I mean the hex editing. Maybe I'll give it a try as well.
[EVO 4G Android Development] marclile:
has anyone heard from toast? i've been trying to keep up on all of these posts but i don't remember hearing anything from him. i would guess that he is working on this but does anyone know for sure?
[EVO 4G Android Development] Vinny75:
I think I read that he is on a trip to atlanta or something
[EVO 4G Android Development] marclile:
damn :)

props to all of you guys for trying to figure this out. you are a lot smarter than i am.
[EVO 4G Android Development] numus:
Been talking to joey, peeps and some others and brainstorming... I dont think we will be able to flash using RUU :( Seems there is an encrypted signature that is generated for the zip minus the 256 byte header. the 256 byte header contains the encrypted signature... Doesnt appear to be filesize dependent (tried to manipulate the file size and didnt work)..

On a side note, the OTA doesn't seem to have this protection (is it signed at all?)

So the man thing about that method is how to get a zip into /cache and how to flag the phone to reboot and install as if it received an OTA update
[EVO 4G Android Development] swatspyder:
I was just reading about the 256 byte signature. We would be wasting our time to continue trying to mess with the signature in these zip files.

http://xdaforums.com/showpost.php?p=6002605&postcount=12
[EVO 4G Android Development] enormous:
I've been pondering this as well... I wonder if it would be possible to set up your wifi router to redirect the communications between your phone and the update server. When you manually checked for updates the webserver you redirect to would then serve up the appropriate files.
[EVO 4G Android Development] numus:
I dont know if this is possible... I am not 100% sure but i believe all firmware updates are sent via the cell network (atleast the notification to the phone that updated software is avalible)... After that then it proceeds to ask you which method you wish to utilize to download the file (at this point we could select wifi, redirect the dns to a non-htc server and have it flash our ota.. but for all of us who already applied the update it is to late for this)... We would have to suspend all cell coverage and see if it defaults to check any dns for firmware updates (not sure how to turn off all cell signals but after that run logcat and attempt to update firmware and see if it attempts to connect to a server to check)... If we could write to /cache this would be much easier but without root that doesnt seem possible :(
[EVO 4G Android Development] poxin:
Just received my phone from sprint and it came loaded with this update. Chiming in to lend another EVO for testing.

Hope someone figures this out :)
[EVO 4G Android Development] swatspyder:
Is there a way to flash over the bootloader with a modified bootloader with modifications to cause it to ignore all signature checking? I know it would be extremely likely for phones to be bricked even if it would work...
[EVO 4G Android Development] enormous:
What I'm thinking about is shutting off your mobile data connection, using only wifi, and manually checking for updates. That traffic would be easy to intercept. Assuming you knew the appropriate response to send you could then direct the phone to the load the "update".
[EVO 4G Android Development] numus:
Will it check for updates via the wifi network is the only real question i have... i am not so sure it will...
[EVO 4G Android Development] swatspyder:
If you could intercept all traffic (Wireshark) and find out what response was sent to the phone, then you should be able to form your own packets and send them to the device, right?

But even then you would have to make sure the phone can even check for an update over wifi.

Or maybe like unrevoked, you could click on a link and have it send the data required to notify the phone that there is an update, and then push the update to the phone.
[EVO 4G Android Development] EtherealRemnant:
It checks over wifi.
[EVO 4G Android Development] swatspyder:
Do you have any data on what packets are sent/received?
[EVO 4G Android Development] EtherealRemnant:
No because I am at work but I just turned off mobile data and background data, turned on Wifi and it failed (because you have to log in to our wifi) but once I logged in to our corporate wifi, it immediately came back and said no update available.

Also, I know it went over wifi because I shut off wifi and it said to turn on either mobile data or wifi to check.
[EVO 4G Android Development] enormous:
As a quick (and non-definitive) test I just toggled off my mobile data connection and did a manual check for updates. It returned "No updates available", so I would assume that traffic went out through my router...
[EVO 4G Android Development] swatspyder:
Can either one of you run your connection through a computer and run Wireshark on it to see what is being sent and received, and what server(s) it is connecting to?
[EVO 4G Android Development] EtherealRemnant:
How would I go about doing that? I'm willing to do it, I've just never used Wireshark before. Wouldn't I need a dongle to capture the packets flying around? Or are you talking about setting my machine up as an AP>?
[EVO 4G Android Development] enormous:
I would happily do that, but I'm currently in bed (should be sleeping!). If there haven't been any takers by tomorrow evening after work I'll give it a go.
[EVO 4G Android Development] swatspyder:
If all data is over wifi, you should be able to passively sniff the traffic going by. You can have your wireless router encrypted, but it would be easier to have it be unencrypted when you are sniffing.

Do you have experience working with linux on your computer?
[EVO 4G Android Development] OneStepAhead:
I'm thinking this isn't going to do any good, unless the phone trusts all data sent from the update server. I'm guessing even If you do intercept the traffic, the update you inject will probably need to be properly signed.
[EVO 4G Android Development] numus:
Anyone tried this? http://xdaforums.com/showthread.php?t=715915

Nevermind.. tried it.. scanned and went right back.. didnt work
[EVO 4G Android Development] swatspyder:
AFAIK, there is an idea floating around that we MIGHT be able to send a rooted image OTA to the phone. We would just have to find a way to get the phone to pull our image, instead of connecting to HTC's/Sprint's update server.
[EVO 4G Android Development] EtherealRemnant:
I used to change distros daily. The app has a Windows version though?