Content
libreddit-ndk.so – Hide stuff in native library! Nobody can ever read native code, no matter how simple! Put a dummy parameter in the calls from the Kotlin code so people will think something deep is going on: KeyUtil.decryptSigningKey("a0c1e177d7afd4faaaee14f6ef712917c576a33dccd7381c63fed3312658bd8"); Actually always returns "8c7abaa5f905f70400c81bf3a1a10175f72101041991f0c5240aa80c4d99d" string JavacomredditauthcommonutilKeyUtildecryptSigningKey(JNIEnvenv,jclassunused,jstringfakeandunused) char keystr (char )malloc(66) ; Malloc? It’s just 66 bytes, use a local variable, stupid. for(int i 0; i 65; i) keystri mapkeyill; A substitution cipher.. height of cryptography in the year 300 BC. keystr 65 0; Null-terminate the string return env-NewStringUTF(env, keystr); Native memory allocations aren’t garbage-collected, idiots, you need to call free() Now you’re leaking memory on every single API request! String parameter is ignored, always returns "s3ybk2jbEg4BmxQqvqgXoGs3AOUHUH8y" On the Kotlin side we just change a few chars at the start and end of the dummy string: KevUtil. decryptiphyApKey( "uty893a3d7af d4faaaee14f6ef712917c576a33dccd7381c63fed331scukko8" ); surely nobody will notice the ‘encrypted’ parameters are remarkably similar: jstring Javacomreddit mediacommonapikeys KeyutildecryptGiphyApiKey (JNIEnv env, jclass unused, jstring fake and unused) char keystr (char )malloc (34); Again with the same stupidity for (int i 0; i 33; i) keystri giphymapgiphykeyi; keystr33 0; return env-NewStringUTF(env, keystr); Again the same bug. ProdrammerHumor.io