On Thu, 2 Nov 2000, Robert Varga wrote: > > Yes, but it is in every aspect similar to what the person who wrote the > first letter in this thread wants to do or is advised to do, namely to > reverse-engineer the operation of a working system which is developed only > for win* and based on proprietary algorithms. That's exactly the same what > the person writing the DeCSS has done. Hence the company creating the > authentication software would probably sue the person writing the first > letter and could expect that the result would be the same as the DeCSS > lawsuit, and it is currently lost. If this happens before the DeCSS > lawsuit is finished in the Supreme Court, then the result will be likely > the same as the first stages of the DeCSS lawsuit, meaning probably lost. > > This is only my two-pence of course, but I could not stand not to point > out the similarities between the two situation.
I'm not even sure this will get into the lists... The main reason that DeCSS has not been defendable as reverse engineering for sake of compatibility is that the program has a clear purpose that is not compatibility. It is a windows program that decodes a dvd movie and writes it to another file. Key points here: 1. it only runs on windows, thus no compatibility. 2. it doesn't actually play anything, only copy it. there are seperate protections for *copying* works than for access to works. If it had never been released for windows, and only released once it worked on linux, the lawsuit might never have happened. (although there has been interesting discussion surrounding the difference between obtaining access to a work being protected, and creating a device to obtain access to a work not being protected) In this situation, there doesn't seem to be a copyrighted work being protected, which means most of the more often debated parts of the DMCA do not apply. In any case, here's what I'd do: *most likely* that "proprietary authenticatioin client" isn't very proprietary. I would be very surprised if they had actually done anything creative in simply authenticating someone. *much* more likely, is that they simply packaged known algorithms as a client and a server that worked together. They wrote it, yes, but the probably used some 3rd party component to do the real work. (i.e. encryption) The only 'proprietary' piece you would have to worry about would be the patents on those encryption algorithms. (like RSA) Technically: - look at the product. find the vendor. go to their website read up. it might just tell you right off what you are looking for. - look at the installation package for the client software. what does it install? is there something like RSAlib.dll? or ssl*.dll? or blowfish.dll? (etc.) heck, do symbol dumps of all the dlls it installed. - look at the server. (if you can) find someone who administers it (the techie, not the librarian) and have a friendly discussion about it. - nmap the server (this is possibly not a good idea, depending on how paranoid the admins are. - set up a dummy server and tell a windows box to try to connect to it. forwarding both request and response while logging. look for the the 'authentication' and for well known things like ssl session startups. be careful not to sniff anyones elses password. You haven't done anything illegal, yet (although be careful about the nmap) and you haven't even written anything, but you might know exactly what you would need to do to write a linux client.
