[hackerspaces] Post Compiling Binary Obfuscation

[Tim Krabec]

Correct, most packed binaries are malware.  I'd put some language in the
AUP/License about decompiling the code, it might not help much, but could
give you some legal grounds in the future.

On Fri, Jul 10, 2009 at 4:21 AM, astera <astera at hackerspaces.org> wrote:

> Hey Eric,
>
> this note may be redundant already, for Enki's wizardry in this field
> of expertize is extensive.
> A packer tool (like Armadillo, for example) is definitely the most
> obvious way to go. However, whether you know when unpacking has
> finished or not while running your application, a debugger will
> definitely tell you, so you could dump the whole decrypted binary out
> of memory...
>
> One combating technique would be to have your app run a debugger at
> all times (where your machine wouldn't allow you to run another
> debugger); or you could have it run inside an x86 emulator.
>
> Though the packer approach might be the most common one, keep in mind
> that - depending on which product you use - anti-virus software might
> throw alarming messages at the user (since this also is the way to go
> when distributing your piece of beloved malware).
>
> Hack on,
> /astera
>
> On Jul 10, 2009, at 12:06 AM, Paul Böhm wrote:
>
> > which os? which languages? a few years back (2002) we released the (to
> > our knowledge) first ELF binary encrypter (the binary format on a lot
> > of unixy OSs). search for teso burneye - but by now there are generic
> > unpackers for it. there's a lot more knowledge in the windows world
> > about how to do this (packer/unpacking are the keywords and it's
> > become an art of its own) - the essential hard part is that you never
> > wanna keep the whole binary unencrypted in memory or it can be easily
> > (more or less) retrieved from there. if you just wanna fool existing
> > tools, you just need to avoid to give indication that the unpacking
> > has completed (the program should already be running, and the unpacker
> > should just believe it's still the packer that is running). as for
> > dynamic languages your best bet is modifying the intermediate
> > representation and the interpreter (e.g. the .pyc files for python) -
> > possibly protecting the binaries of your own interpreter with the
> > binary packing techniques.
> >
> > enki
> >
> > On Thu, Jul 9, 2009 at 2:35 PM, Eric Michaud<eric at hackerspaces.org>
> > wrote:
> >> Hey Guys and Gals,
> >>
> >> I had a interesting question posited to me recently at the space
> >> about
> >> obfuscating binaries.
> >>
> >> So the example would be.
> >>
> >>
> >> I have a binary I'm going to distribute. I know it'll eventually get
> >> reversed, but what I'm asking is how can I make it take longer
> >> without
> >> having to rewrite my code with the intention of obfuscation from the
> >> beginning.
> >>
> >> I'm happy to fill in more if any of you have questions, but I'd
> >> love to hear
> >> your thoughts.
> >>
> >> -E.
> >>
> >> _______________________________________________
> >> Discuss mailing list
> >> Discuss at lists.hackerspaces.org
> >> http://lists.hackerspaces.org/mailman/listinfo/discuss
> >>
> >>
> > _______________________________________________
> > Discuss mailing list
> > Discuss at lists.hackerspaces.org
> > http://lists.hackerspaces.org/mailman/listinfo/discuss
>
> _______________________________________________
> Discuss mailing list
> Discuss at lists.hackerspaces.org
> http://lists.hackerspaces.org/mailman/listinfo/discuss
>



-- 
Tim Krabec
Kracomp
772-597-2349
smbminute.com
kracomp.blogspot.com
www.kracomp.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.hackerspaces.org/pipermail/discuss/attachments/20090710/60f32b94/attachment.htm