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

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

Threaded View

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

@news2.open-news-network.org:

Quoted text here. Click to load it

Poohs fix never corrected the issue Ant ruined my further fun by exposing.

[g]


--  
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: Asic & exe stuff [was: Dustin fess up or you're fired...]


Quoted text here. Click to load it

Rafter.... didn't Pooh Cat's code also handle larger numbers? Am not  
exactly sure!

--  
Jax    :)

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


Quoted text here. Click to load it

Slightly correct. I imported an unsigned integer, knowing full well ASIC  
may instead roll the integer several times and still report a negative  
value; ASIC's integers are signed and have a range limit that's not  
friendly. ABS was used to ensure the rest of the math routines would always  
see a positive number, in the event the roll ever happened, OR the integer  
ASIC thought it saw exceeded 32767; which would automatically cause it to  
be a negative number.  

ABS was not used to deal with the 0080 (in this order, those two bytes)  
issue ASIC has, as ABS has *no effect whatsoever* on it. The integer ABS'd  
or not would continue to be -32768; outside the legal range for an ASIC  
integer. Additional code is required to correct that condition. IE: the bad  
integer being set to a long integer within the integer range.

Quoted text here. Click to load it

No shit sherlock. That's why I found your comment that it was your original  
work to be funny and smell of desperation. As old as ASIC is to think for  
even a second that you are the first/only person to have dealt with ASICs  
integer issue in this fashion. Balls, man. Stupid, but balls.

Quoted text here. Click to load it

Tell them what? That you are the first/only person to deal with unsigned  
integers as individual bytes in ASIC? A language developed in the early-mid  
90s used by thousands of people all over the world? Still used today?  
C'mon, be realistic.

Quit trying to BS so much.  


--  
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: Asic & exe stuff [was: Dustin fess up or you're fired...]


Quoted text here. Click to load it

Yep. As I originally stated tho, EXEVALID is a simple culling tool. For  
most situations, as long as mass cull of executables isn't turned on, it  
does do it's job. Some files are going to be flagged as may not all be  
there, but unless you told EXEVALID it was okay, they still wouldn't be  
culled. Any files that don't pass exevalid sanity check but are seen as  
executables by it can always be examined closer, later.

It can however differentiate between an executable (MZ based) or not, and  
would safely cull those which don't comply atleast that far. As you well  
know, ZM files cannot ever execute their PE selves; so EXEVALID doesn't  
have to worry about them. They can be considered trash and culled. They  
will *never* affect a windows system with native PE code, unless their DOS  
counterpart is a dropper for a Windows program.  

I have actually seen some of those. A DOS based program that actually  
writes a win32 program that goes online and downloads more trojans. The DOS  
program was nothing more than a simple wrapper in this case, but it did  
it's job.

I've never seen a ZM file in the wild used as a dropper for a windows based  
malware program and with newer versions forcing the user to jump thru hoops  
to enable DOS support, I don't see it as a viable future.  

It could be used maybe to get older systems since they'll execute the DOS  
program if asked to do so, and this would evade many culling programs that  
do check for the MZ based magic number; for possible detection purposes, as  
the file might be considered trash and deleted in this case. EXEVALID  
sadly, isn't the only tool/app that doesn't bother to look for the ZM  
signature. I've never checked to see if any of the online emulation/virus  
scanning sites can deal with an executable that's had it's first two bytes  
swapped to ZM. It obviously has no real future in windows on it's own, for  
the aforementioned reasons.

  
Quoted text here. Click to load it

Correct. ASIC can't read 65535 as a normal integer. Normal ASIC integers  
are range limited from -32768 (the manual says -32767 but trust me, you can  
put it at -32768) to +32767. So abs must be used if you aren't concerned  
with accuracy lost after 65535 (that's plenty of blocks, I'm only concerned  
with missing blocks, obviously; not additional ones).  

In my case, I wasn't. Pooh considered it an extremely big deal and  
seperated the two bytes representing an integer and converted them to the  
long integers in asic which can handle numbers beyond 32767 positive.

His demos can handle files exceeding 10 megs in size without considering  
pieces missing. I used abs as you can see in the initial exevalid posting  
because I wasn't concerned about it being used against files of that size  
that should be an executable. ABS when used in this fashion obviously uses  
less code than doing it the way I did in version two, to gain accuracy that  
wasn't needed and wouldn't deal with bogus header information anyway.

The revision to exevalid done to demonstrate that pooh wasn't the only one  
who understood high/low values fixes the accuracy issue in so far as  
reading the MZ header stub, but, still, does nothing if the information  
contained within isn't accurate.  
  
If you do cause a normal ASIC integer to be set at -32768, none of the  
built in asic commands can do anything with it while it remains outside of  
the legal range. Under normal conditions, you shouldn't! cause that issue,  
but it can be done. I provided demo source already doing it. You can't set  
a=-32768 because the compiler will catch you and abort, but you can write a  
little code that does that for you and it won't catch it via the compiler.  
It'll do what you wanted but like I said, if you do, you lose normal  
integer asic commands until you fix it; and that has to be done by changing  
the variable holding it to an integer in the allowed range. I sincerely  
think this is a bug in the programming language itself. 0080 when read as  
an integer in asic will result in -32768, but it's clearly not supposed to.

It's one of several oddities about the language that don't quite match what  
the manual says. Another is the dim command. In the examples and in the  
manual, nothing is ever said about the array element actually starting at  
(0), not (1). So for a ten element array, it needs to be dim apples(9), not  
dim apples(10), unless you want to waste an element or you can't deal with  
start at 0 instead of 1 situations.

Another strange oddity is more likely an issue with NTVDM than it is in  
ASIC, as it only occurs under NTVDM. When using real DOS or another OS that  
emulates a DOS environment, the built in ASIC findfirst/findnext routines  
return all specified matching files.  

Under NTVDM, they miss files that should have matched on a run. and the  
miss/hit appears to be random. Each time you do another run, it'll see some  
files it missed on the previous one and miss others it saw on the previous  
one. So, I had to switch over to another routine outright to handle running  
under NT based Windows. Years ago. It's a peculiar language.  

Years ago, I found an interesting bug with powerbasics dim statement. It's  
runtime would cause a crash out condition when it occured in some cases, in  
other cases, you'd see a memory content dump (if you were trying to print  
from the array or write to a file from it) and then it would crash with a  
funny runtime xxxx:blah error.

In some HLL languages, especially basic like ones, it's been my experience  
that if you dim apples(10) and try to say, apples(12)=oranges it'll stop  
you and won't let you do this, because you don't have a 12th element in the  
array. Powerbasic didn't catch it in the ide, or during compilation. Your  
program was allowed to write beyond the memory space previously allocated  
for your array (buffer really). Since you had no 12th element and it didn't  
catch itself, or your mistake. Usually right above the memory segment into  
the code segment. Do it properly, you can cause code execution. Otherwise  
known as a buffer overrun exploit.

I was able to actually write two programs that were loaded into a tiny  
array that would later directly execute as a result of this. I even used  
the program comit actually writes to disk for a user as an experiment. It  
displayed "Hi there" and a few moments later, runtime error xxxx:blah. So I  
was able to cause it to execute code when I shouldn't have ever been able  
to do that. Buffer overrun exploit, in powerbasic no less.

Another time, it executed my experimental Hi there comit program and died.  
No runtime error, but no return to dos prompt either. Hard lock condition.
So I couldn't guaranteed the program would always completely run what I  
wanted it to by exploiting it, nor could I guarantee it wouldn't crash hard  
or soft with a runtime error.  

ONE time and only one time doing this was I able to get it to run my bogus  
program that it loaded as data and still execute without a runtime error or  
hard crash occuring. Basically, it loaded my program into an array too  
small for it; the program was the last 16 bytes or so of the garbage I fed  
into the array. When this happened, it immediatly gave control to my  
program and this one measily time, when my program ended, it resumed  
control like nothing had ever happened. Otherwise , runtime error and/or  
hard lock condition, but I could usually get my new program to run first.

--  
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: Asic & exe stuff [was: Dustin fess up or you're fired...]


Quoted text here. Click to load it

It does have one small advantage/disadvantage depending on POV, You can't  
run these malware samples directly in Sandboxie.  

http://www.sandboxie.com/index.php?SBIE1312

Running dosbox after you install it in a normal sandbox tho will let you  
run some dos programs.. In a strange fashion. This would totally not work  
for malware delivery purposes. You don't have real access to the host this  
way and if you try anything stupid or "fancy" as pooh put some of my code,  
you'll crash dosbox.

From the dosbox console, I don't have local access to my other drives or  
directories... I have to use a dosbox commmand called mount and specify a  
folder that way. However, I noticed that when I tried running BugHunter, it  
was able to access files in folders I haven't mounted via dosbox and it  
failed to complete a scan without crashing. Sandboxie seems completely  
unaware that bughunter has tried to run under a program under it's control.  

On a good note tho, renaming a file I have access to under the dosbox  
program under sandboxie doesn't really change the filename.. heh.

Doesn't seem like development is happening as fast as it used to with  
Sandboxie... since it changed hands.
  


--  
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: Asic & exe stuff [was: Dustin fess up or you're fired...]

Dustin explained :

Quoted text here. Click to load it

From ASIC.DOC

"ARRAYS - Each element in an array requires two bytes.  (Don't forget  
arrays have an element zero (i.e.  DIM A(2) is comprised of A(0), A(1),  
and A(2))."



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


Quoted text here. Click to load it

My bad. Nice troll. Wanna explain why Pooh never noticed the first element  
then? :) I'm most curious as to your answer.

How did you like my superior little pooh demo? it's 2000 bytes on the nose if  
I continue closing the file handle, 1984 bytes if not. Maybe you can help  
pooh become a better programmer? lol



--  
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: Asic & exe stuff [was: Dustin fess up or you're fired...]


Quoted text here. Click to load it

Other than my obvious incorrect memory recall on what the manual says, what  
did you think about the rest of my post? I have no problem if you want to  
play trolling games as well as Pooh, but I'll treat you no differently as a  
result.



--  
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: Asic & exe stuff [was: Dustin fess up or you're fired...]


Quoted text here. Click to load it

Dustin one of my techs says many, if not most, computer languages start
counting their array elements from zero.  

Surely you knew that? Just wondering if you really did.  

--  
Jax    :)

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

127.0.0.1:

Quoted text here. Click to load it

Huh?
  
Quoted text here. Click to load it

What? Yes, I knew it atleast with asic and some other HLL languages I've  
played with. I've run across some that didn't consider the first element to  
start at 0, but 1. It's upto the language.  

 I was outright wrong when I said the asic manual didn't mention it. Truth  
is, I forgot. It's been years since I even touched asic, let alone actually  
viewed the manual.  

  



--  
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: Asic & exe stuff [was: Dustin fess up or you're fired...]


Quoted text here. Click to load it

Dustin why don't you use a language with fewer flaws than ASIC? Ideally  
one which is still being maintained!

--  
Jax    :)

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

127.0.0.1:

Quoted text here. Click to load it

Jax,

other than the past week or two, I haven't been writing much code of any  
sort. I've been reviewing code from a disassembler window...I actually  
enjoyed some of the discussion back and forth between Pooh and myself.  
Especially the new "how small can you go" challenge. It's possible he may  
still come up with a tighter one to mine, we'll see. It wasn't piss easy  
getting those 16 bytes on him yesterday, btw.  

He *is* paying attention to what I've been showing him about the language.  
In his latest demo, he was recycling variables this time and cut the code a  
little more by doing what I've told him previously and from some of his own  
knowledge.  

I knew he messed with a z80, so I'm sure he's played around with various  
dialects of BASIC before. Anyone who's owned a z80, c64,coco, etc most  
likely has. That's why I figured ASIC source would have been perfect for my  
question to Pooh. Can you tell me what the program is doing. I admit ASIC  
has a funny way of handling integers compared to many other more common HLL  
languages, and it does have a bug in the integer range checks, And finally,  
it's ABS command is a little different than what you would have expected to  
see from most basic dialects. So... in all fairness here, I was a little  
coy in using ASIC for the question. Using another HLL language or even  
assembler would have been straight forward. I don't think he could have  
answered it then either, but, it's not nearly as fun as watching somebody  
step all over themselves when they try to improve your work and break it in  
the process.

He's actually the second person who's tried to fix something that I posted  
in asic, without looking at the manual first. Another troll KD, thought I  
was wasting time doing asic like this:

a=4
c=a+2
d=c
d=d*3
d=d+4
print d

he tried to "optimize" my shitty work with this (and expected asic to be  
cool with it)
a=4
c=a+2
d=c
d=d*3+4
print d

Looks the same right? Well, the top one is asic syntax. The bottom one  
second to last line is not. It'll generate error "E013 - Syntax Error" when  
you try to compile it. ASIC doesn't really "run" programs from it's IDE,  
they must be compiled via ASICC.EXE first. the bottom example won't work.  
But it was supposed to teach me the way I should have done it. [g]

He incorrectly assumed, like pooh did with the abs command, that I didn't  
need to do:

d=d+4, that was "redundant" code and should have been deleted. As this  
would have done what I wanted:

d=d*3+4

Well, in any other HLL basic dialect I've seen, they're right in what they  
thought; but that's just not so with ASIC. I did the things I did in the  
source code i've shared for specific reasons. Mostly as a workaround to  
something funny with ASIC.

All languages have flaws and issues with them Jax. Nothings perfect, the  
more complicated the programming language and compiler(s), the more likely  
you can write code that does something you shouldn't be able to do. Like,  
setting an ASIC integer to -32768.

I like ASIC. It generates tiny programs compared to many other languages I  
know/compilers I've used/abused. I can live with it's flaws. I'm used to  
them, I know how to work around them. It makes me a better coder as a  
result. forces me to think, sometimes, outside the box. Like Poohs been  
having to do lately. [g]



--  
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: Asic & exe stuff [was: Dustin fess up or you're fired...]


Quoted text here. Click to load it

Dustin I don't understand all that code stuff but I'm pleased Pooh Cat has  
given you an education!

--  
Jax    :)

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

Dustin explained on 5/10/2014 :
Quoted text here. Click to load it

No differently than you do now, or no differently than you do him?



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


Quoted text here. Click to load it

LOL. I was being an asshole without valid cause. My apologies.


--  
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: Asic & exe stuff [was: Dustin fess up or you're fired...]


Quoted text here. Click to load it

Dustin..... your apology has been noted.  

Please avoid such behavior in future. Thank you!

--  
Jax    :)

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


Quoted text here. Click to load it

Dustin..... Rafters is not playing at trolling games. He has a respect for  
facts and has drawn something factual to your attention.  

If you don't like it then you don't like the facts. Just saying!

--  
Jax    :)

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


Quoted text here. Click to load it

Ok. You do realize, I haven't touched any ASIC code in 7 years or so, aside  
from this game Pooh and I have going, that is. I don't care that I forgot  
something the manual said. lol.  
  
  



--  
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: Asic & exe stuff [was: Dustin fess up or you're fired...]


Quoted text here. Click to load it

Dustin seven years ago you had your ass handed to you by K-Man and 4Q when  
they helped you with your flakey code. I enjoyed reading this.....

<https://groups.google.com/forum/?hl=en #!msg/alt.os.windows-
xp/D1qAdTXt70Q/x_5_2hTcZgcJ>

http://goo.gl/NKYbbJ

--  
Jax    :)

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


Quoted text here. Click to load it

I'm glad you brought that up, but it's entirely untrue. K-man did rewrite an  
asic program and broke asic syntax; I already told you about that.  

And your buddy Pooh isn't looking so hot now either. He removed the file  
close command in one to make it smaller (not cool, lol; desperation) and he  
hasn't posted one yet smaller than 1872 bytes. [g]

Never has told me what the comit program is writing to disc. Later today I'll  
post the source to a small program that reverses the "code" so everyone who  
can read assembler can all get a good laugh at Pooh, on the house.

Or should I have written, another good laugh at Pooh?

4Q is as accurate as pcbutts in *everything* he writes about other people.  
He's a tabloid style writer. A little truth, mostly bullshit designed to  
paint the "target" in a bad light.  

When I challenged him on his claims, he'd troll like Pooh and yourself do. At  
the end of the day tho, none of his predictions ever came true and I went on  
to work for Malwarebytes. Obviously, he isn't about to publish that.


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