Because I'm a web developer



  • One of the tools we use to deliver our product is a piece of CrapWare(TM) that allows developers to create rules. It's ten years old. It is no longer supported. Even if it was, we did not buy support.

    Architecturally, it's analogous to calc: used by a single user on a single core of a single cpu of a single machine. No communication to external databases, other processes, or anything.

    It was poorly designed for its day. The UI is clunky, unobvious, non-standard, slow, and takes the most convoluted path between any two points to get anything done. But, the developer was fresh onshore and thought it was the greatest thing since sliced bread, so he used it, and now it just... won't... die.

    My current task is to figure out how to make it do something we know it can do, the "documentation" sort of implies it can do, but for which there is absolutely no UI nor command line mechanism to do. How? Decompile it (Java). Ok, crappy code to wlk through, but it should be doable. Except that the authors of the system obfuscated their code. So now I'm looking at 80K lines of this:

    WjJCDSK.WjJCIDD(WjJCDUM());

    Even still, they can't obfuscate strings that appear on the UI. My thinking is that if I can get into the appropriate object, I may be able to walk through it. After all, you can obfuscate the name of a JButton, but not the "JButton" itself. As such, if the command I need is "A B C", then all I need to do is find that string, get the obfuscated button name and look for the associated setAction or addActionListener method to find the callback.With that, I might be able to write a new main program to call the correct obfuscated function to get it to do what I need.

    Then I hit the wall.

    They embedded a tomcat server inside it. Why? Well to send messages from the client to the server of course! What server?

    Turns out the idiot developer who wrote the thing didn't really understand how to build simple a fat client app because he was a web developer, so the only thing he knew how to do was make web requests. As such, the entire application consists of JLabels, rendered to look like buttons, on Panels, with click events to simulate clicking a link in a browser, which call the client-side of a web service, to call tomcat, to call the server-side of the web service, to do stuff, and send stuff back to the "web page". But it's all a single process. There is no browser. 

    As such, my mission is to find the callback in the maze of objects, methods and variables with obfuscated names, with no direct link from the thing to be clicked.

    And no amount of insisting that maybe just buying support or replacing the whole thing might be a better way to go is making a difference: just keep at it!

    </rant>



  •  Google does it too, so this obviously can't be an antipattern but must be a new technique so ingenious our tiny little minds cannot grasp it yet.

    Couldn't you actually use that to your advantage though? How about, instead of digging through the code, separate the two components into an actual client/server application, then sniff the communication that goes on between them. With some luck (ok, I'm probably being naive here), you could reuse the "server" and just throw away the "client".



  • OBTW, the decompiled code doesn't compile. Apparently, the decompilers I've tried convert: public class x extends y { public x() { super(); }} into: public class x extends y { public x() { y(); }}, which is not the same thing.

    Also, the decompilers don't produce source for nested (local) classes, so public class x { class y { ... } } produces no output, so there are lots of unresolved references.

    So much for just debugging through it with a breakpoint in every single function to try and map what happens for a given click event....



  • Why do you need to know exactly what it does?  What is the end goal of all of this madness?  Do they want you to maintain it (i.e. do this kind of mind-numbing bullshit every 3-6 months)?

    If that is the case, then you should be able to easily show a cost-benifit analysis of maintaining vs. purchase vs. rewrite (just throw some numbers together like your rate, how long each upgrade could take, full regression testing for every patch, potential for mistakes and/or data/reputation loss, etc.).

    If they don't have of a good reason for wasting time, money and your sanity to perform an autoposy of this "code", then why are they making you do it? 

    Then there's the other option: leave.  This of course is a delicate balance and depends on the market and your cojones...  If this is something that you could potentially be doing for a long time, I would start updating the CV and reaching out to my network to start looking for something else.



  • What decompiler are you using? I've been using [url=http://java.decompiler.free.fr/]this guy[/url] for a while and it seems to handle nested classes and other uncommon structures without a problem. I have seen it choke on certain things though, it'll just output the raw bytecode for that. I think it's because it doesn't like the older IBM Java compilers. But then, who does? Do you know which compiler originally created the classes?



  • @PSWorx said:

     Google does it too, so this obviously can't be an antipattern but must be a new technique so ingenious our tiny little minds cannot grasp it yet.

    Couldn't you actually use that to your advantage though? How about, instead of digging through the code, separate the two components into an actual client/server application, then sniff the communication that goes on between them. With some luck (ok, I'm probably being naive here), you could reuse the "server" and just throw away the "client".

    Never actually heard of Google Refine, but from the page you linked to, what they're doing is a lot more sensible: running as a server only, and then *you* run the client-side in your web browser.

     



  • @snoofle said:

    One of the tools we use to deliver our product is a piece of CrapWare(TM) that allows developers to create rules. It's ten years old. It is no longer supported. Even if it was, we did not buy support.

    Architecturally, it's analogous to calc: used by a single user on a single core of a single cpu of a single machine. No communication to external databases, other processes, or anything.

    It was poorly designed for its day. The UI is clunky, unobvious, non-standard, slow, and takes the most convoluted path between any two points to get anything done. But, the developer was fresh onshore and thought it was the greatest thing since sliced bread, so he used it, and now it just... won't... die.

    My current task is to figure out how to make it do something we know it can do, the "documentation" sort of implies it can do, but for which there is absolutely no UI nor command line mechanism to do. How? Decompile it (Java). Ok, crappy code to wlk through, but it should be doable. Except that the authors of the system obfuscated their code. So now I'm looking at 80K lines of this:

    WjJCDSK.WjJCIDD(WjJCDUM());

    Even still, they can't obfuscate strings that appear on the UI. My thinking is that if I can get into the appropriate object, I may be able to walk through it. After all, you can obfuscate the name of a JButton, but not the "JButton" itself. As such, if the command I need is "A B C", then all I need to do is find that string, get the obfuscated button name and look for the associated setAction or addActionListener method to find the callback.With that, I might be able to write a new main program to call the correct obfuscated function to get it to do what I need.

    Then I hit the wall.

    They embedded a tomcat server inside it. Why? Well to send messages from the client to the server of course! What server?

    Turns out the idiot developer who wrote the thing didn't really understand how to build simple a fat client app because he was a web developer, so the only thing he knew how to do was make web requests. As such, the entire application consists of JLabels, rendered to look like buttons, on Panels, with click events to simulate clicking a link in a browser, which call the client-side of a web service, to call tomcat, to call the server-side of the web service, to do stuff, and send stuff back to the "web page". But it's all a single process. There is no browser. 

    As such, my mission is to find the callback in the maze of objects, methods and variables with obfuscated names, with no direct link from the thing to be clicked.

    And no amount of insisting that maybe just buying support or replacing the whole thing might be a better way to go is making a difference: just keep at it!

    </rant>

    Why are you bothering with decompilation? It'll be quicker and easier for you to rewrite the POS. If they won't let you do that, tell them it's too complex to reverse engineer. That way either you get to turn this app into something sane, or it becomes SEP (Someone Else's Problem).


Log in to reply