Tweet
Example: Drive Serial Utility
I have recently started a small company to produce software for mobile devices. Some of the products are applications to run on removable writable drives. Specifically, USB pen drives. The applications are preloaded onto USB drives and sold as a system. The user has to accept the license agreement to NOT separate the software from the hardware.
Well, we all know how that will go.
To avoid having the programs just copied to another pen drive and passed around, I needed a way to keep the application from running if it was copied to any other location. While searching the APMS forum, I found a thread that had an apz that was made by Worm. The apz included a DLL also developed by Worm. After a learning curve, I finally got it right and now have a very secure way to protect my system.
The program checks for the recorded serial number of the drive. If it doesn't match the encrypted sn file, it exits. After the splash screen, of course. The sn file does not really need to be encrypted, but I encrypt all the user files, so why not? I think the only way for it to be hacked is to get into the exe, and if the sn file IS encrypted, that won't work unless they can decrypt the sn file, too.
What I do is, check the drive info and get the serial. Then I validate that the serial is correct prior to creating the sn file. Then I create the sn file as a txt and an encrypted file. I then store these files under the serial number in a file archive, and enter the info in a database to keep track of it. Even though it is not necessary (serial is all I really need), I can keep track of what customer has what serial numbered drive.
The plan is, if the user somehow corrupts the program, I email him a little app that ONLY checks the serial number. He then e mails me the sn that he got from the checker. I check it against the database, and if it's a valid serial, I will put a rebuild of the app, minus the sn file, on ftp for him to download. Then, I email him a little update app that will "load" the sn file into the app AFTER he has re installed it. I have a similar procedure for program updates.
Being a small company of one, when I have to preload, it is a pain to have to use a drive checker, a validation step, and a file encryption / creator. 100-200 pen drives later and you wish you had some time savers.
Well, I developed this little utility to help with the chore. You just make sure the drive is connected and Windows knows it's there, and push three buttons to do it all. It has a lot of uses for the APMS developer.
At this time, all of the files are named the same, and I am very careful to store them under a directory that has the serial as a name. The files are named sn.txt and sn.enc. The sn.txt has the serial readily viewable.
The only thing I would want, for my purposes, is a way to use an input box to name the final file. So, if anyone could write that in, I would appreciate it. I did leave some room to put an input box as I am going to tackle this myself when I get time.
I haven't tried yet, but I think it would even work on optical drives. The CD disk doesn't get a serial until it gets it's lead in is written. I think that if you wrote a multi session CD (DVD), put on a Volume label and a small file, that the checker would then see a serial. Create a sn file, put it in your app, then close the multi session when you finish writing the CD.
I know that some of the coding could be redone so that it is more elegant, but, I had to do this rather quick, so I baby stepped it.
I hope everyone all can get some use from it. I have gotten so much from all of you.
Well, we all know how that will go.
To avoid having the programs just copied to another pen drive and passed around, I needed a way to keep the application from running if it was copied to any other location. While searching the APMS forum, I found a thread that had an apz that was made by Worm. The apz included a DLL also developed by Worm. After a learning curve, I finally got it right and now have a very secure way to protect my system.
The program checks for the recorded serial number of the drive. If it doesn't match the encrypted sn file, it exits. After the splash screen, of course. The sn file does not really need to be encrypted, but I encrypt all the user files, so why not? I think the only way for it to be hacked is to get into the exe, and if the sn file IS encrypted, that won't work unless they can decrypt the sn file, too.
What I do is, check the drive info and get the serial. Then I validate that the serial is correct prior to creating the sn file. Then I create the sn file as a txt and an encrypted file. I then store these files under the serial number in a file archive, and enter the info in a database to keep track of it. Even though it is not necessary (serial is all I really need), I can keep track of what customer has what serial numbered drive.
The plan is, if the user somehow corrupts the program, I email him a little app that ONLY checks the serial number. He then e mails me the sn that he got from the checker. I check it against the database, and if it's a valid serial, I will put a rebuild of the app, minus the sn file, on ftp for him to download. Then, I email him a little update app that will "load" the sn file into the app AFTER he has re installed it. I have a similar procedure for program updates.
Being a small company of one, when I have to preload, it is a pain to have to use a drive checker, a validation step, and a file encryption / creator. 100-200 pen drives later and you wish you had some time savers.
Well, I developed this little utility to help with the chore. You just make sure the drive is connected and Windows knows it's there, and push three buttons to do it all. It has a lot of uses for the APMS developer.
At this time, all of the files are named the same, and I am very careful to store them under a directory that has the serial as a name. The files are named sn.txt and sn.enc. The sn.txt has the serial readily viewable.
The only thing I would want, for my purposes, is a way to use an input box to name the final file. So, if anyone could write that in, I would appreciate it. I did leave some room to put an input box as I am going to tackle this myself when I get time.
I haven't tried yet, but I think it would even work on optical drives. The CD disk doesn't get a serial until it gets it's lead in is written. I think that if you wrote a multi session CD (DVD), put on a Volume label and a small file, that the checker would then see a serial. Create a sn file, put it in your app, then close the multi session when you finish writing the CD.
I know that some of the coding could be redone so that it is more elegant, but, I had to do this rather quick, so I baby stepped it.
I hope everyone all can get some use from it. I have gotten so much from all of you.
Comment