[gvb]

[D]o some real enginerering and calculate the ADDITION of bits to set to disable the exploit.

That is very unlikely to be possible. The ROM may be a masked ROM, in which case it is not re-programmable at all. Quite likely it is a one-time programmable (OTP) ROM. For a OTP, at best you can flip "1" bits to "0", but you cannot change "0" bits to "1". It would take a large amount of luck to be able to patch "1"s to "0"s (and not need to change any "0"s to "1"s) to vector to patched code fixing the vulnerabilities.

In addition, many programmable memories require special programming voltages and they all need the proper control signals - very often the ROM is not in-circuit programmable or is in-circuit programmable only via a test/programming circuit at the factory, not in the field.

WRT #1 and #2, the reason for the connector is to allow the hotel staff to recover from Bad Things like dead batteries and confused/mis-keyed locks. I know I've been the victim of dead batteries more than once... if the only recourse is to destroy the lock to get into the room, the hotel is going to be very unhappy and the guest isn't going to be very pleased either.

#3 is "security through obscurity", which will be effective briefly until the next security researcher figures out how to defeat the change.

[K2h]

Your comments on the most likely one time programmable ROM are exactly what I was thinking but didn't take the time to write with the clarity you did. We are on exactly the same page there. My train of thought was that if it was possible to patch the boards using only software that would be an awfully nice gesture to the hotel managers to send a technician out for a day and just fix everything at once [although, if you have to rip the lock apart to pull the board to reprogram it, you might as well just drop a new boad in]. My background is in board level manufacturing so the whole special test fixtures to interface and board probing was the easy part to me - solving the problem of hacking a jump instruction to jump to unused memory and then patching the problem there, then jumping back seemed like a really elegant and fun problem to work on.

I didn't look at the exploit in detail, but as daeken reminded us there are problems with more than just the program in the door lock - so even if a patch to the ROM chip could fix the problem, it probably doesn't fix all the problem so it isn't a real solution.

You are right, everything else 1-3 are really just obscurity solutions and not real solutions - thanks for calling me out on that.