On Tue, Feb 03, 2004 at 05:42:59PM +0000, Torgeir Veimo wrote: > > > > Absolutely not. That is comparable to figuring out how Windows 2000 > > works given nothing more than a printed binary dump (and I mean > nothing > > but 011010111010110111) of a memory image. > > > > You could probably figure out the number of bits in the datapath > between > > the graphics engine and the onboard RAM that way, but there is no way > > you could deduce that the lower 4 bits of the register at offset > > 000123C4 controls the RAM clock slew. > > You might try usermode linux. http://www.directfb.org/mailinglists/ > directfb-dev/2003/10-2003/msg00056.html
That is a neat use of UML. I have used DOSEMU in the past to "spy" on what the hardware is doing to do some blackbox reversing. It usually works pretty well for simple stuff and especially things connected to e.g. serial and parallel ports, because you can get a log of all the port writes for a given function and work backwards from there. This didn't work for more complicated drivers because they won't run in a v86 session. So for those things I had to resort to dead listing. Again, for simple stuff like "read this value from this port, set this bit, write it to this other port" where the intent is obvious and there are few interdependencies, it works great. If you don't get lucky or choose your battles wisely, dead listing can waste a lot of time and effort. I am certain anyone who really wants to reverse nvidia hardware interfaces would need to have some serious project organization. There is already a nvidia reversing project you can find on google, but surprise surprise, it has no progress to show and seems to have been dead for years. It would take a massive organized effort to pull it off and another massive organized effort on top of that to ensure that it is all done in a legal fashion. -- Ryan Underwood, <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
