the good news is that it seems to respect the DHCP specified DNS server rather than hardcoding its own like a lot of OSes do, which means that my copy of AdGuard Home can keep the tracking down to a dull roar
i intend to keep poking and prodding it until i can install a systemwide self signed TLS cert for some mitm decryption fun
i found this blog post whilst poking around: https://blog.ammaraskar.com/roku-tv-philips-hues/#the-roku-developer-ecosystem
the exploit described there no longer works, because roUrlTransfer now disables the file: protocol altogether (`roUrlTransfer.GetFailureReason()` returns "Protocol "file" disabled"). if i try to `roUrlTransfer.SetUrl("pkg:/manifest")`, the brightscript interpreter crashes, the telnet session terminates, and the TV goes from my hello world app back to the homescreen.
looks like i'm not gonna be able to just coast my way through on script kiddie mode. there's gotta be another way into this.
this blog post mentions getting read-write access by using an undocumented feature of the application runner to put the package root on an NFS mount, and create a symlink to / inside the NFS directory. since symlinks on NFS mounts get resolved on the client instead of the server, it should create a link to / through which any file on the machine can be read/written.
i don't know what version of the roku system software the author had, but the version i have allows two upload formats, zip and squashfs. if i upload a squashfs containing a symlink to /, it appears in `roFileSystem.getDirectoryListing("pkg:/")`, but i can't list it, and `roFileSystem.stat("pkg:/root")` returns an empty roAssociativeArray, the same as for a nonexistent file. so i think the symlink is broken.
i'm still trying to figure out how to do the NFS thing.
Vincent Sparks