I've become increasingly frustrated with the limitations of eWallet's export functionality. The output it produces is impossible to use for migration as, among other issues, it does not delineate field names from values. This has made it impossible to migrate my data to KeePass. (The old eWallet import plugin doesn't work - it was for an old of eWallet that would at least put colons after field names on export).
Luckily, for version 7, they've written eWallet in .net. And .net, I can work with. Here's a tool that will launch eWallet, then extract the entire contents of the open wallet from memory and write out a structured xml file containing everything stored within it - as in, what export *should* have been.
eWalletDataLiberator.zip (source included)
It will only work with eWallet version 188.8.131.52661 (the current version).
The next step would be to write a transform to go from this xml to KeePass 2 xml format, so I can complete the migration. I haven't been able to find any documentation on this format, though, only the KeyPass 1 format, which lacks the custom fields. If I can't do it with a transform I might have to write an importer for KeePass 2 to read the liberated xml format, but I might not get a chance to work on that for a while. Any help with either a transform or a plugin would be most welcome.
Any feedback for the liberator tool is welcome too - the goal for that is to get all stored information out of the wallet, even if it won't currently be used by keypass, you never know if it might be in the future.
This is a sample V2 XML file containing the required entries. If you need more examples, create a database with one entry and export it.
You can use any code from here if it suits.
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
There is no documentation of the 2.x XML format, sorry. My suggestion would be to create a small test database and export it using 'File' -> 'Export' (format "KeePass XML (2.x)") to get a sample XML file. Here's an extremely simple sample file:
Thanks for those samples. One thing I haven't been able to figure out is how to mark a field as protected. If I've got a custom string field, PIN, for example, that I've set to be protected, then it comes out identically to one which is not protected.
Is this just a limitation of the xml format - would I have to write a plugin if I want to be able to control which custom fields are protected?
True, in-memory protection isn't supported for plain-text XML files. Writing a plugin would be the easiest solution.
Plugin now written. It imports pretty much everything that is possible, except custom icons. It will do all fields and file attachments, though. There's not a great mapping between the icons used by eWallet and KeePass, though - if anyone wants to improve these, check the mapping is in Importer.cs, the ImportIcon method.
Here's the updated link, including the extractor app, importer plugin, and all source: eWalletDataLiberator.zip
I'd like to list your plugin on the KeePass plugins page . Would you allow me to do so? Are you planning to create some small website for your plugin? If not, should I link to the RapidShare download or should I host the file on the KeePass website? Note that I can't provide download statistics for files hosted on the KeePass website, so if you want statistics you have to host the file elsewhere.
One last request. Your KeePass plugin DLL is built for a specific version of KeePass, i.e. it won't work with future KeePass releases. It'd therefore be great if you could create a PLGX file of it, which will work with future KeePass releases (see ).
Thanks again, best regards
You are most welcome to list the plugin. It's a shame it can't just be an ordinary "select the file and import" thing, but hopefully people will read the readme if they just download it from there without having seen this thread first.
Please feel free to host the file. If I have to do any updates, I'll post them to this thread as rapidshare links, then you can update the hosted file (or not, as you please).
I tried to create a plgx file, but it didn't work. It produces the file, but when it tries to load it it says it's incompatible with the current KeePass version. Passing -debug to KeyPass.exe gives the (slightly) more helpful message: "The given path's format is not supported". I can start poking in the KeePass source and try and debug further, but I really don't understand the point of using plgx files for version compatibility - why not just use the built in CLR functionality to do this?
Stick a KeePass.config file in the program folder and the dll's will just work, no need to mess about with recompilation or anything, or rely on plugin authors to make special versions.
I've added your plugin: http://keepass.info/plugins.html.
Your config file approach looks very interesting; I didn't know this so far. I previously tried a multitude of ways to make plugins version-independent (for example disabling version dependency in the assembly properties in Visual Studio, etc.), but nothing worked, that's why I've designed the PLGX format. Anyway, your config file indeed seems to work perfectly… KeePass 2.14 will ship with a config file anyway (in order to support .NET 4.0), so adding the runtime section isn't a problem at all. The new config file looks like the following (includes a slightly modified version of your runtime section):
As you seem to be a .NET expert, it'd be great if you could quickly have a look at the file to see whether it's fine (I'll of course update the versions before releasing).
Also, one question: you've named your file KeePass.config, however I'd prefer KeePass.exe.config. KeePass.exe.config seems to work fine, so I wonder whether there are any pitfalls with this?
Thanks a lot, best regards
Thanks for adding my plugin to your page, and for hosting the file.
I've done a quick search, and I think .exe.config is more correct than .config, so go with that. As far as I can tell, the behaviour is identical because they need to retain compatibility with files named .config, but the current officially sanctioned naming scheme is .exe.config.
Looking at the example config file you posted, I think it's just the version numbers that need updating. The range of oldVersion needs to be increased to at least 184.108.40.20699 to include plugins compiled against 2.13, and newVersion needs to be the exact version of the new 2.14 assembly. For oldVersion, I chose 2.09 fairly arbitrarily in my example - that should be set to whatever the earliest version 2.14 is backwards compatible with (as in, no types that a plugin might be referencing removed or renamed since then).
The theory is that, for maximum compatibility, a plugin would be compiled against the earliest version that provides the functionality it requires, and the KeePass config file defines which newer versions are backwards compatible with that. In practice, if no-one needs to keep using older versions, it doesn't really matter that older versions won't load the plugin.
If you ever do need to make a breaking change, you simply change the lower bound of oldVersion in the config to not redirect for versions below the breaking change. Hopefully that won't ever happen, though!
Great, thanks for the info!
Unfortunately I doubt oldVersion will have any real meaning in the KeePass case. Almost every KeePass release adds or changes public classes and methods, and some plugins might use them or not. Of course, the main API (plugin class, host interface class, main window, etc.) is relatively stable, but other areas are still evolving. Although I'm trying to keep the interfaces stable, it's impossible to say e.g. since 2.09 nothing changed.
Therefore, I wonder whether there are any disadvantages in setting oldVersion to 220.127.116.11 and let .NET figure out whether the plugin and KeePass are compatible (i.e. all required interfaces/classes/methods are there, etc.)? I didn't try it, but I'd expect the loading of an incompatible assembly to fail immediately with an exception (without crashing KeePass), and this would be presented by KeePass to the user through a plugin incompatibility message. Do you know whether this would work or not (e.g. because the whole KeePass might crash through this?)?
Adding public classes and methods isn't a problem. You can even add (non-abstract) members to classes like Plugin or FileFormatProvider that plugin classes inherit from without breaking. This is the same compatibility as you get from the plgx system, but I guess the advantage of plgx would be that it would fail at compile time, rather than later on.
For example, if you were to remove UrlUtil.GetFileName and refactor all your code to use the built in System.IO.Path.GetFileName instead, this would of course break any plugins that used UrlUtil.GetFileName. You wouldn't find out until they actually tried to call that method, though, at which point a System.MissingMethodException would be thrown, and handled by your normal exception handling routines. (Of course, in this example it would be best to leave UrlUtil.GetFileName in place but add an or attribute to it, avoiding the breaking change).
Breaking changes to the Plugin class itself would cause a failure of the plugin to load entirely, but other changes would only cause exceptions when they were encountered, not at load time.
Ok, I see, thanks. Well, I'll ship KeePass 2.14 with an appropriate KeePass.exe.config file, but will continue to recommend the PLGX format, as this is the only way to know (immediately) whether a plugin is 100% compatible with the latest KeePass version or not.
Fair enough. Technically, the necessary information to determine compatibility is all present in the assembly module metadata, there will be a TypeRef for every imported type and a MemberRef for every imported method. In practice, it would be such an unimaginable nightmare to try and verify compatibility like this that it wouldn't be worth the hassle.
Theoretically, of course, if you've broken backwards compatibility a plugin may not be fully 'compatible' even if it still compiles - compilation doesn't catch everything. 99% is better than nothing, though!
Illiumsoft have released eWallet 7.2, so here's an updated version which works with that (and only that) version:
This one is compiled against Keepass 2.09 for maximum compatibility, using config files. I've checked that 2.14 can load it.
I've updated the plugins page, thanks :-)
Hi Alex, dreichl
Thank you for your hardwork on this matter.
I have tried downloading and running the eWallet Data Liberator by following the readme file. It keeps failing to run and saying that "eWallet Data Liberator has stopped working" and after windows checks for a solution the dialogue box disappears. Then that's that. Nothing further happens.
I've successfully placed the eWalletLiberatedDataImporter.dll file in the KeePas program folder and under the import menu of KeePass I can see the eWallet Liberated Data choice.
I just cannot seem to liberate my data.
Are you sure you are using the right version of eWallet? It should be 18.104.22.168586 - check the about box in eWallet.
Are you sure you put eWalledDataLiberator.exe in the same folder as eWallet.exe (C:\Program Files\Ilium Software\eWallet by default)?
I used eWallet (newest version 22.214.171.124233) for many years and now I change my cellphone to an Android cellphone. I'll try to import my eWallet data in KeePass 2.16, but can't execute the "eWallet Data Liberator". The program always stpps with "eWallet Data Liberator has stopped working". It's in the Ewallet folder.
How can I import over 150 data sets in KeePass 2.16?
Ah, didn't notice they'd updated eWallet. Here's a new version which will work with 126.96.36.199233 (only):
Your new version is now also available from the KeePass plugins page, thanks! :-)
Hi, can you update the plug-in to work with the latest eWallet version 188.8.131.52739 ??
I was not able to find eWallet 7.2.1 version anywhere.
Yes, certainly. Here is a new version which will work with 184.108.40.206739 only:
The new version is now also available from http://keepass.info/plugins.html ; thanks! :-)
One minor request for future versions of your plugin: could you please update the AssemblyFileVersion attribute in KeePassLiberatedDataImporter/Properties/AssemblyInfo.cs (e.g. to 0.5)? By doing so, KeePass can notify users when an update for your plugin is available.
Log in to post a comment.