Right on. I really wonder how technically savvy the crooks are. I don't know much about the OBD hack device and refuse to google it but it's possible it's self powered and doesn't even need the power from the OBD port.
I have also been thinking of another workaround that would really mess with them. It's a bit more involved though. This will basically flip the script on them. The idea is to create an isolated OBD CAN network (aka a spoof CAN network) that fakes the responses an actual car will give tricking the hack tool into believing the transactions completed successfully and new key has been reprogrammed. However when they try the new key, it doesn't work.
As a crude example, assuming the actual hack goes like below:
1. OBD hack tool: Sends CAN message (request) to car to program a new key.
2. Car: Processes the request and sends a response of either success (key programmed) or fail (key not programmed)
With above you could create an isolated CAN network (something simple as a small microcontroller + can transceiver) that sits on the other side of the OBD port and fools the hack tool. Obviously implementing something like this would require knowing what CAN messages the hack tool sends and the responses it expects. You could take the idea even further and have the "spoofing CAN network" notify authorities while it's pretending to be programming a new key.
I don't have a lot of free time these days to be able to work on something like this but if this is still ongoing come summer, might consider.
P.S. Btw, relocating the OBD port far away with extension wires and still requiring data access might present a problem. I believe the max CAN stub length for nodes (I think the OBD port is a node and not the end of the bus?) should be less than a foot. However, I make no claim to be a CAN expert
so might be good to verify beforehand if you go this route.