The delights of on-site working – sun, sea and... WordPad wrangling? Welcome to Who, Me? The Register's open-all-hours confessional for readers who really need to get that one dastardly deed off their chest. Today's tale comes from a reader whom the patent-pending Reg randomiser has elected to call "Javier", and is inspired by the antics of Ben, notepad and an innocuous file called print.exe. …
It probably wasn't WordPad, it was probably an early version of Write (Win 3.0 or earlier) and our pal Javier misremembers.
Procedure was something like rename program.exe to program.txt, open it in Write, make changes, close file accepting changes, then rename the .txt back to an .exe. I might be off slightly in the details, but that was the gist of it. Folks in the know had this version of Write in their bag o'tricks disk and moved it from version to version of Windows.
I have kept a copy of Win3.0's version around for this very thing (and a few other bits and bobs) right up until today, on my last Windows machine (Win2K, which I only keep around for ACad2K. She's airgapped, so fageddaboudit.)
I seem to remember Wordpad being the sweet spot between Notepad and Word, both of which used to sneak all sorts of crap in and bork files if you weren't careful with what you fed them.
That said I'm also quite surprised it worked for editing, but I've also used it to pull ASCII information out of such files before.
I've certainly used WordPad/write to edit binary files. As long as you go into overwrite mode and stick to changing visable text you'll be OK. Don't let it insert or delete anything, and keep a backup first.
Indeed, to this day I add write (and notepad) to the Send To menu.
Under MS-DOS, I typically used Norton Utilities' binary editor, and have at times managed to alter strings in executables and libraries in DOS, when access to the code was missing, or recompiling the whole shebang to correct a simple typo in the user interface took longer than performing the edits in code and executable or library. Under Windows, Wordpad could indeed be used.
I once edited binary code from a company that went out of business. You had to be an authorized user and the code was valid only for a particular machine. I found the branch after the test for valid machine and inverted the test so only invalid machines could run the code. Worked like a charm.
Many moons ago in the early 90s I was doing code and hardware development for smart payphones (basically a microcontroller with support hardware that appeared to the user as a payphone (they were very popular in the USA at the time).
We were asked to do support for a different vendor (who had no engineering presence in the USA). One fine day some of these arrived at the company for repair.
The code (68HC02 as I recall) calculated the amount of money to be deposited for a particular call, but with some entries the result was clearly wrong (it couldn't even display it properly - it appeared the unit had gone completely wacky).
I extracted the contents of the EPROM (UV type) and armed with only a linker map went in search of the calculations using my (purloined) copy of Norton Utilities and I found a division routine that was possibly the worst piece of code I had seen up to that time and whoever had written the multiply and divide code had clearly never heard of underflow or overflow testing or even 'add and shift' or 'test, subtract and shift' which apart from being somewhat elegant have the advantage that the runtime is relatively data independent.
Once I figured that out, I got the instruction set mnemonics and codes from the datasheet and hand assembled replacements for said routines which were (thankfully!) shorter than the originals, then edited the hex file with the new routines (unused locations were padded with NOPs), burned new EPROMS and then everything worked properly - took me about 4 days IIRC.
I was asked if I could edit the background 'music' data to play something different but the quote we gave them for that meant I did not get lumbered with that.
Icon for the original coders.
One weekend when I was on site, the z/OS customer had a problem for which there was a fix. The usual people who down loaded fixes were not it, so I downloaded it, emailed it to the guy sitting next to me, and he uploaded it. It fixed the problem, but occasionally dumped. We decided not to put the fix into production.
When I looked at the dump, I could see the module was corrupted. It dawned on us that during the download and upload different character sets had been used, and so a few instructions were subtly different. We learned not to take short cuts.
Oh hell, I'd forgotten about the accidental mangling of source code files due to this. Damn, that's one hell of a repressed memory, and for good reasons too. It didn't take me long to switch every download into binary mode, which was easier in some systems than others because in some it was a set operation and others it was a toggle operation... eeek... shudders...
Maybe ASCII mode. Maybe the ASCII to EBCDIC conversion (z/OS was mentioned, and the FTP conversion tables for ASCII to EBCDIC are... strangely not as you would expect). Also, I've found that some (non-Unix) systems mess around with the end of a file (padding with nulls to the nearest whole word, for example).
Binary mode in FTP is nearly always safe, but padding to a whole word will change the checksum on a file, something that has caught me out more than once.
Also, if you're using an OS and a storage type that dictates fixed-length records, there's scope for FTP to mess this up as well, unless you really understand what you're doing. Fortunately, these OSs are now comparatively rare, and even the ones that have this hangover have introduced the concept of variable length or free format files.
Back in the DOS 3, 4, and 5 days you didn't even need FTP to mangle your source files. Just use Microsoft's EDIT command. I discovered early on that some of my source files for Microsoft's MASM would skip about one line for every 30 lines of code. Using DEBUG, I found that periodically EDIT would sometimes terminate a line with cr-lf-lf instead of cr-lf. MASM would then think the line of code with the lf at the beginning was a comment. The solution was to purchase Wordstar for the IBM PC-JR, available very cheap at the time from Egghead. A few changes had to be made to the program to change screen settings, but that solved the problem of extraneous characters.
Greybeards might recall the standard from its brief life as an interface bus for early microcomputers, or as something used to hook up testing gear.
Pahh - I'm only 55 and clean-shaven! I remember hacking this to get a better logging program for a rather magnificent data logger from HP In fact they (HP) liked it so much they offered me a job post PhD.
Science equipment to this day is still sometimes shipped new with GPIB (IEE-488). Some are finally taking up USB. However often if there is USB and GPIB, you find yourself using the GPIB because some companies do crap proprietary DLLs for the USB communication that go out of date or don't work on your operating system (some of us run experiments on linux). Some do use USB as a simple virtual serial port, and slowly people seem to be moving onto USBTMC.
you find yourself using the GPIB because some companies do crap proprietary DLLs
This. So much this. If it has USB, or worse yet network, and we don't have source to the firmware, that feature isn't used. If there's no alternate we don't buy the hardware. And yes, that decision gets pushed to other sites. Long live GPIB!
Even in fiction, they look to be using some form of GPIB to hook up R2-D2 in the various Star Wars movies, reckoning by the cable thickness. Or tag and bus. Now we know why!
Yes, the Commodore PET had IEEE-488 routines hard coded into its ROM. Very handy when using 6502 assembler - a bit confusing though with calling all the TALK, UNTALK, LISTEN, UNLISTEN routines etc. My triumph was to get two Commodore PETs "controlling" the same pieces of equipment over IEEE-488 by using a collision detection system in 6502 assembler. Happy days - and then we got the IBM PC running at a staggering 8 MHz and the Aztec C compiler. I was told that our lords & masters chose Aztec because it was being used by the CEGB in nuclear power stations - but that could be an apocryphal tale.
I think Aztec C was the compiler I used on an Atari ST. As for atomic power stations, I bought a bunch of hardware that was decommissioned from such places back at the turn of the millennium. SCADA like systems, running on DEC Vax hardware and programmed in C using the compilers that came with VMS and Ultrix.
GPIB reminds me of National Instruments.
Sometime in the 90's when I was first introduced to NI by a semi-retired scientist who was brought in to help a company with product development. I ended up as an assistant and was exposed to all kinds of new (to me) things. Test instrumentation and data analysis were the things I found to be "the coolest". NI software was amazing back then.. haven't looked at it for years now.
After a quick search , looks like NI is still alive...
https://www.ni.com/es-cl/innovations/white-papers/06/the-national-instruments-gpib-advantage.html
and hated because they repeatedly broke backwards compatibility since I started using it ('90s). I must be the last person on the planet reverting to version 4.0 for controlling experimental hardware. That was the last version you could just carry around on some floppies :).
Those monstrous IEE-488 (GPIB) cables, though, have now vanished in the drawer.
I remember that at one place we used to have users edit their autoexec.bat and disable all sorts of programs like network connect and anti virus (this was around the time of the "I love you" virus.
We had to hide the Autoexec.bat so what we did was changed it's name from Autoexec.bat to reboot.com but it would work because someone discovered that you could have your autoexec start as follows
REMZZthufex
then the bat script
then some wierd characters at the end which was the reboot.com code (4 bytes only )
then we used the assembler to edit command.com and change the string AUTOEXEC.BAT to REBOOT.COM and it was all ready to go.
Reboot.com rebooted the machine
MOV AL,0Fh
OUT 64H,AL
and the boot script remained hidden.
A friend of mine just bought a milking machine for his goats. It has a IEEE-488 bus for diagnostics. It's brand new, came off the production line in October of 2019. I've also seen it in new marine equipment, aviation equipment, and equipment for geosciences ... and I rather suspect it'll be a standard for MILspec gear until roughly four hours after the heat death of the Universe.
It's also still used in tons of measurement and test equipment (which after all was the original purpose). Your computer might not have a built-in GPIB interface nowadays, but hook it up to a LAN- or USB-to-GPIB adapter and you're good to go.
One of our customers told us that they preferred GPIB over LAN because when an operator trips over a LAN cable, it will rip the cable out of the socket and stop production. With a GPIB cable, the operator might fall and get a bloody nose, but production will be unaffected.
NC had a decent ASCII/Hex viewer and editor - F3 to view F4 to edit. It saved me on more than a few times when some muppet had changed/forgotten a password (Yes, in the 1980s they were often saved as readable text in a key file).
I still use NC and it’s *NIX clone Midnight Commander to have a quick squizz inside copies of database files, etc., searching for particular strings.
In my time, I've edited many binaries using different tools.
I have used the original UNIX edition 6 and 7 DB debugger to patch bootstrap loaders to change the calculation for track and block offsets on a PDP11 with non-standard geometry disks (they responded to the RP04 command and register set, but were actually SMD disks with different numbers of blocks per track). I never did get to assemble the bootstrap from source, it never seemed to work.
The first time (before we had UNIX running), I seem to remember that we used a hex editor on RSX-11M for the initial hack, but I can't remember what it was.
I've also used debuggers to unset the lock bit on an TM03 tape controller when it was left hung, by actually using ADB against /dev/kmem (I also remember doing something similar for a Xerox 4050 large laser printer attached to an Amdahl mainframe running UNIX, but this would have been ADB again).
I used the BEEBUG hex editor to remove the code that checked to see whether thw ROM-based version ot WORDWISE 3 was running in sideways RAM (it tried to overwrite a byte in the ROM, and if it changed, it knew it was in RAM. There was also a checksum checker to defeat).
More recently, when one of the places that I worked at deliberately knackered Evolution to prevent it being used by removing a critical file, I used gdb to change the path in a local copy of the entry program it was using to check for one of the backend processes to a location I could write to and restore the file to.
In my view, this has always been a very valid use of the word 'hacking', without (some of) the negative aspects of the word.
used the BEEBUG hex editor to remove the code that checked to see whether thw ROM-based version ot WORDWISE 3 was running in sideways RAM (it tried to overwrite a byte in the ROM, and if it changed, it knew it was in RAM
Those of us with aftermarket RAM/ROM boards just fitted toggle switches in the r/w strobe :-) BBC Micro, of course, not the later machines which had sideways RAM as standard. My Watford board had a battery for the SRAM chip and very occasionally a power cycle could send spurious writes, so having the toggle switch was mainly a way to ensure that images in RAM were still there next time you switched the machine on.
M.
I did put a switch in *MY* BEEB with an ATPL board (I also added a RAM defeat switch to allow me to disable the RAM bank in case I loaded a duff image).
But the reason why I hacked Wordwise was so I could load it into the built-in sideways RAM in a one of the early Master 128 systems that we bought, which as far as I am aware, did not have the option to have any sort of switch fitted.
I also used it in the student lab of BBC Model B's that I used to manage where we did not want to make it obvious that the systems had sideways RAM fitted.
I also at one time produced a machine code hack that I re-vectored the "switch sideways ROM" OS call (can't remember which it was) so that I could use the Acornsoft Pascal dual ROM package on a system that had just one bank of sideways RAM. Each time it switched, I loaded the required ROM image into the RAM bank. I was really surprised it worked, but many of the lecturers used it on their home systems, not that I condone software copying. Worked fine with systems on an Econet with a hard-disk fileserver, added less than a second to the compile time, but on a system with floppies, it took an appreciable time and some clunking of the floppy drive to switch.
Back in the dim and distant past, php removed support for gif generation libraries between versions (presumably due to licensing issues or something)
This was the days when people still used Netscape Navigator 4, with no CSS support, and all our layout was done with tables, font tags and - relevantly - single pixel gifs in various colours. So that we didn't have to manage a hundred image files, there was a simple php file which would use said libraries to create a gif of the specified colour, and it was used all over the site. This was probably a stupid idea performance-wise but, compared to the rest of the site it was a drop in the ocean
What I did therefore, was open a couple of example images in vi, workout which the bytes were that stored the colour table values, and then change the php code to echo the same binary sting with arbitrary colour values concatenated in there.
How very dare you! NN4 did CSS... badly, but it did it. You might have had to not load it in NN4 to stop it looking terrible.
debug
g=c800:5 to low level format an MFM or RLL drive IIRC ...
If you told a young'un nowadays that you didn't need a manufacturer's dedicated app downloaded from t'internet to hard format a drive they wouldn't believe you ...
I assume that command sequence wouldn't do anything any more ...?
New job! No source control! Source code in several locations, or just plain missing! And multiple copies of source code for the same application!
I ended up writing some code to parse directory structures looking for source code type files. The results went into a database, which I could then query to find the set of source code that most closely matched the applications that were in use. This actually did a remarkably good at bringing under control the uncontrollable.
Just a pity that the boss that caused much of the problem ended up fscking me off to the point where I fscked off!
"And multiple copies of source code for the same application!"
At one job in the past, we had a new PFY, for tools dev, who obviously had missed the SW dev course on version control.
After weeks, we realised he was never checking in the last version of the tool before making an update !
Basically, after a month, he had forked every tool, that the senior dude had to merge back !
It also took a while to explain to him the principles of SW updating ...
I had a colleague who just never could understand how Version Control Software worked. Several of us in that office tried to explain, several times each. The best he could ever manage was committing zips of the source tree under different names!
Not too awful many years ago, I was working the support desk for our product, when an urgent support request came in from a customer. It seems that they had been using an early version of our software product, and it had suddenly stopped working. They wanted to know if we could supply them with a fix for it. Upon querying them, I discovered that the version they were using had been released in 1973, and support had ended in 1976! Find the source? Heck, even if I had found the source, I wouldn't have been able to find a punched card reader to read it with. Nevertheless, through a careful reading of the dump they had supplied, I was able to tell them how to tweak their system to make it work again.
In the late 90s, I developed some SQL Server SPs that fed onto pre-existing CrystalReports templates (version 5 or 6, IIRC). In my office they printed fine and dandy but at the customer's premises the reports wouldn't print. After a lot of toing and froing, I found out that the SQL server's name was hardcoded in the report. As the client had a differently named server (duh!), the reports wouldn't connect to the DB. Some hex editing of the .rpt file later, everything worked again.
That was first time with CrystalReports and, as they say, there's never a second chance to cause a good first impression!
I was inflicted by crystal reports when I was out of the office on a customer site in Sweden.
Had to login during the evening back to the office on a crap internet connection with a 13inch laptop screen to work out how to update a report when I had never seen it before or knew anything about it.
Being out of the office, I was unaware of this so it got palmed onto me by a vote I was unaware of by everyone else that decided to teflon it onto me as I couldn't immediately decline it.
Oh, it, didn't go well either
Oh, I'd managed to forget about that.
I had to learn how to use Crystal reports to get reports out of a SCADA system. On site. In the Abu Shabi desert. With only the help files.
The problem was: Once the word got out that "knew crystal reports" I was instantly elevated to Guru status and got given every bit of fucking CR work going.
Now I need to go and curl up in a ball under the desk for a while!
Best way around becoming "guru" is to make it work JUST enough to get by, and pawn it back off on the proper person who should have bloody done it in the first place to "fix any issues".
Let them have big, bold, magenta comic sans on a lime green background, every third line indented weird, or whatever format bugs are normal.
Worked at a company where our (Windows) MFC serialised files contained references to other files. For anyone who doesn't know, MFC serialisation is essentially a memory dump of the object graph. If you open it up in WordPad, it looks like gibberish. All of that didn't stop some of our users from opening files up in WordPad; doing a find-replace on said files references; and saving files. Much to our amazement, there were no instances of file corruption!
In the past I took over, and rather fixed, two applications written in (Borland) Delphi where the developer, in a fit of ********** (insert range of expletives) used the binary dump of internal objects as the saved file format. Because nothing ever changes in a private data format, between dev software point releases, dev software full releases, let alone versions of the application with slightly different class structures.... ******** (I am remembering how painful this was).
Both applications wound up with XML data structures by the time I finished with them. With versioning of the structure used as the first thing in the file.
You'd imagine that a company with the smarts to create one of the most consistent, coherent and effective mainframe operating systems I have ever used and created its own efficient, clear and coherent language in which to write it might try to hold onto the source code for the compiler of that language, wouldn't you? If so, then you would be sadly mistaken.
It was always a mark of maturity in a young programmer that they could perform a Patch Blocks on live code, or a live database, to keep things running until the code could be amended. Nothing stopped the overnight batch.
Is it time for my pills yet? You're not my daughter. That nurse keeps stealing my clothes!
"It transpired that the serial number of the signal generator was incorrect, which in turn "led to the revelation that during development, someone had hard-coded our signal generator's serial number into the DLL and was using it to check that the signal generator was connected.
Remember the panicked hunt for the source code? It had been because of this: "we had borrowed another signal generator and it wouldn't work."
Wow, I'd call for MASSIVE malevolence, here !! Nice job to have been able to understand the fluster cuck !
"I never did manage to do that as I also found the source code missing..."
Same remark. Malevolence and cover tracks.
A program, still in production, created by a dev that doesn't understand exception handlers, and never checked the source into source control (yes, everything else is checked in, and backed up).
Not necessarily a problem until it fails, which it did. No error message. No logging of any use.
Fortunately a) it's written using the .NET runtime, so later on could be de-compiled and b) windbg is both free and extremely good at debugging. Set windbg to start the program and break when an exception is thrown[1]. Trawl through all the data structures in memory, that one looks like the bit of data it's looking at the moment, and definitely isn't in a state the program will be expecting. Let's fix the data and gosh, program runs through fine..
[1] If you do this, you have to load one of the several .NET debugging addons. Well worth it.
That is, editors. If you're using a text editor on a binary, better a line-mode editor than a visual. And better sed than anything more interactive (yes, sed was available for DOS before there ever was Windows). Where's that greybeard icon?
Still, credit where it's due, he used the tools available and fixed it. How is this a story of our protagonist's cockup or misdeed?
Just in case - ths GPIB isn't the GPIB sitting on Raspberry Pi boards.
The Commodore interface bus was GPIB or sort of but with a much - umm - simpler connector. I have vague recollections of playing about with a piece of kit which had been built to use the Commodore version and discovering that it wasn't just the connector that had been simplified but also the functionality.
Two incidents. Back in the days that PDPs roamed the land, I upgraded a customer from a 11-73 to an 11-84. Had everything loaded on the new system. Went in that night and moved live data. Happy customer in the morning so I went back the hotel and sedated myself at brunch. Next day, back at the office, customer is jumping through the phone. Turns out some lad had customized their application to handle 132 character reports and then built a handful. Instead of following protocol and deploying to the customer file structure, it was left in base code. On the system that had just had a bouncy ride across the state. I still had a copy of the new system on a staging server and knew where to find source. Digging through a collection of MACRO and FORTRAN led to one standard declaration to set line width at 80 characters. Building that locally, and dumping the object library gave me a handful of locations to fix with a zapfsl. Memory on those systems was tight and wasn't going back to build a new boot image, I made my edit on the customer disk, ran a utility to reload our objects and then called the customer. "Power your printer off and on please. Now run your report. It's working? No it wouldn't have been the new system, I moved all your custom configurations."
Second pass was on migration contract no so long ago. A large government agency was moving from outsourcing vendor S to outsourcing vendor N. That included moving the customer's servers from one data center to another. The new data center had it's own addressing ranges of course, and there were at least half a dozen applications that used TCP addreses hardcoded in the application with no source available. I mentioned that I corrected one of my application with Epsilon, an EMACS varient I keep in my toolbox. The next handful of apps went easy enough. But when I tried to follow change control and file source code (old executable) and installation (new executable), the Library Gnome wouldn't take my submission because an executable can't be source.
Grammer Nazi in memory of the Library Gnome
In the early 2000's I heard of an expensive project (OFA/Oracle Express MDDB (OLAP) back-end on HP-UX) that was being put on hold and archived with the servers being repurposed.
The person responsible (not me!!) zipped up the application project code and associated databases, only for it to get FTP'd to the archive location as in ASCII mode (no idea why auto mode didn't assist here - maybe it wasn't available on the version used or was accidentally chosen).
This was eventually discovered and a desperate email was sent out asking whether any project team members happened to have personal archives of any of the development.....
No amount of WordPad/edlin/vi etc. would fix that one
The first place I worked, a client would periodically contact the company to get a new run with different parameters of some guided weapon program. They had to get some particular person to do the run, partly because she had the requisite clearance, and partly because she was the only person who knew how to do it. The program originally ran on a 709, then it was run on a 7090 emulating a 709, then on an IMB 360 emulating a 7090 emulating a 709. The source code had long been lost, so the binary program had to be patched to change the parameters.
Back in the mid 1980's we had a pdp 11/73 running TSX+, a multiuser version of RT-11. There was a text editor that would exit after being idle for a length of time, and would print out a message stating something along the lines of "timeout - execution ended". So I wrote a little program in Fortran (the only language available on the machine) to scan for that text string and replace it with something like "ERROR - CPU Meltdown!". Scared the crap out of one of the users......
Back in the 90's and early 00's I was sysadmin at a place where one of the devs had had the only copy of the source for several utilities on his laptop. Which he dropped in front of a bus. Hard disk was unrecoverable.
A year or two after that, we needed to move a certain server to a different subnet. The server happened to be a sort-of-LDAP-thingy used for every single user login for all customers. The devs dutifully hunted through all source code to find any place where it had been hardcoded and make the program use config files or arguments instead.
And on the night when we did the move, we discovered that the RADIUS server source had been on the bus-crushed laptop, *and* had a hardcoded IP address. No client was able to login at all.
I ended up editing the binary in Emacs, and instead of entering the new IP address, I used a hostname that we could then enter into /etc/hosts. We found a few more bits of software where I had to do the same, though the others didn't have quite as large an impact...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
