Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×

True Tales of Hands-on Hacks 54

Posted by timothy from the necessity's-a-mother dept.
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.
This discussion has been archived. No new comments can be posted.

True Tales of Hands-on Hacks More

True Tales of Hands-on Hacks

Comments Filter:

  • Best hack? (Score:4, Funny)

    by zephc ( 225327 ) on Wednesday May 31, 2006 @03:05PM (#15437994)
    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

  • Wireless PDA theft (Score:5, Interesting)

    by Anonymous Coward on Wednesday May 31, 2006 @03:06PM (#15438006)
    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. :)
    • Out of curiosity, what will happen if they spoof the MAC address on the stolen stuff? Or Is it the only identification? (Don't answer the specifics, just curious..)

      (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)

        by Anonymous Coward
        On the wired side, the MAC is the only identification. On the wireless side, we use WPA to auth against Active Directory. In this case, the owner had left their credentials cached in the client, so you could actually see the MAC as well as the username in the logs.

        My understanding is that the thief confessed in tears once confronted.

  • My proudest hack... VOIP (Score:3, Funny)

    by 10100111001 ( 931992 ) on Wednesday May 31, 2006 @03:07PM (#15438017)
    One time I made a phone with nothing but 2 tin cans and a piece of waxed string.
  • was when I hacked apart a laptop with an AR15.

  • HTML version (Score:3, Informative)

    by gEvil (beta) ( 945888 ) on Wednesday May 31, 2006 @03:10PM (#15438044)
    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 one time... (Score:5, Funny)

    by Recovering Hater ( 833107 ) on Wednesday May 31, 2006 @03:10PM (#15438045)
    This one time in band camp- I used an unorthodox body part to power a flute.

    • Re:This one time... (Score:1, Funny)

      by Anonymous Coward
      It's only an unorthodox body part on Slashdot... in the real world, it's actually quite common ;)

  • edit mainframe config on ATT Unix (Score:4, Interesting)

    by yagu ( 721525 ) * <yayagu@[ ]il.com ['gma' in gap]> on Wednesday May 31, 2006 @03:17PM (#15438108) Journal

    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.

    • You'd think they'd be able to get off their lazy 9-5 butts and figure something like this out. I guess that's what happens (rather acute stagnation) when people get too comfy with the status quo.

    • REXX and knowledge of native tools (Score:4, Interesting)

      by erice ( 13380 ) on Wednesday May 31, 2006 @06:20PM (#15439703) Homepage

      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.

      • 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.

      • Maybe I'm missing something crucial about Rexx here. As a scripting language it sure beats CMS EXEC, that's for sure but stringwise it's simply no match for awk/sed. I doubt it even supported pattern matching back in the days meaning you had to code that yourself. As far as I'm concerned doing that then on the IBM really sounds like processing text today with Winword Macros just because the text was typed on a Windows when you could be using sed, awk and perl etc. I think the people at OpenBSD have captur
      • Indeed - the REXX/XEDIT commands (which would almost certainly be present, in the same way sed is on unix) would be exactly analogous to the sed commands.

        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)

    by VCAGuy ( 660954 ) on Wednesday May 31, 2006 @03:20PM (#15438129)
    ...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.
  • 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?
  • In 1979 I built a manually operated punched card reader using 13 phototransistors and a desk lamp. I used it to load assembled object code from a mainframe into my Z80 development board.

    I haven't used it much lately.

    • Very impressive. Did you use a cross-assembler on the mainframe? Why 13 photocells? The card has 12 rows.

      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!

      • Did you use a cross-assembler on the mainframe?

        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

        • Freakin' awesome. Thank you for that anecdote.

          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)

    by smellsofbikes ( 890263 ) on Wednesday May 31, 2006 @04:10PM (#15438538) Journal
    This isn't in the same realm as USB bridges... but it's sure made my life better.

    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.

  • Server Admin 1, Glass Door 0 (Score:4, Insightful)

    by Mignon ( 34109 ) <satan@programmer.net> on Wednesday May 31, 2006 @04:15PM (#15438596)
    real-world folks and how they solved IT problems in unorthodox ways

    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.

  • long in the past... (Score:2, Interesting)

    by dizzy8578 ( 106660 ) *
    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.
  • 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.

    Ob
  • 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 prod
  • 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 ha

  • Ugly mainframe hack (dump decoder). :-) (Score:4, Interesting)

    by Richard Steiner ( 1585 ) <rsteiner@visi.com> on Wednesday May 31, 2006 @05:56PM (#15439517) Homepage Journal
    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).

    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. :-) 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
  • 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
  • well i once hacked up two firewire cameras looking at an object from right angles on a linux system. then i wrote a program to capture the video feeds and detect the position of the object in it. i then fed that to object data to a 3d setup of stepper motors to have a tracker track the object. i build a closed loop system to keep the tracker exactly 1 cm below the object.

    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)

    by ruckc ( 111190 ) *
    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
  • 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 supp

Slashdot Top Deals

Two can Live as Cheaply as One for Half as Long. -- Howard Kandel

Close