To expand on what bheaven said, back before I wrote a full Silkroad Security API, you could only emulate the C->S security state, but not the S->C state. To get around that, I changed the client's pseudo random value of the
DH Key Exchange (secret 'a' of Alice in their table) so my server could decrypt the packets. The whole point of the key exchange is that a is unknown, so by making it known, the middleman app could break into the streams (since secret 'b' was known on the server since we coded that.)
All this is unnecessary nowadays because my SecurityAPI fully supports client and server sides, but a lot of people were using sr33/edx33 based code which relied upon it, so the loader kept it for legacy reasons.