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 <[email protected]> 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<http://www.infiltratecon.com/> > !) > > > _______________________________________________ > Dailydave mailing list > [email protected] > https://lists.immunityinc.com/mailman/listinfo/dailydave > >
_______________________________________________ Dailydave mailing list [email protected] https://lists.immunityinc.com/mailman/listinfo/dailydave
