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.
The windows installer seems to sometimes brick the Orbic's ARM core,
resulting in the DSP returning "Qmi Send Message Fail" when sent AT
commands.
This commit adds a loud warning and confirmation dialog for Windows
users before installing.
Previously, the unlocking method for the wingtech hotspot would add a
invalid mac address to the blocklist. This would prevent the wifi from
coming online after rebooting until the invalid mac was removed.
This commit changes the unlocking method to attempt to *remove* an
invalid mac, creating a no-op condition that still works for unlocking
root access to the hotspot.
This commit also adds documentation for a problem where the hotspot
would occasionally not reboot while completely disconnected and
installing over wifi.
Fixes#466
