Home
JAQForum Ver 24.01
Log In or Join  
Active Topics
Local Time 06:50 02 Aug 2025 Privacy Policy
Jump to

Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.

Forum Index : Microcontroller and PC projects : interpreted source checksum

Author Message
isochronic
Guru

Joined: 21/01/2012
Location: Australia
Posts: 689
Posted: 02:17pm 11 Dec 2015
Copy link to clipboard 
Print this post

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 !



Edited by chronic 2015-12-13
 
viscomjim
Guru

Joined: 08/01/2014
Location: United States
Posts: 925
Posted: 05:41pm 11 Dec 2015
Copy link to clipboard 
Print this post

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: Thailand
Posts: 2209
Posted: 05:46pm 11 Dec 2015
Copy link to clipboard 
Print this post

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.:)
Edited by MicroBlocks 2015-12-13
Microblocks. Build with logic.
 
isochronic
Guru

Joined: 21/01/2012
Location: Australia
Posts: 689
Posted: 01:24am 12 Dec 2015
Copy link to clipboard 
Print this post

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.
Edited by chronic 2015-12-13
 
HankR
Senior Member

Joined: 02/01/2015
Location: United States
Posts: 209
Posted: 09:18am 12 Dec 2015
Copy link to clipboard 
Print this post

  Quote  
One of the Ariane rocket take-off failures (read: explosions !), it was said,
was ascribed to a random bit failure in memory.


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: Australia
Posts: 689
Posted: 05:39pm 12 Dec 2015
Copy link to clipboard 
Print this post


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: Australia
Posts: 6283
Posted: 07:33pm 12 Dec 2015
Copy link to clipboard 
Print this post


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
PRINT chksum
PRINT
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: Australia
Posts: 689
Posted: 09:41pm 14 Dec 2015
Copy link to clipboard 
Print this post

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: Australia
Posts: 689
Posted: 02:03pm 17 Dec 2015
Copy link to clipboard 
Print this post


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 States
Posts: 209
Posted: 07:17pm 17 Dec 2015
Copy link to clipboard 
Print this post

  chronic said  
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..


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.
 
Print this page


To reply to this topic, you need to log in.

The Back Shed's forum code is written, and hosted, in Australia.
© JAQ Software 2025