Yes, it's probably a bit fuzzy, but that's how my brain works at times. Add to that the fact that English is my second language and you've got a really good mix!
In order to make this a bit easier to understand I'll tell you a long story. Hopefully this will make things a bit more clear: At the moment my applications need to be "activated" on the phone. The client has to call our office, provide lots and lots of numbers (so the provided "key" is linked to the client's hardware configuration). Based on the numbers we receive we generate an "client id" and an "activation code". This is the normal scenario and, wile it sound very restrictive, it worked fine so far. Our market is very OK with this kind of licensing. Second scenario: An SalesRep or technician would go on site at a client and install the applications. The sales rep will then call the office to ask for the activation keys - but there's no one at the office to generate the codes! At this point the SalesRep/Technician has only one option: generate the code over the Internet. Unfortunately not everyone has Internet access (please don't laugh: there are areas in Romania without land-based phone coverage!) and if the client happens to live in an area NOT covered by our wireless ISP (Zapp/CDMA) we're in a bit of trouble: the SalesRep can't generate the code so he has to return home empty-handed. To help a bit with this scenario I decided it's time to write a program that can be used in the field to generate activation codes. Having such a program is obviously a security risk! I don't want to lose it and I don't want it to work if our employee forgets an CD in the client's cd drive, or forgets his USB key! If you think that's not likely to happen - think again! I used such a program in the past and have discovered forgotten CD's at client's location or, worst, I found the activation program installed on a client's computer! Elaborating on this scenario, I want to make the app as safe as it's possible and totally disabled if someone forgets the USB key in the client computer (that's my preferred media as the program needs read/write access to a small database). I was thinking of splitting the app into two separate modules, an exe and a dll; The exe would know not know anything about how to generate the key-codes. All that knowledge would be stored in the DLL. To make the DLL hard to crack I was thinking of shipping it encrypted; The exe would ask for an user name and a password, generate the required decryption key based on that info and decrypt the DLL. Next it would LoadModule the DLL, GetProcAddress something and call that routine so the DLL can show it's own GUI etc. In this scenario all key-generating algorithms are very safe in the encrypted DLL but if I have to save the decrypted DLL to disk so I can call LoadModule on it I'll lose most of the security benefits I received using an encrypted DLL. I also can't use self-modifying programs because that would get me into trouble with the new DEP in XP SP2 and the newer processors. There's no guarantee I'll be able to zero-out the DLL on disk before deleting it because there might be an anti-virus application blocking such operations (after all, that would look as if someone is trying to "infect" the dll with lots of zeros!). I KNOW something close to this is possible as there are programs that do on-the-fly decomression / decrypting of program modules. You gave an example your self: shrinker. If they can do it, I can do it. But how do they do it? Hope it makes more sense. P.S: There was an hidden raison to my asking this question: I didn't receive any messages from the list in a while and I wanted to know if the list is operational. Ralph D. Wilson II wrote: > Cosmin, > > I'm not sure if I really undrstand what you are trying to do, so let me > restate what _I_ understand you to be saying: > > 1) You have an application a technician would us (TechApp); that much I got > for sure. > 2) Now, you discuss TechApp requesting the user name and password to build > a "key" > that will be used to decrypt "the program's second stage (a DLL)". > I am kind of thinking that this refers to the software that the > client has licensed (ClientApp). > 3) Next you say "it will load that DLL" which, to me sounds like "TechApp > will load the ClientAPP DLL". > 4) You say it is to call a routine (with the User Name and Password) to 'do > another round of > validation and decrypting of the "data" ' which is where it gets a > bit fuzzy. It sounds like you > have somehow encrypted the DLL?!?!?! > 5) Finally, you want to know if there is a way to "load" this DLL without > saving it to disk . . . > "If it is not saved on disc, where did it load from?", was my first > thought, but then I > decided what you wanted to do was load the DLL, decrypt it to > memory, and then > "load" it from memory. Unless you are dealing with critical > finacnial information, > national security secrets, or some such "mission critical/life and > death" issue, > this strikes me as more than a little over-kill. > > If you have not done so, read my brief message that mentions Shrinker . . . > I did a quick Google and got the following link: > http://www.blinkinc.com/shrinker.htm > > By the way, I have no financial connection to Blink, Inc. ;-) > > > > Respectfully, > > Ralph D. Wilson II Web > Site: <http:thewizardsguild.com> > Systems > Analyst Email: > <[EMAIL PROTECTED]> > San Antonio, TX 78259 Alt Email: <[EMAIL PROTECTED]> > H: (210) 497-2643 > M: (210) 387-7744 > > "Any sufficiently advanced technology is indistinguishable from > magic." A.C.Clark > > __________________________________________________ > Delphi-Talk mailing list -> [email protected] > http://www.elists.org/mailman/listinfo/delphi-talk > > __________________________________________________ Delphi-Talk mailing list -> [email protected] http://www.elists.org/mailman/listinfo/delphi-talk
