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?

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?

Found it at: http://www.osix.net/modules/article/?id=520

Nice one, technomonkey! Thanks for finding that.

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.

NP, Kerm and ACagliano... all credit should go to Google. Thankfully for many of my classmates, I'm not malicious enough to make use of that.

It's trivial to produce a RAM clear, and there are nearly infinite ways to do it. I vote no.

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.

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.

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?

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.

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.