Shouldn't the code on the page say that in that case, and it's still
very easy to spoof. Replace the code that downloads the certificate
and encrypts it with code that does this:
Properties license = new Properties();
license.put("p", TelephonyMgr.getLine1Number());
license.put("d", Settings.System.getString(getContentResolver(),
Settings.System.ANDROID_ID);
license.put("e", aDateInTheFuture);
..
..
and so on.
I think you get the point. We have enabled all settings. Remember I'm
not a hacker/cracker and I have already shown you that it's very easy
to crack your system. You aren't protecting the code. Applications
will still be pirated very easy, and it's even possible to write an
application that does it automatically.
Users of the applications will also be very frustrated if they for
some reason can't contact your license servers, so the value that you
are adding is about zero.
On Jul 23, 5:38 pm, Al Sutton <[email protected]> wrote:
> And doing what you say should cause the application to operate as if
> no license is present (i.e. demo mode).
>
> The demo code is to cover all bases for all types of license where the
> properties in the license are unknown. If you know that you'll be
> using a specific license property your app should enter demo mode if
> that property isn't present.
>
> Al.
>
> On Jul 23, 1:45 pm, Kaj Bjurman <[email protected]> wrote:
>
>
>
> > Sorry to say, but there's a huge flaw in your examples. The snippet
> > below is taken from your link:
>
> > X509EncodedKeySpec keySpec = new X509EncodedKeySpec
> > (ANDAPPSTORE_APP_KEY);
> > KeyFactory factory = KeyFactory.getInstance("RSA");
> > PublicKey key = factory.generatePublic(keySpec);
> > Cipher cipher = Cipher.getInstance("RSA/ECB/PKCS1Padding");
> > cipher.init(Cipher.DECRYPT_MODE, key);
> > byte[] original = cipher.doFinal(LICENSE);
>
> > Properties props = new Properties();
> > props.clear();
>
> > ByteArrayInputStream bis = new ByteArrayInputStream(original);
> > try {
> > props.load(bis);
>
> > } finally {
> > bis.close();
> > }
>
> > Very few classes are using using e.g X509EncodedKeySpec, so it's very
> > easy to find all classes that are using it, and it's thus very easy to
> > find that section of code. Now replace all operands in the class file
> > with no operation instead, except this part:
>
> > Properties props = new Properties();
>
> > I.e. we are creating an empty license.
>
> > Now read all your other code snippets with this in mind.
>
> > E.g.
>
> > 4(c)(i). Testing the phone number
>
> > String licensePhoneNumber = license.getProperty("p");
> > if( licensePhoneNumber != null ) { //Uh, uh. An empty license
> > returns null, we won't do any checks.
>
> > TelephonyManager TelephonyMgr =
> > (TelephonyManager) getSystemService(Context.TELEPHONY_SERVICE);
>
> > String devicePhoneNumber = TelephonyMgr.getLine1Number();
>
> > if(licensePhoneNumber.equals(devicePhoneNumber) == false) {
> > throw new RuntimeException("** Phone Number Check Failed **");
> > }
>
> > }
>
> > Remember that license now is an empty instance of Properties. The code
> > above will say that it is a valid license, and so will all of your
> > other tests as well.
>
> > On 23 Juli, 12:11, Al Sutton <[email protected]> wrote:
>
> > > We don't provice jars specifically for this reason.
>
> > > The code to decode a license is less than 15 lines long and uses
> > > standard java classes (i.e. nothing specific to the system or even to
> > > Android). The code to test license properties is less than 10 lines
> > > and again uses only java classes. You can see the code
> > > athttp://andappstore.com/AndroidApplications/licensing_4.jsp
>
> > > This means that each application would need to go through a full
> > > track, crack, and re-compile cycle (which as others have said is non-
> > > trivial and takes a fair amount of time), and developers are free to
> > > move the decrypt/test code around between versions of their app which
> > > would then require another full track, crack, and re-compile cycle
> > > before the new version could be made available, which, for a 99c app,
> > > is not going to be worth the effort for most crackers.
>
> > > This part is security by obscurity but it's layered in with secure
> > > cryptography in the license as an addition measure to make cracking
> > > harder than if we distributed pre-build jars which a cracker could
> > > swap out.
>
> > > Al.
>
> > > On Jul 23, 7:24 am, Kaj Bjurman <[email protected]> wrote:
>
> > > > Case 2 doesn't hold. It's still a bit of "security by obscurity".
> > > > There are several ways to remove what you describe. One way would be
> > > > to run the program in the emulator/debugger and see where it fails.
> > > > Then check what that method does and correct the logic. Run it again
> > > > in the emulator to see if it still fails, then patch the next place.
> > > > This is usually how programs written in other languages are cracked.
> > > > (E.g. written i C/C++). Cracking in those cases is usually done in a
> > > > debugger for assembler.
>
> > > > What I described in the scenario above is where they aren't using any
> > > > code from you.
> > > > I don't know what your code look like, or what it does. But I still
> > > > guess that you have classes that others can use. It's in that case
> > > > pretty easy to stub those classes out, and cracking all programs in
> > > > your market would in that case mean that they just have to find out
> > > > how your protection works, stub out code from you, and then apply it
> > > > to all programs.
>
> > > > Note that I'm not a hacker/cracker, but I'm curious, and I have myself
> > > > tried to protect programs.
>
> > > > On 22 Juli, 19:58, Al Sutton <[email protected]> wrote:
>
> > > > > That form of approach is one of the main reasons the AndAppStore
> > > > > system can download an encrypted license to the device which can be
> > > > > stored and decrypted as neccessary. This means developers can;
>
> > > > > 1) Occasionally check the license is still valid by retrying to
> > > > > download it, and if it doesn't download due to a network/server error
> > > > > the app can use the locally cached copy.
>
> > > > > 2) Because the client code is open developers can embed it wherever
> > > > > they want in their program logic as opposed to being a single library
> > > > > which can be stripped out and replaced with an "always return true"
> > > > > version.
>
> > > > > 3) Detect spoof servers because a spoof server will be unable to
> > > > > return a properly encrypted file and thus developers can detect
> > > > > decryption errors and mark them as spoofing attempts.
>
> > > > > Al.
>
> > > > > On Jul 22, 6:50 pm, Kaj Bjurman <[email protected]> wrote:
>
> > > > > > Correct, Removing the part that makes the requests, and just return
> > > > > > "true" is what people usually are doing.
>
> > > > > > On Jul 22, 5:01 pm, Micah <[email protected]> wrote:
>
> > > > > > > The pirates will either strip out the licensing requests from the
> > > > > > > application or they will spoof a licensing server. Meanwhile,
> > > > > > > your
> > > > > > > legitimate users can't use your application when they don't have
> > > > > > > access to the licensing server (it's down, they don't have
> > > > > > > internet
> > > > > > > access, etc.).
>
> > > > > > > On Jul 22, 7:55 am, Android Development <[email protected]>
> > > > > > > wrote:
>
> > > > > > > > Maybe an activation licensing key for each binary may be the
> > > > > > > > solution for
> > > > > > > > this. But then again, its easier said than done.
>
> > > > > > > > On Wed, Jul 22, 2009 at 8:20 PM, Moto <[email protected]>
> > > > > > > > wrote:
>
> > > > > > > > > I know that piracy will never end, I mean I'm a solo
> > > > > > > > > developer trying
> > > > > > > > > to fight a war that multi-million companies have spent many
> > > > > > > > > millions
> > > > > > > > > on protecting their content and still they get pirated...
>
> > > > > > > > > Well yes there could be some ugly side effect if google adds
> > > > > > > > > more anti-
> > > > > > > > > pirating features, so I guess I'm not too much for that...
> > > > > > > > > But I
> > > > > > > > > believe there could be a better Android Market system that
> > > > > > > > > allows
> > > > > > > > > anyone with a phone to purchase an app and put it on their
> > > > > > > > > SDcard.
> > > > > > > > > Why not do the following?
>
> > > > > > > > > 1. User purchases app via Android Market.
> > > > > > > > > 2. Phone sends unique ID IME? to server.
> > > > > > > > > 3. Android Market server prepares application with encryption
> > > > > > > > > according to given phone information.
> > > > > > > > > 4. Application downloads to phone. "put it anywhere, SD
> > > > > > > > > card.. etc..."
> > > > > > > > > 5. Application only installs on the correct phone.
>
> > > > > > > > > I know this method would soon or later be hacked but it's a
> > > > > > > > > better way
> > > > > > > > > than current methods, since we still have those faulty
> > > > > > > > > Android version
> > > > > > > > > that allow rooting..
>
> > > > > > > > > -Jona
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
