Note the name change from *AntiVirus* to *AntiPrank*.

I seem to have an unnatural fixation with getting this done, despite unsuccessfully attempts to complete a worthy one using the Celtic3 libraries. But, with Axe at my disposal, and most of the main features set up already, I'm confident that this will go somewhere.

Features Expected to Be included
-Scanner by File Name
-Real Time Shields, constantly checking the calc for bad stuff
-RunProg hook that checks to make sure what you are about to run doesn't match known pranks.

*Need asm help with last 2.

Well, we can certainly help you with that. I didn't know Axe had the capabilities to deal with hooks, though; is that something new?

No. It doesn't yet. Only interrupts.

So you'd have to do the hooks through inline ASM then, correct? Or alternatively, we could teach you real z80 ASM and you could do it that way. All of the things you described are quite trivial in ASM; the hardest part would be designing a database of "pranks" robust enough to catch pranks despite renaming or code-changing, but smart enough to not produce tons of false positives.

Well, a search by program name would be trivial enough for a full system scan. But, for more advanced features, perhaps a search for certain things within the suspected program might prove sufficient.

For instance, Brandon Wilsons BRICK program uses "bcall Unlock Flash". If that bcall can be included in the program's search table, a program that contains it could be warned against using. That is one idea of mine.

Indeed, and that would probably be a good idea to scan for. You could look for a set of bytes, each N sequential bytes long, in each program, then warn the user about what was found ("Flash Unlock exploit", for instance), and ask them if they want to continue or abort.

exactly. And as for real time shields, as i explained to you, how much of a slow-down in calc functions can be expected.

It depends what exactly the real-time shields are doing. I feel like you might want to skip that; what's the point if you check when programs are run anyway?

Well, what would be easier to restore after a crash? An interrupt or a hook?

And, is it possible to make the program restore hooks and settings automatically on RAM clear, or would that require a change to the boot code?

It's equally challenging to restore an interrupt and a hook after a RAM clear; I strongly recommend that you use hooks and chain them rather than use an interrupt, as if you use an interrupt there will be a lot more features you'll have to re-implement, like poweroff and APD. There's no easy way to restore hooks after a RAM clear that I know of, but there might be something that I haven't considered.

zStart does it, but by directly modifying the boot code. Thats the only way I know of. So, I'll abandon the RTS and go with the RunHook idea (though that still is a shield, technically).

As for figuring out potentially harmful commands, I'll leave you to the task of actually finding them out, since you being an assembly programmer means you'll have a better idea what can do what than I will. I'll deal with the main program and the interface, and the scan by name system.

Unfortunately, there's nearly infinite ways to make a program freeze or crash, but I'll try to come up with some bits of code for the most malicious stuff, like trashing the certificate and unlocking the Flash.

If you really want to get a real antivirus program, run an emulated calculator, and run every program/application on the calc inside of it and see if it crashes. That's how computer antivirus software works.

Yeah, but then how do you want to detect malicious programs? Name plus code segment fingerprint? Name plus checksum fingerprint? Just name? Just fingerprint?

Kerm, once you figure out what things should go in the virus definitions database, I will need to know the format of the list.
For instance, assume for instance that the database includes bcall CrLCDFull and ret. By format, I mean how are they listed. So the appvar might read:

,EF4045,C9,

which means it would search first for EF4045, then repeat the search for C9.

Knowing how you plan on separating different search terms would allow me to perhaps include a scan-by-contents feature to the full system scan, as well as produce update files?

Do you catch my drift? I probably didn't explain what I'm saying well.

I catch you perfectly. Because *any* hex value might be a valid part of a search string, I will be doing a length-prepended system (of course, every pair of digits below forms one byte):

03EF404501C9

So you read 03, then the next 3 bytes, and that's one search string. Then next you read 01, then the next 1 byte, and that's another search string.

Ok. But how do you plan on separating search strings within the appvar or definitions file? Like

,03EF4045,01C9, That way it can be read from by moving from comma to comma.

Once again, since you're reading from the beginning, delimiting is unnecessary. And recall that we're dealing with *binary*, not ASCII-encoded hex (ie, "A9" is one byte, not two characters). Have I confused you?

Maybe. What I'm not understanding is how data can be read correctly if its has different lengths. I'll be on later and I'll try to see if i can figure it.

That's why you prepend the length of each chunk of data. Pseudocode for reading each chunk:


Code: