Re: [ATTN POOH CAT] The real Exevalid story

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

Quoted text here. Click to load it

Dustin you wrote..... "ASIC integers will go negative if they exceed  
32767. So of course ABS is a good quick and dirty fix for this  
issue"  

You forgot to say that your recommendation to use ABS changes the
value of the number you're testing!  

What's the use of getting rid of the minus sign if you get
completely the wrong number?  Just wondering!  

--  
Jax        

Re: [ATTN POOH CAT] The real Exevalid story

Jax used his keyboard to write :
Quoted text here. Click to load it

If you go one more than 32767, you get 32768 from the ABS function, so  
using ABS gets you one more correct value than not using it does.



Re: [ATTN POOH CAT] The real Exevalid story


Quoted text here. Click to load it

Rafty what if you go *two* more? What happens then? Just asking.

--  
Jax        

Re: [ATTN POOH CAT] The real Exevalid story

After serious thinking Jax wrote :
Quoted text here. Click to load it

Well, then the error starts to make gradually more and more difference.  
As long as the range of input values is smaller than where the  
differences start to have impact, then it is a valid way to do the  
calculations. If your input values might occasionally exceed the 'safe'  
limit - then you will want to assure that the error is on the 'safe'  
side, as the program does by having the error cause the 'exe' to be  
retained rather than discarded.



Re: [ATTN POOH CAT] The real Exevalid story

On Fri, 06 Jun 2014 12:09:55 -0400, FromTheRafters wrote:

Quoted text here. Click to load it

Hasn't all of this already been explained quite some time ago, FTR?



--  
None are so hopelessly enslaved, as those who falsely believe they  
are free. The truth has been kept from the depth of their minds by  
masters who rule them with lies.  
-Johann von Goethe  

Re: [ATTN POOH CAT] The real Exevalid story

@news2.open-news-network.org:

Quoted text here. Click to load it

Ayep. quick and dirty, as I said originally. Works fine, in most cases for  
the intended task. Something like Upack wouldn't make any difference in the  
math calculations as it's monkeying with the header information. Both  
versions of exevalid can be "tricked" by this. ALL of poohs demos can.



--  
Take it easy... Don't let the sound of your own wheels drive you crazy.  
Lighten up while you still can. Don't even try to understand.  
Just find a place to make your stand and take it easy!


Re: [ATTN POOH CAT] The real Exevalid story


Quoted text here. Click to load it

Nope. The more accurate/less accurate math routines couldn't avoid  
something like upack or anything else monkeying with the header  
information. Both math routines expect the header information to contain  
valid data. The ABS method works fine on files of a normal size, well into  
the 16megabyte range. You don't *need* accurate maths to the byte for files  
larger; they aren't going to be culled with exevalid anyway. They're far  
too big to just dismiss. They'll be analyzed.



--  
Take it easy... Don't let the sound of your own wheels drive you crazy.  
Lighten up while you still can. Don't even try to understand.  
Just find a place to make your stand and take it easy!


Re: [ATTN POOH CAT] The real Exevalid story


Quoted text here. Click to load it

Dustin your description of "inaccurate" doesn't do Exevalid's awful  
arithmetic justice. Exevalid is wildly wrong on any files that are  
larger than 32767.... and there's an infinite number of them!

Your so called "ABS method" isn't needed on files below 32767 and is  
incorrect on files about 32767. Jax says.... think about it!

--  
Jax        

Re: [ATTN POOH CAT] The real Exevalid story


Quoted text here. Click to load it

Rafty what a bizarre arguments You and Dustin are like two school  
boys conjuring up the craziest excuses in the hope that no one will  
realize how crazy they are!

If we apply your argument that Exevalid is on the 'safe' side then  
Dustin may as well make Exevalid score *all* files as exes. Then he  
would need a correctly functioning program to determine what  
Exevalid could not. LOL.

Also don't forget that there are more numbers above 32767 than below  
it. Which means there are more exes for which Exevalid will  
calculate the wrong file size than those it will calcuate the right  
file size.

On both counts Exevalid fails badly. Despite all yours and Dustin's  
spinning, the program is a crock!

--  
Jax        

Re: [ATTN POOH CAT] The real Exevalid story

Jax has brought this to us :
Quoted text here. Click to load it

If you assume that it is supposed to work on the set of all numbers  
instead of what it was written for (typical valid DOS MZ malware file  
sizes) then of course there will be word overflow considerations. These  
will not just go away by using double-words or quad-words, you just put  
the errors further and further up the number line that way, while the  
issue remains. The way around this is to start using exponential  
notation representation which will eventually also introduce rounding  
errors. Programs are written for a specific task, taking them out of  
context is not a valid way to critique them.

Quoted text here. Click to load it

I did a search for exes on my system (these are mostly PE files and not  
relevant to this discussion) just to see the typical sizes. I had only  
five exes large enough to cause an error, and as these are PE files  
which are often larger than the DOS MZ files it can be assumed that the  
vast majority of MZ malware files would not even come close to  
introducing an error. The size value of the largest malware to date  
might even fit three or four times in the word sized representation.

Quoted text here. Click to load it

Perhaps, but you are wrong about why.



Site Timeline