Re: Encoding hacker total quality management

[Steve Lord <steve () buyukada co uk>]

Dave Aitel wrote:

> Today, in addition to various running-the-company tasks, I'm writing a
> specialized encoder/decoder. When you're writing decoders you become
> (unless you're me, cause I'm stupid in this way :>) very concious about
> the "size" of the decoder in bytes, and how much your encoded shellcode
> is bigger than your decoded shellcode.
>  
Some of the tiny demos on scene.org do some whizzy tricks to get the job 
done, and it's fascinating to see things from people who seem to spend 
all their time squeezing as much into 64/128/512/1024 bytes as possible. 
You might want to look there for inspiration, or just the whizzy effects.

Have you considered compressing your shellcode? I guess it depends on 
the goal, but a simple compression algorithm might be able to reduce 
your size considerably if planned out. Mind you, if your shellcode is so 
big that it needs compressing, then I guess you have a whole load of 
other problems ;)

> Size is a weird thing. I've always been a bit obsessed with the
> "ADM/TESO/GOBBLES[*]" effect. One of the claims of GOBBLES was that they
> were the "largest" hacker group. After apache-nosejob.c this isn't hard
> to believe, seeing as they managed to outsmart the best of the time,
> while still making a joke about it. That sort of sploit isn't something
> you drop unless you have some things that are a lot better in your cache.
>  
I think it depends on the group dynamic. IIRC ISS were up on a very high 
horse at the time with the way they handled things, and GOBBLES always 
appeared (at least to me) to be very anti-security vendor in 
orientation. Maybe it was just too big an opportunity to miss?

> Another datapoint: ADM and TESO made almost inapproprietly large spashes
> in the community when they were active. Almost all their exploits were
> beyond the standard, and at times it seemed they were the ones finding
> all the new bug-classes. But at their peak, they couldn't have been very
> large groups. Certainly smaller than the reverse engineering and
> security group at a good sized IDS/IPS company these days.
>  
I think a lot of it again depends on the group dynamic. Larger groups 
tend to have factions within them, smaller groups tend to work better at 
functioning for the good of the group as a whole. As much of a waste of 
time it is, the Big Brother TV series seems to illustrate this idea 
really well, although I guess nobody voted members of ADM out each week 
until there weren't any left. Another thing to compare with is the way 
the company works. A company with a strong hacker ethic will probably 
knock out far much more interesting stuff than a fully corporate borg 
type organisation. Apples Skunkworks and @Stake's research teams spring 
to mind. A more corporate organisation with much larger teams and more 
rigidly defined scopes for research (such as those at Microsoft) 
probably churn out more directly relevant and commercially viable 
research, although this is a completely subjective opinion and I could 
be utterly wrong about this.

> Looking at a status message I sent to Immunity yesterday, everyone had about
> three exploits on it, in active development. You just can't get that
> level of performance when people are sitting in an office checking on
> the stock price and getting free soda. And you can't maintain it for 3-5
> years, which is how long most hacker groups last before merging,
> disolving, and reforming. (Although I think Immunity will be around for
> a lot longer. :>)
>  
Hey, don't knock free soda! Remember code red? Ok, erm... well we all 
know how that turned out, maybe you're right after all about the soda :)
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
https://lists.immunitysec.com/mailman/listinfo/dailydave