Maybe we can get some informations about dload. This code i saw in stock recoverys dload folder. There is a META-INF.zip with a different update_binary, beside full and OTA one. Maybe its a way to flash zips with that, but ive not tested it. Hope someone will give more news about that.
Code:
(!less_than_int(1426750145, getprop("ro.build.date.utc"))) || abort("Can't install this package (Thu Mar 19 15:29:05 CST 2015) over newer build (" + getprop("ro.build.date") + ").");
getprop("ro.product.device") == "msm8226" || abort("This package is for \"msm8226\" devices; this is a \"" + getprop("ro.product.device") + "\".");
show_progress(0.500000, 0);
format("ext4", "EMMC", "/dev/block/platform/msm_sdcc.1/by-name/system", "0", "/system");
mount("ext4", "EMMC", "/dev/block/platform/msm_sdcc.1/by-name/system", "/system");
package_extract_dir("recovery", "/system");
package_extract_dir("system", "/system");
set_metadata_recursive("/system", "uid", 0, "gid", 0, "dmode", 0755, "fmode", 0644, "capabilities", 0x0, "selabel", "u:object_r:system_file:s0");
set_metadata_recursive("/system/etc", "uid", 0, "gid", 0, "dmode", 0755, "fmode", 0544, "capabilities", 0x0, "selabel", "u:object_r:system_file:s0");
set_metadata("/system/etc/install-recovery.sh", "uid", 0, "gid", 0, "mode", 0544, "capabilities", 0x0);
set_metadata("/system/recovery-from-boot.p", "uid", 0, "gid", 0, "mode", 0644, "capabilities", 0x0);
show_progress(0.200000, 0);
show_progress(0.200000, 10);
package_extract_file("boot.img", "/dev/block/platform/msm_sdcc.1/by-name/boot");
show_progress(0.100000, 0);
unmount("/system");
Download huawei_dload_update
If you're looking to flash dload update.app files with stock recovery, it won't happen. Here's why.
Inside the UPDATE.APP is a small file which indicates the recovery type. It's the PACKAGE_TYPE partition. If you look at the text of the PACKAGE_TYPE partition, it's quite simple. It says ONLINE_UPDATE for anything you download from Huawei's server. This makes it ineligible to flash without an online update token from Huawei, which you get by using eRecovery, HiSuite, or OTA, ergo, something which is connected to Huawei's server.
There are files that get passed to support centers where the PACKAGE_TYPE is actually OFFLINE_UPDATE. These can be installed by placing them into the dload folder on the SD card, but none of them are leaked, and it would be against their agreements to leak them.
Since they are signed, we can't just change an online update to an offline update.
Sorry for the bad news.
Of course, if you have an unlocked bootloader, I'm sure there are things you can do.
That sounds bad, but im a little uncertain, because, the latest B360 build from P9 doesnt get that check with packate_type. It looks like all devices are still in beta stage, also Mate9 too.
Maybe if we try the rollback package that was available for beta firmwares and use dload afterwards to update? Just guessing...
dkionline said:
That sounds bad, but im a little uncertain, because, the latest B360 build from P9 doesnt get that check with packate_type. It looks like all devices are still in beta stage, also Mate9 too.
Click to expand...
Click to collapse
I have first-hand confirmation that there are flashable versions, and that the difference is OFFLINE_UPDATE.
It was possible to completely brick a Mate 8 by flashing the wrong firmware, so security-wise, it's a good thing Huawei does it, I guess. At least I have three ways to exploit it in my pocket (but they all require an internet connection)
I spend way too much time on this stuff
duraaraa said:
I have first-hand confirmation that there are flashable versions, and that the difference is OFFLINE_UPDATE.
It was possible to completely brick a Mate 8 by flashing the wrong firmware, so security-wise, it's a good thing Huawei does it, I guess. At least I have three ways to exploit it in my pocket (but they all require an internet connection)
I spend way too much time on this stuff
Click to expand...
Click to collapse
And we wuv you for it!
lawtq said:
And we wuv you for it!
Click to expand...
Click to collapse
:highfive:
Yes thats good, but if we get that offline thing, would be nice, or dload is useless for 7.0, and can be used only for downgrade and 6.0. Thats the point. I rather think, the protection is for beta, not official.
dkionline said:
Yes thats good, but if we get that offline thing, would be nice, or dload is useless for 7.0, and can be used only for downgrade and 6.0. Thats the point. I rather think, the protection is for beta, not official.
Click to expand...
Click to collapse
No, the protection is definitely for official. Huawei doesn't want people to flash packages downloaded from their website without their permission so they changed the system. I wish it wasn't that way, but it is, and they're not looking to change it -- they put in a lot of work to implement it. I think it's a stupid direction to go in, but that's what they chose.
dload is for Huawei service centers to recover devices, more than anything else, at this point. It's possible they will release something that can be flashed with dload, but it will be specifically for dload, and it will not be something like we normally can download from update.hicloud.com/TDS/whatever
Actually, it's possible they have the offline updates stored somewhere on their server that we haven't found yet, so looking for those would probably be the most likely path to finding a way to do offline updates.
Ok mate, i checked now my 2 versions from hicloud and got this weird thing. The first one has package_type.img but the 2nd not, so, wheres the check now? Lets see if this works.
Just to correct, the huawei nova got 7.0 and dload worked without problems. I dont think, theres a check soon, but its not 100% for sure.
edit: it stops with 30%, so theres a next check in it.
dkionline said:
Ok mate, i checked now my 2 versions from hicloud and got this weird thing. The first one has package_type.img but the 2nd not, so, wheres the check now? Lets see if this works.
Just to correct, the huawei nova got 7.0 and dload worked without problems. I dont think, theres a check soon, but its not 100% for sure.
edit: it stops with 30%, so theres a next check in it.
Click to expand...
Click to collapse
Could you please share this file or link, maybe we can find a solution with it, if it's fails on 30% that a good point and we can make it 100% by giving it more trying.
Blue.Ember said:
Could you please share this file or link, maybe we can find a solution with it, if it's fails on 30% that a good point and we can make it 100% by giving it more trying.
Click to expand...
Click to collapse
We have an offline update for C636 mabe it can help somehow, it's in 3rd post in this thread http://forum.xda-developers.com/mate-9/help/help-wiped-products-vendo-bootloop-t3534594/page6
Confirmed working.
gm007 said:
We have an offline update for C636 mabe it can help somehow, it's in 3rd post in this thread http://forum.xda-developers.com/mate-9/help/help-wiped-products-vendo-bootloop-t3534594/page6
Confirmed working.
Click to expand...
Click to collapse
Many thanks to you, I really appreciate that, I will download it and try to push oeminfo.img into it so maybe it can help for C185.
Blue.Ember said:
Many thanks to you, I really appreciate that, I will download it and try to push oeminfo.img into it so maybe it can help for C185.
Click to expand...
Click to collapse
There is another idea.
Get full rom.
Unpack package_type file from update.app
Change value 'online_update' to 'offline_update'
Then repack back.
And try to flash.
p.s. Unpack via Huawei Update Extractor: https://forum.xda-developers.com/showthread.php?t=2433454
Mate9's Profile: https://forum.xda-developers.com/showpost.php?p=70410219&postcount=454
Must add this row to profile:
Code:
<File type="package_type">package_type.img</File>
5[Strogino said:
;70591233]There is another idea.
Get full rom.
Unpack package_type file from update.app
Change value 'online_update' to 'offline_update'
Then repack back.
And try to flash.
p.s. Unpack via Huawei Update Extractor: https://forum.xda-developers.com/showthread.php?t=2433454
Mate9's Profile: https://forum.xda-developers.com/showpost.php?p=70410219&postcount=454
Must add this row to profile:
Click to expand...
Click to collapse
Why do we need to add this line,this firmware is already flashable for mate 9 c6363.
I think we need to change the file size in the script so it match the new firmware or else will get an error md5 mismatch.
It's one of the steps.
Not really. Some Firmware have no package_type.img and are flashable. Some other Firmwares also have no package_type.img but are not flashable. Thats not the real cause of blocking the Update.
gm007 said:
Why do we need to add this line,this firmware is already flashable for mate 9 c6363.
Click to expand...
Click to collapse
It is for other customizations. C432, for example
---------- Post added at 02:31 PM ---------- Previous post was at 02:27 PM ----------
dkionline said:
Not really. Some Firmware have no package_type.img and are flashable. Some other Firmwares also have no package_type.img but are not flashable. Thats not the real cause of blocking the Update.
Click to expand...
Click to collapse
Full or ota? I meant Full. I checked AL00C00B156, L29C432B126, L29C432B138. They all have package_type file.
And i tried install them via TWRP.
TWRP raised error when checking package_type.
But, It is just idea. Need more time to check this.
5[Strogino] said:
There is another idea.
Get full rom.
Unpack package_type file from update.app
Change value 'online_update' to 'offline_update'
Then repack back.
And try to flash.
p.s. Unpack via Huawei Update Extractor: https://forum.xda-developers.com/showthread.php?t=2433454
Mate9's Profile: https://forum.xda-developers.com/showpost.php?p=70410219&postcount=454
Must add this row to profile:
Code:
<File type="package_type">package_type.img</File>
Click to expand...
Click to collapse
Already did that 2 weeks ago but it's still fail on 5%, maybe the other files can help like vedndor_update..APP and the data files also, any way I will try and feedback with result
---------- Post added at 01:55 PM ---------- Previous post was at 01:50 PM ----------
gm007 said:
Why do we need to add this line,this firmware is already flashable for mate 9 c6363.
I think we need to change the file size in the script so it match the new firmware or else will get an error md5 mismatch.
It's one of the steps.
Click to expand...
Click to collapse
Newer phone from huawei they changed it to SHA256RSA signature, but still I don't think it make the update fail
Do you think if i flash this firmware it will debrand my phone from c185 to c636 or it might fail or brick it?
gm007 said:
Do you think if i flash this firmware it will debrand my phone from c185 to c636 or it might fail or brick it?
Click to expand...
Click to collapse
I think it will not debarnd it or brick it, I think it will fail, but please do not try cause I'm not sure enough
Related
Hi,
This is just to let everyone know that the latest updates being pushed by Asus breaks Voodoo OTA Rootkeeper's su backups.
Basically it removes the setuid bit from the su backup that is kept in /system/su-backup and from all binaries in the /system partition.
So you will lose root and will not be able to restore it with Rootkeeper after this OTA.
Luckily, the "1-Click Transformer Root" tool still works on it:
http://forum.xda-developers.com/showthread.php?p=26918950
So you can gain root once again and keep your stock recovery with OTAs enabled.
Cheers!
idcrisis said:
Basically it removes the setuid bit from the su backup that is kept in /system/su-backup and from all binaries in the /system partition.
Click to expand...
Click to collapse
Do you still have the OTA dlpkgfile? If so, could you please share it somewhere (dropbox/box.com/wuala/etc.)?
sbiriguda said:
Do you still have the OTA dlpkgfile? If so, could you please share it somewhere (dropbox/box.com/wuala/etc.)?
Click to expand...
Click to collapse
Here you go:
http://www.mediafire.com/?d1cq2f911ipd35r
From what I can see the culprit seems to be these lines in the updater-script:
Code:
set_perm_recursive(0, 0, 0755, 0644, "/system");
set_perm_recursive(0, 2000, 0755, 0755, "/system/bin");
Let us know if you find another place to hide the damn thing.
Maybe /system/.subackup or /system/.subackup/.subackup
Worth a try perhaps.
idcrisis said:
Code:
set_perm_recursive(0, 0, 0755, 0644, "/system");
set_perm_recursive(0, 2000, 0755, 0755, "/system/bin");
Let us know if you find another place to hide the damn thing.
Maybe /system/.subackup or /system/.subackup/.subackup
Click to expand...
Click to collapse
Nope, set_perm_recursive traverses the entire hierarchy, so the first line will nuke the setuid/setgid bits on whatever executable it finds under /system.
I'm a bit puzzled - though - since the same line is present in each and every OTA released by Asus and to my knowledge no-one has ever had any problem with OTA Rootkeper.
sbiriguda said:
Nope, set_perm_recursive traverses the entire hierarchy, so the first line will nuke the setuid/setgid bits on whatever executable it finds under /system.
I'm a bit puzzled - though - since the same line is present in each and every OTA released by Asus and to my knowledge no-one has ever had any problem with OTA Rootkeper.
Click to expand...
Click to collapse
I had also kept another copy for safekeeping in case they manually detected for the Rootkeeper copy of su. This was stored as /system/etc/su-backup and had mode 06755 as /system/su-backup.
Both were changed to 00755 by the update presumably from the first line.
I would think the second line would be present in all the past updates, but the first may not have been or for some reason wasn't working properly in the previous updates.
Or something very strange happened on my tablet. Unlikely as I have kept everything very close to stock.
Someone else may be able to confirm by tomorrow perhaps when it's been pushed far and wide.
The tf101 9.2.1.24 update nukes Voodoo backups to
Hello, i was able to restore su backup from voodoo after upgrading from 21 to 24 on my tf101, without any problems
Rooted with wolf's method 3 on .21
Regards
PERI also works on the latest update
Confirmed on other tablets, 9.2.2.6 breaks Rootkeeper by wiping the setuid bit from all binaries in /system recursively.
Onwards to next idea!
So I have the asop 4.2.1 built with make otapackage but every time I try to install it using TWRP I get an error 7
What I did:
- built the ota
- deleted recovery folder
- flashed rom - got an error 7
Any tips on this? Thanks.
up?
try not deleting anything and flash again, there might be something in the install script that relies on it. for anything it tries to do there and wont find it will throw an exception and break the install. after you have your cause you can still worry about the recovery.
vomer said:
So I have the asop 4.2.1 built with make otapackage but every time I try to install it using TWRP I get an error 7
What I did:
- built the ota
- deleted recovery folder
- flashed rom - got an error 7
Any tips on this? Thanks.
Click to expand...
Click to collapse
vomer,
You have to remove these lines from '/META-INF/com/google/android/updater-script' file (in your ota zip).
Code:
package_extract_dir("recovery", "/system");
set_perm(0, 0, 0544, "/system/etc/install-recovery.sh");
i.e, search 'recovery' in 'updater-script' and remove that line.
I have been experiencing alot difficulties while pushing Framework-res.apk and SystemUI.apk in my Stock deodexed rom as well as Custom Roms. It always end up in a bootloop.
Can somebody make updater-script for both files separately and make a flashable zip for them, so that whenever I have to flash these 2 files, I just replace them in those zips and I'm ready to go?
I tried learning editing Updater-script, but I always ended up in some errors.
Please Help.
I would really appreciate it, I know its just a 10 minutes work for some people here. :fingers-crossed:
Please Help me
Code:
run_program("/sbin/busybox", "mount", "/system");
package_extract_dir("app", "/system/app");
run_program("/sbin/busybox", "umount", "/system");
systemui above
framework-res below
Code:
run_program("/sbin/busybox", "mount", "/system");
package_extract_dir("framework", "/system/framework");
run_program("/sbin/busybox", "umount", "/system");
not 10mins,
less than a minute
Hey thank you!
Thank u for these codes,
What about Update-binary in META-INF folder? Is it same for every flashable zip? Can I use these codes on both Stock and custom roms?
varun90rulz said:
Thank u for these codes,
What about Update-binary in META-INF folder? Is it same for every flashable zip? Can I use these codes on both Stock and custom roms?
Click to expand...
Click to collapse
open updater-script with notepad and paste these codes,
the update-binary is universal so yea
deathnotice01 said:
open updater-script with notepad and paste these codes,
the update-binary is universal so yea
Click to expand...
Click to collapse
Thanks! I'll just check this and will ask if anything goes wrong! Thanks a lot. :good:
deathnotice01 said:
open updater-script with notepad and paste these codes,
the update-binary is universal so yea
Click to expand...
Click to collapse
i thought editing it in normal notepad will cause problems
status 0?
status 6?
status 7 or something?
74M3NUMB3RS said:
i thought editing it in normal notepad will cause problems
status 0?
status 6?
status 7 or something?
Click to expand...
Click to collapse
works fine with me
I have heard that too
74M3NUMB3RS said:
i thought editing it in normal notepad will cause problems
status 0?
status 6?
status 7 or something?
Click to expand...
Click to collapse
I read somewhere opening in Notepad causes trouble, I use Notepad++ for this purpose.
I have a one question:
what using this code "/sbin/busybox"
varun90rulz said:
I read somewhere opening in Notepad causes trouble, I use Notepad++ for this purpose.
Click to expand...
Click to collapse
Note pad ++ updated would be more appropriate to use.
varun90rulz said:
I have been experiencing alot difficulties while pushing Framework-res.apk and SystemUI.apk in my Stock deodexed rom as well as Custom Roms. It always end up in a bootloop.
Can somebody make updater-script for both files separately and make a flashable zip for them, so that whenever I have to flash these 2 files, I just replace them in those zips and I'm ready to go?
I tried learning editing Updater-script, but I always ended up in some errors.
Please Help.
I would really appreciate it, I know its just a 10 minutes work for some people here. :fingers-crossed:
Please Help me
Click to expand...
Click to collapse
Follow these steps :
1. If you have a custom rom then get its updater-script,open it with notepad++
2. Find & copy this line mount("ext4", "EMMC", "/dev/block/@@@@@", "/system");
Note: @@@@@ will be something different for your device
3.FINAL STEPS MAKE YOUR UPDATER-SCRIPT:
Write these lines
mount("ext4", "EMMC", "/dev/block/@@@@@", "/system");
delete("/system/app/framework-res.apk");
package_extract_dir("system", "/system");
set_perm_recursive(0, 0, 0755, 0644, "/system/framework");
unmount("/system");
That's it & u r done.
Press the Thanks button if i helped you :good:
& Lemme know for any queries
XT907
rooted
unlocked
TWRP 2.5
Stock ROM 4.1.2 98.15.66
Thinking about taking the 98.18.78 OTA and keeping stock. Had a couple of ideas to keep root and keep TWRP.
Looking in META-INF/com/google/android/updater-script from /cache/Blur_Version.98.15.66.XT907.Verizon.en.US.zip, the problem lines are:
Code:
# This breaks root
2863: set_perm_recursive(0, 2000, 0755, 0755, "/system/xbin");
Code:
# This breaks TWRP on reboot
2828: assert(package_extract_dir("recovery", "/system"));
So, looks like the options are
1. Edit the OTA .zip by
a. Adding to updater-script
Code:
set_perm(0, 0, 6755, "/system/xbin/su");
b. Include a script to move recovery-from-boot.p to recovery-from-boot.bak (overwriting previous) and calling from updater-script.
c. Re-sign the zip and flash in TWRP.
-or-
2. Flash the OTA in TWRP, then manually edit /system/xbin/su permissions to 6755 and rename /system/recovery-from-boot.p to /system/recovery-from-boot.bak before rebooting.
Questions are: Anyone tried either? After flashing a .zip in TWRP, can you return to the command line to do stuff before rebooting?
Thank you!
That is interesting.
Is there any way to stop the checks for stock apps and install over them?
donslade said:
That is interesting.
Is there any way to stop the checks for stock apps and install over them?
Click to expand...
Click to collapse
Not exactly. Most of the updates in the OTA are in the form of binary patches. These patches contain instructions to modify existing binaries, and only represent the changes to the files. That is why the OTA is only 50 MB, whereas a full copy of all the affected binaries would be much larger, as high as 600 MB.
For the patch to work, it has to affect the exact same binary that Moto/VZW used to generate the patch. This is why the OTA verifies the checksums of the files to be patched before performing the update.
I suppose you could remove some of the check (apply_patch_check) and apply (apply_patch) commands from the updater-script to ignore updates to bloatware.
Hello, i wanted to know if anyone can help me. I am trying to include a pre rooted magisk but it gives me an error like this:
Failed to unmount /system: No such volume script aborted (no error message)
Updater process ended with ERROR: 7
Error installing zip file '/external_sd/Bootleggers Edited.zip'
my code (which i found online) to include magisk is this:
ui_print(" Installing Magisk Root...");
package_extract_dir("magisk", "/tmp/magisk");
run_program("/sbin/busybox", "unzip", "/tmp/magisk/Magisk-v18.1.zip", "META-INF/com/google/android/*", "-d", "/tmp/magisk");
run_program("sbin/busybox", "sh", "tmp/magisk/META-INF/com/google/android/update-binary", "dummy", "1", "/tmp/magisk/Magisk-v18.zip");
unmount("/system");
I personally think it's because of the busybox, i want to fix this. Just to confirm, I am editing the Bootlegger NOT to post online, it is just for me because i have to much spare time haha
Thanks in advance
RyzoModding said:
Hello, i wanted to know if anyone can help me. I am trying to include a pre rooted magisk but it gives me an error like this:
Failed to unmount /system: No such volume script aborted (no error message)
Updater process ended with ERROR: 7
Error installing zip file '/external_sd/Bootleggers Edited.zip'
my code (which i found online) to include magisk is this:
ui_print(" Installing Magisk Root...");
package_extract_dir("magisk", "/tmp/magisk");
run_program("/sbin/busybox", "unzip", "/tmp/magisk/Magisk-v18.1.zip", "META-INF/com/google/android/*", "-d", "/tmp/magisk");
run_program("sbin/busybox", "sh", "tmp/magisk/META-INF/com/google/android/update-binary", "dummy", "1", "/tmp/magisk/Magisk-v18.zip");
unmount("/system");
I personally think it's because of the busybox, i want to fix this. Just to confirm, I am editing the Bootlegger NOT to post online, it is just for me because i have to much spare time haha
Thanks in advance
Click to expand...
Click to collapse
I fixed the error by now but it doesn't root. So it completed flashing and after launching and installing magisk manager, it said it isn't rooted
RyzoModding said:
I fixed the error by now but it doesn't root. So it completed flashing and after launching and installing magisk manager, it said it isn't rooted
Click to expand...
Click to collapse
Why are you doing this exactly?
Is it not just easier to flash a Magisk zip than going through all this trouble?
Or is this something you are merely interested in trying out because you are interested?
garylawwd said:
Why are you doing this exactly?
Is it not just easier to flash a Magisk zip than going through all this trouble?
Or is this something you are merely interested in trying out because you are interested?
Click to expand...
Click to collapse
Yeah it is indeed because i'm intrested haha i make apps die pc with c# and stuff and wanted tot try this as Well, i always rooted the wat you said forum 3 years, nut i just wanted tot start editing Roms with pre root and edited apps and stuff haha
No idea... Go ahead ?