• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Root [Merit] [ROOT] update.zip [ROOT]

ModdingMyMind said:
Use proper keys to sign it, or disable signature verification from within the custom recovery. Problem solved.
Click to expand...

If a user had a custom recovery, they could find other ways to root :P, or they are rooted already (I.E. not a Samsung/Fastboot user)

And devices like Samsungs won't take keys other than manufacturer keys. I know from experience as I tried the AOSP signkeys to no avail.
 
Motorhead1991 said:
If a user had a custom recovery, they could find other ways to root :P, or they are rooted already (I.E. not a Samsung/Fastboot user)

And devices like Samsungs won't take keys other than manufacturer keys. I know from experience as I tried the AOSP signkeys to no avail.
Click to expand...

You don't need to be rooted to grab a custom recovery for use. Anyone who says otherwise, either do not know what they are doing on their device.... Or the specific provider has taken exceptional steps to prevent such access. Which ultimately isn't seen too often, but, I guess can happen temporarily.
 
Sign keys are mainly for stock. It isn't required to sign anything when using a custom recovery but it makes for good practice none the less lol
 
Also, in addition, and this may be different here, but I personally rarely use fastboot, let alone a pc. For example, I write the custom recovery straight to my recovery partition using either cat or dd commands. Either work. Another example, my recovery partition given my device would be /dev/block/mmcblk0p21.

So, using a terminal emulator on my phone I could simply do the following:
Code: 
dd if=/sdcard/customrecovery.img of=/dev/block/mmcblk0p21

Or

Code: 
cat /sdcard/customrecovery.img > /dev/block/mmcblk0p21

I do this with most of my partitions to include the bootloader (if necessary).

Though, steps are needed prior to this of course before being capable to use such methods, but each device is slightly different before proceeding forward with either one. Its the little things that help lol.
 
Motorhead1991 said:
We can start another thread about this sonwe can stop crapping up Stayboogy's thread.
Click to expand...

Calm down kid. I only shared an opinion based on facts because you wanted to challenge my intelligence on here. Take it or leave it bro. Lol.
 
PMGRANDS said:
Does this work on Any device?
Click to expand...

Depends on the date of the su binary, and your devices system partition. The updater-script found in this update.zip from the OP is initially written to write to the system partition given this variant kept in mind, so you would need to adjust the updater-script to your specific system partition to insure it places the su binary properly on your device. In addition, as stated above, the su binary needs to be considered. If it doesn't work, then you would need to replace the su binary in the update.zip with a more up to date version (if needed). Take note that the su binary is specific to the root application. For example, you couldn't use the su binary from supersu with superuser or vice versa. Another thing, and this does vary with devices; the updater-script just places the su binary in its given directory if you go and look at it, but in some cases that isn't enough to root. Sometimes you have to symlink the su binary from /system/bin/ to system/xbin/, which that too would need to be included in the updater-script if required.

This is what I am trying to explain:

Here is the updater-script provided by the OP which can be found in the update.zip
Code: 
 mount("yaffs2", "MTD", "system", "/system");
delete("/system/bin/su","/system/xbin/su");
package_extract_dir("system", "/system");
set_perm(0, 0, 06755, "/system/xbin/su");
unmount("/system");

Now, look at mount(). That is your focus. My device has a different partition format as well as its location. My /system is an ext4 format and my device is EMMC vice MTD. So I would write it out as such:
Code: 
[B]mount("ext4", "EMMC", "/dev/block/mmcblk0p35", "/system");[/B]
delete("/system/bin/su","/system/xbin/su");
package_extract_dir("system", "/system");
set_perm(0, 0, 06755, "/system/xbin/su");
unmount("/system");

Note: /dev/block/mmcblk0p35 is the location of my system partition on my device (this will greatly vary upon devices).

Also, I mentioned that some devices require the su binary to be symlinked for a proper root. My device happens to require this, so I would need to add it to the script. As follows:
Code: 
[B]mount("ext4", "EMMC", "/dev/block/mmcblk0p35", "/system");[/B]
delete("/system/bin/su","/system/xbin/su");
package_extract_dir("system", "/system");
set_perm(0, 0, 06755, "/system/xbin/su");
[B]symlink("/system/xbin/su", "/system/bin/su");[/B]
unmount("/system");

Depending on the symlink command depends on where the su is originally placed. If initially being placed in /system/bin/ then the symlink will be from ./bin to ./xbin. If originally being placed in system/xbin/, then it would be vice versa. Hope this helps. :-)
 
ModdingMyMind said:
All you have to do is write out the updater-script to be universal when flashing across other devices ;-). Less attitude, more logic bro.
Click to expand...

you don't know jack,

and shouldn't post your uneducated nonsense here...

rewriting updater-script WON'T make this work on other devices--know why? sure you don't, but i do...

update-binary is api specific, must be changed according to device and build, as well as pass verification when the updater-script does

and signatures do matter, and are now often manufacturer specific and not the usual generic google release keys.

you have shown yourself to be as completely full of false information as i've seen 75 to 80% of the rest of the android community to be.

no need for you to argue with motorhead or me, cause you're highly disadvantaged in knowledge of the subject...
 
ModdingMyMind said:
Code: 
ui_print("****************************************");
ui_print("* Created by Modding.MyMind *");
ui_print("****************************************");
ui_print("*   Rooting your Device   *");
ui_print("****************************************");
ui_print("");

show_progress(1.000000, 0);
ui_print("Mounting filesystems...");
run_program("/sbin/busybox", "mount", "/system");
run_program("/sbin/busybox", "mount", "/data");
set_progress(0.100000);

# Delete old files that may interfere.
ui_print("Preparing install...");
delete("/data/dalvik-cache/system@app@Superuser.apk@classes.dex","/system/bin/su","/system/xbin/su","/system/app/Superuser.apk","/system/app/Superuser.odex","/data/app/Superuser.apk","/system/xbin/daemonsu","/system/bin/.ext/.su","/system/etc/install-recovery.sh","/system/etc/init.d/99SuperSUDaemon","/system/etc/.has_su_daemon","/system/etc/.installed_su_daemon","/system/app/SuperUser.apk","/system/app/SuperUser.odex","/system/app/superuser.apk","/system/app/superuser.odex","/system/app/Supersu.apk","/system/app/Supersu.odex","/system/app/SuperSU.apk","/system/app/SuperSU.odex","/system/app/supersu.apk","/system/app/supersu.odex");
set_progress(0.200000);

ui_print("Extracting files...");
package_extract_dir("system", "/system");
package_extract_dir("data", "/data");
set_progress(0.300000);

ui_print("Setting SU permissions...");
set_perm(0, 0, 06755, "/system/bin/su");
set_perm(0, 0, 06755, "/system/bin/.ext/.su");
set_perm(0, 0, 06755, "/system/xbin/otasurvival.sh");
set_progress(0.400000);

ui_print("Symlinking SU Binary for Root...");
symlink("/system/bin/su", "/system/xbin/su");
set_progress(0.500000);

ui_print("Setting SuperSU permissions...");
set_perm(0, 0, 0644, "/system/app/Superuser.apk");
set_perm(1000, 1000, 0755, "/data/data/eu.chainfire.supersu");
set_perm_recursive(1000, 1000, 0755, 0755, "/data/data/eu.chainfire.supersu/lib");
set_perm_recursive(1000, 1000, 0771, 0600, "/data/data/eu.chainfire.supersu/cache");
set_perm_recursive(1000, 1000, 0771, 0771, "/data/data/eu.chainfire.supersu/cache/com.android.renderscript.cache");
set_perm_recursive(1000, 1000, 0771, 0771, "/data/data/eu.chainfire.supersu/requests");
set_perm_recursive(1000, 1000, 0771, 0771, "/data/data/eu.chainfire.supersu/logs");
set_perm_recursive(1000, 1000, 0771, 0771, "/data/data/eu.chainfire.supersu/files");
set_perm_recursive(1000, 1000, 0771, 0660, "/data/data/eu.chainfire.supersu/shared_prefs");
set_progress(0.600000);
set_progress(0.800000);

# Unmounting filesystems...
ui_print("Unmounting filesystems...");
run_program("/sbin/busybox", "umount", "/system");
run_program("/sbin/busybox", "umount", "/data");
set_progress(0.900000);
ui_print("");

set_progress(1.000000);
ui_print("****************************************");
ui_print("*          Install Complete!           *");
ui_print("****************************************");
There is nothing new about your rooting method. Its been around for ages, and is a very logical concept across practically any device. Take a look at my script above and visualize its setup via folders, subfolders, and files. ;-). I wouldn't really say you are the original.... At best, a good contributor to your community.
Click to expand...

again with your idiocy

busybox mount command doesn't work, and anyone who ever reads a recovery log when the command is used will see it fails.

and yes, this root method is original to me, it didn't come from anyone else i assure you.

my mount command is what makes it work for this device, because busybox mount did not and would not produce root on stock recovery 100% of the time. plain and simple. know why? of course you don't, but i do.

learn the edify commands that actually do work in recovery to mount, which you'll only learn from reading source code--and guess what? busybox isn't one of them. the fact that you post something using busybox, which is virtually useless 90% of the time anyway on most every device, shows me even more you're just a regurgitator of useless, incorrect, and misguided info... the reason busybox might appear to work in recovery, even when it doesn't, is because generally /system is mounted by default in most custom recoveries, and therefore doesn't have to be mounted again. and if system was unmounted, unless busybox has been installed into the ramdisk of said recovery--which i've never seen ever, or unless busybox is cp'd to the temp directory by the said package and chown'd and chmod'd, it won't work. busybox. what freakin joke.

don't come here with your nonsense fanboy and try to stir folks up.

you posted garbage in a good thread, someone reminded you of this, and you got butt hurt. best to just quit while you're behind.
 
stayboogy said:
again with your idiocy

busybox mount command doesn't work, and anyone who ever reads a recovery log when the command is used will see it fails.

and yes, this root method is original to me, it didn't come from anyone else i assure you.

my mount command is what makes it work for this device, because busybox mount did not and would not produce root on stock recovery 100% of the time. plain and simple. know why? of course you don't, but i do.

learn the edify commands that actually do work in recovery to mount, which you'll only learn from reading source code--and guess what? busybox isn't one of them. the fact that you post something using busybox, which is virtually useless 90% of the time anyway on most every device, shows me even more you're just a regurgitator of useless, incorrect, and misguided info... the reason busybox might appear to work in recovery, even when it doesn't, is because generally /system is mounted by default in most custom recoveries, and therefore doesn't have to be mounted again. and if system was unmounted, unless busybox has been installed into the ramdisk of said recovery--which i've never seen ever, or unless busybox is cp'd to the temp directory by the said package and chown'd and chmod'd, it won't work. busybox. what freakin joke.

don't come here with your nonsense fanboy and try to stir folks up.

you posted garbage in a good thread, someone reminded you of this, and you got butt hurt. best to just quit while you're behind.
Click to expand...

Assuming the custom recovery that which was built properly for whichever given device it may be, then I can assure you jack, that busybox does in fact come already inside the custom recovery - if personally built (unofficially) then they should go back and fix that from source. If you would like some screenshots let me know. I have no problem unpacking the custom recovery I use, as well, as so many others use, and proving you wrong in that matter. Not to mention, is you diss busybox, and maybe for good reason, but it is busybox which gives most devs the functions and abilities needed to conduct their work on their devices without the need of a pc if when on the go. For example, the ability to unpack, edit, and repack the boot.img/recovery.img on your phone without ever touching a computer - busybox plays an important role with that. But what am I talking about.... So yea, when using busybox commands as demonstrated in the provided script I shared, yes, it does work or else I wouldn't waste my time with it.
 
stayboogy said:
you don't know jack,

and shouldn't post your uneducated nonsense here...

rewriting updater-script WON'T make this work on other devices--know why? sure you don't, but i do...

update-binary is api specific, must be changed according to device and build, as well as pass verification when the updater-script does

and signatures do matter, and are now often manufacturer specific and not the usual generic google release keys.

you have shown yourself to be as completely full of false information as i've seen 75 to 80% of the rest of the android community to be.

no need for you to argue with motorhead or me, cause you're highly disadvantaged in knowledge of the subject...
Click to expand...

I am aware of the update-binary. Something else you left out, is that when using an updater-script and in place you have format(), some update binaries will only except three arguments where as others will except four. So again, don't think I'm a fool in the matter. And again, signatures, do not matter when using a custom recovery. Let me break it down for you. My device requires that the bootloader be unlocked before I can really do much of anything out of the ordinary. Next would be to apply a custom recovery. Third step would be to root the device. Fourth step, would be to make a deodex Rom so I personally may start on theming. I have the Rom made up. I can choose to sign the Rom, or I can choose to not sign it. Since, inside of my custom recovery, signature verification is disabled, it ultimately wouldn't matter just as long as their were no issues with the script and/or binary. I know, because I do it all the time bro! As for learning edify scripting.... I will go ahead and assume you and I know just about the same when it comes to it so I won't even bother wasting my time arguing over that nonsense.

So, anything else we need to get out, so we can clear the air and be done with this pissing contest?
 
Oh, and generally, system is unmounted in the custom recovery ;-)
 
stayboogy said:
the reason busybox might appear to work in recovery, even when it doesn't, is because generally /system is mounted by default in most custom recoveries, and therefore doesn't have to be mounted again. and if system was unmounted, unless busybox has been installed into the ramdisk of said recovery--which i've never seen ever, or unless busybox is cp'd to the temp directory by the said package and chown'd and chmod'd, it won't work. busybox. what freakin joke.
Click to expand...

Here I have unpacked a TWRP custom recovery and provided some pictures to prove that not ONLY is busybox implemented into the source but superuser also! So do yourself the favor and research before you try calling me out like I don't know what I am talking about and placing yourself on a high pedestal like you think you got it all figured out bro.

In the picture, you will see the recovery.img which has been unpacked on my device. Next is the ramdisk folder with which I have unpacked the ramdisk too. Following after is showing the contents inside of the ./ramdisk directory. With that you will see a supersu folder followed by another picture displaying its contents. Afterwards is another where which I display the contents inside the ./ramdisk/sbin directory that just so happens to hold the busybox which you just so happen to call me out on with your previously failing insults.

And to make this part even better, I did all of this on my phone without using a computer but only a simple unmkbootimg binary that I compiled for ARM devices after taking the original mkbootimg source, and reversed its functionality by modifying the source itself. As well as using some additional applets, I.E., cpio - which comes along with busybox - WHICH IS OPEN SOURCE as well buddy! You say I don't know what I am doing or what I am talking about - I beg a differ bro!

ajejesa7.jpg
dy8y2yty.jpg
5yhazejy.jpg
e9e5ubur.jpg
 
Now you have personally seen it for yourself bro ;-)

And before you go telling me that yalls custom recovery doesn't have those features then let me be first to state that its OPEN SOURCE bro. So, assuming it isn't implemented into yalls, then go build it.
 
If you are having problems with busybox working, then it appears you lack knowledge and understanding of what it is actually capable of, and the mere fact that you fail to realize that any edify script calling on busybox found in a flashable zip would OBVIOUSLY cause confliction if such recovery wasn't built with busybox in mind. So, for you and your petty device, it may very well not work properly, but for most, it would, because the majority has it built in the open source. So now, to me, it isn't the mere fact of you calling me out and saying I don't know what I am talking about, but the troubling issue of you being behind the times bro. Catch up.

With that said, I'm not wasting another moment arguing over this. So get your last words in, and claim your so called glory. I got some porting projects to get back to and this is taking up too much of my time.
 
stayboogy said:
the reason busybox might appear to work in recovery, even when it doesn't, is because generally /system is mounted by default in most custom recoveries, and therefore doesn't have to be mounted again. and if system was unmounted, unless busybox has been installed into the ramdisk of said recovery--which i've never seen ever, or unless busybox is cp'd to the temp directory by the said package and chown'd and chmod'd, it won't work. busybox. what freakin joke.
Click to expand...

Hahahahahahaha!!!!!!!

You really are ignorant and oblivious!!!!!

You should go take a look at the TWRP your boy, Motorhead1991, built....

First, let me say, good job and good work on that build Motorhead1991. Now, back to you, stayboogy. Your boy, properly built twrp, and in addition, I decided to take a closer look at it and I happen to notice that his provides supersu and busybox within the ramdisk of the recovery.img as well. Yet, you have 'never' seen this before, and yet, 'using busybox in edify scripting will not work', seems accurate to you? My friend, you are so far lost right now that you are even unaware of what is provided by those you are so familiar with here on this forum. Pathetic bro. And to think, I wasted all this time trying to prove a point and defend myself, haha. You lost this arguement before you even had the chance to spit your words back at me.

I'm out, later.
 
TWRP and CWM function differently. CWM packs a bunch of functional binaries in, TWRP opereates around busybox.

I will have to agree though, I've used busybox mount on a number of things, but it only reliably works on CWM/TWRP and not stock recovery.
 
Motorhead1991 said:
TWRP and CWM function differently. CWM packs a bunch of functional binaries in, TWRP opereates around busybox.

I will have to agree though, I've used busybox mount on a number of things, but it only reliably works on CWM/TWRP and not stock recovery.
Click to expand...

Agree, and being how CWM works with such binaries that way, is what makes TWRP stand out so well because it is statically linked, which I can properly assume you know this :-).
 
@stayboogy,

You see bro, it does in fact work when using proper edify scripting which is evolved around busybox. But just like Motorhead1991 said, and I agree, such scripting will not work %100 with a stock recovery. My entire previous arguement when speaking about such scripts was based around a properly built custom recovery. At no point did I reference the use of a 'stock' recovery.img. So I can only think that after all of which has been said is either you misunderstood me as to which kind of recovery I was initially refering to, or, you really just didn't know.

Either way, the bickering is officially over on my end.

So as alwAys:

-- Happy Hunting!
 
You must log in or register to reply here.
Back
Top Bottom