While waiting for Star Trek progress server-side, I came up with another idea.

I'm going to make a file integrity program for the TI, using the built-in TI-OS md5 hashing routines. The program is going to use an external database of hashes (unless someone recommends that the hash go in program, which i leaned against because it would require an overhaul in program header formats), which consists of program name and hash.

My plan was to make the database a hidden appvar (that can be done, right) and even archived, if possible. So I'll need to know how to hide an appvar.

Also, a related question. Not something I'm gonna do, but just so I know... Can the check portion of this program be set to run within an interrupt, bit by bit, and then the interrupt shut off when its done? So that it kind of runs as a background task?

uhm, i'm not so sure we should hide the program's appvar. in case the database needs to be reset (for ANY reason, specific examples being a bug in the database or removing programs that no longer exist on calc to save space), we don't want to do a full archive clear.

as for headers, how difficult would it be to alter the header when the integrity check runs? just replace the header (if "standard" ion/mirageos/etc) with a slightly modified DCS header. but then the increased file size might trip up Doors, I seem to remember something about it not working with dynamically changing programs.

making it a background task doesn't sound necessary; the program could just run and exit, right before the program runs. we don't need it to constantly run.

just my two cents.

Not reliably if you're using MD5, since there would be state conflicts as soon as anything else used the system MD5 routines.

There are better options than MD5 for simple integrity checks, provided you don't need to be cryptographically strong (that is, robust only against accidental modification rather than malicious modification). A simple CRC is appreciably faster than MD5, or you can go a step further and be error-correcting with a Hamming code or similar.

Point taken. I'll leave the database unhidden, but archived.



Yes, changing program size trips up DCS7, but only if that is the program itself that is running. I can be running one program and change the size of another without messing Doors up. However, my statement is, wouldn't inserting the header into the program require Kerm to make a change to how DCS reads the headers?



My thoughts too. I was just asking for the sake of knowing.



I am looking to be robust against both, since this is going to be branded as a type of IDS for the TI. I am open to options less secure than an md5, since, although calculators are becoming more and more internet capable (just like phones did years ago), I don't see them becoming a major hacking/malware platform.


A few other questions:

1. How long is an md5 hash for a standard size program? Are we talking like a database that's gonna be thousands of bytes for all the calculator variables? Is there an option that is less memory-intensive?

2. Would the community as a whole think that me including Advanced options with the ability to hash (and subsequently check) the OS and the certificates is a good or useful idea?

Why not just append your custom "header" after the Doors CS header? Then Doors CS won't care about its existence. Of course, this would only work if you were working with programs specifically written for your file integrity program. If you wanted it to work with existing DCS programs, you'd have to use part of the icon area or something.

When the program runs in Initialize Database or Update Database modes, it could inject the header automatically. Then, its changing the programs itself. That could work!!!

I'm not entirely sure I understand your goals with this project, but I should posit something if this is intended for programs. Would this be a system that people developing new programs can opt into using by adding its support in their own code? Or would this act upon arbitrary programs? Because in either case, I see a problem, but especially so for the latter. That problem is, how would you deal with programs that are meant to be modified, like those that use SMC for code or data storage purposes? Or what about a program that gets updated to a newer version?

Its designed for arbitrary programs. A programmer can opt-out by including a one-byte code in the header of their program, after everything DCS uses, which will make the checker/hasher ignore it. Otherwise it gets hashed and checked.

Keep in mind that even on modern computers, changes to files need to be pushed on a system running integrity software, or else it triggers the software. A hope for a later release, if i can figure out a way to detect most common ways of updating a program, i may try to automate pushing that.

Modern computer programs don't use SMC. Calculator programs, however, often do.

True. Which makes file integrity difficult to effectively perform. However, like most things in this field its sort of hit and miss to find what works. I hope that quirks of that style that are present in earlier releases in my program get resolved as time passes.

ok, question:

I can give developers the ability to ask my program not to hash their program by them inserting

.db "NO-IDS"

At the very end of their code. But what about TI-Basic users?

Put the string "NO-IDS (omitting the closing quote) as the very last line of the program? Seems pretty straightforward to me, and yields the exact same byte sequence.

Oh. That's simple. I didn't think it would be that easy :p

Final question, and then I think I should be good to go:

I do want to, as an Advanced option, offer the ability to hash and subsequently check the Flash ROM, including the operating system and certificate. How would I achieve that? Could I just run the MD5 algorithm on every flash page and save that result into a file? What Flash pages are the OS and certificate?

Wouldn't that also print NO-IDS to the homescreen every time the program exits?

put it behind any "RET" commands, and it wouldnt make a difference to program execution.