What didn't you understand in my last reply? It is trivial unless I
have misunderstood something.

I guess you got unit tests? Now take the code below. Replace the
download/decrypt code in your unit tests with something like what I
posted previously:

Properties license = new Properties();
license.put("p", TelephonyMgr.getLine1Number());
license.put("d", Settings.System.getString(getContentResolver(),
Settings.System.ANDROID_ID);
license.put("e", aDateInTheFuture);

Then run your unit tests again. Downloading won't fail since we have
_replaced_ the download code, and no decryption would fail, since we
aren't decrypting anything. We replaced that code as well. You don't
even need to find all license check snippets that the developer has
springled his code with, since they all will check against our valid
license that we created above.

I really can't believe that you don't see this. Please tell me in what
way it fails given my description above.



On 23 Juli, 23:07, Al Sutton <a...@funkyandroid.com> wrote:
> We're going to update the page, but we'd kind of assumed it was an
> obvious thing to check.
>
> As for your latest idea, the download code downloads an encrypted file
> so an error would be thrown during decryption which would show up
> problmes with a spoof server or modified download code.
>
> I think you get my point. You may think it's trivial to circumvent,
> but when you get down to it there are various things we've done to
> make it a lot trickier than an initial inspection would make you
> believe, which is why you've still not come up with a reproducable
> system for cracking it. Even if you did crack a version of an
> application, the steps you took wouldn't be easily reproduced for
> other applications and even other versions of the application if the
> developer moved the decryption/test code around.
>
> Al.
>
> On Jul 23, 5:54 pm, Kaj Bjurman <kaj.bjur...@gmail.com> wrote:
>
>
>
> > 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 <a...@funkyandroid.com> 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 <kaj.bjur...@gmail.com> 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 <a...@funkyandroid.com> 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 <kaj.bjur...@gmail.com> 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 <a...@funkyandroid.com> 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 <kaj.bjur...@gmail.com> 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 <mi...@ourmailbox.net> 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 <indodr...@gmail.com> 
> > > > > > > > > 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 
> > > > > > > > > > <medicalsou...@gmail.com> 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
>
> ...
>
> läs mer »
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to