More on fortifying Lotus Notes

[lists@notatla.demon.co.uk]

Duncan Campbell <duncan@gn.apc.org>

> 3. Using NSA's public key, it re-encrypts the 24 bit section of the session 
> key.

> 4. It then compares the result of that encryption with the WRF.  If the two 
> do not match, then it will refuse to decrypt the incoming message.

> Therefore, your Lotus Fortify patch will have to operate on both sender and 
> recipient.   If you can get to the NSA public key inside both functions, 
> and change each in the same way, then does that work?


I'd expect so, but it may be easier than that.  There is likely to
be a section of code that makes a yes-no decision on whether the two
WRFs match.   Replacing the few bytes concerned with the same comparison
in the opposite sense (i.e. approve if different) or with inactivity (NOP)
instructions may do the job.

I read a paper a few years ago where somebody described using these techniques
to defeat copy protection and it never took above 4 hours.  It requires
some familiarity with the assembly language involved.

The programmer can make life a bit more complicated by having more than one
check, and by not flagging the relevant instructions by putting them close
to the bail_with_error function.  Really subtle people don't rely on an
explicit yes-no decision but use some result of the calculation in an
important place later during execution.  Wrong numbers then cause some
unrelated-looking failure.

Unfortunately I don't know any modern assembly language - nobody knows how
to write books these days.   Books hundreds of pages long omit the few page
appendix which is all you really want.