Oh man, I've got a classic one that still gives me nightmares! I was called to a food processing plant where their main packaging line had completely shut down. The system was running on a 20-year-old PLC that had been patched and modified by at least a dozen different engineers over the years - with zero documentation.

The first clue was when I connected to the PLC and found the program was password-protected. No one knew the password, and the original programmer had retired years ago. I had to use a brute-force approach, starting with monitoring all the I/O signals while manually operating the line in maintenance mode.

What made it truly terrifying was discovering that the logic was full of 'magic numbers' - hardcoded values with no comments explaining what they meant. There were timers set to weird values like 32767 (which turned out to be the maximum value for that PLC's timer register), and conditional jumps that seemed to make no sense.

My reverse-engineering process involved:
1. Creating a spreadsheet to map every input and output
2. Using a logic analyzer to capture signal patterns during normal operation
3. Building a state diagram from observed behavior
4. Testing each rung of ladder logic by forcing inputs and watching outputs

The breakthrough came when I realized the original programmer had used the PLC's memory bits as a makeshift database for production counts, and one of these bits had overflowed after 20 years of continuous operation! The system was literally counting to a number it couldn't handle anymore.

It took 72 hours of round-the-clock work, but we finally got the line running again by carefully reconstructing the logic and adding proper error handling. The moral? Always document your code - your future self (or some poor soul like me) will thank you!