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.
One time, I used some network cable to hook a couple of computers together.
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
was when I hacked apart a laptop with an AR15.
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
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."
I'd tell you but then, I'd have to kill you.
Home address, please.
i am trying to xorg's X with Nvidia's driver compiled in to give me screen resolution that is somewhere close to halfway in-between 800x600 and 1024x768 say maybe in the 9XXx6XX or 9XXx7XX range, i once had an old Voodoo3 card that gave me an in-between resolution when i was using Win98 years ago, i have since abandoned MS-Windows in favor of GNU/Linux... anyone ever try this?
Politics is Treachery, Religion is Brainwashing
I Tivo'd that episode and was going to watch it tonight. Thanks for spoiling it, you insensitive clod!
I haven't used it much lately.
You were 80% angel, 10% demon. The rest was hard to explain. - Over The Rhine
"Math in a song is good."-Linford
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 got tired of the tiny container the shredder has for holding paper shreddings, and so I took a computer box, and propped the 5"x12" paper shredder ontop of the box using the box flaps pointed up to hold it in place.
Luckily the box is strong enough to hold the paper shredder there without tape or anything, so whenever I need to take it off to empty it, it's easy. The little shredder has little recessed edges where it fits onto the small wastebasket, and those are what I used to prop the paper shredder up with using the box flaps. It only uses one end of the 'small side box flaps' to keep it from tipping over.
I used a bent-paperclip to hold the "safety notch" in so that the shredder thinks it is secured ontop of its old wastebasket.
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"*
Several of us in I.T. had to take our turns being on-call (which was basically an after hours help desk). Needless to say when our turn was up we were ready to put the other person on-call. Whenever someone called after hours they would leave a voice message and it would page the on call person.
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.
Obviously being on call sucked bad enough but every time you switched with someone (or they were covering for you) it would take about 5 minutes of screwing with the phone to put the next person's pager number in the system. It was problematic and you would get into trouble if you did a typo and the next person didn't receive notices that someone needed the help desk.
So, I had the bright idea to somewhat automate the system using an old PC, Pro Com (with macro) and a modem.
A co-worker and I set up a menu with the ProCom software to automatically dial the correct sequence of numbers for the automated attendent (with just enough pause between each option). We utilized ProCom macros and Hayes commands to make taking ourselves off call much quicker and easier.
"A government is a body of people, usually notably ungoverned." - Shepard Book Quoting Malcolm Reynolds
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 time during hurricane Wilma when I lost power. I was running my email/web server off a 300W inverter powered from my car. Well, the machine wouldn't come up. I tried connecting the monitor to the inverter but it just wasn't powerful enough to run it and the server. The problem was that the filesystem needed to be checked, but I had to monitor to actually see what I was typing. This was exacerbated by the fact that the filesystem was on LVM volumes and didn't have simple names like hda1 or hda2. So I had to blindly type commands to fsck the volume. I ended up grep'ping through /etc/fstab and awk'ing out the relevant fields which I passed to "xargs e2fsck -y". Somehow I was able to do this without a monitor from remembering when I needed to enter the rootpw (and not the root id) to the correct syntax for the awk statement to the flags to e2fsck.
:D
Then there was the time I used a laptop to replace a failed Watchguard... but that was easy because of a firewall CD I carried around. It sure seemed impressive though
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.
Next time, instead of C and gnuplot take a look at R.
My best hack is successfully soldering a DMS3 mod chip into a PS2.
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
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 of the cameras, the tracker will move with your hand (exactly 1 cm below it)
the time for building this system was 3 months and i hacked it up in 2 weeks- from scratch, to matlab models, C models, to real implementation!
* lon3st4r *
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.
We had some gradual students who were collating and uploading data from remote sensors (basically a Z-80 box with a modem and a dozen or so A/D converter hooked to various weather instruments). They would have to use tip(1)[0] to call the sensors, then download the files and reset the sensors. And if they didn't do this at the same time every day, then they'd have to dick with the data file to get the readings to line up with previous captures. So I hacked tip(1) to accept scripting commands from a file (fairly easy, it already had built-in commands, it just couldn't read them from a file), wrote a cron job to kick off a shell script, and *boom*: two freshly-unemployed grad students! [1] Not as cool as wiring up a current-loop-BAUDOT-to-RS232-ASCII converter and stuffing NWS reports directly into a newsgroup, but that one wasn't mine....
:P
[0] Why yes, this was the early 80s -- how could you tell?
[1] Not really, they were actually being paid to analyze the data, not collect it.
Just junk food for thought...
I love how two of the solutions for Windows involve Perl.
Favorite hacks (none as good as that story)
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 supply from the motherboard, wired the 5v rail to the flashlight, and turned the PSU on.
Someone at an old ISP I used to work for had a server that simply had no power button. We had to bridge the pins with a screwdriver to get the thing on. This was quite nerve-wracking the first time, as nobody had the schematics for the mobo anymore and were quite sure what was supposed to attach where.
Not strictly computer related, but I had an old Nokia whose batteries had worn out, and I wasn't happy with the charges for the possible replacements. So I cut the battery in half, and removed the old, dead cells. Then I soldered an array of 16 AA NiMH batteries in a combination of serial and parallel (to get the voltage right) onto the old charging circutry, and taped that to the back of the phone with black electrical tape. Talk time was about 24 hour straight, and you could go for about 2 weeks without recharging. On the down side, you get stopped at every airport security terminal.
And not at all related to me, though I wish it was, is the great Jargon File story about the magic MIT switch.
The ______ Agenda