I need to know more about ADB I guess, like how to get it to stay open when I double click the app if thats even how I open it. Instead the window keeps closing as soon as it opens.
My friend (the one who owns this forum account) just downgraded my G1 from RC33 to 29 and now its asking me to sign in but I can't. Apparently my girlfriend can't either on her phone and we didn't do anything with hers but I just signed her in through wifi since it wasn't on the setup screen like mine was. I on the otherhand am stuck at the beginning and need a way to get around it, I don't know why we lost the data plan we had all of a sudden but I'm not going to bother with that and instead will keep moving forward with an alternative.
I'm completely noob to all things command promp so I don't know what an SDK is, just found out what the ADB is and dled that and the drivers but can't start anything up as of yet. I know my android is at RC29 because of the reboot test on the how to bypass the registration thread.
EDIT: Lmfao I guess I picked a bad time to modify my G1, at the time of this post there is a global outage of T-mobile's internet, everything west of the mississippi river is out so thats why I couldn't sign in before, if this thread gets locked or ignored then its ok, I can just wait it out, but just goes to show murphy's law is the real deal, the day I decide to finally start editing stuff this happens.
I'm not really an expert and I had to learn as I went, but here's how I went through the same problem.
Basically, you don't run ADB as a normal program, you open a command prompt (for vista and xp go to run and type cmd) and then you have to navigate to the folder that ADB is in, so if you have the SDK on your desktop youd type something like
"cd c:\users\yourusername\desktop\SDK\tools" (for vista)
yours will probably differ, but use "cd" to navigate to the folder ADB is in. Then assuming you have your phone and the drivers setup properly, when you're navigated to that folder you can type commands that start with adb or whatever and they should work.
If that doesn't work then your phone may not be setup properly, in which case you need to follow the steps in the registering without a data plan thread, although I had a sim so I skipped the disabling of the insert sim screen. The rest is fairly simple, assuming you've got past the insert sim screen somehow you need to type on your phone
<enter>setprop persist.service.adb.enable 1<enter>
I did this in the email box of the signup so you can actually see what you've typed because you won't know if it's worked until you actually try it. After that again type
<enter>telnetd<enter>
which will allow you to get root access to the phone temporarily, then we connect to your phone from your computer.
In a command prompt on your computer do what I said up top by navigating to the folder ADB is in (c:\users\yourname\desktop\sdk\tools or whatever depending on which version of windows you're on and where the SDK is) and type
adb shell
this will probably say the daemon is not currently running, start the daemon etc.... this is good. If it then gives you a hash (#) at the start of the line you are now accessing your phone from your computer. If not, type
adb devices
and see if it gives you anything under where it says "List of devices attached" in the command prompt. If not it's not recognising your phone so you need to get it to do that first.
Last step when you have this, on your computer type
am start -a android.intent.action.MAIN -n com.android.settings/.Settings
which should bring up the page on your phone to enable and manage wifi connections... Connect to your wifi like normal, check it says connected on the settings page and press back and you can register over your wifi.
Hope this helps, I'm no pro but this is how I did it and it worked fine.
Hi all,
I notice on t-mobile (uk) you are accessible to all other t-mobile users on their internal 10.x.x.x network.
I have two sims and can shell from my home machine into my G1 wherever it is and vice versa (which is great, but...)
However this also means other people can too, and I notice the JF image I'm currently running (1.41 - rc8) is permanently listening on port 5037 (i.e. adb)
ADB is a debugging tool, my hunch is this wouldn't be too hard to crash, and leading on from there to run an exploit on it.
adb is of course running as root, so if exploited it's game over....
all in all, I'm rather concerned some 1337 HaXor is gonna take over my phone.
sure I can kill adb, but it would be nice to not have it running at all unless asked for.
Can I remove it from a startup script somewhere?
TOP TIP, make sure when rooting your phone you don't leave telnetd running else you are asking for trouble!!!!!!
I'm surprised no one has commented on this matter yet (I noticed it this morning.)
This is truly something that T-Mobile would have to fix on their end. I haven't had a chance to try it out today, but when my brother gets here I'll be sure to give it a shot (he has a G1 as well.)
I haven't tested this, so I can't vouch that this is an accurate description of how the system behaves.
However, adb should ONLY listen on the usb port. Listening for an adb connection on an internet-facing interface is just crazy.
I don't see adb running as non-root being a big help either. You can still compromise most of the personal data on the phone and run almost arbitrary commands on the phone as non-root. You just can't change the system image.
As many of you may know, there's currently no native way to screenshot an Android Wear device, and at this point it's pretty cumbersome to need to get to a computer to run ADB just to get a screenshot.
I've managed to at least remove the need for a computer, as long as your phone (or whatever your watch is paired with) is rooted (your watch does NOT need to be rooted), through a simple script I threw together, wearcap. It properly loop-back connects to your device and then connects to the watch over ADB. I'm sure this can be made into an actual app, but I don't care enough or have the time to do it. All you need to do is run it as root with whatever terminal app you desire. Wearcap assumes you've done all the necessary USB debugging settings, which can be found below. Screenshots are saved in /sdcard/Pictures/Screenshots/ on your device and then removed from the watch.
Everything else is pretty self-explanatory, just push the script onto your device, give it executable permissions and be on your way. As noted in the script itself, make sure your screen is on during the connection process, my Moto 360 would typically fail to connect if it was off.
For a reminder of how to setup USB debugging for the devices: http://www.androidpolice.com/2014/0...nlock-the-bootloader-and-root-the-lg-g-watch/
And here is the Google+ thread: https://plus.google.com/u/0/113601948978986762347/posts/6dD6xBrvpjs
"This paste has been removed"
Spere said:
"This paste has been removed"
Click to expand...
Click to collapse
Sorry about that, it's been attached as a text file now.
an apk will be wonderful
I can wrap it into app tomorrow if CEnnis91 is OK with it, I'm thinking to add change of the density as well through adb.
I was just tooling around in my new Quest 2 and, while my level of technical expertise is sufficient to be dangerous, I don't have any real idea what I'm doing as far as rooting, bootloader mods, etc. However, I seem to have stumbled into the regular Android settings after an app I was trying asked for usage permissions, which it seems Oculus doesn't expect any of its bespoke apps to do.
The Android settings behave oddly, though, but more like there's some kind of watcher app that's preventing access to most of these non-Oculus options. Case-in-point, the app that wants usage access, when I enter the Usage permissions screen and select the app from the menu to be taken to the screen where it displays what the app will do with usage permissions and presents the toggle for it, the screen comes up only briefly before the settings dialogue disappears entirely with an error saying that "System has stopped responding". I'm pretty sure if I were fast enough, I could probably toggle it in time, but I could also try to grant those perms via adb (which I only now remembered I could do and thus haven't done yet).
I also found and enabled the actual Developer Options, not the basic one Oculus gives us if we sign up as a developer organization. I am certain that they have actually been enabled: Even though the "{ } Developer Options" menu item keeps reloading the page that its on, settings that you'd expect to find within now turn up in the settings search dialogue.
One of these options is to enable OEM bootloader unlock. Selecting that options from the search results screen (or any other search result you'd find within Developer Options) however does like before, drops you at the menu page with the "{ } Developer Options" option.
It would be absurd if it were to be as simple as enabling that option to gain access to the bootloader and do whatever, even moreso if it was me that first wrote about it -- but, since I'm under the impression that the settings aren't actually broken so much as they are being suppressed, is there a way to toggle these various developer options, including the OEM bootloader unlock, via adb?
(Another point in favor of suppression rather than breakage, the Oculus refuses to take a screenshot of anything I'm doing with a message stating that the device is forbidden from doing so, although in less nefarious language.)
tl;dr -- how might I go about programatically toggling developer options on the device to find out what happens? More broadly, what's a good place to start being more dangerous vis-à-vis my Android technical expertise? I find its structure in every way baffling and nightmarish.
And then just for kicks, there's some oddities, like how the machine name in adb shell comes back as "hollywood" (which I found a bit Baader–Meinhof-y, since I was watching a bunch of Modern Vintage Gamer vids including his one on the Wii and its "Hollywood"-benamed graphics coprocessor). Also, fastboot oem unlock returns a curious error directing the user to visit https://oculus.com/unlock, which doesn't exist, and as far as the Wayback Machine is concerned, has basically never existed.
This settings menu is (or at least it was) fully accessible on my Quest 1 last time I tried it. There does not seem to be an entry point on Quest 2 though.
I am currently enjoying the "Bugjaeger" app from the play store. That is a good ADB solution for the Quest 2. Have fun.
rickthecabbie said:
I am currently enjoying the "Bugjaeger" app from the play store. That is a good ADB solution for the Quest 2. Have fun.
Click to expand...
Click to collapse
Could you please elaborate? Link to any guides or anything?
dwkindig said:
I was just tooling around in my new Quest 2 and, while my level of technical expertise is sufficient to be dangerous, I don't have any real idea what I'm doing as far as rooting, bootloader mods, etc. However, I seem to have stumbled into the regular Android settings after an app I was trying asked for usage permissions, which it seems Oculus doesn't expect any of its bespoke apps to do.
The Android settings behave oddly, though, but more like there's some kind of watcher app that's preventing access to most of these non-Oculus options. Case-in-point, the app that wants usage access, when I enter the Usage permissions screen and select the app from the menu to be taken to the screen where it displays what the app will do with usage permissions and presents the toggle for it, the screen comes up only briefly before the settings dialogue disappears entirely with an error saying that "System has stopped responding". I'm pretty sure if I were fast enough, I could probably toggle it in time, but I could also try to grant those perms via adb (which I only now remembered I could do and thus haven't done yet).
I also found and enabled the actual Developer Options, not the basic one Oculus gives us if we sign up as a developer organization. I am certain that they have actually been enabled: Even though the "{ } Developer Options" menu item keeps reloading the page that its on, settings that you'd expect to find within now turn up in the settings search dialogue.
One of these options is to enable OEM bootloader unlock. Selecting that options from the search results screen (or any other search result you'd find within Developer Options) however does like before, drops you at the menu page with the "{ } Developer Options" option.
It would be absurd if it were to be as simple as enabling that option to gain access to the bootloader and do whatever, even moreso if it was me that first wrote about it -- but, since I'm under the impression that the settings aren't actually broken so much as they are being suppressed, is there a way to toggle these various developer options, including the OEM bootloader unlock, via adb?
(Another point in favor of suppression rather than breakage, the Oculus refuses to take a screenshot of anything I'm doing with a message stating that the device is forbidden from doing so, although in less nefarious language.)
tl;dr -- how might I go about programatically toggling developer options on the device to find out what happens? More broadly, what's a good place to start being more dangerous vis-à-vis my Android technical expertise? I find its structure in every way baffling and nightmarish.
And then just for kicks, there's some oddities, like how the machine name in adb shell comes back as "hollywood" (which I found a bit Baader–Meinhof-y, since I was watching a bunch of Modern Vintage Gamer vids including his one on the Wii and its "Hollywood"-benamed graphics coprocessor). Also, fastboot oem unlock returns a curious error directing the user to visit https://oculus.com/unlock, which doesn't exist, and as far as the Wayback Machine is concerned, has basically never existed.
Click to expand...
Click to collapse
Would you mind explaining how you got the settings page to open on the Quest 2? I am an OG root dev and just picked up a Quest 2 myself, would love to crack into this.
Oh, dang, yeah, sorry things have been mad hectic and I didn't see these responses. I'll provide a write-up tomorrow, ping me again if I don't reply later cause I'm a forgetful idiot.
dwkindig said:
Oh, dang, yeah, sorry things have been mad hectic and I didn't see these responses. I'll provide a write-up tomorrow, ping me again if I don't reply later cause I'm a forgetful idiot.
Click to expand...
Click to collapse
All good, I actually figured out how to launch the settings page from this command:
adb shell am start -a android.intent.action.VIEW -d com.oculus.tv -e uri com.android.settings/.DevelopmentSettings com.oculus.vrshell/.MainActivity
Everything works in this page, except for launching the Developer settings option. This crashes the app as you mentioned, even though I can see the OEM Unlock option in the settings search bar.
This repo is also very helpful, I am getting told to visit the same non-existent page you were as well when running fastboot oem unlock.
GitHub - QuestEscape/research: Sharing our security research on the Oculus Quest
Sharing our security research on the Oculus Quest. Contribute to QuestEscape/research development by creating an account on GitHub.
github.com
Honestly Annoying said:
All good, I actually figured out how to launch the settings page from this command:
adb shell am start -a android.intent.action.VIEW -d com.oculus.tv -e uri com.android.settings/.DevelopmentSettings com.oculus.vrshell/.MainActivity
Everything works in this page, except for launching the Developer settings option. This crashes the app as you mentioned, even though I can see the OEM Unlock option in the settings search bar.
Click to expand...
Click to collapse
Oh, cool, I spent some time myself looking for a similar command, but I don't know much about the inner workings of Android. Do you know if there's a way to programmatically toggle the OEM Unlock switch?
I'll still post my circuitous method of getting there tonight (US/Central), maybe it will be enlightening in some way. I can't take screenshots or video of the process, cause the security policy configured by Facebook disallows it in those places.
Honestly Annoying said:
This repo is also very helpful, I am getting told to visit the same non-existent page you were as well when running fastboot oem unlock.
GitHub - QuestEscape/research: Sharing our security research on the Oculus Quest
Sharing our security research on the Oculus Quest. Contribute to QuestEscape/research development by creating an account on GitHub.
github.com
Click to expand...
Click to collapse
Okay, things are a bit different since when I first posted -- I can grant packages usage access without crashing back to Android settings (`com.android.settings`). However, I can launch Android settings directly using App Manager (https://muntashirakon.github.io/AppManager/). Still can't screengrab, though, and still can't access the Developer Options, can only search for them. Interestingly, the breadcrumbs in the search results refer to the uppermost level as `null`.
So i connected my Quest 2 to Android studio and used the debug and the log tool to see why the settings app crashes when trying to enter the developer settings. I got the exception and maybe i can paste it in here when i get home. Also i managed to sign out of my Facebook account and remove the oculus system administrator but that made the headset useless. I also created an app for the oculus that search for all the installed packages and when you click on one of them it's trying to launch the package in vr shell and found some interesting things such as a oculus assistant and a battery charging mode setting.
Honestly Annoying said:
This repo is also very helpful, I am getting told to visit the same non-existent page you were as well when running fastboot oem unlock.
GitHub - QuestEscape/research: Sharing our security research on the Oculus Quest
Sharing our security research on the Oculus Quest. Contribute to QuestEscape/research development by creating an account on GitHub.
github.com
Click to expand...
Click to collapse
maybe the page does exist, but you don't have the authority to visit it, so oculus redirect you to somewhere else
maybe its not helpfull, but when you start wireless wifi on the Q via a wired adb host , you can install the app 'remote adb shell' (blue cast icon, pstore) on the quest and connect to localhost. so you have an on device adb shell for pm commands. it has to be this remote app because of lack on adb shell command without magiskmodule (termux crashes to the tv channel). i dont know how the activitys are called in android so maybe you got luck. also are the developer options part of the settings.apk? i think they pulled it out like that so why not making a new settings.apk where the devops are available? on this way there is sure an option to have a lock on the wifi adb too so it doesnt shutdown anytime you reactivate. edit: seems that with the new multitasking feature, its possible to hold up a wifi connection even the hmd was locked, just run the remote shell, connect and dont close it. you can connect via pc too without need to use adb tcpip again. before i setup adb tcpip via ' setprop service.adb.tcp.port 5555 ' again on the remote shell app. i now let it locked, and look how long it can holdup the wifidebug without reactivating via cable.
raeumler said:
maybe its not helpfull, but when you start wireless wifi on the Q via a wired adb host , you can install the app 'remote adb shell' (blue cast icon, pstore) on the quest and connect to localhost. so you have an on device adb shell for pm commands. it has to be this remote app because of lack on adb shell command without magiskmodule (termux crashes to the tv channel). i dont know how the activitys are called in android so maybe you got luck. also are the developer options part of the settings.apk? i think they pulled it out like that so why not making a new settings.apk where the devops are available? on this way there is sure an option to have a lock on the wifi adb too so it doesnt shutdown anytime you reactivate. edit: seems that with the new multitasking feature, its possible to hold up a wifi connection even the hmd was locked, just run the remote shell, connect and dont close it. you can connect via pc too without need to use adb tcpip again. before i setup adb tcpip via ' setprop service.adb.tcp.port 5555 ' again on the remote shell app. i now let it locked, and look how long it can holdup the wifidebug without reactivating via cable.
Click to expand...
Click to collapse
.
if someone knows a working terminal for the quest (the original crashes the keyboard after a while). to replace the remote adb shell app, we could use an adb binary that holds up the wifi with adb shell to localhost (shell commands), while another terminal (local, pc or smartphone) can connect through the adb binary over wifi to localhost/quest-ip (for adb commands). but setting up an adb server (not the service) via adb binary and on-device terminal (even via adb shell) is not possible without root (but the remote adb shell app starts one or does it somelike different without root and on-device). when we know how we could put that logic together in a script or apk then). but anyways:
so its setted up now on my quest for holding up debug over wifi (sideload connection) and have an ondevice shell. it runs minimum 23 hours without needing to activate it via cable (adb device to check connection)
1. download/sideload remote adb shell app
2. connect quest2 to a host via usb
3. open cmd on host: adb tcpip 5555
4. disconnect usb
5. start remote adb shell on the quest and type quest-ip:5555 OR localhost:5555 and click connect
6. type in remote adb shell: setprop service.adb.tcp.port 5555
7. minimze the remote adb shell app and let it run
(8). to disable wifidebug: setprop service.adb.tcp.port -1
now there is no need for reactivating until reboot. if you want to run a command go to -> apps -> unknown sources -> open remote app (as there is no recent button).
you can connect to any adb host via wifi (local, pc, smartphone) even after lock or a matter of time (min 23 hours)
the remote adb shell app:
Remote ADB Shell – Apps bei Google Play
Eine Verbindung mit ADB auf einem anderen Android-Gerät läuft über das Netzwerk
play.google.com
with terminal shortcut app you can make settings-scripts then and run them via iconlist for textureresolution and gpu level or whatever ....
ps: maybe im in the wrong subforum now. should i make a thread?
pps: the app 'autostart and stay' adds an autostart option to the quest, which allows to run a launcher before original launcher comes up. (buggy)
ppps: the app SSH Server can set up a SFTP connection for wireless filetransfers
edit: could be that it just work to the first whyeverdisconnect then the quests tracking is beside and you have to reboot
double
Honestly Annoying said:
All good, I actually figured out how to launch the settings page from this command:
adb shell am start -a android.intent.action.VIEW -d com.oculus.tv -e uri com.android.settings/.DevelopmentSettings com.oculus.vrshell/.MainActivity
Everything works in this page, except for launching the Developer settings option. This crashes the app as you mentioned, even though I can see the OEM Unlock option in the settings search bar.
Click to expand...
Click to collapse
This still works today! I have a Quest 2 running V35, and recently un-linked my Facebook and Oculus accounts. After finally getting my Quest 2 back up (still needed to use the old Oculus apk from an Android device and Quest 1 device selection), the timezone was off, so I used the above adb shell command to access settings, and changed the timezone fine.
I also changed the Device Name, although I'm unsure what ramifications that might cause later.
Edit: Don't change your Oculus account password after doing the FB account bypass. You'll break the log-in session, and have to factory-reset and start over.
you can have more settings when you use SetEdit (Settings Database Editor) from pstore. some props are editable, some need root.