What of the three features listed above would you like to see most?
Scanner
 41%  [ 5 ]
Real Time Shields
 33%  [ 4 ]
RunProgram Hook
 25%  [ 3 ]
Total Votes : 12

Ok. Just checking.

I will have it extract the program files to a DCS folder, defaulted to BLASTAV5, but the program will allow the user to edit the name of the directory to extract to, just like a real computer installer. There will also be an on-calc user manual, created by your very own DocDE7, extracted by the installer and sent to the installation folder.

As for that, what byte needs to be changed to specify it as a DocDE7 file? And what will happen if you open it, without DocDE on calc?
There's actually an eight-byte header that specifies that it's a DocDE file. If you try to open it without Doc DE 7, Doors CS will complain that it can't find a viewer and send you to dcs.cemetech.net
so, if i just copy the program data, it should copy over the header as well?
ACagliano wrote:
so, if i just copy the program data, it should copy over the header as well?
It definitely should; it's at least worth a try. I'm beginning to think that a larger benefit of this program might actually be a way to package arbitrary programs and data files in a "group" kind of thing and "install" them into a folder as separate items.
it will definitely provide a protocol for doing so that would be worth investigating. There will be a user's manual with this file, that not only explains features, but also explains certain protocol for moving around programs and data.

Now would be a good time to ask: would I have permission to, in this explanation, delve a little into the format of a DCS folder, as you explained to me?
ACagliano wrote:
List of bad programs:
...
-the program to screw up the screen (makes it turn blue and burns it) forgot the name. I saw it once in the ticalc.org archives and i believe on brandonw's site.


Found it at: http://www.osix.net/modules/article/?id=520
Anonymous wrote:
To Anonymous: A program I discovered that will clear the ram is in assembly.
All you do is name the program (i.e. prgmA), then write

Code:
AsmPrgm
3E1FD710C9

Finally, on the home screen, do
Asm(prgmA (or whatever you named it))
Also, I have another good program; it'll turn the screen blue. However, if you don't take out the batteries in 1 minute or less, your screen might be fried.
It's basically the same as before:

Code:
[b]AsmPrgm
3E1FD310C9[/b]

Finally, on the home screen, do
Asm(prgmA (or whatever you named it))
Nice one, technomonkey! Thanks for finding that. Smile
Kerm, are we including known RAM clears, or leaving them out, cuz if we include them, the list can get pretty extensive. But the blue screen code should be in it.

Btw, for your hook, will it have the hex codes stored within itself, or will it reference the virus definitions appvar, "BDefs" for them. And, a screen idea for the hook warning pop-up:


Blast 5.0 Bad Prgm Warning
program name here

Running this may compromise your system.


selectable options: Run/Abort


**Obviously scaled to screen.
KermMartian wrote:
Nice one, technomonkey! Thanks for finding that. Smile

NP, Kerm and ACagliano... all credit should go to Google. Laughing Thankfully for many of my classmates, I'm not malicious enough to make use of that. Very Happy
ACagliano wrote:
Kerm, are we including known RAM clears, or leaving them out, cuz if we include them, the list can get pretty extensive. But the blue screen code should be in it.
It's trivial to produce a RAM clear, and there are nearly infinite ways to do it. I vote no.

ACagliano wrote:
Btw, for your hook, will it have the hex codes stored within itself, or will it reference the virus definitions appvar, "BDefs" for them. And, a screen idea for the hook warning pop-up:

Blast 5.0 Bad Prgm Warning
program name here

Running this may compromise your system.

selectable options: Run/Abort

**Obviously scaled to screen.
Oh, I thought we were still undecided whether that part would be in my hook or in your Axe program to be called by my hook. Smile
Well, im supplying that to u just in case.
If I had your hook call an Axe program, this is what you would need to have the hook do:

Check to see if My Axe program is present. If not, the hook wouldn't work, or may crash.

Also, I would need your help on how to make the hook either run or abort the intercepted program, as Axe can not do that.

Also, the quickest method I know of to actually scan the program for malcodes using Axe would cause a pretty big delay, as Axe only supports an inData routine that checks one byte at a time. Could you do the check faster in pure assembly?


As for the alternative, if you wrote the hook to handle everything, it would eliminate the need for the external program, but might cause more of a slowdown, as the hook itself is larger (I would think. Correct me if I'm wrong). Which method would you find to be more stable, reliable, and practical? And, if we elect to have the hook control everything, I can write, in Axe, the popup display and the pointer to the appvar, compile it into hex and send it to you, so you have less to actually write.

I'll take your advice on which of these two options would be more feasible.
The "common substring" problem is actually one that's well-solved in computer science, as you might imagine, so yes, it would be faster in ASM. I'm wondering if it wouldn't make more sense to perhaps worry about the "scanner" part first, since you can do that in pure Axe, and the "runprog" part is sounding increasingly complex? I'm also a bit worried about how well I'll be able to interact with DCS's runprog, or if it's going to end up clobbering this one.
I'll do the scanner first, then. Shouldn't take long.
ACagliano wrote:
I'll do the scanner first, then. Shouldn't take long.
All right, sounds good. I guess you'll need me to generate the same definitions file from the "malware" that we've identified so far?
Yes. But you can take your time. I can code the scanner without it, but I will need it to test.

Then, perhaps I can release the program with only a scanner as an alpha version.

I will create a topic requesting volunteers for alpha testing.
It would be cool to scan for some of the known flash unlocking routines and make the user verify that the program is from a trusted source?
elfprince13 wrote:
It would be cool to scan for some of the known flash unlocking routines and make the user verify that the program is from a trusted source?
Exactly, that's one of the things on my list of suspicious code to check.
Kerm, what if you use the standard OS b_calls

arch_Var


Since archiving a variable temporarily unlocks Flash, will that trigger a warning, or is it a different type of unlocking flash routine.
ACagliano wrote:
Kerm, what if you use the standard OS b_calls

arch_Var

Since archiving a variable temporarily unlocks Flash, will that trigger a warning, or is it a different type of unlocking flash routine.
Nah, that's a pretty hard one to exploit. With the power of shells like Doors CS it's much less necessary for a program to archive or unarchive a variable, but it's still not necessary to flag it as something suspicious in my humble opinion.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next
» View previous topic :: View next topic  
Page 6 of 8
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement