Exploitee.rs

helousn wrote:

cj_000 wrote:

helousn wrote:Any chance of a walkthru for us noobs to root the pulse? I've used three different adb's and can adb connect thru the lan to the ip address of the pulse but the next step of adb root gives a device not found error. Even thought the adb connect show connection on port 5555, the adb devices command show nothing.

Thanks!

On the pulse, go to All Applications, Settings, then Applications. Hit development. Check off "Enable Remote Debugging", a message will pop up saying "your files can be modified", press ok.
Then, go to the option below that, says "Remote Debugger IP", go back, and enter your PC's local IP address, then try to re-connect with adb!

Thanks! Definitely closer.. but still not there yet..
N:\adt-bundle-windows-x86_64\adt-bundle-windows-x86_64\sdk\platform-tools>adb connect 192.168.2.11
connected to 192.168.2.11:5555

N:\adt-bundle-windows-x86_64\adt-bundle-windows-x86_64\sdk\platform-tools>adb root
restarting adbd as root

N:\adt-bundle-windows-x86_64\adt-bundle-windows-x86_64\sdk\platform-tools>adb connect 192.168.2.11
connected to 192.168.2.11:5555

N:\adt-bundle-windows-x86_64\adt-bundle-windows-x86_64\sdk\platform-tools>adb push pulse_root.sh /tmp/pulse_root.sh
382 KB/s (1177929 bytes in 3.010s)


So I'm sure I'm missing something but for the life of me I don't know what it is... I redownloaded the pulse_root.sh file but no difference..
Any hints would be great!

Appletini wrote:I just got my system today. Had some issues with it. Had to restart due to the remote not pairing right, but that was only after replacing the 3 AAA’s that were DOA. Still it has a fairly snappy response.

As far as root goes I managed to get that just fine with some tinkering… but like helousn, I had issues using the root script. I just ended up unzipping the script that has the su binary and SuperUser.apk (or you can be less lazy and grab them from http://androidsu.com/superuser/) and then i just ended up doing most of what the script did by hand. I will try looking at why the script failed later but that will mean resetting my device and … I am lazy sorry -_-zZz

cj_000 wrote:

Appletini wrote:I just got my system today. Had some issues with it. Had to restart due to the remote not pairing right, but that was only after replacing the 3 AAA’s that were DOA. Still it has a fairly snappy response.

As far as root goes I managed to get that just fine with some tinkering… but like helousn, I had issues using the root script. I just ended up unzipping the script that has the su binary and SuperUser.apk (or you can be less lazy and grab them from http://androidsu.com/superuser/) and then i just ended up doing most of what the script did by hand. I will try looking at why the script failed later but that will mean resetting my device and … I am lazy sorry -_-zZz

Yep, we just noticed a bug - quick workaround, when you go to adb shell, do this:

adb shell
cd /tmp
sh pulse_root.sh

As you probably saw, our script is looking for our sh in /tmp, and when it can't find it, it gets angry.

cj_000 wrote:After you do cd /tmp, can you do a: ls -l (thats LS -L , but lowercase) and paste the results?

Thanks!

killer4110 wrote:

cj_000 wrote:After you do cd /tmp, can you do a: ls -l (thats LS -L , but lowercase) and paste the results?

Thanks!

This is what i get when i do: ls


C:\Users\killer>adb shell ls
AACS
TestContent
bin
cache
d
data
default.prop
dev
etc
factory_setting
init
init.goldfish.rc
init.gx1200v.rc
init.rc
initlogo.rle
lib
mnt
proc
sbin
sdcard
sys
system
tmp
ueventd.goldfish.rc
ueventd.gx1200v.rc
ueventd.rc
usr
var
vendor



EDIT

Thanks to Zenofex for all of his help, things were messed up on my end and he walked me through everything,

killer4110 wrote:Is there any way to remove the pre-installed apps. Is this something that might be done in a future build?