Re: Dustin fess up or you're fired. I asked for you to post tighter source than mine, and ... - Page 5

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

Threaded View

Re: Dustin fess up or you're fired. I asked for you to post tighter source than mine, and for it to be on my desk this morning. You have one hour.


Quoted text here. Click to load it

Not much point in answering your questions then, as if you had been reading  
as things went, you'd already know what's been going on.  


--  
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: Dustin fess up or you're fired. I asked for you to post tighter source than mine, and for it to be on my desk this morning. You have one hour.


Quoted text here. Click to load it

Partially true. I didn't ask for comments, I asked if you could tell me
what exevalid was doing. You sholdn't need to google for the MZ exe
structure, you'd told us all how much of an IT pro you are.  

Quoted text here. Click to load it

chums? tried? c'mon, rewrite history if you want, but the fact is, you
were shown some simple source code and asked if you could tell us what it
did. You could not do so.  

Quoted text here. Click to load it

Actually, since ASIC doesn't use unsigned integers; to it, they can. Hence
the need for the ABS command. to ensure the rest of the math routines only
saw a positive number. FTR brought that to your attention when he showed
you the asic.doc file timer demonstration command and source code.  

 This statement will retrieve a timer count from the PCs hardware
 circuitry.  
     The timer count will be placed in number1.  The timer count is in
     "clock ticks".  A "clock tick" occurs in the PC approximately 18.2
     times per second.  The PC is continually incrementing this clock
     counter.  This statement can be used to time the duration of events.

     Example:

          CLS
          PRINT "PRESS A KEY"
          STARTCNT&=TIMER
     LOOP:     X$=INKEY$
          IF X$="" THEN LOOP:
          ENDCNT&=TIMER
          ELAPSED&=ENDCNT&-STARTCNT&
          ELAPSED&=ABS(ELAPSED&)
          ELAPSED&=ELAPSED&/18
          PRINT "IT TOOK YOU APPROXIMATELY";
          PRINT ELAPSED&
          PRINT " SECONDS TO PRESS A KEY"

     The above code fragment will time how long you wait to press a key
in  
     seconds.  You could modify it easily to display in clock ticks, which
     would provide much more accuracy, if you deleted the statement which
     divides the ELAPSED count by 18.

     Comments:

     Note that it is necessary to use the absolute value of ELAPSED&
since the  
     clock counts is stored as unsigned integers.  ASIC integers, on the
     other hand, are signed.  If number1 is a long integer variable, then
     TIMER retrieves the full PC timer value.  However, if a normal
     integer variable is specified as number1, then ASIC retrieves the
     least 16 significant bits from the PC timer.



Quoted text here. Click to load it

That's right, FTR pointed out why ABS had been used; you didn't know and  
just wrongly assumed How asic handled things. Your program to prove it  
didn't turn up the 8000h aspect, I provided demo source code prior that  
demonstrated it existed; You thought at the time ASIC was Poo or something  
and didn't know what was going on. I can find the post if you've forgotten  
it. :)

Fact is, when you removed abs, you broke the program and you spent days  
trying to figure out what was going on with asic as a result. You didn't  
know ANYTHING about the way ASIC treats integers. When you did figure out  
what was going on, with FTR and myself assisting, you wrote another "demo"  
that seperates low/high integers and claimed it was original, that you're  
the only one to have done it. But, you did it very sloppy and wasted alot  
of bytes. So I told you how you could have done it and not wasted so much  
code. You wanted to play games and you moved the goalposts to see who could  
make the smallest "demo".

The question originally asked of you was could you tell me what exevalid  
was doing with an exe you fed it or not. And you couldn't. You've deflected  
around that from day one.

Quoted text here. Click to load it

A bit of a learning curve for you.
  


--  
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: Dustin fess up or you're fired. I asked for you to post tighter source than mine, and for it to be on my desk this morning. You have one hour.

Quoted text here. Click to load it

Dustin... in other words Exevalid doesn't work on large files. That's  
definitely not very good.

The other flaws make Exevalid prone to making more errors.

--  
Jax    :)

Re: Dustin fess up or you're fired. I asked for you to post tighter source than mine, and for it to be on my desk this morning. You have one hour.

On 5/11/2014 12:54 PM, Jax wrote:
Quoted text here. Click to load it
How do you know?  You've admitted, several times, that you don't  
understand this stuff.


Re: Dustin fess up or you're fired. I asked for you to post tighter source than mine, and for it to be on my desk this morning. You have one hour.

127.0.0.1:

Quoted text here. Click to load it

What part of, It's not supposed to be run against multimegabyte files  
wasn't clear the first ten times or so I've mentioned it? Most likely, as  
long as abs is present (and it is in exevalid 1), the blocksize will be  
smaller than the file on disk; which exevalid doesn't concern itself with.  
Smaller is okay, bigger would be an issue. EXEVALID would think pieces are  
missing when they aren't.  

The abs method does have a fatality condition tho where it cannot change a  
negative number to a positive one like it should, or get the least  
significant 16bits. And that's when the integer range is invalid. IE: it's  
holding -32768 in a normal ASIC integer. The low/high integer seperation  
Pooh is doing resolves that issue, but doesn't address the flaw all  
versions of exevalid have.  

It addresses an accuracy issue that I didn't care about, and a fix for a  
bug Pooh didn't know about, until I provided source code demonstrating it.  

Other than demo source code demonstrating, deliberatly putting an invalid  
integer into an ASIC integer, I've *never* seen the condition in real life.  
I've yet to see a single MZ executable with 0080 in it's header; which is  
what's required to cause this. 0180 doesn't cause an invalid integer range  
and so, ABS can deal with it. 0180 is -32767 for ASIC...and ff 7f is +32767  
for ASIC. 32767*512 is the amount of bytes (nearly 16megs) EXEVALID can  
handle with the ABS command without it possibly thinking a file is too  
small when it's not; assuming the header information is valid. Since the  
integers are going to roll beyond 32767 and won't set themselves as -32768  
on purpose (that's something you can deliberately cause, but ASIC won't  
normally do), using ABS, i'll always have a positive number that can be  
upto 32767; which supports a file of around 16megs in size. 16776704 bytes  
to be exact. Anything beyond that won't be correctly represented using the  
abs cheater method; because the integers are rolling now.

The bug is with ASIC, Not my program. Due to the abs command being used in  
the first version of exevalid, exevalid can get a negative number if it  
ever read 0080 in the header; because the abs command isn't working like it  
should have in that condition. The number remains -32768. This odd issue  
does NOT come up during the normal course of using/writing in asic. The  
integers will roll from -32767 to +32767 fine. Under normal conditions, you  
can't force a normal integer to hold -32768 and it won't roll that far  
before heading back to positive, unless you've forced it too, like I  
demonstrated.  

Although you can't cause asic to roll one into -32768, you can read that  
value into an asic integer with a file call, OR do something with a long  
integer and stick it right back into a normal integer; ASIC won't catch the  
range limit being exceeded in those cases. So the value will be -32768.

My theory on this: as far as ASIC is concerned, I just read half of a long  
integer into a normal integer and it didn't catch me. (A long integer is  
4bytes, and ASIC would have expected me to use a long integer to represent  
-32768) shown here:

a=32765
a&=a+4
a=a&
print a

It shows -32767 on the screen when you run it. If you change 4 to 3 in the  
source and recompile, you'll get -32768. Which is technically, an invalid  
range limit for a normal ASIC integer, but 0080 is the correct first half  
of a long integer in asic followed by ffff to represent -32768.

However, like I said in my theory, I think it's because I just as far as  
asic is concerned, tried to put half of a long integer into a normal  
integer and it didn't like it.

a&=-32768&
open"o",1,"file.dat"
print #1,a&
close 1

This program writes 4 bytes to file.dat. Which represents -32768 to asic as  
long integer. the first two bytes of the long integer are 0080 in the file.

That's the actual "flaw" EXEVALID has, because it only checks the MZ header  
and only a section of it. It doesn't look for a PE signature, or the  
indicator in the MZ header that one might be present. So it goes by the MZ  
header information only to determine file size, and that may not be  
accurate if it has an included PE/NE/etc program and it's really just a  
STUB.

That's what Ant pointed out the other day. Not Pooh. It's something I've  
known about since writing the program, but not something I was overly  
concerned with fixing. It was never released to joe public, so... as far as  
I was concerned, researchers knew the flaw and understood the risks and  
used the tool with caution.

Quoted text here. Click to load it

It's not an overly complicated program. It's not able to make very many  
mistakes.  
  



--  
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: Dustin fess up or you're fired. I asked for you to post tighter source than mine, and for it to be on my desk this morning. You have one hour.

Quoted text here. Click to load it

Dustin what a lovely way of saying Exevalid has a major bug and doesn't
work as it should do.

Very nicely but evasively expressed!

--  
Jax    :)

Re: Dustin fess up or you're fired. I asked for you to post tighter source than mine, and for it to be on my desk this morning. You have one hour.

127.0.0.1:

Quoted text here. Click to load it

That's a fine example of the fact you haven't got the foggiest idea about  
what I wrote. It really is. You're so lost on this discussion, it's not  
even funny anymore. Yet, you keep trying to comment. That aspect is funny.  
Saddening kinda funny tho.

It's far better for you to keep your mouth shut and let us assume you're an  
idiot, than it is for you to speak and us be able to confirm it.

Food for thought, Jax.
  



--  
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: Dustin fess up or you're fired. I asked for you to post tighter source than mine, and for it to be on my desk this morning. You have one hour.

On 5/11/2014 5:26 AM, Ant wrote:
Quoted text here. Click to load it
An ant which doesn't dig? I can dig it! ^_^

TDD


Re: Dustin fess up or you're fired. I asked for you to post tighter source than mine, and for it to be on my desk this morning. You have one hour.


Quoted text here. Click to load it

Dustin it makes no difference if Pooh Cat discovered flaws in your  
Exevalid program or the ASIC compiler on his own or with help from others.  
Those flaws exist whoever found them.  

The sad thing is that when Pooh Cat alerted you to some of the flaws you  
denied them all and then attacked him for his stupidity. How is that sort  
of attitude of yours going to help?  

In the end Pooh Cat wrote some demos and proved to you beyond all doubt  
that Exevalid was flawed. Unfortunately this has made you even more  
defensive. And when Pooh Cat wrote a better version of Exevalid you got  
even more sore. So you tried to deflect the discussion in the ways listed
below.  

To be honest Dustin anyone can see that you posted Exevalid and challenged  
anyone to understand it. Turned out Pooh Cat and others understood it  
better than you! How embarassing.  


-------------------
(1) You hotly debated which version of Exevalid was more efficient and
then you jeered that Pooh Cat's demo program wasn't efficient;  

(2) You also jeered that Pooh Cat took a few days to find your errors and
so he couldn't be respected;  

(3) You asked Pooh Cat strange technical questions as if you were an
examiner at a test and specified he wasn't allowed to look up information;

(4) You claimed you knew of the faults Pooh Cat and others found but
didn't want to reveal them because you wanted to see if Pooh Cat could
find them on his own;  

(5) You then said that you knew of the faults and in real life had
implemented another check on the data processed by Exevalid so that it
effectively did what Exevalid should have done.  

(6) You posted other programs and asked for comments on those instead of
discussing Exevalid.  
-------------------


--  
Jax    :)

Re: Dustin fess up or you're fired. I asked for you to post tighter source than mine, and for it to be on my desk this morning. You have one hour.

On 5/11/2014 12:48 PM, Jax wrote:
Quoted text here. Click to load it
So jackie, since you don't understand this, who is actually writing  
these posts for you?



Re: Dustin fess up or you're fired. I asked for you to post tighter source than mine, and for it to be on my desk this morning. You have one hour.


Quoted text here. Click to load it

Yes it does. It proves Pooh didn't know what he was talking about and
doing at the time. Which was the reason I posted the source code in the
first place.  

Quoted text here. Click to load it

Poohs never released a better version of exevalid. Poohs demos are
stripped down, single run, one file only, doesn't check MZ aspect at all,
demos. He wrote them and declare we're competing for the smallest
filesize. I guess we are now. I'm holding the title now, at 1920 bytes.
[g] And what's worse for Pooh, I made his own program that small, and mine
the same size; doing it two different ways. *hahahaha*.  
  
Quoted text here. Click to load it

Nope. Honestly, I posted exevalid and specifically asked Pooh if he could  
tell me how it worked. He couldn't do so. EXEVALID has no mystery routines  
or non existant subroutines.

As far as embarrasing goes, I just shaved 16 bytes off his latest demo;  
making it even smaller than he did. Not only that, I made another program  
that does the same thing, the same size; without doing it the way he did.  
Somebody should be embarrased, but it's not me. [g]

Quoted text here. Click to load it

No strange questions were asked of Pooh. To his credit, he didn't try to  
pass off another newsgroup poster as one of his techs [g]
  
Quoted text here. Click to load it

True. And as we can see, Pooh didn't do a good job and required alot of  
help and hand holding. EXEVALID isn't a complex program. A serious  
programmer/coder wouldn't have needed all the help. They could have said,  
"it's checking the exe header and comparing the bytesize the blocks say it  
should have to the size on disk". He said it was a mystery routine instead.

Ant pointed out the upack issue, that pooh faithfully kept in his demos. He  
knew NOTHING about the exe header. ;p


--  
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: Dustin fess up or you're fired. I asked for you to post tighter source than mine, and for it to be on my desk this morning. You have one hour.


Quoted text here. Click to load it

Side comment,

While you're helping Poohs trolling efforts; would you like to tell him what  
the comit source is actually writing to disk? He seems to have trouble with  
it. I don't think you'll find any problems with that code, but hell,  
anythings possible.  

I've seen many UPX packed samples, but very few of these upack ones. It  
doesn't seem to be a very good packing util.

http://www.sac.sk/files.php?d=7&l=U

full of them, if you collect them.


--  
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: Dustin fess up or you're fired. I asked for you to post tighter source than mine, and for it to be on my desk this morning. You have one hour.

"Dustin" wrote:

Quoted text here. Click to load it

I'm doing no such thing. I'm correcting misinformation. If you think
he's trolling (which he probably is) then why are you responding to
his posts? The usual way to deal with trolls is to ignore or killfile
them.

Quoted text here. Click to load it

He's not interested. If he's a troll, you're just feeding him.



Re: Dustin fess up or you're fired. I asked for you to post tighter source than mine, and for it to be on my desk this morning. You have one hour.

Ant explained on 5/8/2014 :
Quoted text here. Click to load it

I was somewhat disappointed that Pooh decided to only address the  
calculation of file size as reported in the header. Since you have  
joined in the discussion, I was wondering, if we are only talking about  
equality (as opposed to < or >) of sizes for DOS exes and not PE files,  
if it would have been better to use the byte count from the filesystem  
and divide by 512 to get the equivalent block count (minus one) and  
compare the remainder to the bytes in the partial block. There would  
then only be a 1 in 512 chance that block count would even need to be  
compared in the case where the truncated or additional bytes would be a  
multiple of 512. So iff there was no discrepancy in partial block bytes  
would one ever need to bother with block count. Why calculate bytes  
from blocks if the partialblock already showed a discrepancy 511 times  
out of 512?

I understand that there would still be a need to compare blocks if we  
were not concerned with only equality and needed to not cull out files  
that were larger than reported in the header.

Anyway, it was an interesting discussion for me. I now wonder why  
ASIC's documentation states that the range of signed integers is:

"By default, ASIC will permit regular integer variables. These  
variables are very efficient and only require two bytes (or characters)  
of memory storage.  However, these integers can only hold numbers in  
the range of -32767 to +32767."

as opposed to -32678 to +32767 as one would expect from two's  
complement. Are they using signed magnitude or one's complement i.e.,  
Do they have the concept of a negative zero in play?



Asic & exe stuff [was: Dustin fess up or you're fired...]

[posted in ACAV only]

"FromTheRafters" wrote:

Quoted text here. Click to load it

I don't follow you. It's easiest to calculate the total number of
bytes from the MZ header and compare it to the file size (for MSDOS
only). Why do otherwise?

Quoted text here. Click to load it

There's no need to compare blocks at all. That's just the way the info
is stored in the header. Convert to bytes for simplicity. And - we
should not cull larger files. Files get culled because they are too
short (the actual size is smaller than what the header says it should
be).

Quoted text here. Click to load it

They might but I don't know. I don't have ASIC. Write a test program
to find out how 0x8000 is printed as an integer.



Re: Asic & exe stuff [was: Dustin fess up or you're fired...]

Ant submitted this idea :
Quoted text here. Click to load it

If it is easier, as you say, then there's probably no reason to, but  
the file size as reported by the filesystem will always be positive  
regardless since it isn't controlled by the exe's creator.

I was just musing on the idea that it doesn't matter which stored  
representation of file size gets manipulated in order to be able to  
compare it to the other, and dividing a known positive 'length in  
bytes' stored as a long signed integer (which I assume is what one gets  
from the filesystem) seems more straightforward than doing calculations  
on numbers which may not have been stored by following the rules for  
how they are to be represented when read back out. As you know, malware  
authors do try to muck things up for researchers at almost every  
opportunity. :)



Re: Asic & exe stuff [was: Dustin fess up or you're fired...]

"FromTheRafters" wrote:

Quoted text here. Click to load it

Yep (or zero), and so will the value from the header if you handle it
properly.

Quoted text here. Click to load it

The thing is to always treat sizes as unsigned and do range checks. In
the case of the MZ header, word 2 can have valid values of 0 to 511.
Word 3 can have values from 1 to whatever the maximum number of blocks
an MSDOS exe can be. I don't know what that limit is. Because these
are 16 bit words, the largest value they can contain is 65535 when
treated as an unsigned short. Perhaps ASIC doesn't have an unsigned
integer and that's why abs() has to be used.



Re: Asic & exe stuff [was: Dustin fess up or you're fired...]

Ant wrote on 5/8/2014 :
Quoted text here. Click to load it


Yeah, I posted a snippet from the documentation earlier (and perhaps in  
a different group) that states that as a reason for using ABS on data  
delivered as an unsigned integer. Pooh's fix (or workaround) did  
essentially the same thing by interpreting the bytes as character  
codepoints and then reverting them back to representing integers before  
doing the calculations.



Re: Asic & exe stuff [was: Dustin fess up or you're fired...]


Quoted text here. Click to load it

Pooh I'm not exactly clear about all those details...... but that stuff  
about two bytes sounds like a brilliant way to correct Dustin's bugs. Just
saying!  

--  
Jax    :)

Re: Asic & exe stuff [was: Dustin fess up or you're fired...]

127.0.0.1:

Quoted text here. Click to load it

Very simple details, although he's .. umm, shall we say, giving himself  
more credit for his role and lying about the reason I used abs (he has to  
spin the 0080 issue he didn't know about previously somehow!) than is  
necessary. The fact you aren't uhh, exactly clear about basic computer  
knowledge 101 stuff here isn't in the least bit surprising.

(1872 bytes) written by me, not Pooh.


http://www.youtube.com/watch?v=3umaLe37-LE


print"Dusty Buster. Version 3"
print"Written by Pooh the cat April 25th, 2014"
print""
print"Enter filename: ";
input filename$;
bload filename$ 0 6
y=3
gosub m:
partialblock=256*temp
y=2
gosub m:
partialblock=partialblock+temp
y=5
gosub m:
blocks&=256&*temp
y=4
gosub m:
partialblock=512-partialblock
blocks&=blocks&+temp
blocks&=blocks&*512
blocks&=blocks&-partialblock
print""
print"Totalsize ";
print blocks&;
print" bytes"

end
m:
temp=peek(y)
return



--  
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!


Site Timeline