Interesting that the port provides direct memory access. I imagine that this was a simple way to provide access rather than defining a complete protocol with things like "Download Access Log", "Reprogram Log". Just let the handheld device give you access to memory and you can build whatever functionality you want later.

I actually worked on something like this where I had a program that would send arbitrary code to be executed on a device. That way it could be made to do whatever we wanted.

That isn't a bad thing if there's some way to authenticate, and it looks like the big flaw here is that the unique ID is also readable from the same memory.

You need to ensure that the memory layout stays exactly the same for all future generations. Thats a very bad omen if you end up needing to break or rearchitect things. This is just being cheap, and in the process completely defeating all security. Of which there was none to begin with, given a 32 bit keyspace and a proprietary crypto.

Executing code has the same memory layout problems and is a complete no-go if your target device happens to use the Harvard architecture.

It would be more of a deterrent if they would have only allowed writing the sitecode via the programmer, and only then if it was blank. So basically, the locks ship with blank sitecodes, the programmer can set them once (other code on the lock would handle writing the sitecode to nvram, inaccessible to the programmer's read "command"). After that the only way to change the code is to reset the nvram. This way the sitecode wouldn't be readable from the programmer, and a malicious programmer couldn't set a sitecode that they provided. The requirement of resetting nvram would be enough to mitigate most attacks, especially if you could only make it accessible from the other side of the lock.