• Add a switch in the corner to let the user swap to dark mode.
• Remember this preference.

Since this is pubic now, we should add a license.

We need a little logo and some simple branding stuff (theme colors, font, etc).

The original design for Decompiler Explorer included a box in which the user could type source, which would then be compiled and have the binary be sent for decompilation and shown as the results. This makes it a lot faster to round-trip source -> decompiled source, which is likely what most people care about seeing anyway.

Including this would add the additional overhead of needing to run compiler workers (something the original did), potentially for many versions of the compilers ala Compiler Explorer. Users will likely want to specify compiler/target/platform/commandline options.

You can upload anything and it will be fed to the tool. Try to narrow down what's actually supported and do some basic filtering.

Related #35

Currently results are captured with other logging messages into one stream. These should be separated so output is displayed independently.

I'm not familiar with Boomerang, but Reko and Snowman should be pretty fast. Something may be broken in the backend.

We can detect crashes and failed decomps easily enough. Correctness and formatting are more challenging. If a decompiler generates incorrect/unreadable output, give an option to the user to flag it for investigation by the vendor.

Currently it just shows "404 not found" or "Bad gateway" depending on which stage in the deploy process is running. We should have a nicer "updating, please wait" page.

Currently waiting for docker swarm to tear down is a manual process, would be great to automate this.

Eventually we will want to compare different versions of decompilers to see how they evolve over the years, this should be an option similar to how CompilerExplorer does it with an easy dropdown/searchable list.

It would be nice to have sample files included on the site to demonstrate the functionality without requiring users to upload a binary of their own. It would make using the site from a phone actually have results. Also it would demonstrate the output for desktop users who initially open the site, instead of just a blank screen.

Our users are likely to be VR experts/enthusiasts, so someone is just going to try it eventually. The current docker-based container system is decently separated, although Docker Is Not A Security Boundary still applies. The key resources to protect are the commercial software/licenses and the auth tokens, though it would be nice to also maintain availability.

General architecture:

• Frontend (nginx?)
• Middle (glennbolt?)
• Backend (all the decompilers)

MVP:

• binary upload
• Binja/Ghida/Angr output
• resource limits (filesize client/server limits and runtime server limits)
• rate limiting of some kind
• separate frontend/backend
• traefik/HTTPS
• cached/static render
• S3 storage
• authenticated api
• Don't use printing but rather return value from wrapper (change structure of back-ends)
• Syntax highlight apps that don't have it built-in
• Make go pretty (theme HTML)
• Comment out version info at top of file and normalize text for each decompiler
• Add readme
• Escape non-html output

POST MVP:

• S3 logins for friendlies
• some threat modeling/dealing with eventuality of being popped
• Support for uploading source and/or selecting a function?

Some of the provided samples include binaries which apparently timed out during analysis:

• Preferably we adjust the timeouts so this does not happen on samples, especially with default-enabled tools.
• Sample binaries are not available so I cannot confirm locally and check that the tool is not choking on the input.
• The timeout is not listed so I don't know how long the tool took before timing out.

If someone shares a decompiler bug repro via dogbolt link, it'd be nice to allow anyone receiving that link to download the input file, so they can reproduce the issue locally.

This would allow dogbolt to be used to report issues to open-source decompiler issue trackers, without unnecessarily restricting the people who can reproduce and fix such issues.

https://github.com/mborgerson/mdec/tree/master/backend/jeb

Setting the hard limit less than INFINITY causes it to crash. Only on the deploy server though, this did not happen on my local install.

>>> args.mem_limit_soft=10000000000
>>> args.mem_limit_hard=10000000000
>>> decompile_source(args, conts)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 9, in decompile_source
__main__.DecompileError: b'Traceback (most recent call last):\n  File "decompile_retdec.py", line 58, in <module>\n    main()\n  File "decompile_retdec.py", line 23, in main\n    subprocess.check_call([RETDEC_DECOMPILER, \'--output\', outfile.name, \'--cleanup\', \'--silent\', infile.name], stdout=subprocess.PIPE, stderr=subprocess.PIPE)\n  File "/usr/local/lib/python3.8/subprocess.py", line 364, in check_call\n    raise CalledProcessError(retcode, cmd)\nsubprocess.CalledProcessError: Command \'[PosixPath(\'/home/decompiler_user/retdec/bin/retdec-decompiler\'), \'--output\', \'/tmp/tmpgp113qgs/tmp18f8xilr\', \'--cleanup\', \'--silent\', \'/tmp/tmpgp113qgs/tmpqfw3g882\']\' died with <Signals.SIGABRT: 6>.\n'

>>> args.mem_limit_soft=100000000000
>>> args.mem_limit_hard=100000000000
>>> decompile_source(args, conts)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 9, in decompile_source
__main__.DecompileError: b'Traceback (most recent call last):\n  File "decompile_retdec.py", line 58, in <module>\n    main()\n  File "decompile_retdec.py", line 23, in main\n    subprocess.check_call([RETDEC_DECOMPILER, \'--output\', outfile.name, \'--cleanup\', \'--silent\', infile.name], stdout=subprocess.PIPE, stderr=subprocess.PIPE)\n  File "/usr/local/lib/python3.8/subprocess.py", line 364, in check_call\n    raise CalledProcessError(retcode, cmd)\nsubprocess.CalledProcessError: Command \'[PosixPath(\'/home/decompiler_user/retdec/bin/retdec-decompiler\'), \'--output\', \'/tmp/tmpnd1o63o3/tmp94lqqgqz\', \'--cleanup\', \'--silent\', \'/tmp/tmpnd1o63o3/tmp_fhab1h3\']\' died with <Signals.SIGABRT: 6>.\n'

>>> args.mem_limit_soft=100000000000
>>> args.mem_limit_hard=resource.RLIM_INFINITY
>>> decompile_source(args, conts)
b'<pre>//\n// This file was generated by the Retargetable Decompiler\n// Website: https://retdec.com\n//\n\n#include <stdint.h>\n#include <stdio.h>\n\n// ------------------- Function Prototypes --------------------\n\nint64_t __do_global_dtors_aux(void);\nint64_t __libc_csu_fini(void);\nint64_t __libc_csu_init(void);\nint64_t _fini(void);\nint64_t _init(void);\nint64_t _start(void);\nint64_t deregister_tm_clones(void);\nint64_t frame_dummy(void);\nint64_t function_1003(void);\nint64_t function_1040(void);\nvoid function_1043(int64_t * d);\nint64_t function_1050(void);\nint32_t function_1053(char * format, ...);\nint64_t function_1103(void);\nint64_t function_1143(void);\n...'

>>> args.mem_limit_soft=resource.RLIM_INFINITY
>>> args.mem_limit_hard=resource.RLIM_INFINITY
>>> decompile_source(args, conts)
b'<pre>//\n// This file was generated by the Retargetable Decompiler\n// Website: https://retdec.com\n//\n\n#include <stdint.h>\n#include <stdio.h>\n\n// ------------------- Function Prototypes --------------------\n\nint64_t __do_global_dtors_aux(void);\nint64_t __libc_csu_fini(void);\nint64_t __libc_csu_init(void);\nint64_t _fini(void);\nint64_t _init(void);\nint64_t _start(void);\nint64_t deregister_tm_clones(void);\nint64_t frame_dummy(void);\nint64_t function_1003(void);\nint64_t function_1040(void);\nvoid function_1043(int64_t * d);\nint64_t function_1050(void);\nint32_t function_1053(char * format, ...);\nint64_t function_1103(void);\nint64_t function_1143(void);\n...'

When we merge a fix, the entire site goes down apparently. It would be nice to minimize this disruption. An easy solution is to have the public service update nightly. Ideally standing up the new version before tearing the old version down so we can transition smoothly.

current decompiler iframes don't flow well in mobile resolutions. AKA: make moar responsive

The repo is moved to https://github.com/decompiler-explorer/decompiler-explorer

We need an FAQ page that includes:

• What this is (for people who aren't familiar with decompilers)
• Links and short descriptions for all of the tools involved
• How it's being hosted (CPUs, RAM, etc)
• Who made it
• Where to get the code
• How to contribute to the code

Anything else?

Currently if you have a dogbolt link where two tools disagree, there's no way to know which one is correct. (e.g. BinaryNinja vs Hex-Rays here)

Adding a "disassembly" pane would give a source of truth, to allow users to understand what the input to the decompilers actually was, and which one is correct.

Just checked the workers and found multiple runners from various decompilers, just spinning. We probably need to have a stricter timeout on the runner script and actually terminate the process correctly. I'm not sure why the current implementation didn't work.

Notable finds:

• Reko
• RecStudio
• Boomerang

https://github.com/mborgerson/mdec/tree/master/backend/hexrays

Would be interesting to see a decompiler test suite added such as this one https://github.com/frabert/extreme-decompiler-showdown by @frabert

Could show users specific features, feature parity (or lack thereof) and would cut down on load of people just uploading sample test binaries.

30 seconds timeout on current hardware doesn't seem to decompile even the smallest executables. We should bump up either the timeout or the hardware before release so it actually gets results.

If service is being run in a network not connected to the Internet, assets will fail to download from CDN provider. Just serve them locally.

We want this service to help improve the tools, so when things fail we may collect and store the submitted binary for analysis. Don't send us anything you don't want us to keep.

• Currently everything is squashed into center container making >3 decompiler comparison pretty tight
• Checkboxes/Input section take up more space than necessary
• Don't need a footer, just put the mention about GitHub in the header

Recommend something more like mdec:

The decompiler names should be clickable with links to the vendor's preferred landing page.

Test PRs to make sure they don't blow up deployment.

I have something you can start with here: https://github.com/mborgerson/mdec/blob/master/.github/workflows/build.yml

Try to bring down startup costs for this tool.

Decompilers may provide options to adjust their output. It would be nice to be able to expose some options.

https://github.com/mborgerson/mdec/tree/master/backend/r2dec/mdec-r2dec

Currently the only way to access the uploaded binaries is via SSH to the deployment box, or via Django admins. We should look into a cleaner solution that allows us to give access to these binaries without giving complete access to the rest of the infra.

Put all the functions in the same order in each decompilation so it's easier to compare.

User selects file and then has to mouse over to upload. Just upload the binary.

M2c is quite possibly more accurate for mips/ppc than the other decompilers as its fine-tuned for byte-matching decompilation.

https://github.com/matt-kempster/m2c

You can test it out here:
https://simonsoftware.se/other/m2c.html

and here:
decomp.me

If you need some mips assembly:
https://github.com/n64decomp/mk64/tree/master/asm/non_matchings

Currently, workers are poll-based and if you have 2 instances of one worker, they will both try to decompile everything. We should do one of the following:

• Make the queue push-based and server-authoritative
• Make the clients "check out" requests and skip over others' checked out requests

It may be insightful to see how long an analysis took in a particular tool.

Related #55

User may want just one function in a binary. Allow specifying functions to display, vs showing the entire binary.

Basic "hello world" program that runs in 3 seconds on my local box, timed out on the deployment after 120 sec.

This binary: https://dogbolt.org/?id=a539678b-ea84-4dbd-9fbf-b566613f787

Upload: uploads_binaries_797ff3689d304e6a9ffa154ee3e8e20d5d10b62e233740a6028dd0e03caaf3bf.zip

Currently the frontend polls requests every second for every decompiler, which ends up being 8 req/sec/user, which is a lot. We should reduce this number by using only 1 request per binary job, and remember to cancel outstanding requests if the user uploads a new binary. We may be able to use websockets instead, to really tone down the volume of requests

Not getting output for simple binaries.

Mention:

• This is a collaborative effort, so we should change the 'Made by Vector35' verbiage to reflect it
• Mention the GitHub org
• Update URLs

Fat Mach-O files are a collection of binaries in one file, separated by architecture. Some of the tools can read the containers and analyze them, while others fall over, even if they could analyze the inner Mach-O. Similar happens with archive libraries (.a). It would be nice to have some way to "thin" the files for the decompilers with less capable loaders.