base64 encode is only a transmission tool to slip over ascii lines ~ we have some general approaches here which could lead to useful ideas but any implementation as strong as jarsigner and keytool has built in power that can be applied to the work at hand - though I would dismiss reports of LVL being busted as what they are talking about (usually) like when my new hero Diane Hackborn hero speak of crypto / cracking: cracking there can sometimes be 90 years instead of 91 years to bust it or something as the rule there is author did not disclose some weakness in professional papers - they are not taking about F.P.G.A. on somebody's lappie passwords ...duh, Masters Thesis Candidates with liquid nitro flasks where the rest of us might carry a handheld used to do nasty things with the nitro and stuff like that If your app has to go to a server you can keep writing code on enough checks can be put in ..... depends a lot on where the app has to run and whether it is actually worth busting as in a 4.2 billion dollar market of games and social with everything else dominated to near total oblivion on raw numbers then a commercial based app can force the issue with - "look, we have to have these controls to protect our ( and your ) legitimate work" any business who wont sign off on that is bye-bye right there as you don't need them for gaming and social what's the point: see don lancaster case against patents first off anyone who can take an app apart and modify it then put it back together could do it cheaper faster and better from new work -- so if someone is doing this then it is a cheat they got from someone a lot smarter than they are another thing is LVL uses work based on jarsigner and keytool those give powerful checks that can be run at load time and is just more work adversary has to defeat so then if it is there it provides places to work like check something in the xml / bundle or whatever we have an obvious approach if there is something attacker has to modify to cheat the run Arriving at detection has to go along the lines of shipping License Checker over AES-Obfuscator running as a lower priority thread ( which could inadvertently result in a user being denied access to an application that they have legitimately purchased ) then using that with LVL which uses 2048-bit RSA public/private key pair to ship the LicenseChecker.checkAccess() it would seem some sort of approach based on what the attacker would have to modify would ultimately arrive at at security model upon which you could get something useful done ~ if there is something that has to be a certain way or the thing wont run and then modifier ( attacker ) can only pilfer by changing those and you can at least make good guesses what they are then we have a place to start and would be much better if those load-checks could run asynchronous on a Service rather than throwing ANR from Activity onLoad() ( which is the way they have it in samples - totally f-'n wondur.puppy code ) As Nikolay Elenkov suggests it's Message Digest of which SHA-256 is "the next great thing" and costs nothing more to use in fact SHA-512 even runs faster on 64-bit machines than SHA-256 due to alignments on boundaries issues and can be placed directly in the source code without disclosing anything except the call-chain to get to the check which could figured with some debugger tool the wicked part about it is if it is worth busting then subject is nasty ( to say the least ) [CUE:]( "lon chaney phantom of the opera" ) first rule of thief is don't do any work and if not then it is a weakness in your own work that needs to be fixed anyway I could write this just for screw-off have some fun while drinking coffee waking up if you can give me about 1-K of whatever to work from = say for example List<String> or Map<String,String> or byte[].length > 512 I have some code that I wrote for a GUI designer as a Gist at Git Hub on https that may have some ideas or useful tidbits butcha gotta promise not to make fun of my comments in it .... I was screwin off as it seemed rather simple and obvious Nick
On Nov 10, 9:06 pm, Chad Ata <chad...@gmail.com> wrote:> Ah, ok - I like this approach =]> I'm a bit fuzzy on the implementation details, but I think I can figure> this out.> > Thanks!> -Chad> > On Thu, Nov 10, 2011 at 6:56 PM, Nikolay Elenkov> <nikolay.elen...@gmail.com>wrote:> > > > > > > > > On Fri, Nov 11, 2011 at 11:45 AM, Chad Ata <chad...@gmail.com> wrote:> > > Thanks for the response Nikolay,> > > > I was hoping to avoid server-side checks because I don't want potential> > lag> > > or bugs to affect the legit users. But I'll consider your suggestion if> > this> > > becomes a big problem for us.> > > You could embed the hash as a resource with a non- obvious name,> > and tripple-base64 encode it for extra fun if you don't want to use a> > server. If they are changing/modifying your resources, it might be> > better to store bits of it in code and calculate it dynamically> > though.> > > --> > You received this message because you are subscribed to the Google> > Groups "Android Developers" group.> > To post to this group, send email to android- develop...@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 On Nov 10, 9:06 pm, Chad Ata <chad...@gmail.com> wrote: > Ah, ok - I like this approach =] > I'm a bit fuzzy on the implementation details, but I think I can figure > this out. > > Thanks! > -Chad > > On Thu, Nov 10, 2011 at 6:56 PM, Nikolay Elenkov > <nikolay.elen...@gmail.com>wrote: > > > > > > > > > On Fri, Nov 11, 2011 at 11:45 AM, Chad Ata <chad...@gmail.com> wrote: > > > Thanks for the response Nikolay, > > > > I was hoping to avoid server-side checks because I don't want potential > > lag > > > or bugs to affect the legit users. But I'll consider your suggestion if > > this > > > becomes a big problem for us. > > > You could embed the hash as a resource with a non-obvious name, > > and tripple-base64 encode it for extra fun if you don't want to use a > > server. If they are changing/modifying your resources, it might be > > better to store bits of it in code and calculate it dynamically > > though. > > > -- > > 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 -- 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
