Re: Datasheet-flation?

On 11/29/2024 6:44 PM, Carlos E.R. wrote:

On 2024-11-30 02:00, Don Y wrote:

On 11/29/2024 3:30 PM, Carlos E.R. wrote:

My first job was as programmer for small company. They had tasked an external programmer with creating a software for them with LabWindows. This thing creates displays; think a virtual oscilloscope display, for instance, measuring things like temperature, pressure, rpm, etc. My boss says "I want you to add a voltage display". Simple.
>
Well, the original programmer had removed the header file that assigned labels to both the display windows and the code. The code would say "display_crt(31, A1)", where 31 was the element in the display to display rpm, for instance. If I inserted "voltage" in the display window, all the numbers shifted by one, so that 31 became pressure, for instance.
>
The programmer had sabotaged the code so that no one could touch it by replacing labels with their values.
>
It took me months to recreate the header file with labels. My boss thought I was useless: it is difficult to explain this to a non programmer.

>
I took a contract, years ago, to address a similar issue; they had hired
a "student" to write the code, he managed to get it working, then finished
school and "moved on".
>
Of course, they eventually wanted to modify the product and discovered that
they didn't have a *copy* of the source code -- not even a PRINT copy!
>
So, I reverse engineered the binary (not just "decompile" because that
sort of result adds very little to understanding the code) adding comments,
judiciously choosing function and variable names, etc.
>
Some years later, I took on a much larger reverse engineering job (500KB
binary).  But, relied on tools to help with a lot of the grunt work.
>

I carefully documented since then every program I wrote. I did not want any other person to suffer what I did.

>
Be thankful it wasn't intentionally obfuscated!  In your case, all you had
to do was recreate the symbol mappings.  Imagine if the original code had
been passed through an obfuscator so, in addition to symbolic names, the
actual control flow had been deliberately distorted!

 Huh. I think not, because then the LabWindows environment would not run.

Obfuscators preserve the intended functionality.  They just dick with
the steps to get TO it.
E.g., display_crt(31, A1) might be transformed into:
     figger = 961;
     bugger(123, 9987, foo);
     blandow();
bugger(int vvvrs, int vvvsr, char *gobbler) {
     fftre = strlen(gobbler) + 88;
     for (greg = fftre; greg -= 3; greg > 4)
              sstste += greg[gobbler];
     figger += 8*8 - 1;
}
blandow() {
     display_crt(sqrt(figger), A1);
     figger -=25;
}
Though, more likely, superfluous whitespace and newlines would be
omitted just to make it look like a REAL mess!
[If I've done this correctly (in my head), you will see that display_crt
is invoked with the same arguments in your original case.  There's just
lots of other cruft inserted that does nothing productive (though that
stuff could also be looking forward to something ELSE that will be done,
later -- e.g., arranging for figger to have a particular value that
can be exploited later.]
You can also "break rules", like using values left on the stack after
a function return -- because you KNOW you aren't going to do anything
to compromise those values before you can access them (a taboo,
otherwise)

For closed designs, it is relatively easy to embed invisible dependencies
in the code that are highly resistant to "tampering" (revising the
software is just a special case of tampering!).  If you don't understand
that this has been done to thwart your efforts, you can spend AGES looking
for elusive bugs that have been DESIGNED to deliberately hide!
>
[The goal of any such effort is to increase the cost of copying/modifying
to the point where it approaches the cost of designing from scratch]

 Or to force hiring again the original developer.

This is most often done BY the principal to protect his IP.
I had a client complain that my code was "broken" (I provide free
lifetime support as an indication of the faith I have in my
deliverables).  Yet, the binary he delivered in the sample product
(I don't keep client prototypes as they take up too much space)
was obviously different from the code delivered (amusing how
often this happens!  Do you really think I won't notice that you're
giving me something that is different from what I delivered?  Do
you think that I don't KEEP copies of all this stuff???).
He begrudgingly admitted that he had run an obfuscator on my
code with the "guarantee" that the code would function as originally
intended.
Nope.
"Well, can you at least take a LOOK at it?"
"Sorry, I have no desire to sort out YOUR mess.  Talk to the folks
who made the 'guarantee'."
Your goal (as an employee, contractor, supplier, etc.) should always
be to have the client/customer NOT need you after the "sale".  If
he likes what he got, then he'll come back for more work/product.
Forcing or coercing the client or customer inevitably leaves a
bad taste in their mouth -- that they associate with *you*!