On 12/22/2014 05:29 PM, Chris Angelico wrote:
On Tue, Dec 23, 2014 at 6:57 AM, Dave Angel <d...@davea.name> wrote:
I figure I must be misunderstanding something in your explanation, since a
brute-force password guesser would seem to only need four billion tries to
(probably) crack that.
<snip>
As to the assumptions... uhh... that was never something I really
understood. I think you're probably right, and this was part of the
paranoia of "my code might be stolen". You're attempting to attribute
a level of logic to the requirements which has no supporting evidence
:)
I recall a DLL that implemented the license check, and an application
called a function in the DLL and looked for true or false. Even the
exported function name was a pretty good clue. And extremely easy to
intercept and defeat. I did convince the company (my employer, though I
didn't normally work on the license stuff) to statically link instead.
And to stop shipping all the symbols with the executable. Most security
flaws are of this form, not sophisticated cracking.
I also wrote my own form of protection in 1976 to make it difficult for
somebody to retrieve source. The previous version had simply added a
protect bit to the image file. Mine saved a completely different file
every time you re-saved the program data, to try to make it hard (not
impossible) to recover it. Then it stored a separate key in each sector
of the file so reading it into the interpreter was always possible. I
had a couple of constraints - the file couldn't grow, and it had to be
fast enough to have no impact on load time.
I had a guy claim that the CIA got interested in the code, and cracked
it during a lunch hour. But I suspect somebody got hold of the source
code, which was available to our field service staff.
There were a couple of iterations before this code was stable. Not in
the algorithm, but in what amounted to a few back-doors. For example,
it turns out the error display logic would show the line in error,
unencrypted. So people would munge the code sufficiently to cause
errors on most lines, and retrieve them one at a time.
Another thing I did in 1976 which was apparently unusual was to add a
checksum to the code itself. The Boot Rom would self-check before
starting the machine, and it also checksummed the loadable microcode
before passing control to it. Prevented some corruption problems.
Another thing that machine did was to run a RAM diagnostic from the time
it booted till the operator specified the drive from which to fetch the
microcode. The entire test took many minutes to run, but it was
entirely silent unless a problem occurred. No pass counts or anything.
When I added that code, manufacturing found some machines that had
been put aside as flaky, actually had RAM errors. The test was
necessary crude, because the entire boot, including disk logic, had to
fit in 1k.
Ahh... memories.
--
DaveA
--
https://mail.python.org/mailman/listinfo/python-list
