• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Product ID

 
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, all!
I have task to do like that: We have Java API and Product wich
uses this Java API. In Java API and products we should have
product ID, but it should be different. So how can I achive that
in compile time (there is no #def in Java 1.3)? I've got idea
of abstract class and 2 classes that extend the abstract, but
contain different Product ID, but this way is run time and we
need compile time.
Any ideas are welcome.
Thank you in advance.
Alex Givant.
 
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Any static final variable is treated much like a C #define, i.e. its value is substituted in-place. So you can generate a little three-line classAnd the value will be substituted in-place wherever you use it. I believe (but am not sure) the application will even run properly if you don't include the class.
- Peter
 
Alex Givant
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, Peter!
It's not exactly what I need. We already have this definition in
API, but for product we want to define other product ID, so I
should take API that already contains product ID and somehow
change it to other one. The only way that I see for compilation
time is to exclude the class with Product ID from compilation
when the API will be used with other product and include if we
what to deliver standalone API.
Any other ideas?
Alex.
 
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Make your ProductID such that it can hold dynamic data. The data might come from a database that you use or from a file generated at product install time. When the ProductID class is invoked, that class will read the ID from the file or from database.
Hope this solves your problem.
 
Peter den Haan
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Maybe supplying a serialized ProductID object would work?
- Peter
 
Alex Givant
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Let's me to explain it more in details: The exact idea is to
have some product ID and prevent customer from changing it (like
taking the ProductID class out of JAR, decompiling it, creating
new ProductID class and put it back to JAR).
So we want to be sure that customer uses all the time *our*
ProductID class. It's possible to create MD5/SHA1 hash in
manifest file, but my question how it'll be used? I know how it
use when you have signed JAR that contains applet, but what are
rules for application.
The only way that I see right now is to use some obfuscator, so
if anyone could recommend the good one, it'll be appreciated.
Thank you in advance, guys.
Alex.
 
Peter den Haan
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ah. Now I'm clear
One way to do it would be to use a SignedObject. To create one, you start by generating a key/certificate pair in the Java keystore using keytool. Then you create the product ID, store it inside a SignedObject and serialize it:This code would run for every copy of your application, producing a serialized signed object (productId.ser) for inclusion in the application jar. To verify,The verify() step will throw an exception if the object has been tampered with. But where do you get the values for y, p, q and g, you may ask? These are the four (large) numbers that characterise your DSA public key. You hardwire them into your application so that someone else's signature won't work (short of decompiling classes etc). To obtain them, open your KeyStore as in the first code snippet and doYou'll only have to do this once, after generating your key pair.
None of the above is tested, so YMMV.
I've been thinking if you could achieve the same thing simpler with a sealed, signed jar. You must defend yourself against someone unjarring the thing and constructing a modified jar with a different signature and more nasty tricks like that. To verify the certificate, you could open the jar directly and use JarEntry.getCertificates(), but that might get ugly. Alternatively, you examine the signer(s) of your classes' protection domain (object.getClass().getProtectionDomain().getCodeSource().getCertificates()) and verify that the certificate is correct. But then you still have to verify that the sealing is intact, and it gets messy. I've got the feeling that I'm missing something here but maybe someone else can help out.
- Peter
 
reply
    Bookmark Topic Watch Topic
  • New Topic