Recently, I picked up reverse engineering of the E5573 device. The overall goal was to compromise the “authconsole” binary, and gain access to a shell on the device, without use of the “reset pin” trick outlined by forth32 (and therefore, preserving NVRAM).
We can accomplish this via the JTAG interface, using a J-Link to affect compromise. From previous extraction of vendor firmware, we know that the binary controlling authentication is “authconsole”. We first locate this in memory: from practice, I’ve found that this is generally located within 0x200000 from 0xc3000000. Ensure that you do not dump too much memory at once, or your device’s watchdog timer will complain.
You can quickly check for the presence of this binary by searching for “Welcom to enter” or any of the binary blocks below. Once identified, we can patch two key code paths within the authconsole binary. Firstly, the password check itself (replacing 20 B9 with 05 46 is fine):
As well as a “return code” check for the application:
Here, we replace the offending instruction with 00 20 (mov r0,#0), therefore passing the next check, and avoiding the “eUAP login return” path.
Once this is done, you should get the “eUAP>” prompt, which acts as a shell. Simply use “sh” to turn this into an actual shell, on which you will be the root user.
At this point, I have derived a second method to access the e5573 device, without resetting the non-volatile RAM or overwriting the firmware completely. In hindsight, I had been extremely close to this solution before, but was unable to identify the authconsole binary in memory, due to subtle changes in code between the version running on my device, and the version running on the target.