tarkb
commented
9 years ago https://oeis.org/wiki/Email_Servers_and_Superseeker https://oeis.org/ol_source.txt
Another possible source for finding the "checksum algorithm(s)" since they seem to be "constant" and only vary with the "stroke number." The "checksums" can be viewed as an "integer sequence" so assuming there is some rhyme or reason to them, algorithms used to find other "integer sequences" may show some hints as to the algorithm/operations involved.
I do have a (very old) Mathematica + license, so may look at ol_source.txt some day. Too many other projects, so little time :)
"superproc8.f / superproc9.f "
Fortran is perversely enticing ... and you thought it was obsolete, noone used it anymore :)
I have not really found any generic "algorithm brute force" program for arbitrary data, but such a thing should not be hard to write...the trick is
1) time to run
2) operations to support between "steps" in the sequence, to go from:
value A -> value B -> value C
this could be a number of operations (add 1st and 2nd bytes, shift 3rd byte left 3, complement
8th byte, etc. -- lots of possible operations and also operands, some possibly involving
constant operands not within the data itself..."add" itself has variants "ignore overflow" or
"store high unit to xth byte" so even that is not so simple...god forbid any of the data is "signed"
and yet more possibilities...
so while a "brute force" in theory would work eventually, it may not be
computationally feasible3) values may not be on even "byte boundaries", would need to guess the bit and byte endian and also "bit size" (e.g. some values might be 4 bits long, others might be 16, etc.)
Which makes generic "brute force" of the algorithm to go from one "checksum" to the next likely to take too long to be feasible without further information. That said, a "typical" search might be feasible, e.g. assume all values are each one byte long, maybe clamp number of operations per transition to 10.
an interesting tool for visual comparison of arbitrary data:
"Protocol Informatics - Tools for Binary Protocol Analysis"
most things I have seen about reverse engineering say "have lots of time & patience, be prepared to write your own tools"...not sure there are too many "generic" tools out there for data of unknown format...even finding the format of one particular field would narrow things down a lot.
The smarter/quicker approach of course is to debug/decompile steno programs/drivers whose license does not forbid this. Or someone has/makes a contact who knows the details :)
The StenoRam itself, the software on it could likely be "dumped" and decompiled too...no idea of the hardware needed/legality of doing that :) AFAIK in the U.S. reverse engineering is generally allowed by default (IANAL...thank god!)...which is why much software you must agree not to reverse-engineer or decompile/disassemble it in order to use it :)
Ben Tarkeshian has posted notes of reverse engineering a stenoram machine to the point where it might be possible to add plover support.
vim: foldmethod=marker
SR3_REVENG_v0.0.2.txt
CHANGELOG: v0.0.2 no need to clear stenoRAM beforehand; init sequence has the "starting" stroke number for "QUERY" / "NO STROKE" exchanges
DISCLAIMER: {{{
This I believe is the bare minimum for how to write a "working" driver; there are still many gaps and this is still very much a rough draft.
And the usual:
}}}
misc. notes: {{{
stroke data is sent as either:
it seems, whenever a "one byte" stroke is keyed, it is always sent as one byte; this means some combinations of keys for the "2-byte" or "3-byte" stroke formats may not actually ever be seen on the wire
in practice, it shouldn't really matter to a driver; it is unambiguous how to decode 1, 2, and 3-byte strokes;
a single "stroke packet" can contain from 1-3 strokes (that is, up to 3 "really fast" strokes might get crammed in a single packet)
there are (at least) 3 different (what look to be) 8-byte "checksums" --
the 2 "checksums" that seem to be "mandatory" to "understand" are:
both of those seem to only be generated from the "stroke number" count, so it is sufficient (if incredibly ugly) to just log each checksum/stroke number pair and build a table, and then the driver knows what to expect/send; reverse engineering the "checksum" format would still be ideal of course
the 3rd checksum is included with stroke data and I assume more useful, and I assume can be used to detect if corrupted stroke info. was received; understanding it would also be ideal, but it seems like it can be entirely ignored for a "bare minimum" implementation
}}}
some possibly useful tools and documents for finding the "checksum" algorithms {{{
(google these)
}}}
{{{ INIT
1 WRITE:28: 16 03 00 00 01 00 00 FF 09 00 BA DD B5 9A 8A 91 25 A4 03 00 00 FF 00 00 02 01 03 00
2 READ_:26: 16 03 00 00 05 00 00 00 08 00 36 9F F4 8A 4C 0C 3C B5 8E 46 0D 01 53 52 33 20 "S""R""3"" " in ASCII
3 WRITE:28: 16 03 00 00 01 00 00 FF 09 00 99 27 52 26 BD 34 6C F8 04 00 00 FF 00 00 02 01 03 00
4 READ_:21: 16 03 00 00 06 00 00 00 03 00 00 00 00 00 4C A8 18 1A 00 00 00 ^^ ^^ for the SR reply, what matters is the stroke number; the PC should take that stroke number, and
}}}
{{{ INITIAL "QUERY FOR STROKE" EXCHANGE
}}}
{{{ SHUTDOWN
}}} ================================================================================
{{{ FLOW OF EXECUTION
do the "INIT" sequence; this determines at what stroke number the initial "PC QUERY FOR STROKE" and "SR NO STROKE REPLY" bytestrings should start at
until PC starts the shutdown sequence do
{{{ 28 bytes: ( 10 constant bytes: 16 03 00 00 01 00 00 FF 09 00 {{{ * 8 variable (well...hardcoded to stroke number...) bytes: DE 0A BB FF EA 2E 97 41 # 01 00 00 90 C8 55 A6 C8 D2 1C E6 # 01 01 00 4C FD 6C 00 28 C2 EB 3A # 01 02 00 5B F0 AD 04 B7 E2 F1 F9 # 01 03 00 D4 18 93 2A B4 94 BF 07 # 01 04 00 8C 0B 98 46 64 20 5B 4B # 01 05 00 74 12 94 B0 59 82 8C 89 # 01 06 00 D8 BD 8F DA B7 CD FE DD # 01 07 00 4F 34 E2 7C 39 EA 04 F3 # 01 08 00 03 77 9D 85 C4 38 F9 D3 # 01 09 00 00 44 28 CB E8 EA 62 C6 # 01 0A 00 ... }}} 1 constant byte: 01 * 2 variable bytes: Y0 Y1 (stroke number) 7 constant bytes: 00 64 00 02 02 03 00 }}} )
{{{ * 8 variable (well...hardcoded to stroke number...) bytes: 07 01 FF FB 1E C4 6D 92 # 00 00 FF FF FF 00 00 00 00 00 EC 49 41 B3 # 00 00 00 00 00 00 07 05 08 0E 91 4F 4E C5 # 00 00 01 00 00 00 0E 0A 10 1C A5 6C 11 1B # 00 00 02 00 00 00 79 17 2C 4A 7F E8 C4 29 # 00 00 03 00 00 00 1C 14 20 38 38 40 24 E2 # 00 00 04 00 00 00 63 19 28 46 0D D0 CE 55 # 00 00 05 00 00 00 F2 2E 58 94 08 54 6D 95 # 00 00 06 00 00 00 5D 6B 9C E2 AD 78 81 DD # 00 00 07 00 00 00 38 28 40 70 37 38 56 AE # 00 00 08 00 00 00 3F 2D 48 7E 74 12 39 98 # 00 00 09 00 00 00 C6 32 50 8C 26 39 F5 F8 # 00 00 0A 00 00 00 ... }}} 2 constant bytes: 00 00 * 2 variable bytes: Y0 Y1 (stroke number) 2 constant bytes: 00 00 }}} ) end
done
}}}
{{{ STROKE DATA
{{{ the SR sends 25-33 bytes containing stroke information (
{{{ determining the size of the stroke info. "packet" ( if single stroke in this transmission, SR sends 24 + (1, 2, or 3) bytes if two strokes in this transmission, SR sends 24 + (1, 2, or 3) + (1, 2, or 3) bytes if three strokes in this transmission, SR sends 24 + (1, 2, or 3) + (1, 2, or 3) + (1, 2, or 3) bytes:
}}} )
{{{ 24 byte "header" ( constant 8 bytes: 16 03 00 00 03 00 00 00 {{{ variable 1 byte: L0 how many bytes follow the X variables if 1 stroke in this transmission: 07-09 for 2 strokes: 08-0C for 3 strokes: 09-0F (to replicate 0F: try hitting -Z quickly, }}} since a single -Z is sent in 3 bytes) constant 1 byte: 00 {{{ variable 8 bytes: X0 X1 X2 X3 X4 X5 X6 X7 }}} checksum of some sort perhaps {{{ constant 2 bytes: 01 00 indicates: "1 stroke in this packet" 02 00 indicates: "2 strokes in this packet" }}} 03 00 indicates: "3 strokes in this packet" {{{ 2 variable bytes: Y0 Y1 stroke number, increments after every stroke;
}}} 00 0F (Y0 Y1 after the stroke) constant 2 bytes: 00 00 }}} )
{{{ 1-9 bytes of stroke data ( {{{ EITHER ( variable 1 byte: Z0
}}} )
}}} )
}}}