Uhhmmm … yeah … like I would know what to look for 
I was afraid to look, but it actually doesn’t look too bad. Juce keys have comma separated exponent and modulo in one string. Crypt_RSA has them as separate structure members.
Okey, did you get it to work?
I’ve got all the pieces written, but am having some trouble getting it to work.
I have a PHP programs that use the Crypt_RSA library to generate a key pair, and encrypt authorization strings using the private key. Another PHP program serializes the public key and uses native PHP base64_encode on it to translate it into a string format that I cut and paste into the plugin C++. On the plugin side, I have written and debugged a compatible base64_decode function that is used to decode modulus and exponent and stuff them into part1, and part2 of an RSA object.
Two comments on the Juce RSA object:
-
Crypt_RSA has a static isValid() method that would be nice to have on the Juce side as well. My problem is likely to be lack of understanding of the bit-level details of how Strings become MemoryBlocks become BitArrays, but being able to eliminate the key as the source of error would be appreciated.
-
I changed the Juce source so that RSAKey.part1 and part2 were protected not private, as my approach was to subclass and add a new constructor that takes a base 64 encoded key generated by my PHP program.
I welcome any debugging advice. Should I try something like using 32 bits of data and a 4 bit key in order to be able to work it through the debugger? Any test vectors that would be particularly illuminating? Seems to me that this is probably some sort of endian-ness thing.
Ok, I’ll change those members to be protected. As for debugging, it’s pretty hard to know what to try… I guess using small numbers is a good start, and following the maths operations that it performs on them.
Look at CMake (http://www.cmake.org), which can create the Unix Makefiles you need to compile the application on Linux (or the VS8 project files on Windows, or XCode project files on Mac). Should make life a bit easier.
Speaking of which: Jules, if you’d include CMakeLists.txt files in your distribution, you’d never have to bother with updating build files again 
very interesting tread.
I’m considering using a keyfile with RSA encoding and challenge response to protect my software.
I get it all for the online distributed soft but my problem is that there would be a boxed version as well.
Is it possible to generate a “short” and srong serial with RSA which would be used to connect to the server that send the key file?
Or maintaining a list of valid serials on the server side would be a solution?
Any suggestions?
Yes this is what we do. The “serial” is really only a unique string in the database.
This project has been on and off the back burner for a couple of weeks. I think I am really, really close, as I can decode 2 byte messages perfectly. However, I think I’m bumping up against some endian-ness issues, and am hoping that somebody has been through this before. I’m trying to write a Juce RSA decoder that interoperates with PHP 5 and Crypt_RSA.
I’d appreciate hearing about any lessons learned and/or gotchas associated with sharing BCD/RSA encoded data between PHP/Crypt_RSA and C++/Juce.
Thanks!
OK, so I have my server acting as a “dongle”… what about switching to actual hardware dongles via USB? Does it make sense to use the same challenge / response using RSA keys as I do with the sever? I’m afraid I don’t have much experience with drivers… just curious if the same approach can be used whether the dongle is hardware or internet. For example the hardware would have the private key backed in… and the software would check against that? Or would the hardware open up more secure possibilities?
For my software, I wrote a RSA keygen (which only I own) and so every customer gets a license file from ShareIT (they have the keygen on their servers, it automatically sends the license file via email to the customer).
But honestly, it’s not really a good protection, cause all my software was still cracked after 2 days, by just removing the part in the software that actually checks for the license file.
The only really good protection would be that every single version of the software would be a little different (some kind of watermark) and so one could recognize which customer got which watermark. Because any watermark that has nothing to do with code can be simply removed by comparing 2 different watermarked versions of the same software and removing the difference (that is: the watermark), the watermark would be best somehow “integrated in the code” because then it cannot be removed without destroying the code thus making the application unworkable.
So this would require again making small changes in the source code, recompiling the source code, and then sending it to the customer - so he would really have a unique version that differs from the ones that other customers have. These small changes could for instance be adding bogus executions at random places, that have no effect on the logic of the code, but will make it different on the binary side - so every customer has different binary code in his .EXE or .DLL by which one the producer is able to find out who it belongs to, in case the .EXE is found on the net or even cracked.
This task could possibly be automated on the server side, if the software is bought via credit card or PayPal over Internet. In my opinion, this is the only really good protection, because it is truly not removable.
You will be able to identifiy the source of the leak , but:
- that won’t be a proof that the original buyer is guilty. Maybe his computer was stolen, maybe his email account was compromised, etc.
- what will you do with that name / ip address ? It is very likely that it won’t be someone in the same country as yours, but someone in a faraway country as russia, china, egypt or whatever. Maybe with a stolen credit card. So what actions can you take ?
true, but very unlikely all that! i’m sure that guy would get into massive trouble, because he’s automatically suspect #1 and maybe also the cracker himself, not only the cracker’s supplier.
Would it be difficult to port JUCE’s RSA code to PHP? So it does the same thing? Basically I only need to encrypt a String with a fixed RSA key. I never used PHP, so I don’t know what are the implications…
php’s fairly c-like, though I don’t think it has the integer types that you’d need to make sure the maths was all handled in the same way. I’m sure it’s possible, but probably a bit laborious. When I had to do some webserver crypto I just wrote a mini command-line app to do the encoding, and called it from php.
Thanks. I think I will just use JUCE to do the RSA’ing and put everything in a table in the Database. Yes, PHP is fairly C-like, it was very easy to get results more or less instantly.
This thread has been very enlightening!
However, there are a couple of things I don’t understand (I am rather new to this subject, so I may be being stupid!):
-
Even if the key information has been RSA encrypted, you’ve got to decrpyt before checking it. What’s to stop someone producing a version of the executable with the decrypted (and modified) info already burned into it?
-
You have to rely on OS calls to get the unique information for a particular machine (mac address, sid etc) - won’t these be very obvious and easy to patch to return spoofed information?
You can never stop people hacking your exe - the best you can hope for is to make it tedious enough that they can’t be bothered re-hacking it each time you release a new version…
[quote=“OldSkoolMark”]This project has been on and off the back burner for a couple of weeks. I think I am really, really close, as I can decode 2 byte messages perfectly. However, I think I’m bumping up against some endian-ness issues, and am hoping that somebody has been through this before. I’m trying to write a Juce RSA decoder that interoperates with PHP 5 and Crypt_RSA.
I’d appreciate hearing about any lessons learned and/or gotchas associated with sharing BCD/RSA encoded data between PHP/Crypt_RSA and C++/Juce.
Thanks![/quote]
Hello OldSkoolMark,
Did you finally managed to get it working ?
Thanks,
Salvator
Sorry a newbie with perhaps a stupid question, but why don’t services like Shareit and Paypal provide a service themselves for software vendors to integrate such protection with the product sale? They could then security use the original debit/credit card number for the software purchase as the key for internet activation.
There must be some problem with it, but I’m not sufficient devious in nature to work out what it could be.
All I can think is if the banks don’t offer it as a service, then extended effort in software protection must be a losing proposition, or they’d already be reaping in higher commisions on their services. I may not be devious enough to understand the problem with it, but I’ve been in the USA long enough to know, if financial corporations can make money on something, they do it.