985 replies to this topic

[smalldroid34]

I am using 32b liveCD, have fxe back to for a fresh start, twice, no love. only time i could actually connect with the remote storage was first time i ran this, now it just tells me it couldnt connect to host, and i need to repair network, Suck verizon.........just curious why GB and ICS both got 1-click roots on windows, and JB cant?

[SamuriHL]

FU Verizon, Ive got so many paid apps that are useless without root, I truly hate you right now. Could someone who managed sucsses post their terminal window so i can compare it to mine. I can run whole process fine except I dont actually get root. when its pushing exploit i get   "/system/bin/sh: /storage/rfs0/pwn: not found" also phone never vibrates, if i press return, it cleans up, hit return again reboots phone. On reboot SU wants to update and fails, exactly like duhast89 posted at the top of this page, post # 541. Banging my head so much my keyboard is getting bloody.
 

 

That means that the Bionic is not connected to the samba share.  You need to make sure it's connected through the Files app BEFORE you run the run.sh script.

[SamuriHL]

I am using 32b liveCD, have fxe back to for a fresh start, twice, no love. only time i could actually connect with the remote storage was first time i ran this, now it just tells me it couldnt connect to host, and i need to repair network, Suck verizon.........just curious why GB and ICS both got 1-click roots on windows, and JB cant?

 

Because they keep patching the security holes used by root exploits every time one is found. As I said, you need to figure out why it's not connecting to the samba share.  Go through all the steps and verify at each one that it worked.  Don't just blindly run through them.

[maros]

FU Verizon, Ive got so many paid apps that are useless without root, I truly hate you right now. Could someone who managed sucsses post their terminal window so i can compare it to mine. I can run whole process fine except I dont actually get root. when its pushing exploit i get   "/system/bin/sh: /storage/rfs0/pwn: not found" also phone never vibrates, if i press return, it cleans up, hit return again reboots phone. On reboot SU wants to update and fails, exactly like duhast89 posted at the top of this page, post # 541. Banging my head so much my keyboard is getting bloody.
 

 

Do you have the samba storage mounted on phone? Also check the storage path. Could be rfs1 e.g.

 

Please Login or Register to see this Hidden Content

 

Please Login or Register to see this Hidden Content

  81.13KB   24 downloads

[matjmonk]

Question oh Guru's, I'm experimenting with running through the exploit so I understand everything before I make the jump to JB and I'm now at the part of using the files app to connect to remote storage but I don't see any options to allow me to do this within the app or system settings, is this a JB "feature"?

[SamuriHL]

Question oh Guru's, I'm experimenting with running through the exploit so I understand everything before I make the jump to JB and I'm now at the part of using the files app to connect to remote storage but I don't see any options to allow me to do this within the app or system settings, is this a JB "feature"?

 

yes.

[matjmonk]

yes.

 

Thank you kind sir!

[BoognishMike]

Hey all,

 

First off, big ups to this exploit.

 

 I'm having an issue with superuser.  I get a pop up wanting to update the Superuser binaries:

 

 

Hit "install" (recovery install gives the same result) and I get this:

 

"There was an error install Superuser. Please send a log of the error to the developer"

 

 

Any thoughts?   I've looked in Google Play and the issues is addressed by recovering from a .zip file.  I have no idea how to go about that / what it will do.  Any help is greatly appreciated.  I'm not a Linux expert, but I've been using some distro or another for a long time and i'm not afraid of command line stuff.  Android rooting and whatnot are out of my wheelhouse but i'm trying to learn as quickly as possible.  

 

The main thing I want to accomplish is to take advantage of the entitlement exploit to get my unlimited data tethering back!

 

Thanks all,

Mike

[livinginkaos]

Did you wait for the phone to quit vibrating before continuing on?  If not, try running the exploit again and wait for the vibration to stop.

[matjmonk]

Hey all,

 

First off, big ups to this exploit.

 

 I'm having an issue with superuser.  I get a pop up wanting to update the Superuser binaries:

 

 

Hit "install" (recovery install gives the same result) and I get this:

 

"There was an error install Superuser. Please send a log of the error to the developer"

 

 

Any thoughts?   I've looked in Google Play and the issues is addressed by recovering from a .zip file.  I have no idea how to go about that / what it will do.  Any help is greatly appreciated.  I'm not a Linux expert, but I've been using some distro or another for a long time and i'm not afraid of command line stuff.  Android rooting and whatnot are out of my wheelhouse but i'm trying to learn as quickly as possible.  

 

The main thing I want to accomplish is to take advantage of the entitlement exploit to get my unlimited data tethering back!

 

Thanks all,

Mike

 

 

Did you wait for the phone to quit vibrating before continuing on?  If not, try running the exploit again and wait for the vibration to stop.

 

I thought I saw somewhere in this thread that it was recommended that you uninstalled Superuser before running the exploit or am I just confused??

[SamuriHL]

If there are any old remnants of root on the system partition, it's likely this exploit will fail.  Reflash the system img and try again.

[Int_Rnd_Pooka]

If there are any old remnants of root on the system partition, it's likely this exploit will fail.  Reflash the system img and try again.

I'm getting the feeling that step ONE should be to re flash system.img only. I see a lot of problems that are being solved with just that and another attempt.

[SamuriHL]

Yea, I know.  What's happening is most of the people using this are coming from a failed attempt at using OTA Rootkeeper to restore root.  So there's old su binaries and other crap in system still with the wrong perms and all that.  That's interfering somehow with the root process.  Flashing system.img clears out the cobwebs and gives you a clean start.  Honestly I'd recommend a trip through the House of Bionic with the 98.72.22 FXZ using the Keep Data option.  Once you do that it should go smooth.

[matjmonk]

ok, VMware gurus (you know who you are!) is there a way to have the player persist the "tmp/share" folder? I've been making several dry runs through the root exploit directions and every time I bring up the Linux VM, that folder is gone. I'm sort of guessing that is how it is supposed to work but wanted to make sure. It's no big deal, I've downloaded the motoshare2 file and saved it in the downloads on the VM so it's just a matter of copying it to the folder and unzipping it each time but I thought I would check.

 

thanks

[SamuriHL]

Has nothing at all to do with VMWare.  That's a linux thing.  You're asking if you can persist a *TEMP* directory.  LMAO.  Um, no.    That's why I created mine as /share.  

[matjmonk]

Has nothing at all to do with VMWare.  That's a linux thing.  You're asking if you can persist a *TEMP* directory.  LMAO.  Um, no.    That's why I created mine as /share.  

 

BUT it does persist several other folders in that directory!! That's pretty much what I thought and I had thought of doing the same thing and just modifying Dan's directions to fit my world. I've been able to test everything except the Bionic file part since I would actually have to install JB to do that. Not sure why I'm so hesitant to do that now.

[livinginkaos]

actually, if you suspend your session and don't power down ubuntu, it will still be there - but

 

To expand on Sam's, your directory can be anywhere that you want within your file system.  You just need to remember to adjust the path in the code to read where you have it.

 

[share]
path = /tmp/share
available = yes
valid users = guest
read only = yes
browsable = yes
public = yes

[SamuriHL]

BUT it does persist several other folders in that directory!! That's pretty much what I thought and I had thought of doing the same thing and just modifying Dan's directions to fit my world. I've been able to test everything except the Bionic file part since I would actually have to install JB to do that. Not sure why I'm so hesitant to do that now.

 

Are they truly persisted....or recreated on startup?  

[marty45714]

What SamuriHL said is PARTIALLY true. It depends on the *NIX distro you're using. I used CentOS, a Red Hat based distro. The /tmp filesystem is permanent in Red Hat. It just gets cleaned up automatically by a utility called "tmpwatch". Some other distros, and I'm assuming Ubuntu must be one of these, build the /tmp filesystem in RAM so that it is wiped every time the box is rebooted. Solaris UNIX is this way. So the best thing to do is indeed what SamuriHL stated. Build the Samba share in another folder. It doesn't matter where, as long as Samba has permissions to read it, and you make sure you change your Samba config to match whatever path you are using.

 

ok, VMware gurus (you know who you are!) is there a way to have the player persist the "tmp/share" folder? I've been making several dry runs through the root exploit directions and every time I bring up the Linux VM, that folder is gone. I'm sort of guessing that is how it is supposed to work but wanted to make sure. It's no big deal, I've downloaded the motoshare2 file and saved it in the downloads on the VM so it's just a matter of copying it to the folder and unzipping it each time but I thought I would check.

 

thanks

[SamuriHL]

What SamuriHL said is PARTIALLY true. It depends on the *NIX distro you're using. I used CentOS, a Red Hat based distro. The /tmp filesystem is permanent in Red Hat. It just gets cleaned up automatically by a utility called "tmpwatch". Some other distros, and I'm assuming Ubuntu must be one of these, build the /tmp filesystem in RAM so that it is wiped every time the box is rebooted. Solaris UNIX is this way. So the best thing to do is indeed what SamuriHL stated. Build the Samba share in another folder. It doesn't matter where, as long as Samba has permissions to read it, and you make sure you change your Samba config to match whatever path you are using.

 

I can't help it if Red Hat sucks.  LMAO!    (Seriously, I *HATE* Red Hat).  But yes, you are correct about that.  I was basing it on the fact that he's using an Ubuntu VM.