HMAC's encryption changed?

Issue #32 resolved
Edoardo Rinaldo created an issue

I tried to use the OJOC-keyhack but I had an issue during the last part. Inside the "libhmac-c" decompiled version I've not found the required lines for the decryption, but there is something very similar:

#!

int32_t v2 = v1 + (int32_t)&g135; // eax
    *(char *)(v1 + (int32_t)&g135 + 340) = -124;
    *(int32_t *)(v2 + 336) = -0x6a731b3b;
    *(char *)(v2 + (int32_t)&g17) = 40;
    *(int32_t *)(v2 + 341) = -0x57d82e33;
    *(char *)(v2 + (int32_t)&g19) = 23;
    *(int32_t *)(v2 + (int32_t)&g18) = 0x4996133f;
    *(char *)(v2 + (int32_t)&g21) = 94;
    *(int32_t *)(v2 + (int32_t)&g20) = -0x7fe1e5e2;
    *(char *)(v2 + (int32_t)&g23) = 25;
    *(int32_t *)(v2 + (int32_t)&g22) = 0x2c07c279;
    *(char *)(v2 + (int32_t)&g25) = 67;
    *(int32_t *)(v2 + (int32_t)&g24) = -0x7076b5b2;
    *(char *)(v2 + (int32_t)&g27) = -88;
    *(int32_t *)(v2 + (int32_t)&g26) = 0x48da2dc2;
    *(char *)(v2 + (int32_t)&g29) = -75;
    *(int32_t *)(v2 + (int32_t)&g28) = 0x19cba61b;

And, of course, decrypt.sh does not work with that (with or without the first line). I tried to understand by myself how to get it to work but I'm not good enough and I don't really know how this decryption works.

So the real question is: have I done something wrong or is the keyhack outdated? I'm sorry if I've done grammar mistakes or misunderstood something. Thank you in advice.

Comments (11)

  1. Christian Fibich repo owner

    decrypt.sh tries to arrange the constants in these write accesses to a global memory to retrieve the encrypted key, then compiles it together with the decode() C function and executes the resulting program.

    It uses the fact that the decompiled version of the former releases of libhmac.so gave away the correct order of the constants in variable names (such as g19, &g18, ...), and just sorts the lines by this variable.

    decrypt.sh thus strongly depends on retdec.com always generating similar C code structure for this decompiled section. That's a problem, because if the compiler that generates libhmac.so decides to optimize this section differently, this breaks decrypt.sh. If you have a more potent decompilation tool at your hands, like IDA Pro, decrypt.sh to retrieve the encrypted key is no longer necessary.

    In the case of 4.55.1 I shuffled the first few lines (the lines not containing "v2 + (intN_t)&gNN" ) and arrived at a working ordering for these lines

        int i=0;
        uint8_t v2[40];
    
        *(int32_t *)(v2 + i) = -0x6a731b3b;                               /* v2 + 336 */
        i+=4;
        *(char *)(v2 + i) = -124;                        /* v1 + (int32_t)&g135 + 340 */
        i+=1;
        *(int32_t *)(v2 + i) = -0x57d82e33;                               /* v2 + 341 */
        i+=4;
    
        // Sorted according to gNN below
    
        *(char *)(v2 + i) = 40;                                 /* v2 + (int32_t)&g17 */
        i+=1;
        *(int32_t *)(v2 + i) = 0x4996133f;
        i+=4;
        *(char *)(v2 + i) = 23;
        i+=1;
        *(int32_t *)(v2 + i) = -0x7fe1e5e2;
        i+=4;
        *(char *)(v2 + i) = 94;
        i+=1;
        *(int32_t *)(v2 + i) = 0x2c07c279;
        i+=4;
        *(char *)(v2 + i) = 25;
        i+=1;
        *(int32_t *)(v2 + i) = -0x7076b5b2;
        i+=4;
        *(char *)(v2 + i) = 67;
        i+=1;
        *(int32_t *)(v2 + i) = 0x48da2dc2;
        i+=4;
        *(char *)(v2 + i) = -88;
        i+=1;
        *(int32_t *)(v2 + i) = 0x19cba61b;
        i+=4;
        *(char *)(v2 + i) = -75;
    
        return decode(v2);
    
  2. Edoardo Rinaldo reporter

    Thanks, it worked great! I got it to run but I'm still having issues I can set the location and I see other jodels, but I cannot do anything (not even look a the comments). In the console I get 478 error (I've seen on other issues that it's caused by the captcha verification) and this one:

    Could not load image file [location][numbers].jpg: Couldn't recognize the image file format for file... " etc.

    (Edit: I forgot to mention that those images are actually not readable, it's not a Reading error) I don't know if maybe something changed in the captcha verification system or maybe is just me, because I had several troubles installing the requirements on Windows, I'm going to try again on Linux when I return home.

    Trying to upload an image will lead to another error:

    #!
    
    [image location]
    Traceback (most recent call last):
      File "[...]\ojoc\ojoc.py", line 378, in new_post
        post = dialog.get_post()
      File "[...]\ojoc\OJOC\gui.py", line 209, in get_post
        imagePathUtf8 = GLib.filename_to_utf8(imagePath_opsys, len(imagePath_opsys),0,0)
    TypeError: GLib.filename_to_utf8() takes exactly 2 arguments (4 given)
    

    (In particular I realized that I just skipped the Webkit thing just because I didn't find anything clear about getting that on windows)

  3. Peter Müller

    Hay,

    I've also tried to get the Version 4.55.1 working but have the same problem as Edoardo Rinaldo.

    I've found only a similar codeblock with v1's and v2's and g's like Edoardo did.

    Now I understand that something is wrong with the decompiling website (or did I understand you wrong?)

    Anyway even if I copy paste your text from "int i=0;" to "return decode(v2)" into the hmac.txt to feed the decrypt.sh with I only get errors and nothing is working.

    Even if you help me does that mean that from now on everytime I want to decompile and try to get the hmac key it will fail because they did something else since version x?

    The errors I get when I want to feed the decrypt.sh with your (Christian Fibich's) text are:

    <stdin>: In function ‘main’:

    <stdin>:13:29: error: ‘v2’ undeclared (first use in this function)

    <stdin>:13:29: note: each undeclared identifier is reported only once for each function it appears in

    <stdin>:60:5: error: redefinition of ‘i’

    <stdin>:6:8: note: previous definition of ‘i’ was here

    I've copy pasted everything in your textfield so nothing is missing... I don't get where the problem is...?

  4. Christian Fibich repo owner

    Do not send received image_headers as this causes problems with the cloud image storage.

    The new flag OJOC.Connection.USE_IMAGE_HEADERS forbids the use of the received image_headers.

    Addresses #32

    → <<cset f85b434ea15f>>

  5. Christian Fibich repo owner

    @ @giazazi

    Regarding the 478 error, try to delete ~/.jodel/jodel.cfg (Should be located under C:\Users\<Name>\.jodel under Windows). If that does not work, try with a new uid (as a command-line option or by deleting the "Jodel" entry in the system Keyring)

    Regarding the error when loading images, this has something to do with the cloud image storage suddenly no longer understanding the image_headers sent as a part of the request. In f85b434e I introduced the flag OJOC.Connection.USE_IMAGE_HEADERS that can be used to disable sending of the image headers. See if that helps.


    @ @pemu66

    Just take the lines I pasted above, put them in a main() function, and compile together with decrypt.c...

  6. Daedra2223

    The new Jodel App Version 4.57.1 seems to cause again an 478 error, do you have an Idea how to deal with that?

  7. Christian Fibich repo owner

    Key retrieval is exactly in the same way as with 4.55.1

    You need to decompile to C, find the correct lines, sort them according to the gxx vars, and swap the first two. See the ojoc-keyhack subproject. I'll document the exact steps there some time in the near future.

    If the new key doesn't help, try a new device_uid

  8. Daedra2223

    Hello Christian,

    thanks for your reply. You are doing a very good job, I love your OJOC Application. Will it still work when new versions of Jodel are published, e.g. 4.58.1 ?

    Big Thanks and kind regards

  9. Log in to comment