Re: Put down that decompiler

Andrew Savory(?) writes that if you have to stoop to decompiling a product to figure out a problem, it is the vendor's fault because they chose not to supply you with the code and documentation. So, if the vendor does not provide the source and the particular functionality is not well explained, it is completely vendor's fault. I wish it were so simple.

I do agree that in the ideal world, every feature would be documented and/or working 100% correct. In reallity, it may be somewhat different.

To give an example, Weblogic server allows to add your own security providers by dropping a jar into a particular directory. So, one of BEA customers gets a patch for the security provider code and dutifully drops it into the directory as per detailed instructions.

And the fix does not work. Couple of support rounds happen where frontline support checks and rechecks that the customer has the right version of the file (yes), that it was put in the right directory (yes), that the fix does match the problem (again yes). All is correct, but nothing changes.

The case gets escalated and out of desperation, we (effectively) stop beliving the customer and ask to provide a listing of the security provider directory showing sizes and dates of all the files.

And then we realize that instead of a single jar (patched providers bundle), there is also another file in there called something like providers.jar.bak, an original copy of the bundle. Removing that file makes the problem goes away. Looking at the source code, it turns out that every file in that directory is loaded up as a jar with a provider bundle. And so, the old bundle kept being picked up.

Whoever wrote the documentation, asked the old provider to be backed up. And so they were. But nobody expected the backed up file to be in the same directory. A bug was filled and issue was fixed.

But all this took a while. Mostly because we did not have access to the customer's system and everything was being done from the arm's distance. If the customer was conversant with a decompiler, they could have reverse-engineered the code that loaded the jar and ether noticed the problem right away or put log statements in to print out when the jar was loaded (and see it ping twice, rather than expected once).

The lesson here is that, yes this was dodgy and should have been fixed (and was). But there is a range of situations where the problem lies in shades of meanings and reverse-engineering will often give a better and faster answer than jumping up and down and screaming for the vendor to fix 'something, anything, whatever it is'.

On a related note, it might have been possible to identify the same problem by running a FileMon and noticing that backup file was actually read in where it should not have. But in my eyes, FileMon is just one of the tools in reverse-engineering/decompiling toolkit, so
it would be out of Andrew's reach as well.

BlogicBlogger Over and Out