Slashdot Mirror
True Tales of Hands-on Hacks
PCM2 writes "InfoWorld is running a fun special report offering true tales of "enterprise hacks" -- real-world folks and how they solved IT problems in unorthodox ways. Can you beat the story about the tech who hacked a USB switch with a timer to bridge two air-gapped networks? Or the one who used Wi-Fi to track a missing tool cart? What's your proudest hack?" It's in PDF, but freely downloadable.
My best hack was when I constructed a nuclear reactor from a paper clip and a dirty napkin for the inhabitants of P3X-491.
Sincerely,
General John "Jack 'MacGyver'" O'Neill
"I would say that 99 per cent of what my father has written about his own life is false." - L. Ron Hubbard Jr.
I tracked down a student who stole a wireless-equipped PDA at our University. Stolen machines are usually reported to us, so that we can monitor the DHCP server for their MAC address in case a clueless thief tries to bring them back on campus. In this case, he didn't turn the PDA off, so it left a nice trail in the RADIUS server of his movements for the next two hours as he roamed around different campus access points. Since the log showed the time that the PDA left that area, the police were able to track back who had access to those areas at that time of day (it was after hours) and eventually recovered that PDA plus a few older models from a new student custodian. :)
One time I made a phone with nothing but 2 tin cans and a piece of waxed string.
1 voice in a sea of voices
It's in PDF, but freely downloadable.
Or you could just click the big blue article titles if you don't feel like dealing with a PDF.
This guy's the limit!
This one time in band camp- I used an unorthodox body part to power a flute.
My humor is probably your flamebait
One time, I used some network cable to hook a couple of computers together.
Pffft. I did that with duct tape once...Oh, you meant you *networked* them...
This guy's the limit!
I overheard a friend bemoaning the loathsome monthly mainframe configuration task. It took four members of her team one week of every month to edit in TSO the huge configuration files to gen the mainframes. She showed me what kind of edits were typical.
I took an example month's suite of edits, created an RJE job that streamed the gen config to a little used ATT Unix box on which I was self-teaching the coolness that was (and is) Unix.
On the Unix side, I piped the stream into a "sed" script with a file defining all of the edits. The entire round trip of the unedited file back into place with full edits on the mainframe took less than one hour and required no monitoring or work on my part other than initiating the job.
Not only did this save gi-huge time and man hours for that team, the edits were always perfect (the edits were very simple, e.g., new date and size configuration information), and the preparation from one month to the next required only minor edits to the "sed" edit script, which took minutes typically.
I got big-time recognition for what I thought was a simple favor at the time. We were very pleased.
Oh, and then 20 years later a MotherFucker laid me off... excellence doesn't guarantee employ. Sigh.
...rather, a fax system: two lathes, a photocell, a sounder, some thermal paper, a microphone, small microheater, PCB (with hardware to turn the heater on and off in response to sound). It wasn't a bad little "I'm bored" project.
Q: "Why do sound techs say 'check 1, 2'?"
A: "Cause if they could count any higher they'd be lighting techs."
At my work, we produce power converters: put some arbitrary voltage into this chip, and it produces a precise, fixed voltage. They're what turns a cellphone battery's power into what's needed by the display, backlight, processor, and transmitter, frinstance. The efficiency of a converter is what determines how long the battery lasts, and it's measured by how much power comes out compared to how much went in. We quantify this by supplying a range of input voltages, and for each one, varying the output current -- the demand. Since we can measure the input current, and we know the output voltage, the output voltage * current, divided by the input voltage * current, is the efficiency. From this we can derive a three-dimensional curve, a surface, showing the efficiency at each point within the operational voltage/current limits. Doing a thousand of these measurements and writing the value for each point, takes a couple of days to produce a reasonably high-resolution curve. Which we had an apps engineer doing, by hand, to a predetermined accuracy. What I wrote does the same thing in two hours, using a stack of power supplies, power sinks, and multimeters, all hooked up by GPIB, but there's a sticking point.
Electricity has two facets: amperage, which is basically how many electrons are flowing, and voltage, which is a measure of each electron's energy. Amps aren't lost: you don't have electrons getting stuck in corners and not coming back out. Voltage, however, IS lost. That's the whole point of voltage, essentially: when you plug something in, you're changing the volts into work and heat, and returning the used electrons, the amps, to the power company to be recycled. So when I want to measure efficiency and I put a certain voltage into a power converter, some of that voltage is lost in the wires themselves, heating them up. I tell the power supply to produce 5 volts, and it does, but the load at the other end of the wires may only receive 4.8 volts. That doesn't sound like such a big deal, but it's 4%, and when your system is 92% efficient and someone else's is 96% efficient, guess whose system gets purchased?
To account for this, I could either use short, fat wires from the power supply -- like jumper cables, short fat wires lose less voltage -- or I can measure the voltage right at the converter, and know what it's actually using. Even better, I can build a closed-loop feedback system, where I tell the power supply to produce 5 volts, measure what's actually being delivered, then tell the power supply to raise its voltage until I'm getting what I originally wanted. Then I don't care about wires. So that's what I did, and to make it even neater I wrote a software controller that optimizes the loop response -- it closes in on what I want like an informational homing torpedo. It's neat to watch, especially when I consider how long it takes to do this by hand. Especially when I've done it by hand, for two days.
You might be interested in knowing that MS Excel, despite its claims, only seems to have one good way to do graphic display of 3-D information: a pivot table from which a surface chart takes its data. It took me forever to figure that out because it doesn't seem to be listed anywhere in the help files. But if I set up the output from the measurement system as tab-delimited outputs of the form:
\t\tOscars \tRazzies \tScuzzies\n
hanks \t5 \t3 \t2\n
roberts \t7 \t3 \t4\n
cruise \t2 \t5 \t9\n
excel chews it up and makes a lovely graph, from which we can see where the converter's poles and nodes are, and get a measurement of capacitor quality and loss across the diode that's 1/3 of a good switching power supply (and its major source of efficiency loss at low input voltages.)
For the record, it's written in MatLab but I'm moving it over to a C script with plotting in GNUplot.
Nostalgia's not what it used to be.
I'm hazy on the details, but during a power failure in server closet one admin wanted to get in to bring down the boxes gracefully before the UPS gave out. But the door was locked and the power failure prevented him from gaining access. So rather than his users losing lots of data and several hours of checking and rebuilding filesystems, he busted his way in with a big metal fire extinguisher and got the job done. His boss told this story proudly.
I used a bungee and duct tape to replace a power supply on a Network Appliance 450 and spliced the cables into the power distribution bar.
It lasted until the suits realized the whole company was running on it and approved the replacement cost.
Those same suits drove the company into bankruptcy in 2001 and fled to the South of France after selling a fraudulent user base to another national ISP.
*"Cogito Ergo Liberalis"*
From the section on Home brewed email archiving:
For his part, Scott took two weeks to write a small C program that would FTP the Domino and Sametime mail logs to the Linux server while monitoring the size of the captured log files on a cumulative basis. When that starts amounting to what can be easily fit onto a DVD, the program kicks off a DVD burn job on the Linux box. If the burn is successful, the program removes the local copies of the logs from the Linux box, as well as the working copies on the production Domino and Sametime machines, to conserve much-needed disk space. Finally, it sends an e-mail notification to the systems administrator reporting on the status of the burn, whether the job needs to be redone or it's safe to drop a new blank disc into the drive.
This seems like something that would take about 1-4 hours to automate in most scripting languages. Also, using C would have beared no performance increase as the most time consuming operations (FTP files, burn DVD-R) are out of your control. I would have chosen BASH, Perl, or Python for this task.
The mainframe (Unisys TIP) transaction environment I worked in at NWA had only two ways for F66 programs to generate trace output -- you could stick a CALL DUMPER statement in to dump 1-to-n words of a buffer in octal, or you could stick a CALL DMPFLD statement in to dump 1-to-n words of a buffer in FIELDATA text. There was no CALL PRTADP equivalent (for those familiar with the Unisys USAS environment).
:-) Then, it kicked off a second runstream to run the FORTRAN decoding program and sat around waiting for the FORTRAN program to terminate. Again, the execution of t
The end result was single 132-column print file containing a bunch of blocks of octal or FIELDATA information (each with at most a 6-character label) sitting in a print file.
Both dumping methods had serious disadvantages. Reading raw octal isn't fun, and neither format would give you relative word offsets (just raw memory addresses) so on long dumps it was hard to figure out where you were in a given buffer without doing a certain amount of math and counting on a 132-column printout, and in general it could be a lot better. It was also hard to read on an 80-column terminal (some viewers would wrap it, others would simply truncate the stuff beyond column 80). So I decided to write a dumper decoder to make things a lot more readable.
One of the nice things about the TIP online transaction environment is the fact that you can write batch programs which aren't really online transactions, but which can connect to TIP anyway and use TIP services.
We had a fairly large library of utility subroutines out there that could decode a word of data in various ways. We had specialized formats for storing a binary date+time (ACCMIN), storing a binary flight+date, and various other special formats, and these routines would decode a word of otherwise obfuscated information and make it nice and easy to read.
I wanted to be able to display those suckers in human-readable decoded format underneath the original octal words if I could detect the presence of a specialized data field, and I also wanted to frame the FIELDATA output from PRTADP statements in such a way that it would be obvious which words you were looking at in the trace.
I also wanted to write a nice front-end for the thing which detected various options on the command line and presented the information in a nice fullscreen viewer on the mainframe.
For this project, I created two parts:
(1) a FIELDATA FORTRAN V batch TIP program which could read the raw trace file containing the trace information to be decoded, which could connect to TIP, which could tap into the nice utility library, and which could generate a nice formatted report to a file.
(2) a CALL macro front-end which could be called from a command prompt, solicit input from the user, interpret options, and effectively drive the above F66 program, then read the resulting output and present it to the user in a nice fullscreen viewer so they could page and/or search through it however they wanted.
The problems:
(1) FORTRAN V programs could only read/write 6-bit FIELDATA. I also didn't know how to create a FORTRAN program that I could call directly from the command line. Oops!
(2) CALL macros were easy to write and were made to be run from the command line, but they could only write 9-bit ASCII files (though they could *read* both ASCII and FIELDATA).
(3) There was no way to directly link the two together (CALL macros are self-contained interpreted macros, and they don't have any way to directly call a program which is written in another language, or even residing in another CALL macro source file!).
The ugly solution: I had the CALL macro write an ASCII COMMAND file, then kick off a breakpointed runstream (whose execution was hidden from the user) which called the ED line editor to convert the command file to FIELDATA so the FORTRAN program could read it. That's roughly the same as piping it to the line editor, I guess, but a lot uglier.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
I took an example month's suite of edits, created an RJE job that streamed the gen config to a little used ATT Unix box on which I was self-teaching the coolness that was (and is) Unix.
On the Unix side, I piped the stream into a "sed" script with a file defining all of the edits. The entire round trip of the unedited file back into place with full edits on the mainframe took less than one hour and required no monitoring or work on my part other than initiating the job
But required another machine and another account for a job that could have been done more efficiently on the local machine. Seriously, did no one in your friend's group know how to program in REXX? That's the text processing engine of choice in an IBM mainframe environment. It's as if a group of people were hand editing files on a unix system (becuase they didn't know how to use sed, grep, perl, etc) until someone had the bright idea to ftp the files to a Windows machine and process the data with Word macros.
We have big 1000 lbs safes to store stuff where I work. I had a task of moving one with a refrigerator dolly/handtruck. The handtruck broke (thin solid rubber tires got pinched in half by the rim and the floor). We still needed to move the safe. I found a 6' long 1" thick wooden dolly, broke it in pieces and rolled the safe around like a giant stone in egypt.