Closed merichzte closed 9 years ago
I changed 21 to 22 on line 167, it worked without errors, but not sure if this is a solution.
In Java I used to use 21, in OSDLyrics we're using 23, in PHP 22. For encrypting (the decryption is using the same algorithm, and I quite believe their server too) we're using: {3 bytes for encryption settings, 3 NULL bytes, 16 bytes with request MD5, NULL-ended encrypted string} So, remembering we start counting the array at 0, 3+3+16=22. Than start decrypting at 22 would be the right one anyway...
I'm pretty sure this has something to do with issue #3, maybe there were some 2 bytes combination in MD5 that was being read as an UTF-8 character.
is it possible to check for "<"character then start? Some queries works with 21 some with 22.
Would be wrong, it should always be 22, the problem is that some bytes are misread and interpreted as an UTF-8 multi-byte character. For correctly fixing it, we'll need to catch the result as ISO_8859_1/Binary from the package receiving till decryption, and make sure all the methods called are also treating the String this way, the decryption result and the following should continue to be in UTF-8. The same way you found a querie that in the current code the 22 bytes results in 21 characters, there will be some who can even endup in 10 characters.
The decryption part is something I still need to get my head around.
Seems to have been fixed in 9887cc5395d51bc5f664d11930ae34cad6d681e9, can you check it?
works great! this is a great tool.
In JRE8, when I run the tester I get:
after adding
System.out.println(neomagic.toString());
to line 169 I get:So guessing that "-" at the beginning is creating trouble. I checked stackoverflow for possible answers: http://stackoverflow.com/a/18275066 http://stackoverflow.com/a/7390288
seems relevant. Yet I am not good at this yet, so not sure how to implement them.