Programming of the Past
by Albert Einstable
I belong to the generation of programmers who contributed to the development of information technology when it was still called "automatic processing of information" in the 1980s, when mainframe systems were programmed pending the first personal computers.
The operating systems were very generic and not very personalized and the customizations were made by us programmers with very long and boring lines of code initially in assembler, then FORTRAN, COBOL, PL/1, and RPG, in particular in this case on IBM systems (System/360, System/32, System/34, System/36, System/38, up to AS/400). We can say that we were the first to do something by generating those program lines that today we could call the first hackers.
To give an example, to generate program lines in assembler, each field (data or numbers) to be used in the program itself had to be declared in the opening in the registers, but above all "clean" as if they were boxes to be prepared for subsequent processing. But the declarations, the dimensions, and the cleanliness of the field had to take into account whether you worked or would have worked with integers, decimals, alphanumeric, text; but also the presumed lengths of both integers and decimals, obviously also including the fields that would have been generated as results from the elaborations.
You can imagine what it meant with complex programs when the fields to be declared had to take into account input fields, constants, processing fields, transformation fields, and output fields for hundreds of fields and constants of a single program.
And this is where the true story of the first hackers begins, which I would say was born out of necessity and therefore with a small ethical semblance.
To generate these programs, it sometimes took days or weeks of work by a programmer, also because in the tests the famous "overflow" errors often occurred, i.e., incorrect declarations of the fields, which depended on the variables and constants entered.
Once the program was completed and tested, the source lines were "compiled" and transformed into an object program (not editable). While the source remained the property of the programmer or his company, the compiled object program was transferred and installed to the customer. The source program was practically never left to the customer, except in exceptional cases, but in any case the complexity made any attempt to manipulate third-parties useless (there were at least thousands of lines of code, sometimes tens of thousands).
It sometimes happened that the customer did not pay, or delayed the payment, or no longer paid the balance or maintenance after purchasing the program or going into litigation for some other cause.
How would you protect yourself from these risks?
Simply by inserting lines of hidden code in routines that could generate an overflow error in the presence of a certain event, so that the programmer needed to intervene with the source to return a new compiled object program.
Malware routines were called in the presence of, for example, a calculation like this:
Where uyear was the year of the system (not editable because taken from the operating system), while xy contained a variable calculated by the program itself in subroutines which could be an event counter or a variable that could be set from a hidden field or from a calculation made by the serial number of the software which resulted in the number of years in which the guarantee of operation was desired.
In this case, after two years the program called the routine-x which suddenly overflowed the program, while showing a message of "call for assistance." The most common overflows were given by declaring an integer field and then processing it in decimal, so that the decimal part was seen as "overflow error."
I am aware that it was a trivial and perhaps not very intelligent solution, but always consider that we were precursors and only custodians of computer programming in a world where programmers hardly existed yet.
Even today, these subtle systems are widespread among teenagers, video game programmers, or even, it turns out, on large systems or companies that use programmers that develop software independently, in the event that the source code part is not intended for sale to the customer.