0

I have a problem that I cannot found for days. I need to decrypt a response message, but the encrypted message is in the body of the response. The encrypted message is not encoded to string (ex: base64).

The response body:

{"status":"1","message":"o¨:\u0005Í#cÒßàÂîà\u0015°;æ5\r÷\u00267\u0015èÕ ðC35Á\u003c\u0007whq`{1fv\u000bÀ¯\u00188?Í2,`zpT rÚAÖ\u0005þ9¯¢@rëQ}COQQÄd]\u000b\bRU¯~E:ßUpgÊó\u0010XôØ\u001aræ|\u0007(KÉS\u0000dNr\u0003¾ zi0á\u0017¯ò°j\u0015éÕ÷µ\u0017 \u001a4\u0018u£Iûô\nQ\fâ\u000bÃO¼Õîðѳ?åýÝ\u003c{A\u000e\u00275+УÜÅQ\u0026´EµÁ\u0016$\u0010Ù\t~|¼0*º41ÒL~Ŭ{­A\u0014²\u001cµÉ tÎåhTØÍt@\u0010ð^0sZ\u003d\u003d\u00010ñZ\"\u000e\t)\u001e\u0005ªÆKÑÜÓ©Uä¦wÙ3ó¡{oúh®aÉ/B´\u0019\u001bÿ+¯óÍ\u0004»÷çôÏ°xsh.,Ó`¤7\u0007é^ÇÈ1/Ä\u0026¦1\u001cÕívpÖ¯_Àý\tÎø½dÍæ]\u001e\u0017\u0000IÄÙ;í\u0007ek4ÇF§gk\u0015\u001d¯t[\"²\f\u001bPÿíiì\fªô+\u003e£~ß \tAb¿\u001b\u0011{Ê7\rf\u0017g\u001e¤\u0004o\u000e×ÐôL\u001dè1¥¯åÀi\u001c.BiÞ\u0019Ü\f³Ù\u0006`ØiÏËP쾯uÉØt\u0026QÖ^¶\u001a??\u001doc\u0003ï9\u001c»û\u0007\u0014\u0012\u001c\u001dMÂDpWkLdOD­ò¥C\u0017ÖAkmÍ~½\u0005¡ë,}0É\u0005]v°u+øüüñMïçîf¯¹\u0016ç4ÏÈ\u0003Ì01\u0011dÈïü¥§USÔHFÇÌ¡+CF"}

The response header:

X-Application-Context : application
Date : Wed, 06 Feb 2019 08:59:20 GMT
Content-Type : text/plain;charset=ISO-8859-1
Transfer-Encoding : chunked

I need to decrypt in message parameter. I tried to googling it, almost every answer is saying that the encryptor should encode the result to string first. But in my case I cant make the encryptor to do that. The encryptor also dont want to tell how to read the message.

Everytime I use solutions I found, I always get the same error:

Input length must be multiple of 16 when decrypting with padded cipher

The encryption using AES/CBC/PKCS5Padding. I decrypt the message using java spring. Thanks in advance.

KSD Putra
  • 487
  • 2
  • 7
  • 1
    The string you've been provided with is unicode escaped (yuck, it should be encoded to base64 really), try the answers on [this question](https://stackoverflow.com/questions/13700333/convert-escaped-unicode-character-back-to-actual-character). – Luke Joshua Park Feb 13 '19 at 03:13
  • The solution you give isnt suitable for complex message as in my case. A comment in the thread said it, and I have tried it too. Still, thank you :) @LukeJoshuaPark – KSD Putra Feb 13 '19 at 03:26
  • 1
    Yeah I thought that might be the case. Since the data is encrypted and then unicode escaped to a string, you're likely losing information in the UTF8 conversion. I'm doubtful you'll be able to convert it back to the original byte array. – Luke Joshua Park Feb 13 '19 at 03:31
  • There are another companies that used this very same service. And the encryptor said the others can convert it back. So there is a way. – KSD Putra Feb 13 '19 at 04:02
  • In the JSON you showed, the encrypted bytes were first expanded as-is into Unicode characters (because that is what JSON works with), then certain characters were escaped in `\u00XX` or `\X` format (see Section 9 of the [JSON spec](http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf)), and then the resulting characters were encoded to ISO-8859-1 for transmission. You need to reverse that process... – Remy Lebeau Feb 16 '19 at 01:17
  • ... decode the ISO-8859-1 to Unicode characters, then parse the characters and decode the escape sequences (any JSON parser worth its salt can do that for you), and then truncate the resulting characters to 8bit. You will now have the original encrypted bytes that you can decrypt as needed. – Remy Lebeau Feb 16 '19 at 01:19
  • @KSDPutra IMHO using binary data without encoding is very bad practice. Some characterset encodings and libraries may discard non-printable characters or misinterpret the escape-based encoding. I suggest you get in touch with the service provider and manage to get the binary data properly encoded (base64 or hex). – gusto2 Feb 21 '19 at 08:44

0 Answers0