This fixes several space-related issues at once.
We have observed the following phenomenon on TP-Link, Orbic and Moxee:
- Filling /data bricks the device (broken wifi, broken rndis, broken
display)
- Filling /cache does not (it only bricks rayhunter if it's installed
there, and it might break firmware updates)
Therefore it would make sense to store the entire rayhunter installation
in /cache.
This is a great idea for TP-Link and Moxee, because /cache is
significantly larger than /data. However, on Orbic, /data is
significantly larger than /cache!
This PR refactors orbic-network and tplink to use a shared codepath for
setting up the data directory. A symlink is created at /data/rayhunter,
and what it points to is device-specific:
- Orbic will have its data at `/data/rayhunter-data`
- There is a new alias `installer moxee` that overrides this to
`/cache/rayhunter-data`
- TP-Link will have its data at /cache/rayhunter-data when there's no SD
card, and /media/whatever when there is one.
In all cases, existing data is migrated to the new location. The user
can switch back and forth between two values of --data-dir and the data
will be moved over every time.
This PR has one huge wart, and that is that the USB installer for Orbic
remains untouched. The annoying reason for this is that the
DeviceConnection trait is insufficient to reflect all the different
kinds of shells you can have over USB: adb with fakeroot, and serial
with real root. I think it's not possible to create the right
directories with 'rootshell -c'.
I'm thinking of spawning a telnet server over serial, so that we can
just do telnet again, but this is for another time.
telnet_send_command_with_output returns output with the original command
contained. This leads to higher-level bugs. Fix#894
Also, change telnet_send_command_with_output to not return any "exit
code" related output. This is now only part of telnet_send_command,
which means this output does not leak into users of the DeviceConnection
trait.
On firmware M7350(EU)_V9_9.0.2 Build 241021 (but not sooner), entryId=2
was being sent before entryId=1. entryId=2 is invalid if entryId=1 does
not exist yet. The reason it works is due to both requests firing
simultaneously, so sometimes entryId=1 is indeed being registered first.
We may also be hitting random race conditions on the backend, not 100%
sure. Try to alleviate them by sleeping 1 second between started
requests and waiting until the DOM is ready.
Also, on sluggish devices, it can happen that nc is not ready within
100ms. Fixing that with exponential backoff.
There is a shell injection vulnerability after all, so we can just
launch a remote shell, tplink-style. Except there's no telnetd on this
device so we need to use netcat.
This was found in the goahead binary on the device using Ghidra. The
decompiled code for this endpoint looks like this:
```c
void FUN_0003c614(int param_1)
{
int iVar1;
undefined4 uVar2;
int local_160;
undefined1 auStack_15c [64];
char acStack_11c [256];
int local_1c;
local_1c = __stack_chk_guard;
if (param_1 == 0) {
error("input parameter is NULL!");
uVar2 = 0x66;
goto LAB_0003c808;
}
iVar1 = websGetJsonItemValue(param_1,"password",10,auStack_15c,0x40);
if (iVar1 != 0) {
iVar1 = get_log_level_something();
if (1 < iVar1) {
some_logging_func(2,"modifying root password(%s)...",auStack_15c);
}
iVar1 = sprintf(acStack_11c,"echo root:\"%s\"|chpasswd",auStack_15c);
acStack_11c[iVar1] = '\0';
system(acStack_11c);
}
```
Usage is `./installer orbic-network`, as an alternative to `./installer
orbic`. It should work on Windows without any kind of drivers.
This installer also works on the Moxee device.
There is a bug in `telnet_send_file` where we never close the connection
to nc, and instead wait for it to time out.
This means every file transfer takes at least 5 seconds.
