Database Info

[RESOLVED] Researching how to root - Official OTA_Supersonic_1.47.651.1-1.32.651.6

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.

Google Experience only

I am happy with what I have since the new update from Viewsonic.
If I only want to add Google Experience, marketplace, do I still need to go through the process of rooting, installing clockwork and a new UI?
Is there just a simple way to add GE to the Classic UI?

Gapps install
http://forum.xda-developers.com/showthread.php?t=842590

Everyone,
I have had zip luck with this method of installing zapps. Not a dev, but I've been doing this long enough.....
I moved the Recovery file to to /sdcard. Checked for command and command line inside that file All ok to my eye.
Downloaded the gapps file which my WinRAR pronounces a WinRAR/Zip file. So I tried renamein the original update.zip and didn't get any install. So I extracted using winRAR. Still no install.
I tried the permutations as well. Extracted using G-Tablet extract. Still no results.
There must be something I am missing here -- too much holiday cheer or too many crowds or whatever.
Suggestions?!
Rev

butchconner said:
Everyone,
I have had zip luck with this method of installing zapps. Not a dev, but I've been doing this long enough.....
I moved the Recovery file to to /sdcard. Checked for command and command line inside that file All ok to my eye.
Downloaded the gapps file which my WinRAR pronounces a WinRAR/Zip file. So I tried renamein the original update.zip and didn't get any install. So I extracted using winRAR. Still no install.
I tried the permutations as well. Extracted using G-Tablet extract. Still no results.
There must be something I am missing here -- too much holiday cheer or too many crowds or whatever.
Suggestions?!
Rev
Click to expand...
Click to collapse
I HAD to resort to putting on Clockwork Mod 0.8 to get GApps on my G Tablet.
Putting the update.zip on the internal and sd card storage did not work for me either with the newest update installed.
Clockwork Mod is a super easy install - just follow the instructions on how to install G Apps...basically: put CWM on your SD card in it's root (meaning NOT in any directories) and rename it update.zip, put the corresponding recovery directory on the SD as well. I use Winrar as well, I drag the recovery directory right from the file itself and to the SD Card.
Will look like:
Drive: update.zip
Drive: /recovery/command
basically.
Flash it the normal stock way (power and volume +). I press Power and Volume + without even powering off the device, because if the device is powered down and then you start it and miss that first start up, the device WILL delete the recovery/command file and the update won't flash.
GL

I don't officially get to play with my GTab until after package opening tomorrow so I can't do anything today, but I'm trying to line up my to do list. I have never rooted, flashed, or modded anything but am not afraid to play around as long as I don't brick the tablet.
What do you mean when you say "put the corresponding recovery directory on the SD as well. I use Winrar as well"? What is the corresponding recovery directory? What do you use Winrar for? I Googled "winrar" and found " WinRAR is a shareware file archiver and data compression utility developed by Eugene Roshal, and first released in the fall of 1993.[1] It is one of the few applications that is able to create RAR archives natively, because the encoding method is held to be proprietary. " I cannot figure out why it would be needed to load the standard Android market.

MSU_Sparty,
When you do updates (or installs) that have to be flashed onto the internal sdcard, they usually com in pairs of files. You will have an update.zip file that has the update in it (DUH!) -- and accompanying it will be a "Recovery" directory that has a command file in it (The command file has only one line that "calls" the update.zip file.
WinRAR "Zip" utility enters the picture because most of the devs here use WinRAR to package updates. The when they tell you to decompress it, you use WiinRAR and are left with a .zip file to install.
That's the question I had about this update. The Gapp file show to be a RAR package, but when I un-RAR it I come up with no .zip file -- only regular files.
Hope this helps you understand.
Rev
P. S. -- If you are new to this business, take it slow and easy and read ahead on this site and make sure you understand what you are doing. I try to do that, but even with years of IT experience I still mess things up once in a while.

Neoprimal,
Thanks for the tip about CWM. I have two tablets and the other has CWM on it and is fairly modded.
But this tablet I am trying to keep basically stock so I can get updates, etc. and see what the "state of product" is.
As mentioned in my previous answer, I am stumped because I am not getting what looks to be an update.zip file from the Gapp download. When I use WinRAR to decompress the Gapp file, I don't get a .zip file -- only a couple of directories. On the other hand, when I rename the Gapp file update.zip and try to flash it it doesn't work.
Again, thanks for the reply.
Anyone else with suggestions!!!????
Rev

Thanks. What you've written really does clarify the previous post. I appreciate it.
But let me ask another naive question. Why don't the developers create their update programs so they can be installed by just downloading them OTA like most applications? That would sure make it easier for neophytes. I'm guessing that the reason is because we aren't really adding an application but replacing the OS.
I greatly appreciate your guidance and that of all of the folks who use this forum.
Happy Holidays!

[Completed] [Q] Unknown Serial, Cannot Wipe, or Factory Reset. Stuck in Boot Logo Screen

Hi
I have an Asus Fonepad 8 (K016 or FE380CG. 2GB RAM, 16GB ROM), I know it's not popular around here.. But any help is very welcome.
My initial device's state
- Stock rom 4.2.2
- Root (installed: Greenify, App Ops, Coolify, System App Remover (Jumobile))
- I uninstalled about 20 system apps
then I received OTA update to Lollipop and it displayed the infamous android "error" with the red exlamation mark. so i uninstalled every root app, EXCEPT System App Remover (silly me i forgot the most crucial part), probably meaning that some system apps are still gone. I also did full unroot inside SuperSU.
I tried factory resetting in order to successfully update to Lollipop, but once I get to the setup Welcome screen, these dreaded messages show up. ENDLESSLY
Unfortunately, com.android.phone has stopped working
Unfortunately, com.android.systemui has stopped working
Unfortunately, com.process.acore has stopped working
Click to expand...
Click to collapse
One time, the endless torture stopped and I was able to access Settings. I opened Applications and there was very (infact, too) few apps installed. Less than 200MB of RAM is used. I thought the factory settings failed, so I tried doing the same thing again in fastboot mode. But still a no-go.
Then I tried
Code:
fastboot -w
and it did say "success" but it couldn't format. "File system not supported". I forgot the exact message but that, i think is the point.
In Droidboot Provision OS, there is an option called "SD download". I put the official ROM for my device (.zip) in my SD card, then tried doing exactly that. Still no-go. Below is the entire (not exact) process
Copying E:\ASUS_UPDATE.zip to /cache (i renamed my firmware .zip file to that)
Copying asus update file (i have no idea where this file (if it even is a file) is located)
then my device reboots
a brief "no command" error appears
reboots back to my faulty state
Click to expand...
Click to collapse
I then tried to erase cache and userdata, and ran
Code:
fastboot update fw.zip
This appears
archive does not contain android-info.txt
archive does not contain android-product.txt
Click to expand...
Click to collapse
Desperate enough, I tried to again erase cache and userdata and system (probably my worst decision). and the device is now stuck in boot logo screen.
My awesome representation of my device's boot logo screen
ASUS
powered by
ANDROID
Click to expand...
Click to collapse
I booted my device back to fastboot, and my serial number was shown as "unknown". The same appeared when i type below code in cmd in my PC.
Code:
fastboot devices
One thing to be noted. I am really confused with ASUS's official firmware.
There is no recovery.img, system.img, userdata.img or cache.img
Here is a list of files and directories inside of it:
META-INF (folder)
recovery (folder, 2 files: recovery-from-boot.p and install-recovery.sh)
system (folder, a lot of folders inside like "app", "bin", "etc", "fonts")
boot.img
fastboot.img
splash1.img
splash1_s.img
splash2.img
splash2_s.img
splash2.img
splash2_s.img
ifwi.zip
modem.zip
Click to expand...
Click to collapse
I do not have nandroid or any kind of backup.
I have googled and tried everything I could find for the past 9 hours. So, i think it's high time I ask experts about this.
I am thinking of taking it to the service center. But any more knowledge regarding this beforehand is very valuable to me.
I know this is too long but I've highlighted the most important parts.
Any kind of help is welcome.

Hi, thank you for using XDA Assist. Unfortunately there is not a dedicated forum and there is very little information about your device on XDA. There is nothing on how to flash the stock firmware. But it sounds like that's what you need to do right now. Looking at ASUS's web site it looks like there should be another zip file. ifwi.zip, in the one you extracted. That's most likely where the image files you are missing reside.

jd1639 said:
Hi, thank you for using XDA Assist. Unfortunately there is not a dedicated forum and there is very little information about your device on XDA. There is nothing on how to flash the stock firmware. But it sounds like that's what you need to do right now. Looking at ASUS's web site it looks like there should be another zip file. ifwi.zip, in the one you extracted. That's most likely where the image files you are missing reside.
Click to expand...
Click to collapse
Hi. Thank you so much for replying and taking the time to read my long "story".
Sadly, yes. There is little to no community for my device.
Regarding ifwi.zip, below is part of the content of the file.
FE380CG_16_BOM_TOKEN_v79.54_CRAK_DEV.bin (3.608 bytes)
FE380CG_16_IFWI_v79.54_CRAK_DEV.bin (4.194.468 bytes)
FE380CG_1_BOM_TOKEN_v79.54_CRAK_DEV.bin (3.608 bytes)
FE380CG_1_IFWI_v79.54_CRAK_DEV.bin (4.194.468 bytes)
FE380CG_2_BOM_TOKEN_v79.54_CRAK_DEV.bin (3.608 bytes)
FE380CG_2_IFWI_v79.54_CRAK_DEV.bin (4.194.468 bytes)
FE380CG_32_BOM_TOKEN_v79.54_CRAK_DEV.bin (3.608 bytes)
FE380CG_32_IFWI_v79.54_CRAK_DEV.bin (4.194.468 bytes)
Click to expand...
Click to collapse
I doubt that it's the system image. The file size is just way too small.
The folder with the largest size is System, and inside there are a lot of folders (app (system apps and asus's bloatwares are inside), bin, etc, fonts, framework, etc, and build.prop). It almost looks like ASUS doesn't package system into a .img file, rather in a folder. That's why I am also looking for a script file that "copies" this folder into the device, if it exists.
I am now downloading the latest (was just uploaded by ASUS) firmware, which is Lollipop.
I'll dig in the file and see if I can find anything interesting.

Ok, download's finished.
Below is the root directory of the new firmware.zip
META-INF (folder)
recovery (folder)
system (folder)
boot.img
droidboot.img
splash.img
file_contexts (no extension)
l_recovery.fstab
partition.tbl
ifwi.zip
modem.zip
Click to expand...
Click to collapse
ifwi.zip has the same contents, only a newer version.
I tried fastboot update fw.zip and the same error pops up
archive does not contain 'android-info.txt'
archive does not contain 'android-product.txt'
error: update package has no android-info.txt or android-product.txt
Click to expand...
Click to collapse
I have attached a screenshot of updater-script I found inside META-INF/com/google/android. and screenshots of the directories of the firmware zip's contents. Hoping any is helpful to solve this.

First, I know nothing specific about your device. But do you have a custom recovery on your device? CWM or TWRP. The updater-script looks like it should be flashed in a custom recovery, not with fastboot. Edit, also, what's in the system folder, etc. Are there image files in there?

jd1639 said:
First, I know nothing specific about your device. But do you have a custom recovery on your device? CWM or TWRP. The updater-script looks like it should be flashed in a custom recovery, not with fastboot. Edit, also, what's in the system folder, etc. Are there image files in there?
Click to expand...
Click to collapse
Sorry for the late reply.
I just got the device back from the service center.
I inquired about where I can get the firmware file, and the guy said ASUS's website, but to flash it I need a tool.
It seems that this tool then copies the entire system folder to the device.
Anyways, the problem is solved now. Thank you very much for your help.

Glad you got it fixed. I'll close this thread.

Camera is broken.

Hello,
My device is the Mate 9 (MHA-L29C185B110) and I seem to have a problem with the camera.
When pressing the button to take a photo, the camera app restarts itself. I try again, but didn't work, to no avail.
I also tried to record a video. It seems to work, but the camera freezes but it's still counting, otherwise recording.
I have just recently flashed a custom recovery img (TWRP), the boot img on another thread that prevents the device from being automatically encrypted, and SuperSU root.
Do any of you have a solution to this problem?
Would this be because I haven't flashed Public_data.zip and Full_HW_data.zip?
And will this problem fix if I completely install the MHA-L29C185B172's firmware?

SeanPHTRPW said:
Hello,
My device is the Mate 9 (MHA-L29C185B110) and I seem to have a problem with the camera.
When pressing the button to take a photo, the camera app restarts itself. I try again, but didn't work, to no avail.
I also tried to record a video. It seems to work, but the camera freezes but it's still counting, otherwise recording.
I have just recently flashed a custom recovery img (TWRP), the boot img on another thread that prevents the device from being automatically encrypted, and SuperSU root.
Do any of you have a solution to this problem?
Would this be because I haven't flashed Public_data.zip and Full_HW_data.zip?
And will this problem fix if I completely install the MHA-L29C185B172's firmware?
Click to expand...
Click to collapse
It could be a problem if you flashed a boot image for a different model. You need boot image for C185B110. It should work without hw and Public zips, but a lot of other things break without flashing those. Updating to C185B172 will fix it.
By the way, which supersu did you use?
If the one from the "Decrypt" thread in Guides you don't need to flash a pre-decrypted boot image, the installer does it for you.

ante0 said:
It could be a problem if you flashed a boot image for a different model. You need boot image for C185B110. It should work without hw and Public zips, but a lot of other things break without flashing those. Updating to C185B172 will fix it.
By the way, which supersu did you use?
If the one from the "Decrypt" thread in Guides you don't need to flash a pre-decrypted boot image, the installer does it for you.
Click to expand...
Click to collapse
As for the SuperSU, I think I took it from the full root guide w/o decrypt img, but obviously I had to use a decrypt img because of stock
SUPERSU-2.79-MATE9-init.d_support
For the boot (No force encryption boot)
This is probably where things went wrong. I flashed the wrong build image.
https://forum.xda-developers.com/mate-9/development/stock-boot-img-library-t3573312
I had to use above link because I couldn't flash SuperSU since I don't have an external sd to extract it from (Since you have to format your data before flashing it)
I couldn't find the hw and public zips for C185B110, so if you have it, a link would be generous.
Would flashing stock boot img for MHA-L29C185B110 fix it?
and what would happen if i flash stock boot.img?
and do you have a decrypt boot.img for C185B110?
Thanks!

SeanPHTRPW said:
As for the SuperSU, I think I took it from the full root guide w/o decrypt img, but obviously I had to use a decrypt img because of stock
SUPERSU-2.79-MATE9-init.d_support
For the boot (No force encryption boot)
This is probably where things went wrong. I flashed the wrong build image.
https://forum.xda-developers.com/mate-9/development/stock-boot-img-library-t3573312
I had to use above link because I couldn't flash SuperSU since I don't have an external sd to extract it from (Since you have to format your data before flashing it)
I couldn't find the hw and public zips for C185B110, so if you have it, a link would be generous.
Would flashing stock boot img for MHA-L29C185B110 fix it?
and what would happen if i flash stock boot.img?
and do you have a decrypt boot.img for C185B110?
Thanks!
Click to expand...
Click to collapse
It would probably fix it yes, but no boot image or hw/public exist for B110 so I'm guessing it shipped with that build.
You'd have to update, using https://forum.xda-developers.com/mate-9/how-to/guide-mate-9-flash-update-package-t3593108
I don't think you can use Firmware Finder as you're probably missing the System Update feature.
Either that one I linked or FunkyHuawei, but Funky cost money to use.

Thanks,
I will try using the link you used.
although it is not clear.
On manual update step A, do you need to download all three?
the base, the OS(windows) and the model?
and where do i put these files?
and on b and c on update zip
do i have to download two update.zip?
for example, C185B110 and C185B172
do i also need to download full ota instead of just ota? fullota is incompatible, says firmware finder on mobile

SeanPHTRPW said:
Thanks,
I will try using the link you used.
although it is not clear.
On manual update step A, do you need to download all three?
the base, the OS(windows) and the model?
and where do i put these files?
and on b and c on update zip
do i have to download two update.zip?
for example, C185B110 and C185B172
do i also need to download full ota instead of just ota? fullota is incompatible, says firmware finder on mobile
Click to expand...
Click to collapse
Yes, download base, os and MHA. Extract all to the same folder. You should only have one folder named HWOTA and the files/folders in that. If it extracts to a folder with the same name as the zips, enter the folders and copy hwota folder then go back one folder and paste/merge so you end up with one folder named HWOTA. Easiest way is putting it directly in C:\hwota\, if your windows version allows it. Else place it on desktop. (long file paths or a path containing spaces might make hwota not function correctly).
You need to download all 3 files (fullota update.zip, hw zip and Public zip), easiest way is using firmware finder to download. Either mobile or the pc version. For pc go to the common base tab and search for your model and then download the build you want including public and HW zips.
You only need to download the fullota update, hw and Public zip of the build you're updating to. If you're on b110 and going to update to B172 you only need to download B172.
Rename the files according to the guide (update.zip, update_all_hw.zip and update_data_public.zip), place them in either hwota/update folder or make a HWOTA folder on your sdcard and put the renamed files there.
When running hwota, select script update folder or sdcard update folder depending on where you put the files. Select same model update.

One last question:
Does it have to be FULLOTA, not just OTA?

Can I recover Tab3 7.0 Android 4.4.2 WiFi using Haimdall on FWUL and how is it done?

As Odin in Windows does not do the trick for me, flashing stock ROM onto the Tab3, 7.0 WiFi device, I'll now want to try using Haimdall on FWUL.
But to make that happen, I seem need seperate .img files as Haimdall works with seperate files instead of that big tar.md5 file like Odin in Windows does.
So the first question would be:
What tools do I need to get all these seperate .img files out of the stock ROM Odin uses??
In Haimdall I managed to detect the Tab3 device and download and save the PIT file successfully.
But when I try to write into 'recovery' partition using a renamed file (TWRP 3.0.0-0.img) recovery.img, the process failed.
The log shows successfull writing of the PIT file, but it failed on recovery.img with this error 'failed to confirm end file transfer sequence'.
Also, there's no progressbar showing on the Tab3 device, while writing.
I already tried other USB cables, same results.
So the second question would be:
What did I do wrong, or did I miss something?

xdausernl said:
As Odin in Windows does not do the trick for me, flashing stock ROM onto the Tab3, 7.0 WiFi device, I'll now want to try using Haimdall on FWUL.
But to make that happen, I seem need seperate .img files as Haimdall works with seperate files instead of that big tar.md5 file like Odin in Windows does.
So the first question would be:
What tools do I need to get all these seperate .img files out of the stock ROM Odin uses??
In Haimdall I managed to detect the Tab3 device and download and save the PIT file successfully.
But when I try to write into 'recovery' partition using a renamed file (TWRP 3.0.0-0.img) recovery.img, the process failed.
The log shows successfull writing of the PIT file, but it failed on recovery.img with this error 'failed to confirm end file transfer sequence'.
Also, there's no progressbar showing on the Tab3 device, while writing.
I already tried other USB cables, same results.
So the second question would be:
What did I do wrong, or did I miss something?
Click to expand...
Click to collapse
To extract the firmware down to the individual .img files, try this thread, it leads to another guide on another site.
https://forum.xda-developers.com/showthread.php?t=2138885
Keep in mind, this guide is a bit old, the basic process is still valid but some things may have changed in how Samsung firmware is put together, there may be some extra steps required for firmware from newer devices.
Sent from my LGL84VL using Tapatalk

Droidriven said:
To extract the firmware down to the individual .img files, try this thread, it leads to another guide on another site.
https://forum.xda-developers.com/showthread.php?t=2138885
Keep in mind, this guide is a bit old, the basic process is still valid but some things may have changed in how Samsung firmware is put together, there may be some extra steps required for firmware from newer devices.
Sent from my LGL84VL using Tapatalk
Click to expand...
Click to collapse
Thanks for your reply,
Right after I wrote this text, I came up with another approach ... to just rename the stock ROM extension 'tar.md5' to '.tar' and so I did, then I unzipped the file.
But thanks anyway ...
Inside I found several files and about 6 image files and the PBL.bin file.
For 4 partitions I found an image file, system.img, NVM.img, cache.img and hidden.img.
Guess what ... with Haimdall in FWUL the upload went successfully and there's also a statusbar on Tab3 while at download, where as Odin (any version) in Windows failed on me all the time.
All files needed to upload seperately though, all at the same time gave me this error 'failed to confirm end of file transfer sequence'.
For the boot.img file I couldn't find a partition.
Recovery.img and the PBL.bin file failed to upload using Haimdall with errors 'failed to upload' and 'failed to confirm end of file transfer sequence'.
I also tried to rename a TWRP image to recovery.img, but that upload failed as well.
At this point I only proved the hardware being OK, that is the USB cable and the USB port on the Tab3 device.
It seems like Android operating system crashes after the message windows from antivirus program 'program has stopped', it then shut down and reboot.
After login the same thing happens all over again ... like some sort of boot loop.
And there's just not enough time to change any of the system settings, nor to disable any apps due to all those message windows you have to click first.
Overall status being Android operating system is still faulty.
This means that I just may be able to fix this thing, I only need the right tools to get the job done.
And I can't believe there's no one out there that couldn't help me out ...

xdausernl said:
Thanks for your reply,
Right after I wrote this text, I came up with another approach ... to just rename the stock ROM extension 'tar.md5' to '.tar' and so I did, then I unzipped the file.
But thanks anyway ...
Inside I found several files and about 6 image files and the PBL.bin file.
For 4 partitions I found an image file, system.img, NVM.img, cache.img and hidden.img.
Guess what ... with Haimdall in FWUL the upload went successfully and there's also a statusbar on Tab3 while at download, where as Odin (any version) in Windows failed on me all the time.
All files needed to upload seperately though, all at the same time gave me this error 'failed to confirm end of file transfer sequence'.
For the boot.img file I couldn't find a partition.
Recovery.img and the PBL.bin file failed to upload using Haimdall with errors 'failed to upload' and 'failed to confirm end of file transfer sequence'.
I also tried to rename a TWRP image to recovery.img, but that upload failed as well.
At this point I only proved the hardware being OK, that is the USB cable and the USB port on the Tab3 device.
It seems like Android operating system crashes after the message windows from antivirus program 'program has stopped', it then shut down and reboot.
After login the same thing happens all over again ... like some sort of boot loop.
And there's just not enough time to change any of the system settings, nor to disable any apps due to all those message windows you have to click first.
Overall status being Android operating system is still faulty.
This means that I just may be able to fix this thing, I only need the right tools to get the job done.
And I can't believe there's no one out there that couldn't help me out ...
Click to expand...
Click to collapse
I have to edit the last post, because I can change the stock ROM file name as mentioned before and that did not cause any problems with the md5 hash.
At this point, I can also download all files (10) succesfully from Heimdall with the Samsung tablet.
The only problem is caused by replacing the 'system.img' file, as the tablet immediatly reboots after Heimdall released the device after download was successfully.
It could mean that after the succesfull download, the downloaded system.img file is deleted at immediate reboot of the tablet, which would also explain why there's no changes after tablet reboot.
With all the other 9 downloaded files from Heimdall, it took several seconds until reboot of the tablet.

xdausernl said:
I have to edit the last post, because I can change the stock ROM file name as mentioned before and that did not cause any problems with the md5 hash.
At this point, I can also download all files (10) succesfully from Heimdall with the Samsung tablet.
The only problem is caused by replacing the 'system.img' file, as the tablet immediatly reboots after Heimdall released the device after download was successfully.
It could mean that after the succesfull download, the downloaded system.img file is deleted at immediate reboot of the tablet, which would also explain why there's no changes after tablet reboot.
With all the other 9 downloaded files from Heimdall, it took several seconds until reboot of the tablet.
Click to expand...
Click to collapse
Try a windows PC and try flashing via Odin, it tends to work better than Heimdall.
Also, if you are trying to use a system.img that is different than the system.img in your firmware, your bootloader may not be allowing the different system to flash or boot on your device.
Sent from my SM-S767VL using Tapatalk

xdausernl said:
Thanks for your reply,
Right after I wrote this text, I came up with another approach ... to just rename the stock ROM extension 'tar.md5' to '.tar' and so I did, then I unzipped the file.
But thanks anyway ...
Inside I found several files and about 6 image files and the PBL.bin file.
For 4 partitions I found an image file, system.img, NVM.img, cache.img and hidden.img.
Guess what ... with Haimdall in FWUL the upload went successfully and there's also a statusbar on Tab3 while at download, where as Odin (any version) in Windows failed on me all the time.
All files needed to upload seperately though, all at the same time gave me this error 'failed to confirm end of file transfer sequence'.
For the boot.img file I couldn't find a partition.
Recovery.img and the PBL.bin file failed to upload using Haimdall with errors 'failed to upload' and 'failed to confirm end of file transfer sequence'.
I also tried to rename a TWRP image to recovery.img, but that upload failed as well.
At this point I only proved the hardware being OK, that is the USB cable and the USB port on the Tab3 device.
It seems like Android operating system crashes after the message windows from antivirus program 'program has stopped', it then shut down and reboot.
After login the same thing happens all over again ... like some sort of boot loop.
And there's just not enough time to change any of the system settings, nor to disable any apps due to all those message windows you have to click first.
Overall status being Android operating system is still faulty.
This means that I just may be able to fix this thing, I only need the right tools to get the job done.
And I can't believe there's no one out there that couldn't help me out ...
Click to expand...
Click to collapse
Droidriven said:
Try a windows PC and try flashing via Odin, it tends to work better than Heimdall.
Also, if you are trying to use a system.img that is different than the system.img in your firmware, your bootloader may not be allowing the different system to flash or boot on your device.
Sent from my SM-S767VL using Tapatalk
Click to expand...
Click to collapse
Thanks for your reply.
But I came to Heimdall because Odin3 in Windows and even JOdin3 in Linux failed.
My guess is that the installed system.img on the system partition the culprit was in this case, because the stock ROM was the correct one for my tablet.
If you don't have the correct software, you either cannot install it or you will get your device bricked.
My device seem to be software bricked, for that matter and that is due to either the root software, anti virus software or an combination of both.

xdausernl said:
Thanks for your reply.
But I came to Heimdall because Odin3 in Windows and even JOdin3 in Linux failed.
My guess is that the installed system.img on the system partition the culprit was in this case, because the stock ROM was the correct one for my tablet.
If you don't have the correct software, you either cannot install it or you will get your device bricked.
My device seem to be software bricked, for that matter and that is due to either the root software, anti virus software or an combination of both.
Click to expand...
Click to collapse
Meanwhile I think I found a possible cause for failure using Heimdall-Frontend.
Heimdall-Frontend uses only extracted content of a stock ROM, in my case that's 10 files.
Although the download of the 'system.img' file completed successfully and Heimdall-Frontend releases the connected device, there's still a slightly different behaviour at reboot of Tab3.
Because after the release of the connected device, Tab3 then immediately goes into reboot.
That's not the case with all other downloaded files.
After releasing the connected device, it then takes a few second until the Tab3 goes into reboot.
So my guess is that at immediate reboot the downloaded 'system.img' file will then be deleted from the Tab3.
That would explain why after reboot nothing has really being changed.