Razer Sila: OpenWrt 15.05.1; looking for the ipq806x/generic maintainers

For Developers
1

Hello there!

Thanks to a relatively old exploit (/ubus is exported with the admin user having full r/w/x access to everything), I was able to inject a SSH hostkey into the old Razer Sila and log in - a discontinued device with still pretty respectable stats and features! In fact, it is still my main AP.

However, considering there will never be a new firmware for it, and that it runs plain OpenWrt with a few company additions, I have been wondering if there is something better I can do with it - like using it as a SAT>IP server with the USB ports or maybe even run parts of Home Assistant there due to it's range of wifi, bluetooth and other devices that would make it an ideal smart home hub.

Now, when logged in, I can find this tidbit of version information:

root@SAP201-0003-SN1848010907-44-5e-cd-01-09-08:~# cat /etc/openwrt_release
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='Chaos Calmer'
DISTRIB_REVISION='unknown'
DISTRIB_CODENAME='chaos_calmer'
DISTRIB_TARGET='ipq806x/generic'
DISTRIB_DESCRIPTION='OpenWrt Chaos Calmer 15.05.1'
DISTRIB_TAINTS='no-all busybox override'

I have also dumped all partitions separately using dd just to be sure and looked at the current state of affairs in opkg; the keys are outdated.

root@SAP201-0003-SN1848010907-44-5e-cd-01-09-08:~# opkg update
Downloading http://downloads.openwrt.org/chaos_calmer/15.05.1/ipq806x/generic/packages/base/Packages.gz.
Downloading http://downloads.openwrt.org/chaos_calmer/15.05.1/ipq806x/generic/packages/base/Packages.sig.
Signature check failed.
Remove wrong Signature file.
Downloading http://downloads.openwrt.org/chaos_calmer/15.05.1/ipq806x/generic/packages/alljoyn/Packages.gz.
Downloading http://downloads.openwrt.org/chaos_calmer/15.05.1/ipq806x/generic/packages/alljoyn/Packages.sig.
Signature check failed.
Remove wrong Signature file.
(... etc, etc, etc ...)

So I wanted to build my own packages for it and thus went digging for the image builders - and found them, too. No problem. This is the one I use, right now: https://downloads.openwrt.org/snapshots/targets/ipq806x/generic/openwrt-imagebuilder-ipq806x-generic.Linux-x86_64.tar.xz (My WSL is already setup and equipped with proper resources - I did tinker with my OLED LG TV which uses WebOS and parts of OpenWrt - so I have been tinkering with that too, as well my FriendlyElec NanoPi R6s, which runs plain OpenWrt 22.)

Question is, though, since the Sila was never added as a proper device in any documentation, how do I go about building packages now? As I have full root access, it is no problem to extract whatever information I would need out of the device et verbatim. That said; what do I actually need?

I may have overlooked it, but I was trying to find two things:

My hopes would be to be able to deploy a few updated packages to a USB drive and update some of the internals, then strip the proprietary extras out, re-introduce LuCi and basically have a neat little device to tinker with :slight_smile: But in order to do that, I need to know how exactly I go forward building packages, if there is anything specific that I need and what not.

As an addition, here is everything installed on the Sila: https://gist.github.com/IngwiePhoenix/7fcb7b1784111ae1b01f3d36fedcddb4

Not directly related; but I would like to reconfigure uboot to see if I can make it boot off a USB drive should desaster strike. If you have a pointer for setting this up, I'd be quite thankful for that. Due to being visually impaired, soldering is not exactly something I am exactly good at... ^^;

Thanks for reading and kind regards,
Ingwie

1 Like
2

As ipq806x has never existed in the official OpenWrt 15.05, but was added later, you are apparently using a proprietary OEM version based on the ancient 15.05

For built packages to be compatible, you would need the toolchain from the device OEM vendor, so that all base C libraries etc. would be compatible.

Trying to use newer official SDK for package compilation is futile.

If you want to use a modern OpenWrt, you would first need to create support for your device. probably easiest done by getting old sources from the OEM vendor, and then using info from them to creates DTS definitions etc.

3

I thought having access to the device itself would be sufficient? Guess I was off there.

Looking at the installed packages, I do see ucLibc - which seems normal and standard to me.

root@SAP201-0003-SN1848010907-44-5e-cd-01-09-08:/mnt/usb-2# opkg list-installed | grep libc
libc - 1.0.14-1
libcares - 1.10.0-1
libconfig - 1.4.9-1
libcurl - 7.40.0-3.2
uclibcxx - 0.2.4-1

And:

root@SAP201-0003-SN1848010907-44-5e-cd-01-09-08:/lib# ls -l libc*
lrwxrwxrwx    1 root     root            19 May  7  2020 libc.so.1 -> libuClibc-1.0.14.so

That said, I have never built a DTS before. I will look into that, thanks for the pointer. :slight_smile:

As for contacting the OEM... Well, I had tried way before finding out about the exploit, and they were not cooperative, at all. And the company that worked with them on this problem seems to have gone away.

What i mean is, that one of the things that stood out to me in the uhttpd configuration, was a URL:

# uci show uhttpd
uhttpd.main=uhttpd
uhttpd.main.listen_http='0.0.0.0:80' '[::]:80'
uhttpd.main.listen_https='0.0.0.0:443' '[::]:443'
uhttpd.main.redirect_https='1'
uhttpd.main.home='/www'
uhttpd.main.rfc1918_filter='1'
uhttpd.main.max_requests='3'
uhttpd.main.max_connections='100'
uhttpd.main.cert='/etc/uhttpd.crt'
uhttpd.main.key='/etc/uhttpd.key'
uhttpd.main.cgi_prefix='/cgi-bin'
uhttpd.main.script_timeout='60'
uhttpd.main.network_timeout='30'
uhttpd.main.http_keepalive='20'
uhttpd.main.tcp_keepalive='1'
uhttpd.main.ubus_prefix='/ubus'
uhttpd.main.disabled='0'
uhttpd.main.apiurl='https://na.apiv1.ignitiondesignlabs.com/apiserver/api'
uhttpd.main.token='<Removed, dont know how important it is or not.>'
uhttpd.px5g=cert
uhttpd.px5g.days='730'
uhttpd.px5g.bits='1024'
uhttpd.px5g.country='ZZ'
uhttpd.px5g.state='Somewhere'
uhttpd.px5g.location='Uknown'
uhttpd.px5g.commonname='OpenWrt'

I had gone and looked up ignitiondesignlabs.com and it seems their endpoints are all gone - and I could not find a contact to them either to see if they had any more informationa bout this device or sources. So unfortunately, I guess I have to rule OEM supplied help out...

4

This is also incorrect, it doesn't.

5

Welp, now I have a device tree and original kernel image and it's config.

I backed up all partitions (all 17 of them) and am still making sense of it all. However, now that I have the device tree (well, the FDT out of which I have to peel the real DT first) and kernel config, what else am I missing in order to make an OpenWrt port for the Sila now?

I will be taking it apart in a few days to look for UART or JTAG pins to help in this endeavour. Because I refuse to let it become a useless paperweight.

6

from https://fccid.io/RWO-RZ370251/
image

it would have been an exceptional paperweight though, the device's very heavy.

I was considering getting one of these a while back, when my local MM had two open boxes on sale, but they were asking more than the price of a new unit, when it was still being sold.

1 Like
7

I never thought of looking up FCC database entries. Seriously bookmarked this - actually an amazing thought.

image
image432×589 74.2 KB

Top is UART, bottom left is most definitively JTAG. I just watched a video about how to identify those to aid me in this endeavour; someone recommended me make sure I have JTAG access so I can recover from a worst-case scenario (which I might actually need, lol).

I didn't find the image you screencapped there just yet, working through the docs. But if this pin header is there and I don't have to find someone to help me solder (almost blind = no soldering...) then it's time to go ham!

Again, thanks for the pointer, this is insanely useful.

I concour. First thing I did when I got it was to let the box slip out of my hand and fall on my foot. Painful. ^^;

8

Finally! I'm very happy to see someone interested in doing that too
I've been trying to update things on Sila but failed to update anything I managed only to tweak some settings such as switching the LED color back to green and fixing the Wi-Fi settings, I'm interested and will be following this thread and try to help if possible, Hope we see more progress

9

Ohey @Ibrahimiq :slight_smile:
The Sila is effectively deadlocked; it's SSL implementation and cert bundle is dead as hell. xD

# curl -Lv dropzone.ingwie.me/pk
> GET /pk HTTP/1.1
> User-Agent: curl/7.40.0
> Host: dropzone.ingwie.me
> Accept: */*
>
< HTTP/1.1 308 Permanent Redirect
< Connection: close
< Location: https://dropzone.ingwie.me/pk
< Server: Caddy
< Date: Sat, 02 Mar 2024 18:47:19 GMT
< Content-Length: 0
<
* TLSv1.2, TLS Unknown, Unknown (22):
* TLSv1.2, TLS handshake, Client hello (1):
* SSLv2, Unknown (22):
* TLSv1.2, TLS handshake, Server hello (2):
* SSLv2, Unknown (22):
* TLSv1.2, TLS handshake, CERT (11):
* SSLv2, Unknown (21):
* TLSv1.2, TLS alert, Server hello (2):
* SSL certificate problem: certificate has expired
* SSLv2, Unknown (21):
* TLSv1.2, TLS alert, Client hello (1):
curl: (60) SSL certificate problem: certificate has expired
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

The installed opkg can't grab updates either because of that. So, yeah... That part is a goner. :slight_smile:

I haven't had a whole lot of time lately to investigate more into device trees; but I am still sitting here with the FDT ready to extract and smash into a kernel build.

Thing is, before I do that, I want to change the u-boot config to have it try to boot off USB or at least chainload into it.

Currently, I basically see this roadmap:

  • Fully understand the extracted device tree, start to finish.
  • Build u-boot + Kernel and inject the Sila device tree into them.
  • Edit the u-boot on the device to change the boot config so that I can test-boot alternative kernels and u-boots.
  • Once I have a properly working setup, build an OpenWrt SDK targeting the Sila (fork or something?) and try to finalize bringup.
  • (Optional, very likely not happening) Upstream the information, so it becomes officially supported and built for
  • Flatten the whole device, slap a "retail" OpenWrt on it, and have a fancy new device!

I also have to still buy a JTAG chip and multimeter to pick out the pins... However, I have a working RISC-V board exactly next to the Sila - so the idea is to wire them together (uart + jtag) to use the VisionFive2 board to effectively debug the Sila and whatnot.

So yeah, still working on it, just a little slower. ^^

1 Like
10

Hello @IngwiePhoenix Any update on Sila?