Cemetech File download: https://www.cemetech.net/programs/index.php?mode=file&id=1753

So I remember I started talking about this a while back, but didn't have the skill to pull it off. Well, I now officially have, at least in part. I was struck with this idea when CALCnet was implemented for the TI-83+/84+ line of calculators. Five to ten years ago, cell phones were devices that could only make phone calls, and now.. they can talk, text, use the web, and along with those new capabilities... vulnerability.

Assuming that calculators follow this trend, which CALCnet has already proven them capable of, I forsee a time when calculators might well become victim to the same (or different) types of exploits and vulnerabilities. Even in liu of that, you might also want some extra protection against pranksters putting actually-harmful "viruses" on your calculator.

This project is the answer to both possibilities. Blast Calculator Security Suite, shortened to BLASTCSS is a real malware detector and file integrity checker. Project Page is http://clrhome.org/blastav

1)) Unlike some of the other "virus scanners" in the archives of Cemetech, Omnimaga, and ticalc.org, BLAST actually scans for real malicious code, not just for names like "VIRUS", or not really scanning at all. It accomplishes this by utilizing a virus definitions file that is automatically updated weekly on the project page. More on that below.

2)) BLAST also implements a file integrity checker. You may optionally generate a file attributes database that scans every protected program and program on your device and records the (1) name, (2) type, (3) size, and (4) 24-bit checksum. This is done by choosing the Update Attributes File option from the main menu. You may then select the Verify Attributes option from the main menu to check your calculator for any program of the same name and type on your calculator. The size and checksum will then be displayed on screen, in red text if the attributes differ and green otherwise.

** When files this program uses become outdated (1 week for the attributes database, and 1 month for the virus definitions), a red warning symbol will be displayed to the left of the item that is outdated. The virus definitions and the attributes file are timestamped, and that timestamp is displayed on the bottom of the main menu whenever this program is used. **

3)) This program also has a silent and automatic feature... the ability to recover your system clock settings after a reset. EVERY time this program initializes, the system clock is read out. This time is then checked against the last clock save in the settings file for this program. If the system clock is later than the saved clock, your saved time is updated. If, however, the system clock registers an earlier year, evidence of a reset, the last clock save is written out to the system time.


Further plans for this program include:

1. Intercepting a user exiting the program edit menu, and silently updating the size/checksum, so as to reduce the number of false positives in the attributes check.

2. Intercepting a program being run and performing either an attributes check, a virus scan, or both beforehand.

3. Chaining these functions with existing hooks for Celtic, Doors, and any other future programs.

4. [pending networking implementation] a firewall to integrate with networking protocols implemented in the future.


The Virus Definitions

A separate segment to this project is the community-sourced virus definitions database. On the project page for this project at ClrHome, http://clrhome.org/blastav , there is a page dedicated to this. On that page, any calculator user knowledgeable about byte sequences that can harm the calculator may go to this page and submit: (1) the OPCODE that is dangerous, and (2) A description of what it does. Character limiting is not yet implemented, but until it is, please limit your OPCODE lengths to 100 characters and your descriptions to 256 characters. Bear in mind that the longer your description is, the larger the definitions file. Upon being verified and accepted, your addition will be built into the next definitions release. You may also download the most recent definitions file from this page. Definitions files are rebuilt weekly by an automated script.

** By the way, a dangerous opcode is not simply something that RAM clears or crashes. I'm referring to code that can do serious, permanent damage to your calculator. **

Now, time for a screenshot:

As a maker of a fake virus checker, HEY! stop stealing my customers!
As a "normal" nerd, what calc will this be for? (I assume CE or CSE, what language if CE?) I don't really see this in the post, and the website link seems outdated/ points to a "page doesn't exist"

lmao, sorry! :p
This is for the CE, and written in C, but anyone who is willing to port it back to the CSE or the monochromes is welcome to send me a PM.
Also, the links have been fixed.

Seeing as there is no point to viruses on calculator, I don't see the point of a checker, but I could see this being fun to try and get it to detect random ''malware'' programs I guess.

Now I need to start actually writing calculator viruses just to see if this works.
What types of 'viruses' will it detect? As far as I know nothing is really damaging to the calculator. The worst thing I can think of is corrupting variables, and...

...actually program corruption could make a good virus. Is there a definition for that yet?

No, but that's what the checksum is for.

The existing definitions are displayed @ http://clrhome.org/blastav/definitions.php . Left column.
The current one there was supplied by Zeda.
It is possible to actually render a calculator permanently unusable. It's called "bricking". There's tools out there that demonstrate it.
Beyond those, things that lock up or freeze the calc in a way that you cannot ON out of it, or things that modify parts of the OS in ways that change its ability to reset, or other things that can do harm.

Detecting programs that will corrupt other program would require a bit more intricate of a scanning algorithm, and is something I'll certainly implement if I can figure out an actual algorithm that can identify it. Although, the integrity checking bit can serve as a bit of a warning for a file that has been corrupted, and that is actually the intent of that feature.

EDIT: Anyone who is familiar with computer rootkit checkers and file integrity software will be able to tell you that it's very hard to algorithmically predict what code is going to corrupt a program or file. This is because a file can be anywhere in memory at any given time. And checking for any code that would ever write to an address in memory that a program could ever exist in would trigger a ton of false positives... namely, probably every program ever written would show up.
So, you come at that problem from two angles. Most rootkit/virus scanners operate using virus definitions or rootkit strings. Which are more or less the same thing. They are byte sequences... code... that is typically associated with a certain type of virus. For example, things that enable promiscuous mode on network interfaces, enable root ssh and other services, modify configuration files, turn your firewalls off, etc.
And then you have file integrity software. This software checks for changes to files that you did not actually cause. This software can return some false positives, but can detect some form of virus or hacking-related corruption to a file.

Corrupt someone's entire calc and make it unbootable:

Code:

So a program corrupter that also corrupts all checksums, including it's own if it has one, to disguise itself.
//or the program corrupts the antivirus and modifies/returns all checksums as good
//or corrupt virus definitions to not include itself

ouch. Any fix for that, or is that the ASM to use when you want to teach someone a LONG lasting lesson?

Use Cesium and its backup features, it blocks the effects of this bug.

Not a long lasting lesson. It's easy to fix. Reinstall OS, but this time taking out the battery to reset. All done.

Like TLM said, USE CESIUM! Cesium is a great shell, and its back up feature is AWESOME. Check out TLM's video on its back up features .

Couldn't a potentially malicious program simply store those opcodes plus or minus a fixed value, then copy those into user memory, re-add the fixed value, then move code execution to wherever it copied the instructions to?

My knowledge of assembly is limited but I doubt that there is a way to prevent that besides preventing programs from copying data into user memory, which would also be hard to prevent since you could just add a fixed value to a "valid" pointer to get an "invalid" one.

Also, what's to stop a program from opening your program and changing it, causing the checksum to always return true? You could checksum your own program, but then it would just run the function that always says all files are valid and it would assume everything is fine.

Implement, within the program-running hook, a \die\ for any program attempting to modify the BLASTCSS code or any of its relevant files. Or, add the AppVar names, and BLASTCSS to the virus definitions file, and whitelist the main program. Thus any other program referencing the Suite or its dependencies is assumed to be malicious.
I also intend, to anyone who knows what this means, to implement a statewise firewall that will hopefully be persistent. The persistent part will require anyone developing a networking protocol to devise it in a compatible way (pre and post jumps, with the addresses stored). I'll detail the intended design of that in the User Guide I'm currently writing, for anyone (re: Kerm) who may at some point implement something and wishes compatibility to do so.

long lasting if the person asks me to put games on their calc and is too lazy to do it themself...
also, jcgter, CE's don't have an easily removable battery

Will you add the ability to scan only selected programs? I would think it'd be faster and easier than scanning all 80+ programs I have every time I send a new (not trusted) program to my calculator.

Full-calc scans/attributes checks will always be a feature. You'd be surprised how fast it would actually complete. I'll have to bring Mateo in to speak to the speed of the ti_DetectVar() function in this scenario.

As I develop some of the automated scanning, via ProgRun intercept and Edit intercept, you will be able to have any program you are about to run scan itself before doing so. If enough people support the idea of being able to select individual files or groups of files to scan, I'll add that as well.

Also, a fairly complete version of the Documentation for this program is available at http://clrhome.org/blastav now. This documentation also includes a brief description of the intended firewall, and requisites for making any networking protocol compatible.

It's fast.

So, Mateo I added you supplied opcode, as well as the hex representations of the strings "BLASTCSS", "AVDEFS", and "AVData", so that any program attempting to reference one of these things triggers. Now obviously, the scanner *should* return a false positive on itself.... it doesn't.

This is the struct I use to temporarily hold each virus definition's data:

Code:


I then pull out the data. With the size of the opcode string, I do:

Code:

opcodestr is the hex encoding of the string (for displaying). So if the string is "EF", for instance, this memory area will actually contain: 4546h.

I then pull out the hex itself. With the size of the hex string, I do:

Code:

opcodehex is the actual hex we want to search for. So if we want to search for EF, this memory area actually contains EFh.

For the scan loop, I have this:

Code:

searchtypes is an array containing the equates for protected program and program.
I have tried this loop as optemp.opcodestr, optemp.opcodehex, &optemp.opcodestr, and &optemp.opcodehex and none of these return the false positives I'm expecting. What am I doing wrong?

For some reason I can't seem to load the virus definition file. Does v0.3b even support it or is it a v0.4b and above thing?

To my recollection, v0.4b implements a fix that allows the file to be loaded. That fix is that tivars_lib exports an all-caps variable name, whereas the definitions file in v0.3b was AVDefs. Thus, its actually attempting to load a file that doesn't exist. Use v0.4b or better.
Although v0.4b might have issues too. Standby.