Home page logo
/

dailydave logo Dailydave mailing list archives

Re: Trojan Languages
From: Andrew <munin () mimisbrunnr net>
Date: Fri, 29 Nov 2013 11:29:52 -0500

This is not a thing that LLVM is good at, really, at least not without
some care.

LLVM is "low level" in a way that means specifying integer bit widths.
This could be a problem when attempting to write code that works on 16,
32, and 64 bit platforms. You will go through many gyrations to ensure
that when you need to pass a 32-bit value to a system service, you will.
The language infrastructure won't help you here and you'll fight it.

The language and its infrastructure also isn't a "VM" in the way that
say the java VM is. For example, you will do your own memory management,
either in the code that you write, in the code that you generate, or in
a custom implementation of an LLVM interpreter.

Ultimately, your question of "why isn't this done more" can be answered
succinctly by "writing multi platform code is hard". C is multi
platform, I can write so much C code and build to target x86, arm, ppc,
mips, and weird TI DSPs by just changing stuff in CFLAGS. So why doesn't
every C program run on every microprocessor that we know how to code
generate for?

This is an advantage of python, because the python/java bytecode and
language has few (allowing wiggle room, if there was justice in the
world this should be 'none') places where there are hardware platform
specific concepts expressed. Pointers and references work the same,
multithreading and cache coherence works the same (or just doesn't, ha
ha python), GC works the same. The implementations of python are very
different though, and maintaining python interpreters that work on
ISA/hardware combinations is tricky.

Of course, using a dynamically typed, super-hard to analyze (all the
aliasing problems of C! except instead of a finite-sized integer key
into global memory we can use INFINITELY SIZED string keys into
"memory"! sign me up!) and quirky language
(http://pastebin.com/CB3SZJPK) to write code that is "much more correct"
is also I think playing on "way too hard" mode. Sometimes I think that
people that ask questions like "how do I make my programs fail less
often" should spend less time trying to emulate people that write dating
websites, and more time trying to emulate people who write (er, wrote,
gotta go drink in sadness now) code for the space shuttle...

Anyway, applied programming language technology is hard.

On 11/21/13 17:25, Mohammad Hosein wrote:
are you using the civilian off the shelf Python ? if i was into typical
enterprise pentest or offense biz two questions would be raised immediately
- so the AV people need a tiny addition to their engines to particularly
act out when something smells like python particularly when the calls
are going down like ..the same route , well , since its always the
standard python ?
- isnt this a risk if our adversary finds out a node is active on her
system and grab the thing and use the "forward-thinking technology"
against us or their own favor whatever that is ?

obviously i am asking such "selling-session" standard questions like
most .org/.gov typical customers to hear your technical counter argument
( presuming i am going to learn something , not get iced by a move like
mad men's don draper in the scene where he talks about the candy in the
brothel and what it meant to him -- a ceremony :> )

meanwhile i am going to put this out for folks () dd to hear back : LLVM is
one the wonders of the world . although Duqu developers preferred to
develop code based on their own framework ground up and flame used the
typical lua embed , developing a middleware-style LLVM-based transformer
to produce native code from some .py or .rb for almost any platform -
x86 ..to ..say..  TI's rarely used DSPs - is easy work -- why using this
technique isn't popular in "our circle" ?

-mh



On Thu, Nov 21, 2013 at 1:53 PM, Dave Aitel <dave () immunityinc com
<mailto:dave () immunityinc com>> wrote:

    So as much as Chris tries to drive all of the complexity for
    INNUENDO to the server, I find there's a sort of feature-gravity
    that makes you want to put it onto the client. Even the simplest of
    modules has a big enough state table and complexity that I'm tempted
    to call it a "Behavior" and not a module at all. INNUENDO's client
    is of course running Python, and I wanted to explore WHY for a second.

    Obviously one reason is that Immunity has a ton of Python
    experience. But in trojans, Python is hardly most people's first
    pick for a language. You're hauling 40Mb of code and data with you
    when you want to run somewhere. This isn't ideal for a lot of
    scenarios.

    But you're getting one, *very* important thing when you use Python:

    1. Your most complex code will be a lot less buggy.

    For advanced remote access trojans, you are operating in a
    completely unknown environment and frankly, you may NEVER be able to
    update it or reach it again. Any detection or failure could be
    globally catastrophic. This means your code has to be forward
    thinking in a way that is not typical. So it simply has to be much
    more correct than code usually is. People tend to write complex
    things more CORRECTLY in Python than in Ruby or Lua or
    (Naudhubillah!) C. That reason alone is why the future of remote
    access trojans is embedded Python engines. If you're trying to build
    trojans that have emergent behavior, then you need a language that
    makes that behavior as clear and easy to understand as possible.

    I mean, deep down, I refuse to give any ground whatsoever to the new
    industry of incident response people who just realized how useful
    instrumentation and anomaly detection is. It's time to tool up for
    the challenges ahead! :>

    -dave
    (P.S. You can mess with INNUENDO atINFILTRATE 2014 in Miami
    <http://www.infiltratecon.com/>!)


    _______________________________________________
    Dailydave mailing list
    Dailydave () lists immunityinc com <mailto:Dailydave () lists immunityinc com>
    https://lists.immunityinc.com/mailman/listinfo/dailydave




_______________________________________________
Dailydave mailing list
Dailydave () lists immunityinc com
https://lists.immunityinc.com/mailman/listinfo/dailydave

_______________________________________________
Dailydave mailing list
Dailydave () lists immunityinc com
https://lists.immunityinc.com/mailman/listinfo/dailydave


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault