Shoutbox

After doing some quick research it would seem this is possibly because of a Side by Side issue. This link addresses the issue:

http://support.microsoft.com/default.aspx?scid=kb;en-us;835322

As well as this thread on a forum:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=72965&SiteID=1

quote:

---

Originally posted by .Norma
After doing some quick research it would seem this is possibly because of a Side by Side issue. This link addresses the issue:

http://support.microsoft.com/default.aspx?scid=kb;en-us;835322

As well as this thread on a forum:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=72965&SiteID=1

---

Ahh ok thanks. Those links are quite helpful


Edit - I've updated the first post with a version of the tool which shouldn't need the runtime librarys in a DLL, so hopefully that will work

Ah, I can verify that this version works without the runtimes.

Very good job!

The tool still does not work properly, solus.

The password is incorrectly formed, making the encryption and decryption wrong.

quote:

---

Originally posted by CookieRevised

quote:

---

Originally posted by solus
I discovered that for some reason, the password is scrambled, and that the password is unicode (2 bytes).

---

The password is unicode because you can enter unicode characters. Remember that this also has implications of how the password is scrambled. Your pseudo-code is correct (appart from "0 to length" which should be "length-1") although lacks the big notice that all characters must be interpreted as unicode characters, as that is what they are, not as ascii characters.

(and this is also where one of those bugs were in old Plus! versions in regards to the "changing password")

---

quote:

---

Originally posted by CookieRevised
The tool still does not work properly, solus.

The password is incorrectly formed, making the encryption and decryption wrong.

---

Oh yes, sorry I just noticed that the password is not retrieved as a unicode string, so for the moment if your password contains unicode characters it will not work correctly.

I'll change it later

Thanks CookieRevised

quote:

---

Originally posted by solus

quote:

---

Originally posted by CookieRevised
The tool still does not work properly, solus.

The password is incorrectly formed, making the encryption and decryption wrong.

---

Oh yes, sorry I just noticed that the password is not retrieved as a unicode string, so for the moment if your password contains unicode characters it will not work correctly.

I'll change it later

---

It is not only that... even with passwords in ascii you will have the very same problems. (I even didn't tested unicode with your program yet, only ascii passwords, but the cause is the same: your scrambling/descrambling routine)... Retrieving the password from the textbox is one thing (which isn't the cause of the problem), handling the password another (which is the cause); you need to handle it as unicode (even if it is ascii).

People using your tool (and even sticking to ascii passwords) will find that their logs will either be encrypted wrongly (and opening them up in Plus! will fail because it will say "password incorrect") and decrypting some logs will also fail with some (ascii) passwords.

Important for downloaders of this tool: As it is now, chances are very high that you will corrupt log files by using this tool (even by using ascii passwords). => EDIT: it has been fixed

quote:

---

Originally posted by CookieRevised
People using your tool (and even sticking to ascii passwords) will find that their logs will either be encrypted wrongly (and opening them up in Plus! will fail because it will say "password incorrect") and decrypting some logs will also fail with some (ascii) passwords.

---

I'm not sure I understand what you mean...
In what case would they be encrypted/decrypted wrongly?

quote:

---

Your pseudo-code is correct (appart from "0 to length" which should be "length-1")

---

Ok, I'll change this in the first post. Thanks

In extremely many cases...

Like I said, the password's characters should be handled as unicode, not as ascii. It isn't some small limitation that you can fix later. It is a very serious bug which will result in wrong (un)scrambled passwords and thus in wrong encryption/decryption (no matter if the original password is ascii or not).

eg: test your program with the (pure ascii) password "éééé" (=4 times 0xE9) and you'll see. The scrambled new password is not "ÒÒÒÒ" (=4 times 0xD2), like it is in your current tool, but should be a unicode string containing 4 times the unicode character 0x01D2.

quote:

---

Originally posted by CookieRevised
In extremely many cases...

Like I said, the password's characters should be handled as unicode, not as ascii. It isn't some small limitation that you can fix later. It is a very serious bug which will result in wrong (un)scrambled passwords and thus in wrong encryption/decryption (no matter if the original password is ascii or not).

eg: test your program with the (pure ascii) password "éééé" (=4 times 0xE9) and you'll see. The scrambled new password is not "ÒÒÒÒ" (=4 times 0xD2), like it is in your current tool, but should be a unicode string containing 4 times the unicode character 0x01D2.

---

Ahhh thanks, I understand now.
I've modified it so that unicode is used now. I'll never underestimate unicode again

Nice job solus!

It works nicely for me for single files. In its current state I don't find it particularly useful, though, so I have a request for you!

Essentially, I have 2 years of encrypted log files, which I would like to decrypt. Doing so file by file with your tool would be cumbersome. Obviously the log files are divided into directories (by date, in my case).

My suggestion to you is to add a function where your program takes a directory and a password as inputs, then searches for all *.ple files in that directory tree, and decrypts them, naming the output files as *.txt. Possibly with an option of deleting the old .ple files after decryption.

That would make me a verry happy man!

Mikael