Re: combinations of 4

["Michael Greenberg" <greenberg () nji com>]

On 8 Apr 2002 at 15:27, Valdis.Kletnieks () vt edu wrote:

> On Sat, 06 Apr 2002 17:01:59 PST, KF <dotslash () snosoft com>  said:
> > I am in the process of archiving power pc instructions that do not
> > contain null... I have come to the decision that if I could generate a
> > list of all possible unique 4 char combinations for a given list of
> > alpha numeric chars then I could quickly sort the rest out in gdb...
>
> Many people have posted various nested-for-loop solutions, without
> actually *thinking* here.  Note the following:
>
> 1) "do not contain null" - that's *different* than "A..Z".  There's a
> *lot* of instructions that contain non-printable non-null characters.
> Most of them, in fact.  For a 32-bit instruction, there are 2^32 (or
> 4,294,967,296, of which 4,228,250,625 (or 255^4) do *not* contain nulls.
> Only 66,716,671 (or about 1.5%) of all possible 32-bit instructions *DO*
> contain a null.

While your other comments are insightful (and incredibly interesting), 
I believe KF intended to simply insert all of these generated sequences 
into a call to __asm__() or a similar function and then 'sort the rest 
out in gdb', that is, see what calls were valid.  While your method 
will get you better results, isn't a kludge, and will probably work 
while his will not, that's not quite what he was asking.

As a good deal of x86 shellcode goes around, it would be interesting to 
see a compiled list of null-free opcodes for various architectures.  
Buffer overflow code, however, tends to be exceedingly unique to each 
attack.  'Default code' -- for instance, Aleph Null's code -- is quite 
common for attack vectors that place few restrictions on the input 
buffer.  What would perhaps be most constructive would be a 'blue card 
database', wherein opcodes and their various properties could be 
codified and searched for.  Of course, I don't plan on writing such a 
thing (lacking unilateral knowledge) and can't think of anyone who 
would.

HTH,
Mike.