Jump to content

iShafayet

Members
  • Posts

    15
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

iShafayet's Achievements

Seeker

Seeker (1/7)

0

Reputation

  1. Manko, I get it now! Excellent idea! I'll be using tougher encryption alg such as aes 256... I'll implement this as soon as I get home. Thanks again!
  2. Manko, thanks for taking all the trouble to suggest the updates. I understand that the dll's security is as good as none at all. But using any checksum that works by having user input from autoit exe will loose the purpose of using the dll at all.. The dll is used to store the key and make it accessible to the autoit exe it was designed for only. All that trouble I had to take only because autoit exe's are so easily reverse engineerable. It's just unfortunate that the dll itself isn't secure... I was thinkin about a way to scramble and obfuscate the dll itself to make reverse engineering less probable...
  3. AWESOME WORK! Can't wait to see when it is fine tuned.
  4. - Thank you Digisoul - MrCreatoR, I hardly see the point. We are not discussing how strong the algorithm is. We are rather working on it's usability in this particular scenario where the user's input is not wanted.
  5. - Yes. That's true. But it would be much more securer if the dll could not be cracked so easily. - Thanks, trancexx. I was wondering if it would be possible anyway to bypass this vulnerability. - Can you present an example where the user doesn't have to enter anything? - I'd be doing it soon. Thanks again for the tips.
  6. - It Exactly does that. I've implemented md5 checksum. The checksum is put inside the dll in compile time. At runtime the dll gets the md5 hash of calling exe and then returns the stored key only if both md5 hashes are matched. - It's already there. Look inside the rswhkid.c in the \res\ folder.
  7. MrCreatoR, dude. I thought it is obvious what I meant. Maybe I wasn't able to explain properly. In your method, the user must enter the password each time... This would be a way to prevent other users to access the data. But I don't intend that. I intend to prevent other Applications to access the data. I hope I made my point clear, this time. And about the user doing much more work, the 'user' here is the end user (who will use an app that uses the created dll) not the developer/programmer. Alright?
  8. MrCreatoR, I understand what you are trying to tell me. This is indeed a very secure way... But what I'm trying to achieve is to make the Key exclusive to the Executable, not to the user... That means, my quest is to find a way to store (and get) the key securely without any action from user.
  9. Very interesting approach hyperzap. I wondered about the same thing few months ago. But just like Manadar said, it just ain't gonna work...
  10. Manadar, thanks a lot for the enlightment. Indeed, I forgot that string literals are stored in dll's quite directly. (my bad)... I'm lookin for a way to counter cracking. Should I succeed or fail, I'll post the way you cracked it, with the next update (if any)...
  11. MrCreatoR, Thanks for commenting. But I don't get your point. Certainly we can encrypt a text inside autoit. I fail to see how that is relevant. You are having to put the key INSIDE the autoit exe. Thus your key is compromised if someone decompiles your executable. $sCryptedPass = 'E3A867A30EFC51508A2B2290A4CBDC754A63F613FB9C7BC5' RSWHKID makes it possible to store & retrieve key from the dll (which will ONLY work for the exe it is intended to work with). So, when you distribute your project, end user can not reverse engineer your key even if they decompile the Executable, the dll (and thus the key inside) remains not compromised.
  12. (Relatively) Secure Way to Hide Keys inside a DLL This is a way to Securely store a small amount of Data inside a DLL. As we all know, autoIt Executables can be prone to decompilation (and thus easy reverse engineering). But if a vital piece of information (like the encryption key of a database) is put inside a c dll that can not be so easily decompiled. So, even though the algorithms inside the au3 is compromised, the Data is NOT compromised as it is encrypted with the key stored in the dll. I've spent few hours on it.. Please try it if you have a few moments to spare. What's Included? 1. The DLL Creation Wizard (+tcc compiler) 2. Complete Video Tutorial. HOT! 3. Source for the entire thing. P.S. Any kind of comments and suggestions are welcome. Download 0.01 Pre-Alpha - (Program FIles + Video Tutorial) Regards Sayem Shafayet
  13. Hmm.. works like a charm. Really well done, mate.
×
×
  • Create New...