Konloch Software

10 Years Of Bytecode-Viewer

Published 10/18/2024

Today marks the 10 years anniversary of Bytecode Viewer. One decade. I started BCV early in my reverse engineering career, I had several years of Java programming experience, but I was still fairly new to the reverse engineering scene.

I’ve learned a lot through this project, and I still continue to do so to this very day. I am eternally grateful for the help, knowledge, and friendships I’ve made through BCV. I really do mean it when I say that I’ve learned a lot, and I’ve grown a lot through this project. I continue to try to keep up with the modern standards the best I can, entirely thanks to everyone who has helped me directly, indirectly, or through the project itself.

When I started BCV the Java reverse engineering scene was very different. In my mind, it was in an era where the popular projects were not maintained, and closed source, so they contained niche bugs. At the same time the tools that did work, possibly missed certain opcodes due to later JVM changes. This meant I personally, had to constantly switch between multiple decompilers back then. (Fernflower, JAD, JD-GUI, DJ-GUI, etc.)

My group of friends (we were all students back then), encouraged reverse engineering, and we would collaborate together. One of my close friends maintained the Java Bytecode editor we used. I decided to take it upon myself to build a static analysis tool that allowed us to get an in-depth look at any compiled Java binary. BCV started off as a student’s passion for reverse engineering, and I’ve tried to keep that experimental attitude throughout.

Back then, the Java reverse engineering scene was not unified - there was several independent decompiler projects but no single project brought them all together.

Part of what made BCV easy to use, was the side by side screens. BCV allows up to 3 panes to be shown simultaneously - when paired with multiple decompilers that have different heuristic engines, the source code produced is generally different for more complicated blocks of code. This means as an experienced developer you can see what the original source code would have been by inferring between each decompiler.

The beauty of Java is the JVM, and the beauty of the JVM is in the bytecode. The issue with it, is it leave a lot open for interpretation. In 2024, the decompilers are doing an amazing job. Generally, all you need to do is pass your classfiles through a deobfuscator first, and then you can use Fernflower, or another decompiler, and you’ll get readable Java source code. If you’re not doing that deobfuscation pass initially, or if the code block is unwieldy large - multiple decompilers are your best friends.

When I started BCV, the term Bytecode Viewer didn’t exist. We called them Java Decompilers (and still do). I like to think BCV is the reason Intellij and other IDEs call their decompilers “Bytecode Viewers”.

Intellij - Bytecode Viewer(Click to enlarge)

My personal feelings for the decade of BCV - gratefulness. I’m glad it’s still relevant enough for me to have to keep my skills maintained, it’s made me a better developer. My goals for the future are to continue to work on the BCV project, maintaining and implementing suggestions / bug fixes when possible.

Obviously I didn’t create BCV by myself. I may have started the project, but I consider myself a contributor and maintainer at this point. The same title as Nico, Bl3nd, and countless others who have contributed to the project throughout the years.

BCV Credits

I like to think I help keep things on track, but the true credit goes to the BCV community. Throughout the years the torch has been passed from developer to developer, each person contributing the amount they could which was just enough to help BCV when it was needed. There are some specific people I would like to talk about, in the chronological order of when it all happened.

Bibl

Bibl is a good friend of mine, and he contributed to BCV back when the project first started. Originally in the BCV beta days, I had maintained my own Bytecode Decompiler, and I included it in the BCV project. It wasn’t the best, and had many pitfalls. Bibl was working on his own decompiler called CFIDE, and he donated the code to the BCV project early on. The default Bytecode Decompiler in BCV is CFIDE to this day, it’s incorporated as one of the default decompilers, and maintained by the BCV community. Bibl also wrote the initial plugin API, we still use this to this day. He also sped up the initial boot time for the non-fat jar releases. Sadly we no longer support that release format, but the code still exists for it.

Fluke

Fluke is another good friend of mine, almost 10 years ago to this day he made the iconic BCV icon. Taking the red Sun / Oracle Java coffee icon, and turning it green. It’s a design I consider timeless, as it stands side by side with the Java counter-part. I believe this icon represents the project perfectly, and embodies everything this project stands for. Bytecode and Java go hand in hand, so the icon should represent that, and it does.

ItzSomebody

ItzSomebody has been contributing code since January 30, 2018. Back when Java-10 released, it introduced some changes that broke BCV. (I believe the ASM library was outdated) - And I was not available at the time to fix it, so ItzSomebody came in and saved the day. He ended up having to revert the codebase to a previous state, rolling back a lot of community changes that complicated the codebase and made it hard to maintain. Without his work, BCV would not be here today.

Nico

Nico has been contributing code since March 27, 2021. There are many things Nico has done for BCV. I am missing a lot, but here are the notable ones I can name. He’s not only upgraded us to maven, but actually talked with me and convinced me why it’s needed and how much of a benefit it could be. (As a result, I use maven in almost all of my projects to this day). He’s helped organize our libraries, and single-handedly maintained and fixed specific niche libraries we cannot operate without. He’s fixed critical bugs with those libraries and continued to contribute to open source in a way that I am very proud of. Nico is truly a developer that I am glad to call a friend, and someone who has taught me a lot, both directly and indirectly through his conversations and code. Nico is one of the main reasons the BCV project is in such a professional state. I truly owe him a lot for what he has taught me.

weisJ

weisJ has been contributing code since August 5, 2021. They maintain the library BCV uses for theming (darklaf) - They are responsible for a lot of the bug fixes / additions the library needed to support features BCV uses. The dark theme is my goto theme, it’s one of the few changes that really brought BCV into the modern era. Nico originally authored this change, but weisJ has continued to really help make Bytecode-Viewer look amazing, including swapping us to SVG icons and more.

GraxCode

GraxCode has been contributing code since March 13, 2022. They have maintained the CFR decompiler API, fixed various bugs and implemented feature additions. Overall the changes provided by GraxCode have resulted in a more stable, modern, and easy to use application.

Bl3nd

Bl3nd has been contributing code since November 3, 2022, so trying to boil everything they have done in a single attribution is impossible. However, the past few weeks Bl3nd has been working on Jump to Declarations. This feature means you can click CTRL, and use your mouse to jump to class, variable, and function declarations. This is a feature I have dreamed about since BCV 1.0 in the beta. Words cannot describe how grateful I am for their work on this, as I use BCV almost daily. Since I’ve been using it with the developer snapshots - I can’t use BCV without it.

Decompilers & Library Credits

BCV wouldn’t be the program it is today without the decompilers it has. I did not make these. The credits go to the respected authors and contributors of those individual projects. I will do my best to name the people I know who helped me personally.

  • FernFlower - This decompiler was the very first decompiler added to BCV. I contacted the authors through E-Mail asking about open sourcing FernFlower but never got a response. I am grateful JetBrains was able to secure the rights to the project, and that they decided to open source it.
  • CFR - Lee Benfield created this decompiler and helped me implement it correctly. They have supported the BCV project since I have contacted them, and I am grateful for their support.
  • Procyon - mstrobel created this decompiler and helped me implement it correctly. They have supported the BCV project since I have contacted them, and I am grateful for their support.
  • Krakatau - Storyyeller created this decompiler, disassembler, assembler, and helped me implement it correctly. They have supported the BCV project since I have contacted them, and I am grateful for their support.
  • JD-Core - Java-Decompiler team created this decompiler and helped me implement it correctly. They have supported the BCV project since I have contacted them, and I am grateful for their support.
  • JADX-Core - JADX team created this decompiler and helped me implement it correctly. They have supported the BCV project since I have contacted them, and I am grateful for their support.
  • Smali / BakSmali - Smali is one of the ways you can edit code in BCV. It’s added to help make android / APK modding easier, but it works for most Java classes as well.
  • Dex2Jar & Enjarify - These projects are used for APK support, they are core libraries used for making APK importing possible.
  • ASM - The core of BCV, without this library we would not be even close to having the amount of content we have in it today. Prior to using ASM we used BCEL and that was painful to work with.
  • Countless others - I know I missed some, but these are the ones that come to my mind immediately. BCV is a great example of a project being powered by countless libraries. BCV by itself is a shell, and all the various libraries give life to the project.

My apologies if the decompiler credits seem canned, the truth is almost all the decompiler authors I contacted were extremely helpful and entirely supportive of the BCV project. I know for a fact Bytecode-Viewer would not be what it is today without their help and support. So I am truly grateful. There is not one that stood up above the rest because everyone did such an amazing job. Honestly, thank you all, still to this day.

There Are Many More

I couldn’t include everyone, but I wanted to talk specifically about these people because they truly have helped ease the burden of development I have felt from BCV. For the latest list of contributors click here.

BCV Forks

Any good piece of open source software should have forks, each with their own unique changes and flavors that make back-porting to upstream hard.

Bytecode Viewer has countless forks, the majority of them are closed source! I think that is wonderful, and I almost wish I licensed BCV MIT due to that. I believe having a shared foundation for reverse engineering is important, and BCV provides just enough to make some really great changes.

Java Disassembler - Created by a friend of mine rcx, this fork is a great example of some amazing improvements to BCV. I’ve included what I could back upstream to the current BCV, but the Maple-IR integration is something I still have to add. This feature is part of the deobfuscation I was talking about earlier, and it makes any decompiler usable. I was lucky to experience this back when it was private, and I am grateful the team let me experience it first hand.

BCV Ports

I maintain the official main BCV repo at https://github.com/Konloch/bytecode-viewer but there are countless ports of BCV out there, all of them official in their own capacity. (Rest assured, they all have my blessing. BCV is an open source project, and I encourage ports, mirrors and other releases of that nature).

Interesting Notes

BCV Future - The Next 10 Years

My plans for BCV are, in no specific order:

  • BCV 3.0.0 - BCV contains enough changes at this point to publish a 3.0.0, so expect that very soon.
  • CLI needs to be rewritten and is in the middle of that rewrite.
  • Continue translation support, I realized there are quite a few bugs with them (failures in translation, etc.)
  • Bug fixes, general additions to features and continued maintenance.
    • ‘uniform decompiler formatting’ - add as a setting etc
    • Refresh should no longer move the scrollbars
  • Expand into more than just Java bytecode - Kotlin, and other JVM specific bytecode support is something I have planned.
    • As well as other bytecode beyond the JVM such as papyrus engine bytecode, lua, etc.

3.0.0 Preview (2024 Release)

The 3.0.0 preview is currently available, the latest snapshot is always on the GitHub page.

We’re in the middle of development for 3.0.0, so you can track the progress now, there is no ETA. The loose goal I wanted, was to release it on the 18th, but we’re not ready yet. I will update this page when 3.0.0 is ready.