thank you, Pearson, for this opportunity

Maybe encrypted to hide backend internals?

Well the issue is pointed out clearly on line 5

Base64?

@netikras yah, looks very much like it. @parzi, did you try base64 decode? what does it say?

Pearson OMG

So it just prints whatever the ErrorMessage query param is?

@JhonDoe naaah it's not..

netikras@netikras-xps:~$ a="wAG4Ls1xGXEbgn7vknPiATyYGrCcMXB2Y1W"
netikras@netikras-xps:~$ echo "${a}" | LC_ALL=C base32 -d
base32: invalid input
netikras@netikras-xps:~$ echo "${a}" | LC_ALL=C base64 -d
�
�.�qq�~��s�
<���1pvcUbase64: invalid input
netikras@netikras-xps:~$

EDIT: Well okay, it prolly is, but it's still encrypted -- not a plaintext message in b64.

@netikras Try echo $a | base64 -d | gzip -dc

@dcprm I don't have the full text you know :) Feel free typing it all by yourself :D

@netikras sorry about that! I will try.. but I think it might be encrypted anyways..

@dcprm And you still don't have >50% of the message...Doesn't gzip need the whole message to unzip anything from it? Honest question

@dcprm I have a feeling it's a stack trace... Look at those line lengths. The shortest ones prolly refer to either "at java.lang.reflect.Proxy" or "Caused by:".

And that would explain the use of printing errors in FE! Whoever knows how to read it can read it and debug. All others - just see it as a crypic text

@netikras I don’t think so.. unlike Zip, gzip can uncompress in-stream as in this case pipe. What we should be able to see is that magic number in 10 byte header. More information at Wikipedia https://en.wikipedia.org/wiki/Gzip

I have tried incomplete files with gzip it does give me output but just prints garbage characters at the end 🗑

@dcprm I tried that too :)

netikras@netikras-xps:~$ a="wAG4Ls1xGXEbqn7vknPiATyYGrCcMXB2Y1W"
netikras@netikras-xps:~$ echo "${a}=" | LC_ALL=C base64 -d >/tmp/smth
netikras@netikras-xps:~$ file /tmp/smth
/tmp/smth: data
netikras@netikras-xps:~$

Since a newline is not a part of base64 codeplate I'm guessing each line is encoded/encrypted separately. That said dumping the first line and trying to analyze it should work.

EDIT: ohh.. a newline represents a plus :) And + is in the b64 codeplate. My bad!

EDIT2: GZIP + b64 feels awfully weird btw... Why gzip it then if you're still exploding the amount of data transferred by b64ing it?

Most probably just encoded ciphertext of the actual stacktrace.
They probably don't want to show so much info about their systems.

If you manage to decode it and I’m right about line 5, you owe me a penny

oh my god what happened.

It takes whatever you give it. Two people noticed the URL.

It's literally random.org output so no it's not b64, even encrypted.