reverse engineering pwcx

[QuantumG <qg@biodome.org>]

Having watched the discussion around pwcx since the first posting, I 
thought I would take a look at libpwcx.a.  It consists of 3 .o files 
each containing full symbol information and in total a *very* small 
amount of code.  There is no secret algorithm or complex image 
processing in this code.  Having worked on reverse engineering a complex 
audio processing application (see our paper Using a Decompiler for 
Real-World Source Recovery, to appear WCRE 2004), I expected to see some 
serious floating point calculations or at least something recognisable 
as a FFT or some other known algorithm.  There is none of this in the 
pwcx driver.   I could provide complete decompiled source code for this 
binary, however due to the legal questions I'd rather just say that 
there is really not a lot of effort required here to black box this 
driver and replicate what it is doing.  The biggest job will be 
deciphering the two or three large tables used in the decompression 
operations.

The specific issue of pwcx dealt with I'd really like to ask why 
companies perfer to release binary drivers over open source drivers.  A 
Linux kernel driver is really easy to decompile.  There's a number of 
factors that make this so, especially the large amount of symbols 
generally left in binary drivers, but mainly the fact that kernel 
drivers are by design small contained pieces of code.  Also, they are 
generally written in straight C with the only function pointers being 
well documented interfaces (and the function pointers are not changed 
dynamically).  Compared to say, a win32 application written in C++ with 
all that stdcall/fastcall stuff, a linux kernel module is a joy to 
decompile.  So why bother releasing a binary only driver?  The company 
is not protecting its intellectual property.  If an amature like me, who 
knows nothing about web cams, can understand this driver than surely 
someone at one of Philips' competitors reverse engineered and understood 
this algorithm within weeks of the drivers for this camera hitting the 
market.  I'm sure Philips' knows this so why force Nemosoft to sign an 
NDA?  And more importantly, why not let the community maintain this driver?

Trent Waddington
Decompiler maintainer, http://boomerang.sourceforge.net/