Java 8 crashes when clicking scrollbar on El Capitan.

Note: This should no longer be necessary, since this is fixed in the latest version of OS X/Java (I still don’t know on who’s part the error was). It still might be a fun read if you like reverse engineering and hacking into system libraries.

Java 8 crashes when you click a scrollbar when using El Capitan (OS X 10.11).
There is a bug report here, but there is not much going on there, so I decided to take a look at the problem and see if I can fix it. And it worked.

The process of hacking the binary.

  1. Disable the new “System Integrity Protection” (SIP) mechanism by booting in Recovery Mode (hold Cmd-R while booting). Open a Terminal and trigger: csrutil disable. Reboot. This is required since the binary we are going to patch has the new restricted flag and cannot be edited (not even by root!).
  2. Now we will patch this binary:

    I did it using Hopper (which is an amazing piece of software, but not free). This is a fat binary (contains both 64 bit and 32 bit binaries). I patched the 64 bit part.
    You should look out for address 0x0019d6. There is a call instruction to a function in the CoreUI framework. We will replace the function call by setting RAX to 1. However patching in movq $1, %rax is too long. Instead use (AT&T syntax):

    xor %rax, %rax
    inc %rax

    Java 8 scrollbar patch.
    Save the file and leave the original signature in.

  3. Finally, you could turn SIP back on again. By triggering csrutil enable in Recovery Mode.

I could simply upload the modified binary here, but that would probably violate the licensing of this binary. Instead I will provide a patch file for JRE_1.8_60. The patch file is a bsdiff/bspatch file. You can install that through Homebrew. Launch:

bspatch /System/Library/Frameworks/JavaVM.framework/Frameworks/JavaRuntimeSupport.framework/Versions/A/JavaRuntimeSupport /System/Library/Frameworks/JavaVM.framework/Frameworks/JavaRuntimeSupport.framework/Versions/A/JavaRuntimeSupport /path/to/my/patch/JavaRuntimeSupport.pch

The patch file actually removes the x86 part from the fat binary. This could be problematic.

What did we do?

The call we stripped out actually tested which part of the scrollbar we clicked. For some reason (I didn’t investigate), a crash occurs in CoreUI.framework. The surrounding function to that call has this pseudocode (generated by Hopper):

int _GetScrollBarHitPart() {
    rax = 0x1;
    if (HitTest() == 0) {
            rax = -1;
            if (rax <= 0x6) {
                    rax = *(int32_t *)(0x8b00 + rax * 0x4 + 0x4);
            else {
                    rax = 0xffffffff;
    else {
            rax = 0xffffffff;
    return rax;

We basically replaced the function call to return a 1. So the pseudocode becomes:

    if (1 == 0) {

So we will always pick the else case.

The result

As a result of our patch, clicking the scrollbar obviously doesn’t crash anymore and also has only one behaviour left: it is as if you always click the scrollbar handle itself. So you can click the scrollbar below or above the handle and can still drag it. In a normal situation the scrollbar would take jumps.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s