Open parkerlreed opened 3 years ago
Got vagrant working
Changed it to a newer Ubuntu version
Updated the dropbear URL
Changed image to arkham
Harcoded the name url and sha1
Image built
Booted it once now on the Asus OnHub and it took forever and did a factory reset. Set it back up with Google but no services running on reboot (it did an update as soon as I set it up)
Trying a second time now and Ill see if I can connect without setting it up
Okay so before initial setup it works
The initial setup does a firmware update that seems to wipe it out.
From the initial setup with working SSH after going through the process it updates every time. I made sure to use the latest image URL so I'm not sure what the hell is going on
It's just making fun of me now
So I eventually have to cancel out of setup and reconnect just for it to recognize that it updated. Afterwards the SSH service is not running
And yeah it connected
The changes from this repo work but only before the initial setup. Afterwards it does a factory reset and completely wipes everything
I would break out my serial again to set it up according to my guide but my only USB to UART adapter broke. I'll update as I can find out more.
Any idea why it would be factory resetting on setup? I used this as the image URL
name="OnHub SRT-AC1900"
url="https://dl.google.com/dl/edgedl/chromeos/recovery/chromeos_9334.41.3_arkham_recovery_stable-channel_mp.bin.zip"
sha1="17d027c79d4dda386ff31e206a751f53c4ea9880"
That was straight from the latest XML
I just realized the update URL
https://dl.google.com/dl/edgedl/chromeos/recovery/onhub_recovery.json
Differs from what it updates to
URL provides
9334.41
While the up to date version in the WiFi application reports
11021.84.4
Now to try and find the updated URL
I sniffed the newer update via tcpdump on my main router but I can't make heads or tails of the download
[parker@wolfcola ~]$ file /home/parker/chromeos_11021.84.4_arkham_stable-channel_full_mp.bin-11074c6d087fdbb61dc3108450a4fedd.signed
/home/parker/chromeos_11021.84.4_arkham_stable-channel_full_mp.bin-11074c6d087fdbb61dc3108450a4fedd.signed: data
I let a second factory reset capture run longer and I picked up a URL that isn't even used (weird unreleased version)
Ok so 7zip was able to skip past the header garbage and extract the rootfs. The update file ONLY contains ROOT-A and not a full ROOT-A at that.
I tried copying those files on top of the ROOT-A from 9xxx but it didn't boot that recovery image.
So the current findings are:
I'm, trying to set this up on a gale
here but have not even been able to enable SSH. Which hardcoded URLs have you used for dropbear and busybox. I've used these ones:
BUSYBOX_URL="https://busybox.net/downloads/binaries/1.26.2-defconfig-multiarch/busybox-armv6l"
DROPBEAR_URL="https://archive.raspbian.org/raspbian/pool/main/d/dropbear/dropbear-bin_2020.81-3_armhf.deb"
However SSH is not working, like I mentioned in the other comment this might just be because dropbear is failing to start for some reason. I'm not sure how I can troubleshoot this though...
One thing which I'm finding odd is that @marcosscriven states that root should persist even when there's an update issued by Google but you're seeing something different.
I assume this same update is on gale as well. So it's wiping out your access, making everything fail.
The only time I had SSH access was a brief moment during setup before it said "Oh hey there's a newer version" and proceeded to update it.
I just used the gateway IP to SSH in for that brief second. Usualy 192.168.84.1 or 192.168.86.1 depending on if you are in setup or booted fully.
My best guess for the update weirdness, considering Google has done their damndest to obfuscate this, is that they are actively wiping it out fully on this most recent update (And not providing this update as its own recovery image)
Using the dropbear URL from #49 I was able to get SSH working.
As long as I don't connect to the puck to the internet the connection stays active, as soon as I connect to the internet an update kicks in, I was able to verify it by watching the update of update_engine_client --status
every second. After it finalizes the system reboots...
I poked around the upstart services and galeforce seems to use update_engine_client --is_reboot_needed
to detect if it needs to repatch the partitions with its changes, however as soon as that command exit code switches to 0
a reboot is triggered, and I don't think any of the code in update.sh
is even executed.
I'm not too familiar with Chromium OS, so I don't know if there's anything we can do to prevent auto reboot and apply the galeforce patches. And that's assuming that this is the issue and not something else.
4 years ago now I adapted the TP-Link instructions for the Asus OnHub. I just retired the Asus and am looking for interesting stuff to do with it.
My original guide was mostly in the spirit of what this tool provides https://www.exploitee.rs/index.php/Asus_OnHub
Just curious if this should work on the OnHub as well, or if it needs a little tweaking?