HMAC's encryption changed?
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)
-
repo owner -
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)
-
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...?
-
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>>
-
repo owner @ @giazazi
Regarding the 478 error, try to delete
~/.jodel/jodel.cfg
(Should be located underC:\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...
-
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?
-
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
-
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
-
repo owner Regarding the key retrieval, may I direct you to the subproject https://bitbucket.org/cfib90/ojoc-keyhack
Yesterday I pushed a solution that does no longer rely on retdec.com that will hopefully also work with future app releases.
-
Thank you very much for the fast support!
-
repo owner - changed status to resolved
- Log in to comment
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 breaksdecrypt.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