Home page logo
/

dailydave logo Dailydave mailing list archives

Re: Trojan Languages
From: Justin Ferguson <jf () ownco net>
Date: Fri, 29 Nov 2013 17:50:18 -0500

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.

So you load a C program to prevent writing bugs in C? Seems like there
is an exportable idea that doesnt require 40MB of interpreter being
hard-baked in, but I dunno.

People tend to write complex things more CORRECTLY in Python than in Ruby or Lua or (Naudhubillah!) C.

Well the setup is the conjecture of some stuxnet style infiltration
where reliability is requisite. Then the second part is "we have to
pay attention less and debug less if we write it in
$scriptinglanguage", which is sorta an anti-thesis to the first point.
Is Python, Ruby or Lua not written in C? At this point you're trusting
a random assortment of 3rd party developers over your own?

That reason alone is why the future of remote access trojans is embedded Python engines.

If anything, the small footprint and ease of integration seems to lend
itself more to Lua than Python.

 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.

Are airplanes allowed to use python et al in their control systems? Or
is it more or less plain and straight C with a lot of focus on
debugging and verification of the code paths and such?

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! :>

/signed

On Thu, Nov 21, 2013 at 2: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! :>

-dave
(P.S. You can mess with INNUENDO at INFILTRATE 2014 in Miami!)


_______________________________________________
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 ]