Home page logo

dailydave logo Dailydave mailing list archives

Re: Trojan Languages
From: Mohammad Hosein <mhtajik () gmail com>
Date: Thu, 21 Nov 2013 16:25:40 -0600

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" ?


On Thu, Nov 21, 2013 at 1:53 PM, Dave Aitel <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! :>

(P.S. You can mess with INNUENDO at INFILTRATE 2014 in Miami<http://www.infiltratecon.com/>

Dailydave mailing list
Dailydave () lists immunityinc com

Dailydave mailing list
Dailydave () lists immunityinc com

  By Date           By Thread  

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