Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Binary data encode to base64 give wrong result in 2020.2.1 version

David | Last updated: Mar 27, 2020 01:35AM UTC

The last working version is 2.1.07. Later version when encode binary data to base64 it always gave wrong result when compare with 2.1.07. This request I take from HTTP Proxy History For example here is msgpack encode correct with 2.1.07: iKN1cmyvZG9jdW1lbnQvZGV0YWlspWxhYmVsp3NlcnZpY2Wrc2Vzc2lvbl9rZXmgqHBsYXRmb3JtAathcHBfdmVyc2lvbs0nELJtYXN0ZXJkYXRhX3ZlcnNpb24Aq3JldHJ5X2NvdW50AKxyZXF1ZXN0X2hhc2itMTU4MzkzMzY3NDI5OA== But when use 2020.2.1 version, result is this: /f11cmz9ZG9jdW1lbnQvZGV0YWls/WxhYmVs/XNlcnZpY2X9c2Vzc2lvbl9rZXn9/XBsYXRmb3JtAf1hcHBfdmVyc2lvbv0nEP1tYXN0ZXJkYXRhX3ZlcnNpb24A/XJldHJ5X2NvdW50AP1yZXF1ZXN0X2hhc2j9MTU4MzkzMzY3NDI5OA==

Michelle, PortSwigger Agent | Last updated: Mar 27, 2020 10:59AM UTC

Thanks for getting in touch. Would you be able to email us some screenshots or a screen recording of the steps you're taking to help us try and replicate the issue here, please? If you can email them to support@portswigger.net that would be great!

David | Last updated: Mar 27, 2020 11:37AM UTC

I already provided a correct and wrong result above. Can you please check with your developer in code? It's hard to provide this in screenshot. For example with 2.1.07, these raw bytes data: 88 a3 75 72 6c af 64 6f 63 75 6d 65 6e 74 2f 64 65 74 61 69 6c a5 6c 61 62 65 6c a7 73 65 72 76 69 63 65 ab 73 65 73 73 69 6f 6e 5f 6b 65 79 a0 a8 70 6c 61 74 66 6f 72 6d 01 ab 61 70 70 5f 76 65 72 73 69 6f 6e cd 27 10 b2 6d 61 73 74 65 72 64 61 74 61 5f 76 65 72 73 69 6f 6e 00 ab 72 65 74 72 79 5f 63 6f 75 6e 74 00 ac 72 65 71 75 65 73 74 5f 68 61 73 68 ad 31 35 38 33 39 33 33 36 37 34 32 39 38 encoded to base64 is: iKN1cmyvZG9jdW1lbnQvZGV0YWlspWxhYmVsp3NlcnZpY2Wrc2Vzc2lvbl9rZXmgqHBsYXRmb3JtAathcHBfdmVyc2lvbs0nELJtYXN0ZXJkYXRhX3ZlcnNpb24Aq3JldHJ5X2NvdW50AKxyZXF1ZXN0X2hhc2itMTU4MzkzMzY3NDI5OA== This is the correct result. But in Burp 2020.2.1, these same bytes encode to base64 is /f11cmz9ZG9jdW1lbnQvZGV0YWls/WxhYmVs/XNlcnZpY2X9c2Vzc2lvbl9rZXn9/XBsYXRmb3JtAf1hcHBfdmVyc2lvbv0nEP1tYXN0ZXJkYXRhX3ZlcnNpb24A/XJldHJ5X2NvdW50AP1yZXF1ZXN0X2hhc2j9MTU4MzkzMzY3NDI5OA== which is very wrong.

Michelle, PortSwigger Agent | Last updated: Mar 27, 2020 02:33PM UTC

When we get a bug report, we always try to replicate the issues within the software here as well as taking the information from the original bug report. If we can replicate an issue this means we can check for any other areas/tabs within the software that may be affected. So far, although I understand the issue is with the encoding not being correct and you have provided samples, I am having issues replicating the problem. If you could send some steps or a video to show which tabs show the incorrect encoding, e.g. do you just see this on the Proxy History tab, does it show on the Decoder tab?

David | Last updated: Mar 28, 2020 01:21AM UTC

Hi Michelle, I have sent an email with video showing problem to support@portswigger.net

Michelle, PortSwigger Agent | Last updated: Mar 30, 2020 10:05AM UTC

Thank you!

David | Last updated: May 03, 2020 02:52AM UTC

It has been more than 1 month and the latest 2020.4 still has this same problem :(

Uthman, PortSwigger Agent | Last updated: May 06, 2020 10:55AM UTC

This issue has been raised with our development team and you will be notified when a fix is implemented.

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.