psifertex

It's not abhorrent. It's quite common and the correct thing to do here.

Them not disclosing doesn't make you safer. The people that want to abuse this could be actively exploiting it shortly after the commit went live. Waiting more time before the blog / marketing release is NOT the help you think it will be.

This is a very, very, old debate in the security community, just read the rest of this thread and you'll see plenty of explanation as to why.

They did not, in fact, botch anything. They notified the responsible party and followed a practice that is pretty much the accepted norm (and for good reason).

How recursive should their notifications be? Just the tip three distros? The top dozen? Every embedded Linux router company? How about every hosting provider?

They did what they're supposed to without being paid for it. The only other good source of funding for security research besides marketing budgets for security companies will NOT result in a disclosure timeline you'd be happier with. ;-)

I doubt it will and I hope it doesn't.

External security research happens for one of only a few reasons typically:

1) hobbyists who are learning or just like to do it for fun 2) bug bounties (good luck with those in most open source) 3) marketing for security companies 4) non-public research going to CNO/CNE

If you want to kill 3, the output of 1 will not come close to 4 and the public is NOT better off with fewer public bugs.

You could try to make that case either way, but as has been pointed out by others all over this thread, the system we've landed on (90/+30) is industry standard after over two and a half decades of experimentation.

Anything else inevitably has worse for the public good.

Having spent that entire time and then some on both offensive and defensive teams, I assure you longer delays after notification do NOT decrease the overall risk to the public.

There's a reason we've landed where we have as a security community.

I'm curious what you would consider better UX?

We have actually been more inspired by Jetbrains lately than VS Code. Take that for what you will.

We do try to pick simple sane defaults while still allowing enough customization to adapt to different workflows.

Actually working on a startup wizard for first time users if they want to more closely replicate the feel of other RE tools since muscle memory is hard to break.

IDEs have changed a lot in the last 50 years. Just like we shouldn't advocate for hand writing assembly for all code, we shouldn't be stuck using CLI tooling the same way.

I share your apprehension regarding the current AI landscape changing so quickly it causes whiplash but I don't think a mindset of "it's been fine for 50 years" is going to survive the pace of development possible by better LLM integration.

Yes, actually, if you know someone there they were selling extras:

https://defcon.org/html/links/dc-news.html

I don't know why people think this, you're not the first person I've heard it from either.

First, I literally saw them do shots during a talk yesterday for some first-time presenters. Secondly that WASN'T the "old defcon" either! Drinking is a relatively new tradition in the history of the con. I've spoken twice. Once at DC 17 (no shot offered) and once at DC 23 (shots were offered). There's video proof:

No drinking, DC 17: https://www.youtube.com/watch?v=okPWY0FeUoU Asked to drink, opted for a coin instead (we were asked beforehand): https://youtu.be/6dmvtbrM6hs?feature=shared&t=1153

Can I just say, thanks to the person who posted this for waiting until this week to do so. (Side note: I suspect it was due to the recent coverage from C++ Weekly which is a great resource: https://www.youtube.com/watch?v=h3F0Fw0R7ME)

As recently as last week we had some horrible performance problems but it looks like the queue (https://dogbolt.org/queue) is mostly still fine! Other than the long pole of a few of the decompilers being backed up, things are humming along quite smoothly! Josh + Glenn have done some great work on it! (https://github.com/decompiler-explorer/decompiler-explorer/c...)

Yes, lets! And before hacker summer camp when we're way way too busy! :-)

Binary Ninja likewise is empty and keeps up just fine as well. It's not a coincidence that the two commercial products that are funding it are both confident enough to put their stuff online like this.

And it's no conspiracy theory or intentional sandbagging, you can see the implementation: https://github.com/decompiler-explorer/decompiler-explorer

and if anyone can improve the other tools performance we'd be happy to accept it. We reached out to the Ghidra devs: https://github.com/NationalSecurityAgency/ghidra/issues/5228 but they didn't have any silver bullets for us either.

Yup, I'm aware of both of those, but none of those tools listed so far are intended for the IR to be for human-consumable unlike disassemblers and decompilers. You think disassembly is verbose compared to a decompiler? Go look at the equivalent Vex (Valgrind's IR) for any non-trivial disassembly. It's suuuper verbose.

As far as I know, BNIL (https://docs.binary.ninja/dev/bnil-overview.html) is the only one that is designed to be readable and it still wouldn't make sense to include it in an IL comparison such as the one done here for decompilation in my opinion.

That was indeed the logic. The two main commercial solutions included (Binary Ninja made by Vector 35, where I'm one of hte founders) and Hex-Rays both pay for all the hosting costs. And it's not particularly cheap -- there's a fair amount of compute to drive the decompilers especially as some of them are... not very efficient.

IRs aren't generally suited toward small snippets of examination by human when you're starting with a full binary. I would imagine something like that would only work well when done for very small bits of assembly. Likewise, you might be interested in BNIL which is an entire stack of ILs that Binary Ninja is based on. (You can see it exposed in the cloud.binary.ninja UI or the demo)

We know! Similarly, the GH repo is actually the Decompiler Explorer:

https://github.com/decompiler-explorer/decompiler-explorer/

I do remember dogpile, but as one of the folks who named it, nope, that wasn't a conscious influence!

It's been on the dev builds enabled by default for several months now and no longer labelled beta, but we're in the middle of a release process right now so at some point soon this week the current stable will have a full debugger release (though you can try that version now if you switch to dev)

Was this due to load or server restarts or are you still seeing errors? Pass me a GUID either publicly or privately (my handle on twitter accepts DMs or an email address at my handle.com as a domain) if you don't mind and I can take a closer look.

Binary Ninja can as well (sorry for the delay, been on vacation this week) though none of the tools will download and use PDBs that might be available via public servers or otherwise by default in the configuration we're using on dogbolt. It would potentially be possible but our goal isn't to provide a test of all tools in all possible configurations as much as it is to get a good overview. Once you start tweaking each tool differently you're better off running that sort of analysis locally.

And both companies behind those licenses (hi, I'm one of them!) donated licenses to support this.

That said, you're right. It's unlikely we'd ship our entire binaries plus code to live in-browser though the amount wasm stuff people are doing lately is fascinating.

This is actually why we chose _not_ to implement no-more-gotos for Binary Ninja's HLIL! Code is actually more readable with gotos in some situations and trying to force their elimination hurts readability.

Nope, not when you ask them and they provide the license.

This is being run with the permission of all the commercial products. In fact, we (Binary Ninja) and Hex-Rays (once I figure out the exact mechanism with Ilfak) are the ones actually paying hosting costs! It's both good for the community and hopefully shows off the value in commercial decompilers. :-)

Nope, Ilfak gave us a license for it and as Binary Ninja devs we're using a legitimate licensed copy of Binary Ninja as well. All above board and we're hoping to add more commercial decompilers in the future as well as we can integrate them and the companies behind them are willing.

RE: Demand. We just got 2x the workers but as the easy coast wakes up I'm not confident it'll hold up too well, several of the decompilers are... VERY resource intensive so there's really no good way without an exorbitant amount of compute to scale to heavy demand.

Eventually a better queue system with better pre-processing to filter invalid things is on our todo list

Thanks! We debated it some internally and I'm glad it won out, I think it's worth it. Plus, it has a nice logo that goes with it.

Yeah, sorry about that. We're working on getting it up again but no promises. I'm on vacation in Europe while the rest of the team is about to head to sleep so might be a bit before we have it more stable.

Sorry for the outages, friends. We're actively working on getting it able to handle higher load but we knew that if we hit HN we'd be swamped no matter what we did. We're spinning up more workers and fixing obvious perf issues as we see them, but if it's not available when you try it make sure to check back later!

No need to use a password manager. Simply search email history for the very first usage of the email...

I agree there were many others (beyond even these I can think of a several), but I think Ryan was mainly referring to was how many were regular online CTFs at the time.

Wasn't both barcode-shmarcode and oCTF both more in-person events than available online?

So I do a weekly live-stream which is a bit much to follow to just casually learn: https://youtube.com/c/vector35

But more importantly, there are video excerpts for some basic features which should at least help with understanding how to use BN:

https://www.youtube.com/watch?v=xKBQatwshs0&list=PLCVV6Y9Lmw...

We've got a few more in the editing queue I need to clear out as well.

That said, I agree in terms of needing more intro tutorials would be helpful. Part of the problem with producing something like the IDA books is that we are under far too active development. Our UI and features have grown exponentially over the past few years so there was just never a good time to make something that wouldn't be out of date before it was even done.

You might be interested in joining the Binary Ninja slack which is a great community for getting questions answered. https://slack.binary.ninja/

There's also the free cloud version which doesn't have quite the same features but is an easier introduction without paying. https://cloud.binary.ninja/

Totally fair -- breadth of architecture support is definitely one of the biggest strengths of Ghidra! IDA does as well but purely for disassembly which isn't nearly as useful.

EDIT: But yeah, we designed our lifting to be as simple as possible. Specifically the way we handle flags tends to simplify much of the normal tedium around what's required for other decompilers. If you do decide to build a C167 module, give us a look again. :-)