Reverse engi­neer­ing a 10 year old java program

Recent­ly I start­ed to reverse engi­neer a ~10 year old java pro­gram (that means it was writ­ten at about the same time when I touched java the first and the last time at the uni­ver­si­ty – not because of an dis­like of java, but because oth­er pro­gram­ming lan­guages where more suit­able for the prob­lems at hand). Actu­al­ly I am just reverse engi­neer­ing the GUI applet (the fron­tend) of a ser­vice. The ven­dor does not exist any­more since about 10 years, the pro­gram was not tak­en over by some­one else, and the sys­tem where it it used from needs to be updat­ed. The prob­lem, it runs with JRE 1.3. With Java 5 we do not get error mes­sages, but it does not work as it is sup­posed to be. With Java 6 we get a pop­up about some val­ues being NULL or 0.

So, first step decom­pil­ing all class­es of the applet. Sec­ond step com­pil­ing the result for JRE 1.3 and test if it still works. Third step, mod­i­fy it to run with Java 6 or 7. Fourth step, be happy.

Well, after decom­pil­ing all class­es I have now about 1450 source files (~1100 java source code files, the rest are pic­tures, prop­er­ties files and maybe oth­er stuff). From ini­tial­ly more than 4000 com­pile errors I am down to about 600. Well, that are only the com­pile errors. Bugs in the code (either put there by the decom­pil­er, or by the pro­gram­mers which wrote this soft­ware) are still to be detect­ed. Unfor­tu­nate­ly I don’t know if I can just com­pile a sub­set of all class­es for Java 67 and let the rest be com­piled for Java 1.3, but I have a test envi­ron­ment where I can play around.

Plan B (search­ing for a replace­ment of the appli­ca­tion) regard­ing this is already in progress in par­al­lel. We will see which solu­tion is faster.

Text why pro­pri­etary or no hard­ware docs hurt the manufacturer

I stum­bled about a text which describes why it is ben­e­fi­cial to dis­close hard­ware pro­gram­ming docs and why it does­n’t help in keep­ing this infor­ma­tion away from the com­pe­ti­tion. I don’t repeat it here, so go and read it.

It’s a lit­tle bit old (last mod­i­fied in 2003), but IMO still up-to-date. If some­one approach­es a com­pa­ny for hard­ware docs, please pro­vide this link to them!

Unfor­tu­nate­ly it fails to men­tion that it would even be nice to get docs for obso­lete or not sup­port­ed any­more hard­ware (if your com­pe­ti­tion learns even stuff from your hard­ware which is 3 – 4 gen­er­a­tions old, it is not real­ly a com­pe­ti­tion and you most prob­a­bly are lead­ing because of inno­va­tion, if not you either are too expen­sive and open­ing the docs would be a rea­son to buy regard­less, or your soft­ware devel­op­ment is not good enough and open­ing the docs would allow users to fix this prob­lem them­selves). This could be a first step for a com­pa­ny to “test the water”. It would be an invest­ment with­out any mon­ey in return (the com­pa­ny does­n’t sell such hard­ware any­more), but it would show the com­pa­ny how it affects their image, how much they have to invest and what they can get in return (when peo­ple do cre­ative things with your obso­lete hard­ware you haven’t imag­ined before, you can bet they can do the same with your cur­rent hard­ware too… you may get an entire­ly new mar­ket “for free”).

If you apply some more thoughts about this top­ic and for exam­ple graph­ic cards, you even notice that any infor­ma­tion the com­pe­ti­tion may get by look­ing at freely avail­able hard­ware docs for graph­ic cards (instead of reverse engi­neer­ing it), can only be used 2 – 3 inno­va­tion cycles lat­er. This is caused by the short turn around times between new graph­ic cards. When a new graph­ic card hits the mar­ket, a devel­op­ment team already works at the sec­ond next gen­er­a­tion (and the next gen­er­a­tion is most prob­a­bly not only in fea­ture freeze but at the bug fix­ing and per­for­mance enhance­ment step). Now, how much val­ue does the com­pe­ti­tion gain from this? I would say only the mon­ey need­ed for the reverse engi­neer­ing. At the same time you gain mon­ey from hard­ware sales from those peo­ple which use (the result of) your hard­ware docs. And the com­pe­ti­tion is required to open their docs too (see below for the “com­put­er freaks” part), so you can safe the mon­ey for the reverse engi­neer­ing lat­er too.

For sound­cards this is a lit­tle bit dif­fer­ent. There you don’t have such short cycles, but cur­rent­ly there you have a pub­lished stan­dard (HDA) and you have Cre­ative with no docs at all on the oth­er side. Hey, Cre­ative, if you stum­ble upon this, what about kick­ing Microsoft in the ass by pro­vid­ing your hard­ware doc­u­men­ta­tion to any­one and ben­e­fit­ing from a lot of peo­ple which are pissed off because their shiny Creative-gear does­n’t work on Vista? I’m sure a lot of peo­ple are will­ing to spend their free time to find a way to make your hard­ware use­able on Vista (and on oth­er OS’) with­out get­ting mon­ey from you. And I’m sure peo­ple will find a way to get stuff out of your hard­ware which makes your eyes fall out of your head (and increas­es hard­ware sales). Oh… yes… hey, VIA, what about the docs for your soundgear too? There’s no mar­ket for sell­ing hard­ware docs, but a huge mar­ket to sell sound hard­ware. And those peo­ple which play around with non-mainstream soft­ware are those peo­ple (com­put­er freaks) which rec­om­mend hard­ware to peo­ple (mom, dad, neigh­bors, friends) which don’t play around but just use main­stream soft­ware. Those “ordi­nary” peo­ple may not depend on your hard­ware docs, but the com­put­er freaks will more like­ly rec­om­mend stuff which works not only on the main­stream stuff (just in case some­one wants to try some non-mainstream stuff).

The same (com­put­er freaks rec­om­mend­ing hard­ware) is true for cable TV / satel­lite TV / … stuff.

A way to encour­age hard­ware com­pa­nies to sup­port *BSD

In multimedia@ we have a dis­cus­sion about the envy24* chips. One ques­tion is how to con­vince com­pa­nies to pro­vide some tech­ni­cal infor­ma­tion or at least free hard­ware sam­ples. As part of the answer I point­ed to http://www.bsdstats.org/ which may be able to pro­vide some num­bers (e.g. envy24* chips with­out a match­ing dri­ver) which may help in nego­ti­at­ing some stuff with a com­pa­ny. Unfor­tu­nate­ly not many envy24 chips show up there. Part of the prob­lem may be that not enough peo­ple run the bsd­stats port (and enable peri­od­ic report­ing of at least the devices).

So do you have any unsup­port­ed hard­ware (not only lim­it­ed to sound­cards) or some hard­ware which is still up-to-date but lacks some fea­tures in the dri­ver (this is at least the case for all recent sound­cards like envy24* or HDA based ones)? Fine, run bsd­stats and enable the peri­od­ic report­ing. Maybe we are able to get enough num­bers to show to com­pa­nies so that they think it would be finan­cial­ly ben­e­fi­cial to sup­port us in some way (free hard­ware, docs, tech­ni­cal hints, whatever).

Oh… while we are at it, the ALSA peo­ple added sup­port for some envy24 based cards based upon the reverse engi­neer­ing effort which was need­ed to write our dri­ver as it is now. So if you are work­ing for a com­pa­ny and read­ing this: if you sup­port us, you get the Lin­ux stuff for free too. 🙂 And as an addi­tion­al bonus, you can show a work­ing dri­ver with­out any bad legal strings (e.g. GPL infec­tion) to OEMs. So go and cal­cu­late how much sales you can do with embed­ded stuff and come back to us with some tech­ni­cal hints and/or free hard­ware (it costs some few bucks for you to pro­vide this: not much if it fails but a large amount of return if it works out).