![]() |
Forum Index : Microcontroller and PC projects : interpreted source checksum
Author | Message | ||||
isochronic Guru ![]() Joined: 21/01/2012 Location: AustraliaPosts: 689 |
Now that interpreted source is being sent and updated remotely as a routine thing I think interpreted source needs an inline check of some sort. Normally of course there are checksums and so on when the program is set into place, but that does not check that the the original source had self-consistency, or that the embedded source is exactly the same after a few years in eeprom. So I have tried a simple checksum-like approach which seems to be working well so far at least. The command looks like QCNTRL 123456.. 999999xx.. When run the command sums the source ascii (using a method) as an integer and compares it to the first number. If it matches the program continues as normal. If it does not match, the program reports the sum and aborts eg before causing damage. For convenience during development, if the first number is zeros, the command is bypassed. When ready, the programmer sets the first number to the correct value, and thereafter if there is an unintended change the source won't run. Of course changing the number from zeros also changes the ascii so the sum itself changes, typically increasing a small amount. This could be an exasperating progression ! So the second number is used as a sponge where each '9' can be decreased to knock down the sum a little in compensation. A little trial and error then leads to a self-consistent setup. The first try, the sum is reported. This number is then put into the source. The second try, the new sum is reported. The source is then updated. It is probably very close to a match now so the second number can be nudged down to suit. A third try is probably not required but is not a huge hassle if needed. It is not absolute of course, if one bit changes then another could as well, with exactly a complementary change that annulls the effect of the first. Unlikely but possible. However the chances are getting very small at that point. Testing works ok, if I so much as add a space the altered program is rejected. I am tempted to label it a "quoll" or better still a "madge" --- older aus readers can guess ! |
||||
viscomjim Guru ![]() Joined: 08/01/2014 Location: United StatesPosts: 925 |
M I N D = BLOWN! Can you post a simple example of this so I can wrap whats left of my simple mind around the process? How would one implement something like this? |
||||
MicroBlocks![]() Guru ![]() Joined: 12/05/2012 Location: ThailandPosts: 2209 |
When you transfer with XMODEM the protocol has a checksum to ensure correct transmission. If otherwise it is transferred over TCP/IP only packets that are correctly received (checksums match) get on the stack to be processed. Checksums are already calculated for each packet and when it is incorrect a retransmission of that packet is done. It all happens in the background. This would then insure that once data is received it will be correct. Would you then still need to do a checksum on the source code? Once it is stored in flash and it gets corrupted, the chance that the checksum algorithm is corrupt is just as big. You would then need a check if your checksum algorithm is still correct by using a checksum.:) Microblocks. Build with logic. |
||||
isochronic Guru ![]() Joined: 21/01/2012 Location: AustraliaPosts: 689 |
Ok (virtual example)... Say you are developing a small program. During development, you put the command QCNTRL 000000 999999 in the source. As the first number is zeroes, the command does nothing, and so lets you edit/run/debug and so on in peace. When developing is finished, you want to activate the run time check. So you alter the zeros to a number. When the interpreter sees the command, it will see that the number is not zero, and check that the number matches the added ascii values of the characters in the program. So if there are say a thousand characters, the number will be the thousand ascii values added. You could analyse it, or just start with a first guess say about 70000 ? When it runs, the number will mismatch and the interpreter will gripe and report the number it finds (say 75432). So you alter the 70000 to the number reported. Altering the 70000 to 75432 will also add 14 to the next found sum. Now the run reports a number that is very close (say 75446). In summed-ascii this is 5 away from your input number, so you can alter the 999999 so as to trim it down by the difference. ( eg 99994 ). Voila it matches and runs! Now if anything alters the text , there will be mismatch and the altered program will be rejected. @MB The beauty is, both the algorithm and the number have to be correct to pass - so if the algorithm is corrupted it will probably cause exit as well. Though there is a case I guess for an interpreter to check its integrity on startup. The algorithm is very small in any case, depending on what the addition includes of course. One of the Ariane rocket take-off failures (read: explosions !), it was said, was ascribed to a random bit failure in memory. edit - Implementing it, is simple in C. As for altering MMBasic to incorporate it, the gurus Geoff/Mathias/Jean would be your best bet I guess. XMODEM is a bit redundant now unless there is actual rs232 I think. AFAIK the usual usb-modem link ( CDC or HID and 1k packets, I forget which ? ) incorporates transmission error handling in any case. |
||||
HankR Senior Member ![]() Joined: 02/01/2015 Location: United StatesPosts: 209 |
I think the reference here is to Ariane 5. The failure mode was in fact software related. A conversion of a 64-bit floating point to 16-bit signed integer value caused a software exception which then had disastrous results. The 64 bit value was out-of-range for signed 16 bit integer representation. The terrible thing is that the calculation did not even have to be performed when it failed, and was only done because it was required by the operation of the predecessor vehicle, the Ariane 4, and that function was left in the code but was entirely unneeded for the Ariane 5 *after-launch phase*. With Ariane 4 code needed to work before and after launch and worked okay in both phases. With Ariane 5 same "old A4" code needed to work before launch only; worked okay before launch, failed almost immediately after launch. If the code had been disabled so that it would not have been run after the A5 launch, all would have been okay. See these documents, the first being the definitive report of the official board of inquiry: http://www.ima.umn.edu/~arnold/disasters/ariane5rep.html people.cs.clemson.edu/~steve/Spiro/arianesiam.htm Many of the rocket explosions we see at, or shortly thereafter launch (actually most), are explosions ordered by the range officer or automatically initiated intentional self-destructions, both for safety purposes. The latter was the case for the Ariane 5 software failure incident. Hank |
||||
isochronic Guru ![]() Joined: 21/01/2012 Location: AustraliaPosts: 689 |
At a guess, the MMBasic interpreter could calculate the sum using a 64 bit integer easily enough. It would have to have access to the user basic text source of course. I don't know if the CFunctions can see other program bits though, maybe it could add the machine code bytes for the same effect. An xmas project for the gurus matherp/geoffg/microblocks etc ! re ariane - by coincidence this is a near anniversary of Aus satellite WRESAT, launched from Woomera November 1967, orbiting till Jan 10. With er, just a little help via some US Redstone initial stages.. I think they found the spent first stage, in surprisingly good condition, in the outback in the '90s. |
||||
TassyJim![]() Guru ![]() Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
Doing a checksum of the normal program memory is not difficult. I am not sure where the library code is and Cfunctions and (maybe)saved variables would need adding to the mix. ' TassyJim ' ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' FOR n = 1 TO 750 b = PEEK(PROGMEM, n) chksum = chksum + b PRINT HEX$(b)+" "; IF n MOD 16 = 0 THEN PRINT NEXT n PRINT chksum PRINT "Normal program starts..." PRINT "*"+rtrim$("Fred")+"*" PRINT "*"+rtrim$("Fred ")+"*" PRINT "*"+rtrim$("Fred "+CHR$(13)+CHR$(10))+"*" PRINT "*"+rtrim$("Fred"+CHR$(0)+" ")+"*" PRINT "*"+rtrim$("Fred"+CHR$(13)+CHR$(10)+"Wilma")+"*" PRINT "*"+rtrim$("")+"*" END FUNCTION rtrim$(txt$) LOCAL cull$, k cull$=CHR$(0)+CHR$(10)+CHR$(13)+" "+CHR$(9) IF txt$<>"" THEN FOR k = LEN(txt$) TO 1 STEP -1 IF INSTR(cull$,MID$(txt$,k,1))=0 THEN EXIT FOR ENDIF NEXT k rtrim$=LEFT$(txt$,k) ENDIF END FUNCTION When you do an autosave, you are told how many bytes are involved. Jim VK7JH MMedit |
||||
isochronic Guru ![]() Joined: 21/01/2012 Location: AustraliaPosts: 689 |
Is the Fred and Wilma a test of the rtrim (?) Stripping out cr/lf seems a good idea but I don't know about the others. I have found a "splinter" though it is not serious. If the last digit of the number itself is altered, eg increases by one, then the ascii sum also increases in sync so the addition misses the change. It only happens for the last digit - ten possibilities. So I propose to keep the last digit always 0, and the adjustment number can be adjusted to suit. If the 0 changes the algorithm can reject it always. |
||||
isochronic Guru ![]() Joined: 21/01/2012 Location: AustraliaPosts: 689 |
Update - have tried it and it works OK. So the action is : a) if the cited number is zero, no further check is done. b) otherwise, if the first number literal does not end with '0', the program is rejected and message printed. c) otherwise the relevant ascii source is summed and the numerical result compared to the number cited. If it matches there is no further action. Otherwise the program is rejected and message printed. The message includes the actual sum found. The number is easy to create, by trimming the filler that follows it, so as to end in 0. eg if the sum number ends in 2 with the filler all nines, you adjust a nine to seven for the initial match; then decrease the sum number 2 to end in 0, and knock the seven down to 5 in sync. |
||||
HankR Senior Member ![]() Joined: 02/01/2015 Location: United StatesPosts: 209 |
Thanks for mentioning this red-letter date in Australian spacefaring history. Read up on quite a bit of this on the web. Fascinating. I had an older cousin who was dispatched from Los Angeles to Australia for a few years to do something with the Deep Space Network. He wasn't apparently allowed to go into any detail about his work then. Wish I knew more about what he was up to. |
||||
![]() |
![]() |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |