HoppaLong Posted May 23, 2016 Share Posted May 23, 2016 At first, I blamed myself for this problem. Something is wrong, but I am not entering incorrect passwords. I built a script around my favorite encryption app, dsCrypt. The script can enter a complex password into dsCrypt directly, or open a text editor and "Send Keys" so the password is completely visible, waitng to be copied and pasted. I have never had a single problem with this script. The problem occurs when I manually type a password. If I encrypt a file by entering the characters manually, I cannot decrypt the file when I move to a different version of Windows. If my script enters the same password, dsCrypt has no problems decrypting the file with almost any version of Windows. To say the least, this is extremely strange! Just to make sure I wasn't losing my mind, I created several "placeholder" text files with very simple passwords like "123456" or "cat-dog." Sure enough, I had the same problem if I manually typed these passwords. If I edited my script to enter these silly passwords, there were no problems with any version of Windows I booted. This weird behavior seems impossible! How could this be happening? If there is no solution, I must switch to another encryption app. I really don't want to do that. Link to comment Share on other sites More sharing options...
jaclaz Posted May 23, 2016 Share Posted May 23, 2016 So, basically we need to imagine your script, then debug it? Anyway, check line 42. jaclaz Link to comment Share on other sites More sharing options...
HoppaLong Posted May 24, 2016 Author Share Posted May 24, 2016 jaclaz, if I used a scripting language created by my dog it wouldn't matter in this case. This script allows me to enter insanely complex passwords many times each day without going crazy. I can certainly enter these lengthy password manually. If I was forced to do that, I would abandon encryption altogether. The point is, this script is doing its job perfectly. How can I debug something that has no detectable problems? dsCrypt has the problem, right? Entering a password manually, as opposed to simulated keystrokes from a script is causing some glitch in dsCrypt's coding. dsCrypt and my script are sympatico. Finally, this script has hidden traps or backdoors. If you open the script in a text editor it looks very mundane. To protect the passwords, certain mouse and keystroke operations must be performed before the code will execute. MSFN has some of the brightest people on the web. My "big secret" would be quickly decoded. I hope you can understand why I can't do that! The truth is, I hate encrypting files. My business partners threatened to shoot me if I didn't start encrypting sensitive documents. (They were joking. Don't get upset!) I guess my only option is to search for a dsCrypt replacement. Link to comment Share on other sites More sharing options...
jaclaz Posted May 25, 2016 Share Posted May 25, 2016 Yep, I understand your desire to not reveal your script contents, but this (respectable) choice makes it impossible for anyone to help/assist you, so your post can only be a (again perfectly understandable) form of ranting. To me it seems evident (but maybe it is just me ) from what you report that *somehow* what actually "arrives" to decrypt when sent "manually" is different from what "arrives" to it when sent through your script. What I would suspect would be that (still *somehow*) what your script is passing is different because it is (say) in a different encoding or format (think - as an example - to ASCII, Unicode or UTF) and I would use a hex editor to verify (after having dumped both the "manual" and "through script" password to file) if such a difference exists. And same goes if the procedure includes a clipboard copy/paste. At least you could describe the procedure and enumerate WHICH versions of Windows create the issue. To give you an example of what can happen (not necessarily your current issue, of course):http://bavih.blogspot.it/2008/07/notepad-bug.html jaclaz Link to comment Share on other sites More sharing options...
Tripredacus Posted May 26, 2016 Share Posted May 26, 2016 Your situation is not unique, the one where you have a problem with your code but cannot post it. So what you need to is replicate the portion that is failing. You do this in preparation to be posted online. A cleaned version of the code (as likely the failing portion is not a unique discovery you have made) that will exhibit the problems you are seeing, but without having all the extra stuff your program does. (I can interject that your program should be built like this already) Often when I have to do this, 90% of the time I will find the problem on my own. Or I will hit the issue where the PoC code works but the original doesn't. Having a working vs non-working set is a great thing. But if after this exercise, your PoC code still does not work properly, you can post it online without worry of sharing sensitive information. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now