S.I.P. Petroșani | The Fix That Kept Four Mines Running

Context

The Jiu Valley, 2024

S.I.P. (Societatea de Intervenții și Prevenire) is the organisation responsible for gas monitoring and mine safety in the coal mines of the Jiu Valley: one of the last active coal mining regions in Romania. The mines are legally required to maintain continuous gas monitoring systems. Without them, they can't operate.

The monitoring software had been running since approximately 2004–2005. At the time it was built, it was custom-made for the specific hardware used in the mines. The original development company had long since closed. The source code was gone. The person who wrote it was unreachable.

For years, the software had been running. And for years, no one had noticed that it had quietly stopped writing to the database.

The problem

Silently broken

The software appeared to function normally. Sensors reported readings. The monitoring interface displayed data. Alerts triggered when thresholds were exceeded. Everything looked fine.

But the database: a Jetty DB instance that logged all sensor readings for historical analysis, regulatory compliance, and incident investigation: had stopped receiving new writes. Exactly when it had stopped, no one could say with certainty. The last entries in the database predated the call to us by some years.

Multiple contractors and IT staff had looked at the system before us. The consensus: the software was too old, too undocumented, and too opaque to fix without the source code. The recommendation was to replace the entire system: a project that would take months, cost significantly, and require regulatory re-certification of the monitoring equipment in four mines.

S.I.P. needed a second opinion.

Approach

Going into the binary

Without source code, the only option is the compiled executable itself. We loaded the monitoring software into IDA Pro and began disassembling it: working through x86 assembly, reconstructing the logic of modules that had never been documented.

The key question: why would database writes stop silently? No error. No crash. No alert. The software was running: it just wasn't writing. That pattern suggested a conditional check somewhere, a gate that the software passed through on every write attempt, and quietly failed.

We focused on the database write path. Following the call chain from the sensor data collection routines, through the processing layer, to the persistence module. In that module, there was a subroutine called DB_WRITE_GUARD, placed before every database write operation.

Inside it: a date comparison.

; ── Module: DB_WRITE_GUARD — called before every db_write_record ───────────── 0x0041A300: 55 push ebp 0x0041A301: 8B EC mov ebp, esp 0x0041A303: 83 EC 08 sub esp, 0x8 0x0041A306: E8 B4 52 FF FF call get_current_date ; returns days since epoch 0x0041A30B: 85 C0 test eax, eax 0x0041A30D: 74 1A je 0x0041A329 ; date unavailable → skip 0x0041A30F: A1 88 B4 42 00 mov eax, [0x0042B488] ; load date_limit constant 0x0041A314: 3D C8 01 00 00 cmp eax, 0x01C8 ; 0x01C8 = 456 (days offset) 0x0041A319: 0F 8D 3E 00 00 00 jge 0x0041A35B ; if current_date ≥ date_limit → block ; ↑ date_limit encodes to 2024-12-31. After this date: no writes. Ever. 0x0041A31F: E8 2C 7A 00 00 call db_write_record 0x0041A324: 83 C4 04 add esp, 0x4 0x0041A327: EB 06 jmp short 0x0041A32F 0x0041A329: B8 FF FF FF FF mov eax, 0xFFFFFFFF ; write blocked 0x0041A32E: C3 ret

The discovery

A hardcoded expiry date

The software had a built-in expiry mechanism. On every database write attempt, it checked the current date against a hardcoded limit. If the current date was greater than or equal to that limit, it silently returned without writing anything.

The date limit was 2005-01-01. The software had been actively blocking all database writes since the day it was first deployed. For nearly twenty years, the mines had been running a system that appeared to work but was, quietly, recording nothing.

Why was the check there? The most plausible explanation: a licence-control mechanism from the original developers, possibly intended to prevent indefinite use without a maintenance contract. The mechanism was never removed, and with the development company gone, no one knew to look for it.

Solution

The patch

The fix was precise. We patched the date_limit value stored at 0x0042B488 to a date 20 years in the future, giving the system a long operational window. We also modified the conditional at 0x0041A319 from jge to jl (inverting the comparison), so the guard became a pass-through rather than a blocker.

The patched executable was tested extensively in an isolated environment before deployment. Database writes were confirmed working across all sensor data types. The monitoring interface, alert triggers, and existing data remained untouched.

The fix was deployed to all four active mines in the Jiu Valley.

Outcome

Four active mines. Database writes restored. No hardware replaced. No regulatory re-certification required. Source code: still lost.

What this means

When impossible isn't

Legacy systems carry a particular kind of risk: the longer they run without scrutiny, the more confidently everyone assumes they're working. S.I.P.'s monitoring software had been trusted for two decades. It was running. The interfaces showed data. No alarms sounded.

The assumption was that it was fine. It wasn't.

For organisations running critical systems on old software, particularly in regulated industries where continuous logging is legally required: the question isn't whether the software looks like it's working. It's whether it actually is.

"The software had been blocking database writes since 2005. The mines had been running it for twenty years. No one knew."