How can I retreive the password I used to encrypt a backup, given that I have the original XML file? It's stored encrypted there. I've forgotten the password since it has been years.

You're probably out of luck.  If it were that easy to reverse engineer the password for a backup from the XML file that created it, it would be relatively of little use to encrypt it to begin with.

Well, the program does know enough to display the length of it correctly in the UI, as I verified with a password I do know.  Plus people have asked this before and been PM'd by Macrium folks, so I guess there is a way to do it which they don't publicise.

I believe the passwords themselves are encrypted in a Registry key if I remember a past post on where passwords are stored.  You'd have to know the encryption key used to encrypt the password you put into the XML.  And I doubt tech support would give out the keys to the kingdom.  Maybe they take your XML, process it, and PM you the password.

Ah, never mind.  I found a naughty way to get the password: dump the process memory and extract all the strings with the given length.   Recognised it instantly after going through all the possibilities!  Haha!

Glad that worked for you, although I'm not thrilled to hear that it was apparently that relatively easy.  I realize that Macrium recommends that XML be stored in a locked down location and that sensitive information has to live in memory at least for a while, but I'd still hope that there might be something that could be done so that discovering a cleartext password from the ciphertext version in an XML file would take someone more than an hour from asking the question to having the answer.

Also, might I suggest LastPass?  Its Secure Notes feature allows you to store arbitrary text in a secure fashion and is therefore a handy way to store things like passwords used with "offline" resources.  And LastPass's core functionality is also quite nice

I admit, I was also a tad worried it was apparently that easy to dump a password from an XML.

Well unfortunately, now the cat's out of the bag.  Even if Macrium updated Reflect so that newer versions protected against this somehow, installers for the old versions would always live on somewhere, and attackers could feed XML files containing an encrypted password to those old Reflect versions in order to recover the plaintext password.  Perhaps this might be an opportune time to implement a suggestion that I wrote up in this Wish List thread to improve the security of those encrypted passwords (sadly, that thread went wildly off-track, initially due to another user's fundamental misunderstanding of key concepts and distinctions).  That would deliver benefits of its own, but if Macrium also incorporated protections against this memory dump tactic at the same time, then passwords stored in that new format I proposed in that thread would only be usable by newer versions of Reflect that also had those memory dump protections, while older versions that were vulnerable to the tactic discussed here would be of no use to attackers because those versions wouldn't understand the new password format.

UPDATE: Upon rereading that Wish List item, I don't think even that would mitigate this problem, because an older version of Reflect would still be able to decrypt the encrypted XML password.  The user might have to change the value of the proposed "Type" value, and an older version of Reflect wouldn't actually work properly with that decrypted password since it wouldn't be "salt-aware" (and because the "Type" value would be incorrect for the encrypted password), but the decrypted password would still exist in memory.  It would have some salt appended to it, but that would be easy enough for a user to identify and remove, thus revealing the true password.  That's unfortunate.

Admittedly, there are a few mitigating factors here that sort of alleviate the idea of just dumping passwords from memory.  For instance, the user apparently has to know the length of the password.  And the user recognized the old password from the list of dumped data and that's how he recovered it.  It's still a little unsettling that it is apparently that easy to do, though.

Even if you didn't know the length of the password, searching the memory space of a process for strings of the range of lengths of typical passwords likely wouldn't involve too much extra effort and would be successful for many passwords used in the real world.  Again, the timestamps of the posts in this thread indicate that the OP managed this in an hour.  So even if it took 5x longer, that would still be trivial.  And the fact that the OP found the password that way doesn't mean that's the only way it could be done.  For example, maybe now that it's been found, it's become clear that there would be an easy way to find the password going forward even if you did not know the length and would not recognize it on sight, such as "the password is always here in relation to some other value that's static in the memory space".