There's a new Ghidra release last week! Lots of improvements to the
debugger, which is awesome. But this brings up some thoughts that have been
triggering my vulnerability-and-exploitation-specific OCD for some time now.
Behind every good RE tool is a crappy crappy database. Implicitly we, as a
community, understand there is no good reason that every reverse
engineering project needs to implement a key-value store, or a B-Tree
or partner with a colony of bees which maintain tool state by
various wiggly dances. But yet each and every tool has a developer with
decades of reverse engineering experience on rare embedded platforms either
building custom indexes in a pale imitation of a real DB structure or
engaging in insect-based diplomacy efforts.
I think the Ghidra team (and Binja/IDA teams!) are geniuses, but they are
probably NOT geniuses at building database engines. And reading through the
issues <https://github.com/NationalSecurityAgency/ghidra/issues/985> with
ANY reverse engineering product you find that performance even for the base
feature-set is a difficult ask.
My plea is this: We need to port Ghidra to Neo4j as soon as possible.
Having a real Graph DB store underneath Ghidra solves the scalability
issues. I understand the difficulty here is: There are few engineers who
understand both Neo4j and reverse engineering to the point where this can
be done. I mean, why do it in Neo4j and not PostGres? An argument can be
made for both, in the sense that PostGres is truly Free and the most solid
DB on the market. The pluses for Neo4j are that RE data is typically
graph-based more than linear.
I spent the last two years learning graph dbs, out of some masochistic
desire and ended up getting certified - and I can still RE a little bit. I
will manage the team porting Ghidra to Neo4j if someone funds it. :)
Either way, sooner is better than later. There are so many companies and
people relying on these tools that it seems silly to do anything else.
P.S. Yes, I remember BinNavi used MsSQL installs for its data, and this was
annoying to install but ... I get why Halvar did it at the time. It's
because he had real work to do and building a DB was not it. I can only
assume Reven doesn't use their own DB? I mean the benefits for
interoperability would be huge between tools. . . like literally everything
you want to do with these tools is better with a real DB underneath.
Lately I've been watching a lot of online security talks - the new thing
for conferences to do is publish them almost immediately, which is amazing.
So like, today I watched Chompie's talk:
(I was honestly hoping it went from RCE to logic bug and allowed you to log
in, but maybe left as an exercise for the reader).
And yesterday I watched Natalie's talk:
(I'm still a bit confused as to how you connect to a phone's baseband with
SIP, but maybe I will ask later at some point). Does the baseband just have
some TCP ports open for RTC shenanigans? If so, that's great, #blessed, etc.
I actually forgot to post my own talk here, so if you want to watch that,
My talk is not actually a call to hack enterprise products - which ya'll
are clearly already doing a lot of (I'm just assuming there are members of
the FIN11 ransomware crew on this list somewhere). It's more about
understanding which business models lead to easy bugs - enterprise software
obviously being one of them, but, for example, DRM components are another
one. There is an endless supply really.
Today I noticed Barracuda is saying that if your appliance gets hacked
you should replace it immediately. It is now trash, or "e-waste" if you
prefer. This is a surprisingly honest thing to say. Previously appliance
companies who get hacked say things like "Meh? Upgrade pls! Don't forget to
change your passwords!" because as we all know, the firmware
boot partitions inside expensive security appliances are all protected by
angry leprechauns, which is why it's still ok in 2023 to have Perl
installed on them, even if you don't know what a ../.../ does in a tar
This honesty would be nice if it also applied to our government agencies -
like instead of this very long report CISA
put out about what to do if you think your Pulse Secure VPN was hacked,
which recommends performing a factory reset, updating your appliance to the
very latest version, and then calling your therapist to have a good cry
about it, they should have instead said: "Yes, your appliance did at one
point control authentication for everyone accessing your network, but
because it had issues with gzip files and opening URIs, it is now e-waste."
Crap, I forgot to write about the graph disassembler I want and why.
Tomorrow, for sure.
So one thing I have as a "lessons learned" from the past 20 years is that
security is not a proactive sport. In fact, we are all experts at running
to where the ball _was_as opposed to where it is _going_.
Like, if you listen to Risky Biz this week, Patrick asks Metlstorm whether
it's time to go out and replace all the old enterprise file sharing systems
have around, proactively. And the answer, from Metl, who's hacked into
every org in Oceania for the past 20 years, is "yeah, this is generating
huge return on investment for the ransomware crews so they're just going to
keep doing it, and being proactive might be a great idea." But what he
didn't say, but clearly had in his head was "but lol, nobody is going to
actually do that. So good luck out there chooms!"
At some level, STIX and TAXII and the whole CTI market are about passing
around information on what someone _might_ have used to hack something, at
some point in the _distant past_. It's a paleontology of hackers past - XML
schemas about huge ancient reptiles swimming in the tropical seas of
your networks, the taxonomies of extinct orders we now know only through a
delicate finger-like flipper bone or a clever piece of shellcode.