windows install script
We need someone who understands how to write batch scripts or powershell, or we need to rewrite this whole thing as a standalone rust binary.
Is anyone working on this? I have low bandwidth right now but could take a crack at it in a month if it's not already in progress
Not as of right now! You are welcome to it!
Looking at this now! If there are no objections, I think Powershell (Windows answer to bash) is preferable to batch (which is a pain to use). But Powershell isn't built in to Windows, so that would be a small extra install step. (Powershell can be used on MacOS or Linux too, fwiw.)
I wasn't able to install this on Ubuntu 22.04 since glibc 2.38 isn't available and I didn't want to do the annoying apt stuff and add an apt repo. But I was able to install this on a Mac (with some annoying security pain that was easy to bypass.)
But it would add a Powershell dependency, which seems unideal.
So, I see three options:
-
Rewrite the install script in Rust: My study of this repo is very brief. If I'm right, this would mean extending
serial/to have the logic ininstall-*.shto download and run adb. The benefit here would be to get ahead of platform-specific install scripts and dependency funkiness. -
Or, just Write an
install-windows.ps1PowerShell script. This would be faster, and require fewer changes to the structure of the repository. -
Or, much cooler, use a WebUSB installer! Much like GrapheneOS does, it might be possible to host this as a webpage and run the script, in the browser, client-side. It would only support Chrome. This is probably the best path, but also a big "needs research" path.
What are your thoughts on prioritizing here? I was thinking I could write the install-windows.ps1 script first, and work on the WebUSB thing in the interim.
Hi! I'm so excited that you want to work on this!
I agree with you that the easiest path here is to make a powershell script, (and powershell is currently installed by default on all modern windows systems) and I think that is the path of least resistance for now.
I would love to have a web installer because the serial binary is currently the source of most of our users frustration and woe with this project and since it is only used by end users for rooting and installation having a web installer could solve a ton of prorblems, while also being easier to maintain and working on more platforms!
We considered writing the install script in native rust as well but this just makes the problems people have with serial even worse and so I'm inclined to not do this. So I think that we should go ahead with a powershell installer ASAP and consider a web installer a top priority as well, knowing that it will take a bit longer and a bit more research. (one question I have is whether we can issue adb commands from the web installer, or failing that how we can push files to the device but there must be a way we can figure out from graphene.)
Thanks!
So, I did a spot of research, and I hope you don't mind me putting my notes here :) A WebUsb based installer might be something quickly achievable with the expertise y'all have.
The sum of GrapheneOS's WebInstaller lives in this web-install.js using fastboot.js as a library. The web-install.s methods are instantiated by a user by clicking <button>s in GrapheneOS's web install page. Both are MIT licensed, which should be compatible with Rayhunter's GPL license.
Following the logic flow, the steps taken for flashing Graphene are (1) unlockBootloader, (2) downloadRelease, (3) flashRelease (which flashes firmware, reboots, and flashes the OS, and (4) lockBootloader.
So fastboot.js might be the way to go if these Orbics are fastboot-capable, and we can copy a lot of the work of using fastboot.js from GrapheneOS's web-install.js. But crucially these don't use adb, so a naive / direct port of install-common.sh is not possible.
Alternatively, there does appear to be ADB over WebUSB, which should make for a more 1-to-1 translation of the install-common.sh script. There's ChromeWebLabs wadb, webadb.org, and this webadb.github.io. These all seem to be in various stages of old/disuse, and it's not clear to me why GrapheneOS used fastboot instead of webADB.
This is where I hit a wall in my research, though. I don't know enough about Androids, the orbic, adb or fastboot, or this project. I have too many questions (can we just use fastboot? does orbic have fastboot enabled? is webadb preferable? how mature are the webadb projects? are there any security footguns to webadb?) to be productive over. So, lacking the expertise, I won't work on the WebInstall stuff. But I will continue on developing the PowerShell script when I get the free time :)
Amazing!! I don't think orbic has fastboot since its not actually android, just a linux install that looks similar to android in some ways. But the webadb stuff should work, I will give this a look. Thanks again!
That's interesting-- when you say it "looks similar to Android in some ways", do you only mean visually, or do you mean in that it implements the ADB protocol?
One more WebUSB implementation I found is https://github.com/yume-chan/ya-webadb (and there might be some promise in using wasm over adb or a reimplementation)
I don't mean visually, I mean that it implements ADB and some of the android permissions conventions.
I've had to manually root the Orbic following the XDA link provided in the instructions and was successful (and I do not see any way this can be done automatically with PowerShell), but I also can't build the rayhunter source using PowerShell because most of the Rust libraries in the source are incompatible with anything that is installed with RustUp installer.
The section "If you're on windows or can't run the install scripts" is vague and needs some improvement. Once I've figured out how to build the source using PowerShell I will submit Windows instructions changes to this repo for considerations.
Wanted to chime in and say that I was able to run the install scripts without issue on Windows using WSL2 (Ubuntu) - I had to use usbipd to share/attach the USB BUS ID for the device so it would passthrough directly to WSL2. I had to do this once when I first plugged in the Orbic device, then again after the first ADB reboot (since the device reports itself as something different when ADB is enabled).
The WSL approach worked great for me and could be a solid "Windows" install method for those comfortable using WSL.
I think this is done since 0.3.0