Yep, Deep Thought's got it. I linked to CertTools because it has both GETCERT.8xp and PUTCERT.8xp. That way you can do both.

A whole certificate is only 8 K, which you can easily fit in main RAM. Also, you can probably figure out a way to completely avoid buffering in RAM and just write straight to the inactive sector.

Well, 8KB, where am I going to put that? And then, when I modify it, I expand it quite a bit because of all of the nested fields.

And writing it straight back to flash would be terrible. That's how I do OS mods, but the certificate is an entirely different creature.


Quick certificate lesson:
The format of a certificate field looks like this.

TT TS [SS] [SS] [DD] [DD] [DD] ...   Where, T is type, S is size, and D is data.

The type can be anything, that is where the 0310 fields come from.

The size however, is where all of the trouble comes in. The first size nibble can either be 0-C, D, E, or F. 0-C are literal, the data is 0-C bytes long. D means that the following byte is the size of the field. E means that the follow two bytes (big endian) are the size of the field. And F is very strange, I haven't seen it used except at the start and ends of App and OS headers.

So the problem that you can see here is that depending on the size of the data, you actually have to shift the data left and right to make room for the size bytes. And then when you go nesting 3 fields inside of each other, that is a lot of calculations that you have to do in advanced if you are only going to write it once.

Consider this, this is what it takes to add text to the about screen:

03, 0D, 14,      (      05, 0D, 11,        (      05, 1D, 0E,      (      B, r, i, a, n, 20, C, o, v, e, n, t, r, y  )))
cert.Rev: size 14    aboutData: size 11    about text: size 0E       text

To write that, I had to put in place holders for the size. But the annoying part, (which I found out), adding only what I showed there to the certificate that will display garbage on the about screen and will not allow the calculator to receive apps or OS's. To make the calculator work, you have to add a bunch more stuff. You have to add so much stuff that the 0300 field size byte actually goes to 0E, which means you have to shift everything over.

Darl, I would have no reason to put this in zStart because it has nothing to do with hooks and only has to be run once. Plus, I think it's better this way, run the program once and get rid of it, that way, no one can take your name off of it.

I didn't put it on the 83+ for 3 reasons. 1) I'm not sure it will work exactly as is, and I didn't want to go disassemble a whole 83+ boot sector. 2) The 83+ is really annoying when it comes to ports, unlocking flash, and writing flash, (83+SE is fine). 3) The 83+ lacks an extra ram page which I use to buffer the certificate while I'm changing it. But I guess I could just overwrite OS data and have it clear ram.

This now works on 83+'s, check it out

A couple months ago, I was talking to BrandonW about how I put my name on the about screen through OS mods. He said that was cool, but to do it the right way I had to put it in the certificate. He then told me how extremely hard it was and how many different things you had to get right to make it work. At the time, the just sounded scary so I didn't look into it.

But now, I've been looking through the boot code for receiving OS's and I noticed that the OS headers are actually pretty simple. I then realized that the certificate uses the exact same format and it also wasn't that scary. So then, after a bit more disassembling, I added a few bytes to the certificate, and sure enough, there was my name on the about screen. The only problem was that there was a line called "Cert.Revision" which displayed garbage. So after a little tweaking I got that working.

I was happy and started writing this program. I was going to add a certificate revision field, with a revision number subfield, and a about screen subfield with an about screen text group. But as I was looking more into the boot code. I realized that if I added these fields, I also had to store the keys in the certificate, otherwise, the calculator would refuse to receive any apps or OS's.

After lots of trial and error with the keys and the format they needed to be in. (At first I had all the keys switched around and in the wrong format) and 5 failed CtlgHelp transfers and 1 failed OS transfer (I had to delete the certificate, but I was prepared for this.) I finally got it to work. Then, I spent a long time making sure this was the most secure program ever because I don't ever want it to glitch. (This includes sending 4 OS's and several apps to two separate calculators.)

I should also mention that I made this program very forgiving. It doesn't assume anything. If you have brandonW's 0005 key installed on your calculator, this mod won't even touch it. It also has code to deal with things previously in the certificate that shouldn't be there. You can see this in the way that it lets you edit what you have already put in the certificate.

Here is a list of the fields it adds:
 - 0300 Certificate revision
     - 0100 Certificate revision number
     - 0500 About screen data
         - 0510 About screen text
     - 0700 Key list
         - 0710 04 OS key header
         - 0730 04 OS key data
         - 0710 0A OS key header
         - 0730 0A OS key data
         - 0710 0104 app key header
         - 0730 0104 app key data
         - 0710 010A app key header
         - 0730 010A app key data

And the end result:



So here's how you can do this. First, download BrandonW's CertTools and send GETCERT.8xp to your calculator. Then run it and transfer your certificate (appVar) back to your computer. It's a good idea to have a copy of your certificate on your computer anyways. (You don't have to do this, it's just a good idea)

Next, send the attached ABOUTNAM.8xp to your calculator and run it. Select "Add Name". It will now ask you for a certificate revision number, you don't have a choice, you have to give it one. Then it will ask your for your about screen text, make that whatever you want.

It will then install the changes and you can go check out your cool about screen. The best part, it is persistent through OS transfers. It is essentially permanent. There are only 3 ways to get rid of it: 1) run this program and select "Remove", 2) Send your certificate back with PUTCERT.8xp, 3) Delete the certificate.

If the program instantly quits on you, that means that you either 1) are using an 83+ (I'm not sure if this will work exactly the same) or 2) have low batteries. If it quits while it is installing, that means it encountered an "F" size byte and figured it's just better to quit. This really shouldn't happen.


So have fun, I made this program as secure as possible. I don't believe you could do anything to crash it, other than maybe pulling out your batteries. (Which is a bad idea)

Edit, the picture wasn't working right:


Edit2: My files got orphaned.

I forgot about the mirage ON + Apps. That's an easy one, so I'll make sure I do that.

But the ON + Alpha is a lot harder. I don't currently use a GetCSC hook, so I don't really have any way to detect that this has happened because pressing ON does nothing, and pressing Alpha doesn't register as a keypress because it's just a modifier. I'll see if I can find some weird way to detect it because I don't really want to make a getCSC hook as the first thing mirage does when you start it is kill the GetCSC hook.

Yeah, you'll probably have to do something like that. And a quick little check shows that this also happens on the 83+BE on page $1A. So essentially, on every calculator, you can't use the first $200 bytes of the last $_A page.

I didn't know about this so I figured you didn't either. And it's a good thing I told you or else you would have some weird problems later on.

In preparation for the release of boot code 1.03, I was looking through the OS receiving code of the boot code. What I noticed, (I'm not claiming this is groundbreaking), is that the OS header and the signature are both stored at the start of page $3A/$7A.

Since knightOS uses the whole memory for variable storage, I was wondering, what have you done to protect against this? Because if someone receives an update to knightOS through the boot code, $4000-$41FF of page $3A/$7A will get destroyed.

Yeah, I know, who tr1p1ea is. I was just saying that I also found the same thing. The good news I guess would be that we both came up with the same conclusion He just did it long before I did.