time
goes up, execution efficiency is reduced' is incorrect, that the
opposite results -- in fact, that's one of the reasons to consider
obfuscation despite the pitfalls -- so I think bad advice is being
handed out with the good here. Another positive is that application
size goes down -- I've never seen nor heard of an exception to that."
Keep in mind that there are obfuscators and there are obfuscators.
Some only replace non-external symbols with shortened ones and maybe
remove any unreferenced methods (which actually deobfuscates to a
degree). They don't really touch the bytecodes. These are reasonable
with regard to performance (reduces class size slightly), but not
particularly effective in terms of stopping a halfway determined
hacker.
Other obfuscators attempt to prevent individual methods from being
decompiled by changing the order of the code, inserting arbitrary
branches and exception handlers and the like. These are a bit more
effective at stopping hackers, though any hacker worth his salt could
figure out how to write a deobfuscator for one of them. I've seen
cases where this sort of obfuscated code takes minutes to verify vs
seconds, due to these changes. Other cases where the JVM just choked
on the class and threw up. (There is a test case out there that I
wrote, known as BigUglyMethod.java -- maybe 100 lines of code. The
folks at Sun likely hate it because it broke their verifier and caused
them a heap of hurt. I got the idea on how to write it by observing
obfuscated code.)
On Aug 2, 11:53 am, Bob Kerns <r...@acm.org> wrote:
> I disagree. It's off topic.
>
> Except for the point about it being harder to decompile Dalvik byte
> codes, but that's just a matter of some tool development work.
>
> And my experience (non-Dalvik, to be sure) is that "Class loading time
> goes up, execution efficiency is reduced" is incorrect, that the
> opposite results -- in fact, that's one of the reasons to consider
> obfuscation despite the pitfalls -- so I think bad advice is being
> handed out with the good here. Another positive is that application
> size goes down -- I've never seen nor heard of an exception to that.
>
> Anyway -- it looks to me like your problems stem from not starting
> from a working ant build and then adding obfuscation.
>
> If you follow the documented approach for creating a new ant build
> project, and then move your code into it, you should have a working
> build virtually out-of-the-box. You can then turn that into a NetBeans
> project or Eclipse project without much trouble, and get the benefits
> of both worlds. Probably even all three is doable!
>
> Then, once you have that working ant build, extend it with an
> obfuscation step. I haven't done that yet -- but having seen how the
> base ant build is generated, I absolutely would not try it without
> first having a solid ant build in place. Then you would not be
> experiencing errors like tasks not defined or missing targets.
>
> The negatives are real, and one is that it will take you some time to
> set it up and get right, and a lot of testing to make sure it's
> right. But I think it will go faster if you start with a blank ant-
> build project, get that solid, and then add obfuscation.
>
> On Aug 1, 3:46 pm, Indicator Veritatis <mej1...@yahoo.com> wrote:
>
> > Pointing out the pitfalls of obfuscation is NOT "moving the thread off
> > topic". For in order for you to understand the answer to your
> > immediate question, "has anyone had success" at it, you have to
> > understand what 'success' could MEAN in the context. And DanH has been
> > quite generous with exactly the background to understanding how
> > limited that success will be.
>
> > On Jul 30, 9:46 am, sblantipodi <perini.dav...@dpsoftware.org> wrote:
>
> > > You are so kind answering me and I really appreciate it
> > > but there are many answers, all are off topic.
> > > I haven't asked if it is good to obfuscate or if I need to switch to
> > > NDK,
> > > I asked if someone succeded obfuscating standard android class using
> > > ant.
>
> > > Please don't move this thread off topic.
> > > Thanks to all.
>
> > > On Jul 30, 5:37 pm, DanH <danhi...@ieee.org> wrote:> Keep in mind that what goes onto the phone isn't Java bytecodes but
> > > > rather the Dalvik translation. Much harder to back-translate than
> > > > bytecodes.
>
> > > > (I've seen obfuscated bytecodes and it's not pretty. Class loading
> > > > time goes up, execution efficiency is reduced, the odds of hitting a
> > > > bug, either in the obfuscator or in the JVM, is greatly increased.)
>
> > > > On Jul 30, 9:11 am, sblantipodi <perini.dav...@dpsoftware.org> wrote:
>
> > > > > Ok, thanks for the suggestions, any other idea? :)
>
> > > > > On Jul 30, 2:59 pm, DanH <danhi...@ieee.org> wrote:
>
> > > > > > Just say no to obfuscation.
>
> > > > > > On Jul 30, 3:36 am, sblantipodi <perini.dav...@dpsoftware.org> wrote:
>
> > > > > > > Since I'm going mad trying obfuscating my projects on Netbeans and
> > > > > > > it's not reasonable
> > > > > > > at the moment for me to switch to Eclipse I need a command line script
> > > > > > > that let me
> > > > > > > build and obfuscate my APK...
>
> > > > > > > Is there some example script, or some tutorial that could help me in
> > > > > > > this "intent"?
> > > > > > > Thanks.
--
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
No comments:
Post a Comment