This has been resolved by using the flash lite exploit to gain root access allowing the misc partition to be flashed with a downgraded main version number which allows the old leaked Eng RUU we have to be flashed!
GUI for how to root
http://forum.xda-developers.com/showthread.php?t=720565
Old and Outdated information from the Original Post listed below for historical purposes ONLY
Who is Affected: If you've flashed the official OTA update on top of a non rooted ROM or your new EVO comes loaded with it, right now it appears there is no way to obtain root...yet!
What is Patched by the OTA: Through the radio.img which the OTA flashes, it updates the Main Version in the bootloader preventing Toast's root methods from working. It also flashes back the stock recovery, removing our root access in recovery mode and ability to apply .zip files. And last of all, the OTA patches the exploit hole in /system/bin/hstools used for unrevoked1 root.
Successfully eliminating all released methods of obtaining root access.
Conclusion:
after going through all these methods with a great helpful member of the unrevoked team, joshua_, this was the final answer:
[22:34] <joeykrim> cant see to find a method to RUU the phone back down ... ive tried all the methods ive seen. any methods i missed?
[22:34] <joshua_> ok, looks like we are hosed then
[22:34] <joshua_> we have a few more tricks up our sleeve sooner or later
Future:
If you have any suggestions/ideas, please post. I might have missed a method.
We will work towards obtaining root for those with new EVOs that have the official OTA applied and those who applied the official OTA.
Details of the tested known root methods:
user debug PC36IMG.zip (toast part 1) - bootloader error - Main Version is older! Update Fail! Do you want to reboot device?
eng build PC36IMG.zip (toast part 2) - bootloader error - Main Version is older! Update Fail! Do you want to reboot device?
RUU_Supersonic_1.32.651.6 extracted rom.zip renamed to PC36IMG.zip - bootloader error - main version is older
RUU_Supersonic_1.32.651.6_Radio_1.39.00.05.31_release_171253_signed.exe - Error [140]: Bootloader version error The ROM Update Utility cannot update your Android. Please get the correct ROM Update Utility and try again.
RUU_Supersonic_1.32.651.1_Radio_1.39.00.04.26_release_171253.exe - Error [140]: Bootloader version error The ROM Update Utility cannot update your Android. Please get the correct ROM Update Utility and try again.
Stock Recovery - Apply update.zip - clockwork recovery update.zip - E:failed to verify whole-file signature E:signature verification failed
flash_image (flash boot or mtd-eng.img) - copied to /sdcard, but sdcard is mounted with noexec. partition with write access for non-root user and allows executing is /data/local . flash_image can't write to the partitions w/o being run with root permissions. chownto and chown of flash_image to user root - permission denied.
##786# - Reset - doesn't seem to effect much in the way of bootloader version ...
Modifying PC36IMG.zip - using a hex editor to attempt at changing the MainVer stored in the android-info.txt, if any bit changes, it seems to fail the validation by the bootloader.
I tried almost all of these after the OTA hit my wifes phone. No dice. Subscribed to further updates on this thread.
I created a PC36IMG.zip file which contained the .6 releases wimax image and the android-info.txt file from the new update. I was then able to successfully flash it with hboot by placing it in the root of the sdcard and doing a down volume power on boot. It found the pc36img.zip file, verified it, asked me if I wanted to flash it. When I selected yes, proceeded to do so. It then reported the flash as having been successful.
I can't tell if the flash actually worked because I don't know where to check the wimax version info...
I don't know if this worked because the phone doesn't care to check the MainVer when flashing just the wimax image or if it did it because I pulled a fast one with the android-info.txt file swap.
I extracted the wimax image from the RUU_Supersonic_1.32.651.6_Radio_1.39.00.05.31_release_171253_signed.exe file.
I wonder if it would be possible to pull the same trick with the larger subset of images from the rooting pc36img.zip files. i.e. swap out the android-info.txt files...
frankenstein\ said:
I created a PC36IMG.zip file which contained the .6 releases wimax image and the android-info.txt file from the new update. I was then able to successfully flash it with hboot by placing it in the root of the sdcard and doing a down volume power on boot. It found the pc36img.zip file, verified it, asked me if I wanted to flash it. When I selected yes, proceeded to do so. It then reported the flash as having been successful.
I can't tell if the flash actually worked because I don't know where to check the wimax version info...
I don't know if this worked because the phone doesn't care to check the MainVer when flashing just the wimax image or if it did it because I pulled a fast one with the android-info.txt file swap.
I extracted the wimax image from the RUU_Supersonic_1.32.651.6_Radio_1.39.00.05.31_release_171253_signed.exe file.
I wonder if it would be possible to pull the same trick with the larger subset of images from the rooting pc36img.zip files. i.e. swap out the android-info.txt files...
Click to expand...
Click to collapse
im guessing the only reason it allowed you to flash a PC36IMG.zip which wasn't HTC signed is because you're using the hboot from the eng build of the PC36IMG.zip which doesn't check for HTC signatures on the PC36IMG.zip file. Not sure if it looks at the MainVer or not ...
once you're on a stock hboot, the PC36IMG.zip file has to be signed by HTC in order to flash!
I think in order for this to be patched, the bootloader code needs to be disassembled between the two versions to find out what bytes were patched and then either remove the code that checks for HTC signing or find a way to circumvent it.
We had to do things like this when working with mach_kernel when we got ahold of the first developer build of OS X for Intel. It was a pain in the ass and took weeks before we cracked the kernel.
There is even more risk with this though since tampering with the bootloader can definitely permanently brick devices.
joeykrim said:
If you've flashed the official OTA update or your new EVO comes loaded with it, right now it appears there is no way to obtain root...yet!
after going through all these methods with a great helpful member of the unrevoked team, joshua_, this was the final answer:
[22:34] <joeykrim> cant see to find a method to RUU the phone back down ... ive tried all the methods ive seen. any methods i missed?
[22:34] <joshua_> ok, looks like we are hosed then
[22:34] <joshua_> we have a few more tricks up our sleeve sooner or later
If you have any suggestions/ideas, please post. I might have missed a method.
We will work towards obtaining root for those with new EVOs that have the official OTA applied and those who applied the official OTA.
Here are details of the tested methods:
user debug PC36IMG.zip (toast part 1) - bootloader error - Main Version is older! Update Fail! Do you want to reboot device?
eng build PC36IMG.zip (toast part 2) - bootloader error - Main Version is older! Update Fail! Do you want to reboot device?
RUU_Supersonic_1.32.651.6 extracted rom.zip renamed to PC36IMG.zip - bootlaoder error - main version is older
RUU_Supersonic_1.32.651.6_Radio_1.39.00.05.31_release_171253_signed.exe - Error [140]: Bootloader version error The ROM Update Utility cannot update your Android. Please get the correct ROM Update Utility and try again.
RUU_Supersonic_1.32.651.1_Radio_1.39.00.04.26_release_171253.exe- Error [140]: Bootloader version error The ROM Update Utility cannot update your Android. Please get the correct ROM Update Utility and try again.
Stock Recovery - Apply update.zip - clockwork recovery update.zip - E:failed to verify whole-file signature E:signature verification failed
flash_image (flash boot or mtd-eng.img) - copied to /sdcard, but sdcard is mounted with noexec. only partition with write access for non-root user and allows executing is /sqlite_stmt_journals . flash_image can't write to the partitions w/o being run with root permissions. another words, need root access to use flash_image
##786# - Reset - doesn't seem to effect much in the way of bootloader version ...
Click to expand...
Click to collapse
since my frien did the OTA update yesterday and "bricked" his phone i have been trying to fix the phone (i have access to bootloader so it seems to me that maybe, just maybe i can save the phone) anyways, i have been getting a lot of the same error messages anytime i try to update/load any stock rom via bootloader.
what my question is, is there a way to take a 1.47.651.1 rom/image and put it into an ruu? i have looked all over htc's website, but they don't even acknowlege the existence of the evo, at least not that i can find.
joeykrim said:
flash_image (flash boot or mtd-eng.img) - copied to /sdcard, but sdcard is mounted with noexec. only partition with write access for non-root user and allows executing is /sqlite_stmt_journals . flash_image can't write to the partitions w/o being run with root permissions. another words, need root access to use flash_image
...
Click to expand...
Click to collapse
Just curious here, regarding the above step, if you had access to a phone that was already rooted, could you use your sdcard in that phone to copy the files into /data and then transfer the sdcard back to the unrooted phone to flash it then?
Sorry for the long multi quote, there are quite a few good ideas and I wanted to make sure I explored each of them as far as the original poster intended.
EtherealRemnant said:
I think in order for this to be patched, the bootloader code needs to be disassembled between the two versions to find out what bytes were patched and then either remove the code that checks for HTC signing or find a way to circumvent it.
Click to expand...
Click to collapse
interesting ... circumventing the HTC signature check would be perfect and essentially give us an eng build bootloader.
in the RUU.exe rom.zip files, the android-info.txt indicate the MainVer along with a separate hboot.img file. the official OTA didn't have an hboot.img file. It only had a radio.img file which must have updated the MainVer value.
Not sure where on the phone this MainVer value is stored? in the radio?
you're suggesting, compare the bootloader, which is obviously stored somewhere in radio.img as thats the only file being flashed thru the OTA which increments the bootloader version number, against an older radio.img to attempt and find which bytes were changed for the version number?
The radio.img files are all around 22mbs ... ugh
if we're able to find the change in version number on the radio.img, not sure how it would help in flashing over it?
i was kind of thinking down these lines...since the bootloader checks the version number of any file it attempts to flash, the version number is going to be the key.
if we're able to increment (or temp change) the main version number in the file being flashed w/o messing up the htc signature, that could work.
2002wrex said:
what my question is, is there a way to take a 1.47.651.1 rom/image and put it into an ruu?
Click to expand...
Click to collapse
i've heard this was often done back in the WinMo days but i haven't seen anything on this board regarding this approach. if you have any detailed information, we could def look into it!
unknown_owner said:
Just curious here, regarding the above step, if you had access to a phone that was already rooted, could you use your sdcard in that phone to copy the files into /data and then transfer the sdcard back to the unrooted phone to flash it then?
Click to expand...
Click to collapse
very clever concept!
i'm not 100% sure on all the different approaches in the suggestion, but here are the ones it prompted me to explore.
unfortunately, every time the /sdcard is mounted on the phone, its mounted as noexec, meaning no files located on the /sdcard can be executed like programs.
also the /sdcard is mounted with uid=1000 and gid=1015 meaning all files mounted on the /sdcard have their uid/gid overwrote so none of them are allowed root ownership.
without being able to "su" to root access, we aren't able to run any programs with root access.
trying to chownto flash_image to any reference file as root results in:
chownto flash_image /system/bin/chown
Can't change user/group to root!
chown root flash_image
Unable to chmod flash_image: Operation not permitted
if i missed the suggested approach, could you elaborate?
Oh boy...... I thought I was alone in this. I try everything I can and now gave up. Any one can rooted this new OTA please let me know. I really need to downgrade from this.
Made me think of a problem that happened with the Directivo a few years back...
ht t p://dealdatabase.com/forum/showthread.php?t=22154
I was looking around, trying to figure out some way to hack the hdvr2 w/o modifying the prom. I recalled something from the xbox-linux team's presentation for CCC, which was something close to "once you break the chain of trust, the box is forever compromised." I thought to myself: "self, if we can load one kernel via BASH_ENV, why can't we load a second kernel?"
Click to expand...
Click to collapse
So, is there a way we could compromise the kernel? If so, then...
Subscribed...
Not really interested in rooting until froyo is working, and I could really use the wifi fixes this OTA is supposed to offer, but I'll hold off installing it until we know it can eventually be rooted.
Mikesus said:
http://dealdatabase.com/forum/showthread.php?t=22154
So, is there a way we could compromise the kernel? If so, then...
Click to expand...
Click to collapse
i read thru the thread. im not clear on how they used BASH_ENV or any other method to load a 2nd kernel.
unfortunately, i think we have an extra layer of security that they dont. thanks HTC!
without nand unlocked on the kernel partition no data can be stored there including a 2nd kernel.
appreciate the link and info. perhaps the ideas or concepts will spur some innovation!
joeykrim said:
i've heard this was often done back in the WinMo days but i haven't seen anything on this board regarding this approach. if you have any detailed information, we could def look into it!
Click to expand...
Click to collapse
the thing about winmo ruu's (here's a topic i DO know well) is that they are always in a zip. you decompress the zip and have access to all the files. one of them will be the ruu, the rest are all the supporting files/images/rom. all of the android ruu's seem to come as on large exe that doesn't allow access to the files, it merely runs itself. in the winmo days if you got a rom with no ruu, and didn't want to flash from SD, you just took someone elses ruu and dumped the rom image in to the decompressed folder containing the ruu.
i appreciate the help joey, obviously you are busy with your own problems and a lot of people around here just throw you the old "SEARCH BUTTON" response. any help is greatly appreciated!
2002wrex said:
the thing about winmo ruu's (here's a topic i DO know well) is that they are always in a zip. you decompress the zip and have access to all the files. one of them will be the ruu, the rest are all the supporting files/images/rom. all of the android ruu's seem to come as on large exe that doesn't allow access to the files, it merely runs itself. in the winmo days if you got a rom with no ruu, and didn't want to flash from SD, you just took someone elses ruu and dumped the rom image in to the decompressed folder containing the ruu.
Click to expand...
Click to collapse
interesting again .. so the RUU .exe files for android, do have a payload stored in a rom.zip file which is dumped to a temp directory after the RUU .exe starts and before it finishes.
now, the rom.zip files have been pulled and posted in each of the two RUU .exe threads we currently have. these rom.zip files do contain all .img files which are flashed to the phone. the catch is though, just as the PC36IMG.zip files used in root, these rom.zip files seem to have a special HTC signature (checksum?) in their header.
if you open these rom.zip files from the RUU in winzip, it will error out, but using 7zip, they open just fine.
im new to HTC, this is my first HTC android phone and its almost been 4 weeks so this is as much as i know. it seems, if we're able to alter these rom.zip files either used in the RUU .exe or naming them PC36IMG.zip flashed thru the bootloader and the phone excepts them, we would be golden!
to help save you some searching and let you see what im talking about, here is the latest RUU rom.zip file
http://www.joeyconway.me/evo/stock/RUU_Supersonic_1.32.651.6_Radio_1.39.00.05.31_rom.zip
Subscribed, I was able to Order my EVO today so I will be watching for development. I pledge my donations to whoever is able to figure it out. I really appreciate the efforts of this community.
I second that pledge for donations! I, like many others here, updated while knowing that I probably shouldn't have. I knew better...
Subscribed.
Thanks for all the effort and work. I hope ya'll get it figured out.
dang, I just got my evo yesterday and got the update message so I thought it'd be ok to update it as I thought it might have been old.
Came home and was excited to do all my customization and tweaks, but w/ no prevail
So my local best buy will not give the phone to the customer without pushing the new OTA to it :/
Apparently all of the stores will be doing this per Sprint and HTC's request.
EtherealRemnant said:
So my local best buy will not give the phone to the customer without pushing the new OTA to it :/
Apparently all of the stores will be doing this per Sprint and HTC's request.
Click to expand...
Click to collapse
Try calling them ahead of time before picking it up and asking if you can just swing by and pick it up yourself and call Sprint to activate yourself. Tell them you are in a rush, make up a story, and see if they just let you pay for it and run.
:crying:
So i just downgraded to ICS again since JB is waaaay too slow and seemed not working well with me.
My current version is 4.03 with US .30, rooted of course. Here's the thing.
My freakn stupid TF700 keeps alerting me with this message.
"New firmware update is available"
I DON'T WANT UR DAM JELLYBEAN UPDATE! I REALLY HATE THAT and do not even wanna see the word ''update" any more
it seriously freaks me out and I wanna kill myself every time I see anything related to 'UPDATE' or 'JELLY BEAN'..
EVERY SINGLE TIME I turn it on, they show me the message. Even if i ignore it once, it is still stuck in the corner of my tf 700 as u can see
from the pictures I attached. In those pictures, things in blue box are able to erase or delete by just sliding it to the right or left.
But those in red box are undeletable. There's nothing i can do to get rid of those stupid update icons and notifications.
What can I do to NOT see this notification again? I will do anything...
PS. While i was reading HTC forum, I found a thread with the same problem and one of em suggested solution
by adding something like this to the build.prop
(ro.config.htc.nocheckin=1)
Of course this one is for HTC EVO 4G LTE so theres no way it's gonna work on my TF 700
but could there be something like this that I could use for my infinity?
If your device is rooted, rename /system/app/CMClient.apk and /system/app/DMClient.apk to e.g. CMClient.disabled and DMClient.disabled - that should prevent starting them at the next reboot.
And, just to contribute something to the community's collective knowledge, please upload your file /cache/dlpkgfile somewhere - I want to know if that is a direct upgrade from 9.4.5.30 to 10.4.4.20.
Problem solved
_that said:
If your device is rooted, rename /system/app/CMClient.apk and /system/app/DMClient.apk to e.g. CMClient.disabled and DMClient.disabled - that should prevent starting them at the next reboot.
And, just to contribute something to the community's collective knowledge, please upload your file /cache/dlpkgfile somewhere - I want to know if that is a direct upgrade from 9.4.5.30 to 10.4.4.20.
Click to expand...
Click to collapse
Well, right after posting this article, I started deleting things using root explorer to see if anything can solve the problem.
Since I am not an expert, I deleted pretty much everything that seemed useless for me, including DMC and CMC whatever they are.
If i knew what I know now, I could have just renamed them, but anyway those files are completely gone now.
and Hallelujah! The notification's gone too. Thanks for your support tho.
I don't know if you still want my dlpkg file since the problem's solved already.
If you still want it, just let me know where to find that file (exact location/directory of the file) and where to upload it.:good:
almightytaek said:
I don't know if you still want my dlpkg file since the problem's solved already.
If you still want it, just let me know where to find that file (exact location/directory of the file) and where to upload it.:good:
Click to expand...
Click to collapse
Yes, please. The exact location of the file is "/cache" and the name is "dlpkgfile". I just noticed that the file will be rather big (~185 MB) and only a small detail will reveal if it is interesting in its entirety, so if you have such a file on your device, please do the following:
- download the dlpkgfile file to your PC and rename it to dlpkgfile.zip
- extract \META-INF\com\google\android\updater-script from the zip
- attach the extracted file (~291 kB) to your reply post
If the first lines of updater-script indicate that it's an update from 9.4.5.30 to 10.4.4.20, the whole file can help users who downgrade to root and want to re-upgrade to the latest JB.
Alright
_that said:
Yes, please. The exact location of the file is "/cache" and the name is "dlpkgfile". I just noticed that the file will be rather big (~185 MB) and only a small detail will reveal if it is interesting in its entirety, so if you have such a file on your device, please do the following:
- download the dlpkgfile file to your PC and rename it to dlpkgfile.zip
- extract \META-INF\com\google\android\updater-script from the zip
- attach the extracted file (~291 kB) to your reply post
If the first lines of updater-script indicate that it's an update from 9.4.5.30 to 10.4.4.20, the whole file can help users who downgrade to root and want to re-upgrade to the latest JB.
Click to expand...
Click to collapse
Here it is.
I don't know why, but I couldn't upload it here with its original form (which is just a file named 'updater-script')
so I added .zip at the end. I bet you know what you have to do now, just delete '.zip' part and use it for the community.
almightytaek said:
Here it is.
Click to expand...
Click to collapse
Thanks!
Code:
assert(file_getprop("/system/build.prop", "ro.build.fingerprint") == "asus/US_epad/EeePad:4.0.3/IML74K/US_epad-9.4.5.30-20120907:user/release-keys" ||
file_getprop("/system/build.prop", "ro.build.fingerprint") == "asus/US_epad/EeePad:4.1.1/JRO03C/US_epad-10.4.4.20-20121026:user/release-keys");
Nice, that's a direct upgrade from 9.4.5.30 to 10.4.4.20. That confirms my theory that there are dlpkgfiles that bundle multiple incremental updates into one.
If you could upload the complete dlpkgfile to some file upload service, US users who want to root their tablet without unlocking would be grateful for a one-step upgrade to the latest JB, having to mess with OTA RootKeeper and the manual upgrading process only once. (I personally don't need it, since I'm unlocked and on WW firmware)
Hi folks.
I have an unusual smartphone from a Brazilian manufacturer, CCE, who have been bought for Lenovo.
This manufacturer are not exactly knowed for their support our product quality and I'm prety sure my device will not be updated or suported for any longer.
It's the SK504 and I want to try to customize the rom, build tunning apps (battery consumption sucks) and things like that. I have a good programming backgroung but not for mobile devices so I'm stepping on eggs for now.
The first thing I tried to do was get a backup from my actual rom so if I mess with something I shouldn't I would be able to come back to a working version through fastboot.
long story short, I managed to obtain through romdump 5 files; checksum.md5, config.gz, system.info.gz and system.tar
but, in the posts I been reading, it gives me the idea that I should get a boot.img, a recovery.img and a system.tar.gz
And with this I would be able to generate my own system.img through a different process.
Since I'm not being able to find what I did wrong, can anyone tell me if there are a different way to get those boot.img and recovery.img?
I tried the "adb backup -f boot.img boot" but it generates a 1kb .img file and I don't believe this is a valid boot.img.
rhodesbauer said:
Hi folks.
I have an unusual smartphone from a Brazilian manufacturer, CCE, who have been bought for Lenovo.
This manufacturer are not exactly knowed for their support our product quality and I'm prety sure my device will not be updated or suported for any longer.
It's the SK504 and I want to try to customize the rom, build tunning apps (battery consumption sucks) and things like that. I have a good programming backgroung but not for mobile devices so I'm stepping on eggs for now.
The first thing I tried to do was get a backup from my actual rom so if I mess with something I shouldn't I would be able to come back to a working version through fastboot.
long story short, I managed to obtain through romdump 5 files; checksum.md5, config.gz, system.info.gz and system.tar
but, in the posts I been reading, it gives me the idea that I should get a boot.img, a recovery.img and a system.tar.gz
And with this I would be able to generate my own system.img through a different process.
Since I'm not being able to find what I did wrong, can anyone tell me if there are a different way to get those boot.img and recovery.img?
I tried the "adb backup -f boot.img boot" but it generates a 1kb .img file and I don't believe this is a valid boot.img.
Click to expand...
Click to collapse
Instead of making a backup, have you tried to find original restore image? Usually it is a an .IMG file.
qwertyu123 said:
Instead of making a backup, have you tried to find original restore image? Usually it is a an .IMG file.
Click to expand...
Click to collapse
I used Root Explorer to look for both, recovery.img and *.img.
No result.
try this http://forum.xda-developers.com/showthread.php?t=2450045
Note: OTA updates don't work on my Nexus 5 due to TWRP blocking them. Now my phone doesn't recognize the OTA update anymore (When my phone went to install the OTA updated and rebooted, it rebooted into TWRP instead and completely ignores the updates existence since then). To fix this I plan to simply push the factory img of 5.0.1 to my device directly. I downloaded the factory .img from Google's website .
However instead of a .img file i'm used to, I got a .tgz. I extracted that and got a .tar and then extracted that to finally get my folder with the .img files. However now I'm not sure which one to push to my device. There is a img file called "radio-hammerhead-m8974a-2.0.50.2.22.img" but judging by the file size, I don't think that's the correct one (only 45MB). There is a .zip file called "image-hammerhead-lrx22c.zip" but this contains multiple .img files, the largest one called "system.img". I'm guessing this is the correct one to push to my device via adb since it's about 1GB in size?
I suspect pushing the entire .zip file to my phone and flashing that would be bad as it looks like it'll overwrite TWRP?
Any help would be greatly appreciated.
Here's a lot of useful information about OTA's Check it out: http://forum.xda-developers.com/google-nexus-5/general/info-nexus-5-ota-help-desk-t2523217
You'll need boot and system at least,
If you plan on keeping twrp and root, you may as well just flash one of the flashable zips already available in the development forum
Actually you should have a radio and bootloader img file. First one is - as the name says - the latest radio software (which is needed for GPS, WiFi, cellular network and so on). Second one is the latest bootloader. I'd update them both.
From the zip archive you should only flash certain imgs - if you flash all your data will be wiped (factory reset). What img files does the zip contain?
Why are you pushing them to your phone? You need to flash with fastboot from your computer. There is not just one img file for the update, there are several for different partitions on the phone. Have a look through some of the guides in the general section. Also, flashing one of the stock flashable zips would be much faster, but why not learn a little as you update.
Vomer has a thread of flashable 5.0 and 5.0.1 stock Google ROMs. Don't worry about factory images because you will lose everything once you flash these and it's a much bigger pain imo to back everything including internal on your phone up.
snappycg1996 said:
Don't worry about factory images because you will lose everything once you flash these
Click to expand...
Click to collapse
Not necessarily true.
You can flash bootloader, radio, and system without losing anything. You'll just have to reroot afterward.
Im still expirmenting with different ways of possibly, hopefully, someday over the rainbow, getting my S7 successfully downgraded. Ive taken so much time waiting for things to copy and paste, and convert, and made a custom firmware hours later, only for odin to either freeze or straight up shut down after reaching file analysis... so im exploring other ways. im not sure if its a good idea to flash only parts of the firmware? like just the AP files?
I wish samsung would allow us to say "I dont care if my phone isnt as secure" and then their butts are covered cuz we consented and we can still downgrade the bootloader and android version as desired.
i cant find any information on how to make a disk image into an lz4 file (as in oreo) since that one system file from the marshmallow stock is simply a disk image, so i went about it the other way and removed the lz4 from all of the oreo files, making them all either plain .bin or plain .img files except leaving the pit file and the meta data folder alone, and then repackaged them back into the same categorized tar.md5 files. odin checks them as legit, but just wont actually *DO* anything with them... so i got looking into my old s5 neo rom and saw that it was a 1 file version and wondered.... maybe i can make a 1 file version with a combination of the files i need/want, all into one custom tar.md5 and then maybe *that* will at least attempt a flash..... has anyone else tried this? or has already been thought about and failed?.... I only want that oreo rom with the marshmallow system image... is it really so impossible??
So glad I have an Appsung device... theyre locking their stuff down just as hardcore so... why not merge the names. Sampple is another option. heh.