tl;dr - to make wbaduk run in IcedTea, grab the wbaduk app jar archive, hexedit the class file not to indirectly invoke System.exit(), then convince your firefox to run the customized applet.
Basically, the problem is that for Java applets, modern Linux distributions (esp. Debian) do not offer pre-packaged Oracle Java, but instead an open solution "IcedTea" - which is supposed to be more secure, but is somewhat more restrictive. So when you open the Java client, after some security confirmation dialogs you see just "please reopen web browser" popup. If you peek into ~/.xsession_errors (or stderr of firefox), you'll see an actual backtrace:
Code: Select all
java.security.AccessControlException: Applets may not call System.exit()
at net.sourceforge.jnlp.runtime.JNLPSecurityManager.checkExit(JNLPSecurityManager.java:391)
at javax.swing.JFrame.setDefaultCloseOperation(JFrame.java:388)
at com.cyberoro.wbaduk.CGameApp.<init>(CGameApp.java:65)
...
There seems to be no reasonable way to make icedtea allow System.exit(). So what does a hacker do? Let's fix the applet!
Code: Select all
mkdir -p ~/go/wbaduk; cd ~/go/wbaduk
wget http://www.wbaduk.com/download/wbaduk_new.jar; unzip wbaduk_new.jar
wget http://varaneckas.com/jad/jad158e.linux.static.zip; unzip jad158e.linux.static.zip
./jad -s .java -t com/cyberoro/wbaduk/CGameApp.class
Looking at CGameApp.java constructor, we see a setDefaultCloseOperation(3); call there, and that was in the crash trace. So let's try what would happen if we made it pass for example zero?
Code: Select all
javap -v -c gnu.bytecode.dump com/cyberoro/wbaduk/CGameApp.class | less
...
public com.cyberoro.wbaduk.CGameApp();
...
17: invokevirtual #83 // Method setSize:(II)V
20: aload_0
21: iconst_3
22: invokevirtual #87 // Method setDefaultCloseOperation:(I)V
According to http://en.wikipedia.org/wiki/Java_bytec ... n_listings the bytecode instruction for iconst_3 is (confusingly) encoded as 0x06, while invokevirtual is 0xb6. Ok, let's open com/cyberoro/wbaduk/CGameApp.class in your favorite hexeditor (I used hed), find 0x06b6 in the file, and replace the 0x06 with 0x03, which is the repr of iconst_0. You can re-jed the file to verify that the call got updated.
Part of the jar archive is, conveniently, com.cyberoro.wbaduk.WBaduk1355292282641.html which we could just open as a disk file in firefox to make the wbaduk client run. In theory. In practice, icedtea will run it sandboxed (e.g. no network connection to wbaduk server) because the code is unsigned - jeez! One way to deal it would be re-packing the jar and signing it, but I just created (after a lot of fighting with lack of docs and the supposedly user friendly IcedTea GUI tools) file ~/.config/icedtea-web/security/java.policy containing
Code: Select all
grant codeBase "file:///home/pasky/go/wbaduk" {
permission java.security.AllPermission;
};
(edit for your path).
Now, just
Code: Select all
firefox file:///home/pasky/go/wbaduk/com.cyberoro.wbaduk.WBaduk1355292282641.html
and things should go smoothly. I didn't get around to playing yet, but there are no graphics glitches and observing games, estimating score etc. works absolutely fine too!
(P.S.: Long-term solution might be to tell the developers to get rid of that function call; e.g. tightvncviewer used to have same problem, apparently. But I've heard that wbaduk people are not very responsive to emails... P.P.S.: Maybe there is a more elegant approach at things, but I'm just a dabbler at Java stuff, and kind of hate Java actually.)
