True Tales of Hands-on Hacks 54
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.
Re:My best hack (Score:4, Funny)
Pffft. I did that with duct tape once...Oh, you meant you *networked* them...
Best hack? (Score:4, Funny)
Sincerely,
General John "Jack 'MacGyver'" O'Neill
Re:Best hack? (Score:5, Funny)
Wireless PDA theft (Score:5, Interesting)
Re:Wireless PDA theft (Score:1)
(Hm.. better still, try to copy the MAC address and spoof it on an innocent student, *that* student will be busted and the thief walks free).
Did the thief tell you that "he didn't do it?" XD
Re:Wireless PDA theft (Score:1, Interesting)
My understanding is that the thief confessed in tears once confronted.
My proudest hack... VOIP (Score:3, Funny)
Re:My proudest hack... VOIP (Score:1)
My best hack (Score:1)
HTML version (Score:3, Informative)
Or you could just click the big blue article titles if you don't feel like dealing with a PDF.
This one time... (Score:5, Funny)
Re:This one time... (Score:1, Funny)
edit mainframe config on ATT Unix (Score:4, Interesting)
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.
Re:edit mainframe config on ATT Unix (Score:1, Offtopic)
Come on. The topic is about your hack. He told you his hack and then added his bit. What the funk is wrong with that?
Spare us please or give us your hack.
[J]
Re:edit mainframe config on ATT Unix (Score:2)
REXX and knowledge of native tools (Score:4, Interesting)
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.
Re:REXX and knowledge of native tools (Score:2)
It was TSO/almost ISPF (might have been available, but noone had learned or started using it yet) in 1983. No REXX available for TSO/MVS, they WERE using the recommended procedures from IBM. It was a telco so the size issues were pretty enormous back then.
Re:REXX and knowledge of native tools (Score:1)
Re:REXX and knowledge of native tools (Score:2)
That's not really a criticism of the op who genuinely made a cool hack though. That's a criticism of the mainframe team at his place of work who didn't know that the facility to automate their edits existed on their own machine.
Justin.
I made a fax machine (Score:3, Interesting)
Re:I made a fax machine (Score:1)
a hack i am still working on (Score:1)
Re:a hack i am still working on (Score:2)
Re:a hack i am still working on (Score:1)
Re:a hack i am still working on (Score:1)
Punched Card Reader (Score:2)
I haven't used it much lately.
Re:Punched Card Reader (Score:1)
My hack was figuring out the hole-punch code on the Montreal Metro tickets in the 60's. I built a template from a strip of tin can, and drilled the holes with a 5/32" bit. Free transit! Yay!
Re:Punched Card Reader (Score:2)
Yes, sort of. I wrote a bunch of ASM/370 macros that corresponded to the Z80 opcodes and generated DCs for the Z80 binary. I then used that to write a native Z80 assembler that would run on my SD Systems Z80 Starter Kit. It was one-pass, no macros, and it fit in less than 4K.
Why 13 photocells? The card has 12 rows.
The 13th was for the hole clock. Being slid across the photocells by hand, it had to be self-clocking. I ran a piece of Dymo Label-maker tape thr
Re:Punched Card Reader (Score:1)
My first job was programming card-based systems. I've struggled with enough card jams at 3:00 AM to appreciate this blast from the past. Remember the "Multi-Function Card Machine" (MFCM)? Affectionately renamed "Mother-F**ing Card Masher".
hardware/software automated testing hack (Score:4, Interesting)
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.
Re:Consider R (Score:2)
Server Admin 1, Glass Door 0 (Score:4, Insightful)
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.
Re:Server Admin 1, Glass Door 0 (Score:4, Funny)
Hopefully he also addressed the security concern that anyone with a fire extinguisher can get into the server room...
Re:Server Admin 1, Glass Door 0 (Score:1, Funny)
PHB: Remove all fire extinguishers.
long in the past... (Score:2, Interesting)
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.
On-Call Rotation Hack (Score:1)
In order to change the pager number normally we would have to have the next person's pager number handy then dial in the automated attendent and press a long series of menu options on our phone to change this.
Ob
Home brewed email archiving (Score:2, Insightful)
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 prod
not really a hack, but i'm proud of... (Score:2)
Ugly mainframe hack (dump decoder). :-) (Score:4, Interesting)
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.
DMS3 into a PS2 (Score:1)
For a professional, it's probably a real easy job. But for me and shaky hands, it was a real pain.
But I'm proud to say i did it and managed to even get the PS2 working properly afterwards too.
Ben
automated tracker (Score:1)
it was damn cool to see the object tracked by the tracker in realtime, with a really quick response time. if you put your hand in front
Moving 1000 lbs safe. (Score:2, Interesting)
This one time in college.... (Score:2)
Perl (Score:1)
A few, less cool cases (Score:2)
Needed a silent server for a friend's house that took up no additional room. Built out a P3 underneath his monitor stand using nothing but screws, rubber bands, and paper / tape for ducting. It was utterly silent and even relatively safe. And it only took up room that he wasn't accessing anyway.
Needed to re-wire a computer, but the lighting in the room was bad for peering inside of cases, and the flashlight was out of batteries. So I disconnected the power supp