Recent content on seeinglogic blog
In the most recent LiveCTF event, we witnessed a turning point: a player brought a custom AI bot that beat both human competitors to the punch… and in the two matches that the bot won, it wasn’t even close.
“What happens if I need to fuzz something that doesn’t take strings or buffers as inputs” is the question I’ve come to dislike most when talking to people about fuzzing.
Hey, I’m Mark! 👋 I’m a developer, hacker, and software explainer. After writing, reading, and finding bugs in software professionally for over a decade, I enjoy improving how people think about and interact with code.
One of the biggest issues with LLM-generated code is a lack of trust, mostly stemming from a lack of understanding from not having written it personally, which leads to reduced confidence that the code handles edge cases properly.
If there’s one tool I like to use to shake some bugs loose fast, it’s fuzz testing. And luckily for Python users, getting started with fuzzing is pretty easy with Atheris.
I’m not sure why, but one of the most slept-on techniques I know of is “reversible debugging”, or time-travel debugging (TTD). The idea has been around for quite a while, but it seems the best free way to experiment with it is using the venerable windbg.
The trick of being a CTF challenge author is making a problem that is fun to solve while presenting the appropriate level of challenge… But the next level of challenge is making a challenge that is accessible and entertaining for spectators, which is what we try to do with LiveCTF by commentating challenges in a sportscast-style livestream format and showcasing different solutions.
Perhaps the question I get asked most about some of my visuals is “could you make this 3D?”, to which my response is usually “yes, but it would be worse for viewer understanding…”
Some intriguing 3D visuals have been coming across my radar recently, which have inspired me to try building a few myself! It started with just reproducing some cool visuals, but I was surprised how much could be done with just basic Python graphing libraries.
Whether you’re in a CTF or troubleshooting a bug for code you (or a coworker) wrote, understanding a bug quickly can make the difference… because let’s be real, nobody likes digging around in a debugger like we’re feeling around for sharp objects in a dark room.
As the CTF community has grown and the game has matured, we’ve seen an upward trend in both speed and sophistication of competitors and challenges, but one of the most interesting and pervasive questions remains: what do CTF champions do that sets them apart?
For security professionals, the name of the game is understanding someone else’s code… and quickly. Whether it’s on an internal team doing source audits, playing in a CTF, or hunting for bug bounties, we want to get to the key parts of the code and start finding bugs as quickly as possible.
When it comes to flame graphs, there seems to be two groups of people: those who think they’re awesome, and those who somewhat abashedly admit they don’t know how to use them.
As soon as I saw the announcement for a new Binary Golf Grand Prix challenge, I knew this was the time I’d finally commit to entering. Binary Golf Grand Prix 4 begins now!
Even months after ChatGPT and Copilot have had a chance to take hold in the development world, it seems there’s still a lot of frenzied excitement… But less discussion of how using LLMs to help write code actually affects developers.
Not long ago, I was auditing a codebase for work (looking for bugs) when I realized that despite the quality of the code, I was becoming mentally fatigued extremely quickly and had a hard time working on it for long stretches of time…
What makes code bad or hard to understand? Often, it’s poorly-managed complexity. For reasons we can’t quite explain, complexity is always worse in someone else’s code, and it never seems like a big deal when we write complex functions ourselves.
Coverage analysis lets you see what happened; automated coverage analysis is about turning runtime data into insights about the code you’re testing with less manual effort. Today we’re finishing our three-part series on code coverage by exploring this powerful approach that has applications in testing, development, reverse-engineering (RE), and fuzz testing.
Code coverage lets you see what happens when a program is executed, but what do you do if you aren’t compiling the program yourself? In the first post of this series, we talked about the basics of coverage and how to get it with a compiler, but if you value coverage in your workflows you’ll need ways to get coverage when you only have a binary.
If I could use one word to describe code coverage, it would be “underrated”. Code coverage is a powerful tool that can help in a number of workflows, and while it is an extra step to gather it, the information it yields can unlock important insights about code.
There’s definitely something about programming that engages people in a very real and profound way. I’ve felt it myself and seen it in others; I’ve watched it dawn as a smile of understanding across someone’s face.
Do you ever find yourself looking at code that you think should work, but it doesn’t? Sometimes I find myself wishing I could just see what was going on because it would make troubleshooting easier, and this led me to the idea of using visualizations to aid with debugging and overall understanding.
Software reverse engineering (RE) has been both a hobby and something I’ve done as part of my work over the years, so needless to say I’ve spent a lot of time trying to understand code that somebody else wrote…