How to patch ‘kdeconnect’ to work under Debian / Stretch.

There exists an Android app named ‘kdeconnect’, which, when paired with the Debian / Stretch / Plasma 5.8 desktop widget by the same name, allows users to sync various features between their Linux desktop, and their Android device. The versions I’m presently using are:

  • Android app: 1.12.9
  • Linux package: 1.0.3~bpo9+0

Besides syncing certain basic messages, such as phone Notifications to the widget, this app allows for the desktop computer to browse directories on the Android device, which the user has authorized from his Android device – as long as the Linux desktop widget software has been patched! Below is another shot, of what this looks like when it’s working:

Screenshot_20190615_181900

The main observation about this is the fact, that it does not work out of the box. The reason for this is the fact that the Linux widget is out-of-date, as a backport. The Linux-based software tries to use an SSH-FS Mount, that specifies ‘DSA’ as its crypto-algorithm. DSA is an outdated, insecure protocol, for which reason the application framework of Android no longer supports it! Android will demand that RSA be used as a minimum.

And so, due to this initial incompatibility, the SSH-FS Mount, which creates a virtual file system in the user’s home directory, in a hidden sub-directory, fails, with an error message to the user that doesn’t seem helpful. This error message simply complains that certain files and folders could not be found, that are supposed to exist remotely, from the Android device.

And so at first glance it might seem like an unsolvable problem. But as it happens, with this exact version of the Linux package, there is a fix, which I’ve been using for months. In the past I wanted to keep this patch to myself, out of fear that my readers might botch this delicate surgery. But I’ve had a change of heart, in that I want everybody to benefit from this app, even if they are using an outdated version of the Linux software. If the reader has the courage to perform this surgery, then the following is for you:

My solution to this problem is based on an observation I once made, which was that, when running ‘kdeconnect’ from the command-line, when the remote mount failed, a message was displayed in the terminal window, which indicated that the desktop software had requested ‘ssh-dsa’ as its HostKeyAlgorithm, and that the Android device was only willing to go as low as ‘ssh-rsa’. What the presence of this error message, within reams and reams of messages, means, is that somewhere, this older version of the Linux software is giving a text-command, for the O/S to be running from within a shell. If this text command could be edited, then it would result in a successful mount, and then, whatever the desktop software wanted to do with this mount would succeed. It’s important to note that Later versions of the Linux software try to control such parameters from within C++ code, that would need to be recompiled, and that for that reason, Those newer versions of the software cannot be patched the way I propose to do here.

My solution was simple in concept: Use a Hex Editor on the compiled library, find where this parameter has been specified, as a compiled String Constant, and change one character. It’s important that within all the tons of compiled, binary code, only this one byte be altered! And there is a catch: The code has its text compiled as UTF-16, rather than as ASCII, or as UTF-8.


 

And so here goes the recipe. First of all, I’ve made a list of all the command-lines that need to be given, within a terminal window. The required software to make this patch is:

  • A terminal window – like ‘Konsole’,
  • A command-line text-editor,
  • The ‘iconv’ command-line utility,
  • ‘Okteta’, the KDE-oriented Hex Editor.

The commands which I need to give from the terminal window, are listed below:

 

dirk@Phosphene:~/Programs$ edit text/*:a-8.strings
dirk@Phosphene:~/Programs$ iconv -f UTF-8 -t UTF-16le a-8.strings > b-16.strings
dirk@Phosphene:~/Programs$ locate kdeconnect_sftp.so
/home/dirk/Programs/kdeconnect_sftp.so
/usr/lib/x86_64-linux-gnu/qt5/plugins/kdeconnect/kdeconnect_sftp.so
/usr/lib/x86_64-linux-gnu/qt5/plugins/kdeconnect/kdeconnect_sftp.so.bak
dirk@Phosphene:~/Programs$ cd /usr/lib/x86_64-linux-gnu/qt5/plugins/kdeconnect
dirk@Phosphene:/usr/lib/x86_64-linux-gnu/qt5/plugins/kdeconnect$ 

$ cp kdeconnect_sftp.so ~/Programs
$ su
(...)
# cp kdeconnect_sftp.so kdeconnect_sftp.so.bak
# exit
$ exit


 

The work-flow of this exercise is, to have a folder in the user’s home folders, which in my case is ‘~/Programs’, where the user can edit content freely, so that after an edited binary named ‘kdeconnect_sftp.so’ can be copied back to its original location in the root file system, where the software is generally installed, and that this last step will require root again.

After the reader types Line 1 above, the terminal window will change to an editor view, into which the following piece of text should be copied and pasted (using ‘Vim’, after ‘i’ has been typed):

 


HostKeyAlgorithms=


After which the new content should be saved, and the editor quit. With the default ‘Vim’ editor for Debian, the last steps will be accomplished with ‘<Ctrl>+C : w q’ .

Then, Line 2 from above can be given as a command, resulting in the file ‘b-16.strings’. This second file will be in UTF-16, Little-Endian format, but without the byte-order mark, as is suitable. This is the same format with which the compiled code contains the text which we’re going to search for.

Next, Lines 3 and 7 from above can be typed in, putting our PWD to the location in the file-system, where ‘kdeconnect_sftp.so’ is usually kept. Line 10 from above will copy this file to the special location in (my) home folder, while Line 13 will create a backup copy of this binary, using root privileges. Important: Because we will be altering the original file by name, the backup file should never be overwritten again. Next, we exit the terminal window for now.

Then, we Open the Okteta Hex Editor app from the Launcher (=GUI), and from within that app, we simultaneously open the files ‘b-16.strings’ and ‘kdeconnect_sftp.so’. The following screen-shots chronicle what needs to happen next:

Screenshot_20190615_194657

Screenshot_20190615_194917

What the screen-shot above shows is what we get, when we use the mouse to highlight the text in question. We then click on ‘Edit -> Copy As -> Values’ to copy that text, in hex format, without any spaces in the hexadecimal code:

Screenshot_20190615_195124

Screenshot_20190615_195224

Then, we navigate the editor to the document that is in fact the shared library, and search for what we’ve just copied to the clipboard:

Screenshot_20190615_195331

Screenshot_20190615_195436

Screenshot_20190615_195614

Screenshot_20190615_195735

There is a detail which I must now stress. In the Text panel of this code – assuming the reader found the piece of text – apparent letters are separated by dots or period-signs. These spaces are in fact bytes equal to zero, and not periods or dots, or actual spaces. The hex code for an actual space would be ’20’. Because these bytes are in fact the high-order halves of 16-bit units, the low-order halves of which are plain ASCII, it’s important that when editing one of those characters, not one of the dots will be replaced with a space, or an actual dot because those characters might look similar. In the example above I already did this. But in the unmodified file, there is a sequence which corresponds to ‘ssh-dsa’ in plain ASCII. The ‘d’ and nothing else needs to be changed to an ‘r':

Screenshot_20190615_200052

Then, the modified file can be Saved.

After that, using root, ‘kdeconnect_sftp.so’ can be copied back over its original location in the root file system. And then, ‘kdeconnect’ can be restarted.

The first time I tried this I ended up with a version that did not work properly, just because I was not careful enough when editing the binary. But because I had made a backup copy of the original binary, I was able to try again. And the result works for me!

Dirk

 

Print Friendly, PDF & Email

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

 

This site uses Akismet to reduce spam. Learn how your comment data is processed.