fSekrit won't open after OS reinstall

[Kamots]

I decided replace XP 32-bit with Win7 64-bit (same hardware). XP to Win7 requires a complete OS reinstall, which I did, and then restored my files. I keep an fSekrit 1.2 file on my system. To my dismay, it won't open. I know for certain the password is correct, but it refuses to open. All I receive is an invalid passphrase message.

In fact, I can now find NO way to open the fSekrit document. I've even tried copying the file back to an XP 32-bit system. The executable runs, but the document will not open. All I can get is the dialog with the invalid passphrase message. Obviously I have a different SID now, and the file has different permissions, but are those involved in the encryption in any way? I wouldn't think so.

How does fSekrit know the passphrase is invalid? Is it encoding something into the encrypted file that should be recognizable upon decryption? Obviously it can't know whether my file content is correct upon decryption, so there must be something knowable that it encrypted in order to make the determination?

For reasons related to the sensitivity of the file content itself I can't just pass along the file and its password to debug with, but maybe I can recreate the problem with some benign content, hmnnn.

Any ideas?

[f0dder]

Sorry if this reply is a bit rushed, but I'm running pretty late for work - felt that it was important to address the issue, though, at least by acknowledging I've seen the post.

SID etc should play no role, as long as you can access the file, and considering you're getting the "invalid passphrase" instead of fSekrit opening with an empty window, at least the data is there and is recognized. But it might have been corrupted somehow during your backup or restore?

fSekrit stores a hash of the non-encrypted text and uses that for verification upon decryption. I hope to have some spare time tomorrow to throw a little program together that reads a fSekrit document and outputs the results of decryption whether the hash matches or not...

[Kamots]

A tool to bypass the hash check and output the result of the decryption would be perfect. The results of that will at least help narrow down the problem. Unfortunately I don't have an "original" copy of the file anymore from the XP 32 system. I backed up the system before I started, then I installed Win7 on top of the hard disk in the system. Then I restored all my files from the backup (backed up to a large external drive), then created a brand new backup of the freshly installed system. After about a week, once everything was working fine, I deleted the old backup files from that final backup of the XP 32 system because all my files were intact and I was already running on my new backup set. So, the only version of the file I have is one that has been manipulated by Win7 64-bit, but NTFS is NTFS, so I can't imagine how it could be the issue. If I have some time over this coming holiday weekend, I'm going to try to recreate the problem, but a tool that will bypass the hash check and decrypt the file will certainly help. Thanks! Love this little program, by the way! Never had any issues until this.

[f0dder]

Ok, I've slapped something very temporary together. Took a bit longer than expected, but rather than just hacking this together, I spent a little time updating some internals so they allow (much) better for handling several fSekrit file format versions; this will be nice if I get around to writing an updater, and cleanups were needed before I extend the format... but I digress.

The test tool currently only supports v2 of the container format, introduced with fSekrit 1.2; v1 support will be added later, I wanted to get a test tool to you as quick as possible. The tool should have supported 1.2 -> 1.40, but in v1.35 I apparently started including the trailing NUL character of the passphrase - oops! Since the format string wasn't updated I don't have an easy way of differentiating these versions, but I'll come up with a solution eventually (will either check hash of fSekrit exe or let user specify which way to try). Lesson learned: write test suites, you silly fool.

I'm attaching two files: SekritReader_test01.zip is for 1.1-1.2, SekritReader_test02.zip is for 1.3-1.40

[f0dder]

Oops, forgot to mention usage: run from a commandline with .exe name as first argument and passphrase as second. NO error checking, very raw output. If spaces in passphrase, "enclosing it like this" should work. If non-ASCII chars in passphrase, dunno what the result is

[f0dder]

Kamots, are you still with us? Had a chance to test the SekritReader files posted above?