I think the initramfs size has increased over time just enough so that by 23.05.3-rc4 the lzma output is stomping the input as it uncompresses.
for 23.05.3-rc3, the compressed image is written at 81000000-8154CAE3 and then gets uncompressed to 80060000-8151F107. im guessing the larger rc4 loses that race.
these have 128MB RAM, so we should just be able to tftp the initramfs to a higher address like 82000000.
pickljar, you can test this theory by ignoring the exploit and running this at the uboot prompt using a 23.05.3-rc4 or 23.05.x release)
if thats works, Toolybird can either just use the 23.05.3-rc3 version initramfs during the exploit then sysupgrade to whatever version is preferred, or wait on me to put out an updated exploit with the higher address
Yes! You folks are legends!! I now have the initramfs booting successfully with the v2 exploit. I'm one of those types who has lost their soldering iron.. so this is amazing
Gotta say, special props to @naf for that code. To the casual observer that seems like some kind of feat. Thanks again!
I'm kinda stuck and not sure where to go from here so any advise would great if possible.
I also have been trying to get a v2 to successful flash. Before today I couldn't get any of the exploits to work but after some progress this morning I can safely say that any of those attempts were going to fail because I discovered that I didn't have my tftp server set up correctly to serve the initramfs.
Now that I know the tftp server is working properly and using the new initramfs + the new exploit I can get a solid green led then flashing green led as soon as I click update on the firmware recovery page. Is there a long waiting period with the flashing green led because once it starts flashing it never goes back to solid green or the white. It doesn't reboot just sits there flashing. If I change IP's over 192.168.1.x I don't get the web gui just the "No Internet Connection" error page.
Am I missing a step? Or performing the steps in a wrong sequence? I've seen where others have been successful so I'm hoping the legends can also assist me.
Same issues here! NO exploit is currently working. I have my tftp server setup and listening. I can connect to it with a laptop on the very same ethernet port that I have the router hooked up to. Also, the router itself never sends a single request to the tftp server. not a single one. This is with plugging it in while holding reset (or not holding reset, makes no difference)
Unfortunately I cannot attach wireshark capture, but you wouldn't see much anyways. You can see the traffic when I go to login to the interface, but there is no request from the router to my pc.
I have heard it may be beneficial to leave a switch hooked up to the ethernet port to keep the card on for some reason. Is that actually the case?
I can do a zenmap of the router and there is not a single open port when waiting for recovery.
Guys sorry I should elaborate, I'm an IT student so I know my way around this stuff a tiny bit! (not graduated yet)
I can never capture any single packet from the router except in response to me visiting the URL 192.168.0.1. Other than that there is no single packet sent with the router as the IP that I have seen. There is no request to 192.168.0.2 for any files, nothing shows up in tftp server log, etc.
EDIT:
A few more attempts and I've now got a bricked deco s4. Cannot recover with tp link suggested method. Cannot recover with any of my methods either.
The guide states to use a method that tp link says is not available for these routers is one confusing thing. Further, I tried to upload the bypass through uboot and I think that might've caused the issue, no idea.
You're severely misunderstanding what is going on here.
Many TP-Link routers will try during bootup to contact a TFTP Server for new firmware. The S4 doesn't do that.
The S4 has the HTTP recovery with that nice webpage where you can select a firmware file and upload it.
Instead of a firmware file you upload the exploit.
And while the bootloader is checking the file. the exploit breaks out of that and executes bootloader commands.
And those commands are then using the tftp client of the bootloader to get the firmware from your tftp server and execute that.
At no point do you need a firmware recorvery tool from tp-link nor is any tftp guide for other routers going to work.
The steps at https://openwrt.org/toh/tp-link/deco_s4 are correct. If they don't work on your router then you've likely got one where TP-Link updated the bootloader to prevent the exploit from working....or you did it wrong.
Maybe these instructions are clearer to you. But keep in mind that they're for the M4, not S4, and you need to of course use the firmware files for the S4. But other than that it should work the same:
Does that mean you had access to uboot via a serial console?
I can only guess that you then took the exploit file and uploaded that? Why?
If you had access to uboot via the serial console then you could have just used the same commands the exploit is using. The following lines are literally inside the exploit file as readable text:
But if you uploaded whatever to the wrong address then you might also have overwritten the bootloader. If that's the case then only a flash chip programmer can revive that device.
I believe I understood the instructions correctly the first time, the exploit uploaded fine, but then nothing else. Let's just say there was great confusion on versions, and at the end of the day, the exploit can't fix the new mistake
