Re: New Binary Bruteforcing Method Discovered

[<mixter () 2xs co il>]

On Wed, 27 Mar 2002, Michal Zalewski wrote:

> Instead, it seems to dig the binary for potentially
> interesting variable names or option lists stored in .rodata (don't want
> to lie, I didn't examine this code very carefully, can even turn out to be
> a trojan ;-). So I think you are making this claim - "this is my
> technique" - somewhat too early. Unless I am terribly mistaken, but the
> name seems to be pretty self-explanatory.

Turns out this is just one part of the fuzz concept (and ours). Oh and sorry,
sorry, I was far from claiming it as "my technique". :) I can't remember and
know about everything new someone thinks of. In any case, I was just sharing
some personal work experience in using shared libraries for binary testing.

> Hello? I think you do not really understand what I was trying to say - try
> 'Turing "halting problem"' in google.com. Nowadays, the analysis of all
> possible execution paths for any given program (for example to find an
> answer whether certain code will be executed or not, and in what order - a
> critical issue for static, automated detection of dynamic vulnerabilities)
> is excessively time consuming and completely not feasible in most cases.
[...]

I see. Well I'm not a mathematician and don't think like one, but,
I'd say this doesn't require a mathematically perfect solution, just a
logically perfect one. Vulnerabilities are in relation to external input,
and the amount of input functions and the multiple states in which a
program at external I/O can be are somewhat more limited although still
huge... what's related is what I talked about, using shared libs for pre-
reporting (I agree, a simple technique) which in turn helps to document the
external entry points (not always all) and focus on them. Black box testing,
by nature, in any case can't thourougly audit code even if it weren't for that
turing halting problem, only a non-black-box program that disassembles the
code 100% and reads all functions from source . Still, it's a helpful topic,
probably especially for closed-source binaries and on windows via function
intercepting DLLs (technically, I know this can be done.. unless of course
this too has been done before :), and unless it doesn't violate any
random idiotic law).

> Knowing the way to solve the halting problem for infinite Turing machines
> in finite time would very likely enable us to perform this analysis for
> finite machines in no time (and have dramatic implications not only for
> computer security).

Would you say that human beings can theoretically solve this problem as they
can oversee all functions in source code (this problem seems to be a white-box
auditing issue to me...) and hence theoretically extrapolate all states...? If
so, do you think AI could eventually solve the problem...?

-------------------------------
Mixter  <mixter () 2xss com>
Development/Consulting/Research
2xs LTD. - http://2xss.com
Tel: +972-9-9519980
Fax: +972-9-9519982
-------------------------------