I am still trying to crack into that unit with the 17.11.07 software. I have a D-Link USB Ethernet but its a HW revision D and I believe I would need a B if we can get ethernet enabled at all.
Also, if we can get Ethernet enabled we will still need to get SSH password or key.
For good or for bad NOT everything appears correct, except the running 17.x version... As of now neither the "commercial jailbreak" supports new versions (well yes they were using exactly the same file to start with Also 16.51.x or newer appears to be no go: uconnect-8-4-8-4an-update
EDIT: haven't got 17.09.07 to try, but on 17.11.07 manifest.lua has changed and the last block/ search keyword is "ota_update" instead. Otherwise all the same, image valid after the edit and script.sh gets fired - at least on 16.33.29 that is @HanJ67 Did you actually try to mount installer.iso after the edit and checked /etc/manifest.lua for the end result before?
Yeah, 2nd attempt is much better as last lua block is correctly terminated and your script might actually run, but unfortunately no successful 17.x runs have been reported so far SWF scripts are not involved in update/jail-breaking run, these ones become relevant only once you are in (and need to enable some app or wifi or navi features etc). Afaik 17.x blocks ethernet dongle usage as well, but let's see if even the USB driver/link gets activated at all?
Do you have a 16.33.29 version I can try this on? I'm wondering if it will get me far enough to execute the "manifest.lua HD_Update" hack you and @HanJ67 were discussing.
I've used the 17.43.01, then finally found a 17.11.07 and had no luck there either.
In my latest attempts on the 17.11.07, I was able to hex edit the "ifs-cmc.bin" on the UPD and replaced the SSH-RSA key with my own. I think this bin will be flashed to the MMC during an update.
That SWDL.UPD got past the initial check and rebooted into update mode, but then it fails the second ISO check and loops. I had to use an unmodified image to finish the update and get back up and running.
I keep reading about making changes only after the 2048 Byte mark in the older versions with the "S" at 0x80. Is this still relevant
in later ISO/UPD images and to the second ISO check?
Right now, I'm looking to find a way to disable that check so that my modified .bin will be written to disk? I think this route would work to also modifying and getting WiFi enabled after a flash of the edited image.
If I had I 16.33.29 or similar older UPD version to attempt the HD_UPDATE hack in the Manifest.lua file I would give that a shot to be thorough.