* Update Japscan.kt
I completely changed the way to find the keys allowing the decryption of the base64 which contains the information of the images to be recovered. Before there was a recovery by regex, but this was not reliable because the location of these strings changes places and the order is important because it allows to reconstitute the two decryption keys. To succeed in recovering them correctly and in the right order, I debugged the javascript, which allowed me to understand how obfuscation works.
I understood that the base64 encryption file, the zjs, was not the same file when we had a mobile useragent and a PC useragent, it is however the same key, just that they are placed at different other place
at the end of the file we have the JS which assembles the keys directly as parameters of a function:
a0_0x39cacb('0x13d') + a0_0x39cacb('0x130') + a0_0x39cacb('0x118') + '6N', a0_0x39cacb('0x145') + a0_0x39cacb('0x116') + a0_0x39cacb('0x10f') + 'oe'
we have another function here:
return a0_0x46c1 = function(_0x46c1ab, _0x5a3fac) {
_0x46c1ab = _0x46c1ab - 0x105;
let _0x5c76b5 = _0xd80153[_0x46c1ab];
return _0x5c76b5;
}
which call string array which contains the key chunks
0 : "laretiLesrap"
1 : "gnp.600/sgmi/"
2 : "atad"
3 : "daol"
4 : "8ceABpX"
..
_0x46c1ab = _0x46c1ab - 0x105;
this operation allows to know the shift in the table, for example
By subtracting 0x105 from '0x13d', we get:
317 - 261 = 56
at location 56, so at index 55 of the array we have: "ohcVEMDTYO7FpBA20zRg"
so here: a0_0x39cacb('0x13d') + a0_0x39cacb('0x130') + a0_0x39cacb('0x118') + '6N'
we replace a0_0x39cacb('0x13d')
by this chain
"ohcVEMDTYO7FpBA20zRg" + a0_0x39cacb('0x130') + a0_0x39cacb('0x118') + '6N'
and that gives us the beginning of the key
and then reverse it
and that gives us the right key
* Update build.gradle
Update build version
* Update Japscan.kt - Completely reverse JavaScript
My modification was missing part of the javascript code to reverse, this modification brings greater stability.
In the JS is decrypts the data, there is a table of character string, this table is the most important element of the decryption because it is used in almost all the functions.
What the algorithm does in a nutshell:
- he shuffles the board until he arrives at a precise position, he pushes all the elements backwards until he finds the right combination. The correct combination is determined by the sum of the digits in the character strings with a more or less complex calculation.
- It calls the table in a "hidden" way with a function that takes a hexadecimal as a parameter (which corresponds to the index in the table)
- once all the keys have been retrieved from the character string table, it assembles them, then reverses them to give the complete key
How I proceeded:
- For the correct position in the table I perform almost the same calculation as the JS but I simplify, this to a tiny margin of error. In the calculation in the JS it parses the INTs in the chain and makes calculations with it, to simplify my task I only check if ALL the elements used contain INTs, I did several debug tests and they are obliged to contain them when the position is good. So starting from this principle I would almost certainly fall on the right position.
- Once my array is correctly sorted, I can with a simple calculation managed to recover the requested element with the hexadecimal
- I reverse the keys and I test the two positions of the keys to decipher the base64
* Update Japscan.kt
Added the possibility to have the parseInt in negative
* Update Japscan.kt
Modification needed to take into account the wider possibility of script changes
* Update Japscan.kt - Add comments
Ajout des commentaires
* [Japscan] Rate limit
* idk
* handle cloudflare shenanigans leading to not finding zjs strings
* translate exceptions
* add number of lookup strings found
* Fix for thumbnails loading
* Increment Version
* Second fix for the JapScan Thumbnails
* Second fix for the JapScan Thumbnails
* Last fix for the JapScan Thumbnails
Co-authored-by: DF-Aces <johanbaker98gmail.com>
beerpsi