Currently decoding is triggered by selecting “Decode as…”, but encoding cannot be triggered directly. I work around it by first selecting “Encode as…” to triggers a new row, then back to “Decode as…”. I can think of two solutions:

1. Add a button “Go!” to trigger it explicitly.
2. Add a null element “Action:” so that the drop-down also changes for encoding.

Hi,

could you make it adapt to darkmode to show the text in white while in darkmode ?

thank you

Decoder Improved generates new tab labels without checking for duplicates. Presumably this happens because the assigned integer label is derived from the count of existing tabs plus one.

Suggestion: When creating a new tab, keep incrementing the integer label until it becomes unique.

Steps to reproduce:

1. Open a few tabs
2. Close the first few tabs, keeping the last ones
3. Close and restart Burp
4. Observe that the tabs left after step 2 have been restored
5. Open a new tab, noting its duplicate label

Seven tabs restored:

New 8th tab:

I just asked it to decode the following as Base64:

YWFhCg==

The newline on the end caused the error "Invalid Base64 Input", the same happens if you have a space on the end. While the error may technically be true, but it would be annoying having to remember to trim excess whitespace.

It also fails with whitespace on the start, but that isn't quite as bad as a lot of things don't like leading whitespace.

Hi Justin & Team,

Thanks for the wonderful tool. I found that if I am using a dark theme in Burp, the characters pasted into DI will be black on black background hence not very easy to read. Can you change this please?

Thanks

1. After the fix #15 , if a string character is deleted in the string editor, a wrong byte will be deleted if there's any \x0d\x0a before the character. This is caused by inconsistent offset calculated by the function calculateByteOffset() here, as the \x0d\x0a will be rendered as a single \x0a in the text editor.

   It should be noted that the string we get from getDisplayString() here doesn't perfectly match the string in the textEditor.getText(), at least for the \x0d\x0a (newline character).

   The calculation for other UTF-8 unmappable characters seems to work fine. I'll try to enhance it if not all UTF-8 multibyte characters are covered.

   This is fixed by 90d4a8b

2. There are some actions that currently don't support data that contains non-UTF-8 characters (eg. HTML entity encoding). Some of them can be improved.

   This is fixed by #26

3. The insertedText here will be a wrong string if \x0d\x0a is present before the string. It's a bug and needs to be fixed.

   This is fixed by 2ee6e2c

Portswigger reached out to me saying that a user requested the ability to export decoder buffers to file. I'll work on implementing this within decoder improved.

Decoder Improved already implements "fuzzy Base64 decoding", and that's very useful for JWS. However, adding "fuzzy GZip decoding" (like the standard decoder does) would be nice!

Currently, I get error "Invalid GZIP Input" when trying to GZip-decode a full response (with HTTP headers + a gzip'ed body). It's probable that #4 must be fixed first.

Decoder improved runs very slow with a large amount of text. Need to improve its performance. Possible causes:

• Unnecessary operations/clone of byte array.
• Unoptimized algorithms in modifiers (at least for URL/HTML encoders).
• Poor undo/redo implementation.
• Redundant logic (listeners etc.) in updating segments and UIs (text editor etc.).
• Memory leak.

BApp Store version of decoder-Improved is quite old. In order to update it you should issue a pull-request to https://github.com/PortSwigger/decoder-improved repo. Would you consider doing that?

Enhancement after #19

Something sounds buggy (due to Burp not supporting extension settings per project) is that the working state will be shared across all Burp instances (including temporary instance). A workaround may be creating a unique name of the setting profile per instance, but it's currently not ideal since there's no way we can delete the settings (unless Burp recycles them). See here for more info.

Or, save the settings to a file and allow users to recover the state from it manually (unless there's a "Burp config files" folder, which seems not).

Another thing might be worth implementing is to add a button that allows the user to clear the setting manually, like at the end of a project to clean up all data.

If a response containing some binary data (here a tar.gz archive) is sent to Decoder Improved, some characters are mangled and replaced by \xEF\xBF\xBD. This sequence is the UTF-8 value for the replacement character, used to "replace any incoming character whose value is unknown or un-representable".

As you can see in screenshots, the sequence "\x1F\x8B\x08" is converted to "\x1F\xEF\xBF\xBD\x08"

More info:
https://apps.timwhitlock.info/unicode/inspect?s=%EF%BF%BD
https://blog.gdssecurity.com/labs/2015/2/18/when-efbfbd-and-friends-come-knocking-observations-of-byte-a.html

Currently the plus sign (0x2B) is being passed through literally. In contrast, the built-in decoder will interpret it as a space character.

Decoder Improved:
abc+-+def --- (decode as URL) ---> abc+-+def

Decoder :
abc+-+def --- (decode as URL) ---> abc - def

I am proposing this change so Decoder Improved maintains compatibility with MIME type application/x-www-form-urlencoded.

https://www.w3.org/TR/html4/interact/forms.html#h-17.13.4.1

Attempts to load the plugin with Beta v2.0.14 results in the following error:
java.lang.NullPointerException
at trust.nccgroup.decoderimproved.JsPrettifier.(JsPrettifier.java:22)
at trust.nccgroup.decoderimproved.PrettifyMode.(PrettifyMode.java:18)
at trust.nccgroup.decoderimproved.ModificationModeManager.(ModificationModeManager.java:49)
at trust.nccgroup.decoderimproved.MultiDecoderTab$DecoderSegment.setupComponents(MultiDecoderTab.java:466)
at trust.nccgroup.decoderimproved.MultiDecoderTab$DecoderSegment.(MultiDecoderTab.java:381)
at trust.nccgroup.decoderimproved.MultiDecoderTab$DecoderTab.setupComponents(MultiDecoderTab.java:264)
at trust.nccgroup.decoderimproved.MultiDecoderTab$DecoderTab.(MultiDecoderTab.java:161)
at trust.nccgroup.decoderimproved.MultiDecoderTab.addTab(MultiDecoderTab.java:87)
at trust.nccgroup.decoderimproved.MultiDecoderTab.(MultiDecoderTab.java:59)
at trust.nccgroup.decoderimproved.ExtensionRoot.registerExtenderCallbacks(ExtensionRoot.java:17)
at burp.BurpExtender.registerExtenderCallbacks(BurpExtender.java:9)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at burp.esk.lambda$registerExtenderCallbacks$0(Unknown Source)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)

At the risk of missing something blatantly obvious, is there a reason why SHA-512 is not supported?

Sorry this is a lame issue but...

... Decoder-Improved is not respecting the dark theme 'Dracula" of Burp 2.0.19beta