webui_invincibility.sh
As of OS version 1.7.0.1 the device disables the Web Interface setting at every device boot. To many users this may be an obnoxious implementation/flaw as a vast number of community reMarkable scripts, including our repush and repull scripts, rely on the WebUI. The webui_invincibility script patches the reMarkable's interface, xochitl, to prevent the device from disabling the WebUI.
Due to the way this patch works, the WebUI switch can no longer be turned off from the settings once it has been turned on. To turn off the WebUI again, one must either set the WebInterfaceEnabled property in /.config/remarkable/xochitl.conf to false and restart xochitl, or simply undo the patch using the -u option of this script.
Do not attempt to use this patch on a different OS version than 1.8.1.1
You can find patches for older xochitl versions here:
- 1.7.2.3: https://github.com/reHackable/scripts/blob/8b963c6f88cd122707e46a21eeffaf46da79c15e/host/webui_invincibility.sh
- 1.7.0.1: https://gist.github.com/CTXz/4adc40b96465ee64542d14581dae18a4
- 1.7.1.3: https://github.com/reHackable/scripts/blob/ac71d094b4212df1680124688ec001f212ab2bd6/host/webui_invincibility.sh
To obtain the latest copy of the script:
$ wget https://github.com/reHackable/scripts/raw/master/host/webui_invincibility.sh
Usage: webui_invincibility.sh [-v] [-h] [-u backup] [-r ip]
Options:
-v Display version and exit
-h Display usage and exit
-u Undo patches
-r Patch remotely via ssh tunneling
The script will create a backup of the xochitl binary before applying any patches. You will need this backup if you wish to undo the patch with the -u parameter.
If you have lost your xochitl backup you can obtain a copy of the xochitl binary for OS version 1.7.1.3 here.
Patch the device via USB
$ bash webui_invincibility.shPatch the device remotely, assuming the device ip is 10.0.0.43.
$ bash webui_invincibility.sh -r 10.0.0.43Undo patches
$ bash repush.sh -u xochitl_backupQ: How do I undo the patches?
A: You can undo the patches by running the patcher with the -u option. This option demands a original xochitl binary which should have been backed up when the device was patched. Should you have lost your backup you can obtain backups of the xochitl binary here:
- 1.8.1.1: https://drive.google.com/open?id=1_vuGKcdBMkW8asU2vDeqrpJxaFRwOj7d
- 1.7.2.3: https://drive.google.com/open?id=1nGpQt6Plugkwf9U-Gh7TI_aXmmeVfr_M
- 1.7.1.3: https://drive.google.com/open?id=1hGcVTnG2aJ6rLoex5MW7K-To0P552emv
Q: Do the patches remain once the device has been updated?
A: No, after an update the root filesystem of the reMarkable is wiped and all changes applied to the xochitl binary are lost.
For the sake of documentation, and in the case that this script will become abandoned, it may be a useful skill to be able to patch the xochitl binary yourself.
To patch the xochitl binary yourself, you will require:
- A original copy of the currently running xochitl binary which can be pulled from
/usr/bin/xochitl - A disassembler of your choice. In this guide I will use radare2 with the cutter GUI which is OSS.
This guide also assumes that the function responsible for setting the WebUI has not been changed. Should the function no longer correspond to that inspected here, improvisation is required.
Theoretically this can also be done using a hex editor, however likely at higher difficulty.
To pull the xochitl binary, simply run:
$ scp root@10.11.99.1:/usr/bin/xochitl .
This will create a copy of the xochitl binary in your current directory. Make sure to back this binary up, just in case that the patched xochitl binary turns out not to be working correctly:
$ cp xochitl xochitl-backup
Now open cutter, and drag the xochitl binary into the "Open File" menu. In the load options, enable Load in write mode (-w) and set the Level to Auto-Analysis Experimental (aaaa). Setting the level to aaaa is very important, as aaa does not find the WebInterfaceEnabled string that we will be searching for to find the function responsible for setting the WebUI.
We begin by searching for the WebInterfaceEnabled string by going to the Strings tab. You will find multiple strings, however, the one we're looking for resides in the .rodata section and begins with a capital letter.
As seen from the image above, this string is stored at offset/address0x00258514 in our case. Thus, we must find the functions that reference this address.
Go to the cutter radare2 console and enter the following command:
axt @ ADDRESS
where ADDRESS is the offset/address at which the string resides at.
In our case:
axt @ 0x00258514
This will spit out which functions reference the WebInterfaceEnabled string:
In our example, the functions fcn.001beed8 and fcn.001bf3ec reference this string. We must now inspect these functions and determine which one is responsible for setting the WebInterface.
To inspect the functions, type their names into the search bar, or as they call it, Quick Filter box. Once found in the list of functions, select it. To simplify things, inspect the function as a graph by clicking on the Graph tab.
The graph of the function should match this one:
Once the correct function has been found, it is time to patch it!
When patching the function, you will want to look for the following cmp instruction at the start of the function:
cmp r0, r5
This cmp instruction compares the value of the WebInterfaceEnabled property in /.config/remarkable/xochitl.conf, which has been returned to register r0 by a previous function call, to the parameter r5, which dictates the function to which state the web interface should be set to (1 - On, 0 - Off). Upon boot, r5 will always be 0, meaning off. If r0 is equal to r5, there's no need to set the WebUI to the same state as it already is in. In other words, the function won't bother setting the WebUI on if it's already on, and it won't bother setting the WebUI off if its already off.
What we want to do, is to change r5 to 1:
cmp r0, 1
We can do that by right clicking the instruction, and selecting Edit > Instruction:
By doing this change, we will ALWAYS check if WebInterfaceEnabled property is set to true. If it isn't true it will simply be set to the state dictated by the parameter r5, which can be 0 or 1.
What makes this patch work, is that once the WebUI has been enabled once, and WebInterfaceEnabled has been set to true, the condition will always exit the function right at the start. This means, even if r5 is set to 0, meaning the WebUI should be disabled, the function will never even get to the part where the WebUI is disabled.
Once done patching the instruction, save the project and exit cutter. To see if changes were done to the xochitl binary, you can run a md5 check between the pached xochitl binary, and the backup xochitl binary:
$ md5sum xochitl xochitl_backup
The md5 sums should differ.
With the patched xochitl binary, all that's left to do is to replace the xochitl binary on the device with the patched one. To do so, you must first stop the xochitl service:
$ ssh root@10.11.99.1 "systemctl stop xochitl"
Now it's time to push the patched xochitl binary
$ scp xochitl root@10.11.99.1:/usr/bin/xochitl
Finally, restart the xochitl service and hope that all went well:
$ ssh root@10.11.99.1 "systemctl restart xochitl"
The patches should now be applied and your WebUI should no longer be turning off after enabling it!
If anything went wrong (ex. xochitl is crashing), then stop the xochtil service again and restore your xochitl backup:
$ ssh root@10.11.99.1 "systemctl stop xochitl"
$ scp xochitl_backup root@10.11.99.1:/usr/bin/xochitl
$ ssh root@10.11.99.1 "systemctl restart xochitl"
Should an issue arise that has not been covered throughout this wiki entry, feel free to submit an issue. We will try our best to respond in time, but would also like to remind everyone that this is voluntary work, and people are busy!