gynvael.coldwind//vx.log (en)

Paged Out! prints are here, and so is #7 CFP deadline

2025年6月18日 00:13:25 +0000

Paged Out! was always intended as a PDF+print zine, but the "print" part turned out to be pretty elusive. We actually did an initial test print of 500 copies in 2019 for a conference I've co-organized (Security PWNing), but that's it. Until last month that is, when we pretty much got back on track with prints — both free prints for events, and — additionally — print on demand if someone wants to buy a copy. We actually also updated the website with a lot of print-related information.

So let's cut to the chase — how to get printed Paged Out!?

You can buy it in the first print-on-demand online bookstore we onboarded: lulu.com/spotlight/pagedout
Note: there's a normal edition, and there are spon sor ship editions — there's no difference between them apart from the price and the back cover; get a sponsorship one if you want to show additional love for the zine :)
You can collect one for free at one of these events: pagedout.institute/?page=event-prints.php
Note: Revisit this list from time to time — it keeps growing.
And finally, you can print it yourself: pagedout.institute/?page=personal-prints.php

At the same time if you or your company would like to sponsor some Paged Out! prints for a specific event or in general, please let us know (prints AT pagedout DOT institute).

So far only issue #6 is available, but we're working on getting all of them out there, including older ones. We're basically going one by one, first #5, then #4, and so on.

Speaking of issues — Call For Articles for issue #7 now has a soft deadline: 30 June 2025

As usual, we're accepting technical 1-page articles about everything interesting related to computers, electronics, radio, and so on. See pagedout.institute/?page=cfp.php for details.

Note: We're having problems getting articles about retro computers, speedrunning, and movement techniques in games (e.g. Apex Legends), so if you can write about that, please do; and if you know someone who could write something about this, please ping them. Of course all the usual topics are welcomed too, as always.

CONFidence 2025 is next week

2025年5月28日 00:13:24 +0000

It's the 20-year anniversary of the CONFidence conference! And it's happening next week (2-3 June) in Kraków, so don't miss out.

Furthermore, we've shipped 500 Paged Out! #6 issues there, so – if you're fast enough – you can grab one for free there :)

Enjoy CONFidence!

P.S. If you don't have a ticket my code might still work: GYN10
P.P.S. Huh, time flies, doesn't it. I think the first CONFidence I attended was in 2008. It's great to see this conference is still going strong and amazing to be a part of its program committee.

No, CTRL+D in Linux terminal doesn't send EOF signal

2025年3月13日 00:13:21 +0000

Initially I was supposed to write another article on something completely different, but then I randomly found myself digging into what CTRL+D actually does on Linux. And it turned out it does something different than I thought, so I decided to share my surprise in the form of an article posted at hackArcana. Here's the first section:

Linux Terminal: CTRL+D is like pressing ENTER

What I always thought—and I'm pretty sure I'm not alone in this—was that pressing CTRL+D in the terminal closes the standard input for the running process. Alternatively, I've heard that CTRL+D sends an "EOF signal" to the application. But if you actually think about it, it just doesn't make sense. After all, in Bash you can press CTRL+D if the line isn't empty, and nothing happens! Perhaps that's a terminal setting then which Bash changes? Or maybe something more, or—as is in this case—something less is going on. Let's investigate!

Somebody's wrong on the Internet

Apart from the correct answer—to which we'll get shortly—there are two lead answers on "what does CTRL+D in a terminal do" that can be found on the Internet. Both wrong.

It sends an EOF (End-of-File) signal/marker/character to the running program.
It closes the standard input of the running program.

The first answer is somewhat correct (we'll get to that later), but not in the way you think.

Continue at hackArcana...

New edu platform and 'Sanitization and Validation and Escaping, Oh My!' article

2025年3月07日 00:13:20 +0000

With the beta launch of my company's educational platform (hackArcana), I finally have a place to write more about the fundamentals of security and post more educational content. The first piece I've written for our new platform touches on the confusion around the terms "validation," "sanitization," "encoding," "escaping," and "filtering". Most readers will of course be familiar with these, but because they are casually used interchangeably, they might not know the actual difference between them. Here's the first section of the article:

During various discussions, I've noticed there is some confusion about what exactly sanitization, validation, escaping, as well as—to add to the list—encoding, and filtering, are. And how do they differ from each other? Furthermore, which should be applied where? If you're confused about these concepts, or just want to polish up your knowledge, you came to the right place.

Note: This is something that can come up during a job interview. It's also bound to come up in the real world when dealing with application architecture and security—e.g. In selecting a proper solution or to fix for your app, or to advise a programmer on one.

The Big Picture

Regardless of which method we're talking about, the end goal is always to be able to process the received input data in a safe way. Note that "process" might mean a whole range of different things here, from storing the data in the database, displaying it in a terminal or on a website, to e.g. feeding it to a deserialization engine.

What's also really common, is that the input data can be processed in an application in more than one way, where each method of processing might have different requirements with respect to the data it receives. This already signals that there's more to the topic than just selecting one method and calling it a day.

Given the above, the actual situation inside the application looks more like this (this is still a simplified picture):

Continue at hackArcana...

On hackers, hackers, and hilarious misunderstandings

2025年1月30日 00:13:19 +0000

"Hacker", as we in the bizz know well, carries different meanings for different people, and this can cause hilarious misunderstandings. Yesterday, the Polish TV network TVN aired the second part of an ongoing documentary about issues in NEWAG trains that were analyzed by Dragon Sector. Near the end, the documentary featured a recording from the November 2024 meeting of the Parliamentary Infrastructure Committee, which was meant to discuss the matter. During the meeting, one of the Members of Parliament took issue with the Dragon Sector team being referred to as "hackers"—the quote above is from him (translated from Polish).

This, of course, is nothing new—just another example of someone knowing the colloquial meaning of the word but not its specialized one. This disconnect has existed for at least the past 40 years.

This raises an interesting question—should we use the word "hacker" in formal settings (court, parliamentary committees, etc.), or would we be better understood if we opted for "cybersecurity specialist" or a similar term, as we often do on LinkedIn and other professional platforms?

Or perhaps we should continue using the word "hacker," as it serves as a great litmus test for whether the person we're discussing these topics with is truly familiar with the computer security industry and its terminology. It’s an unexpected but useful canary—or perhaps a reminder—that not everyone speaks "computer."

Returning to the original quote, and on a rather amusing note—or perhaps to balance things out—multiple departments of the Polish government are actively seeking to hire individuals with the "Certified Ethical Hacker" certification. In some cases, you can even get grants to earn it! Additionally, one can find information on government websites about how Dragon Sector was invited to the National Security Bureau to receive a commemorative letter of congratulations and symbolic gifts after winning the 2014 CTF season.

So, do we continue advocating for our specialized meaning of the word "hacker" in official settings? Or should we revert to something more neutral instead?

Just food for thought :)

Paged Out! #5 is out

2024年11月19日 00:13:17 +0000

Issue #5 of Paged Out! is out! Here are the most important links:

Paged Out! #5 PDF (23MB, release build)
Official #5 Wallpaper (10MB, JPG, 8K); there's a PNG on the website as well
Paged Out! Website
Paged Out! blogpost about #5
and most importantly Call for Pages for Issue #6.

We have some amazing articles and art (finally!) for you in this issue – there are 68 pages altogether (including 2 by yours truly). Here's a high-level list of topics (in alphabetic order):

Art,
Algorithms,
Artificial Intelligence,
Cryptography,
File Formats,
GameDev,
Hardware,
History,
Networks,
OS Internals,
Operating Systems,
Programming,
Retro,
Reverse Engineering,
and Security/Hacking.

Anyway, if you'd like to be informed about Issue #6 once it comes out, here are some ways to achieve that:

You can use an RSS/Atom reader.
You can join this e-mail group (Google Groups).
Or you check us out on social media – we have it all! You can join our Discord server, follow us on X/Twitter, Bluesky, or Mastodon.

Enjoy!
gynvael

CVEs of SSH talk this Thursday

2024年11月18日 00:13:16 +0000

It took us a while, but we're finally doing the first open webinar in English ("we" being my company – HexArcana). It's going to be "CVEs of SSH" presented by Dan Murray!

Dan basically spent the last few months digging into the SSH ecosystem, and has quite a lot of interesting stories to tell. During this talk he'll focus on a couple of high profile CVEs assigned to various SSH client/servers. You can expect technical insight, historical context and humorous anecdotes along the way as we demystify headline-grabbing issues.

The talk is free to attend, but you have to register at https://hexarcana.ch/workshops/cves-of-ssh. Once registered, you'll receive the link to the talk on Wednesday or Tuesday.

Details:

Speaker: Dan Murray
Date: 2024年11月21日 8:00 PM GMT+1
Duration: ~1.5h
Price: Free (registration required)
Other: Recording will be available for a limited time (30 days).

In a few days we'll also announce a 1-day course on SSH led by Dan – that's for you folks who like to dig a bit deeper into the tools you use. Stay tuned!

And see you on Thursday hopefully ;>

Debug Log: Internet doesn't work (it was the PSU)

2024年8月31日 00:13:13 +0000

I woke up in the morning, got to the desk in my home office, checked my email, discord, and the news. Then I switched from my desktop to my laptop and... there's no internet.

That's weird. I just browsed the net on my PC, so what's up with the laptop? Both are connected to the same network, so it's not the problem of the network not having connectivity. As such, the problem lies between my ISP's modem and the laptop (inclusive).

I started with disconnecting and reconnecting the ethernet network cable (it's a pretty stationary laptop, so I keep it wired). That didn't fix anything, apart from displaying a short spinning animation indicating it's trying to get an IP address assigned (a DHCP issue then?). Just to be sure it's nothing on the laptop side I did a reboot, and then power-cycled the nearest network switch for good measure as well. No luck.

Following up on the DHCP lead I logged into my home server, which runs the DHCP daemon... wait... what is this?

ssh: connect to host home server port 22: No route to host

So I moved the chair a bit to check my server rack, and found the home server dark. That's unusual. On closer inspection actually the LEDs on the motherboard next to the power/reboot buttons were lit. A minor explanation here: I use customized Open Benchtable mounts, so the mobo is easily accessible; at the same time it means there are no power/reboot buttons on the case – as there is no case – so I rely on mobos having power/reboot buttons directly on them (or, failing that, small buttons-on-PCBs that you hook into the normal case button connector on the mobo).

I clicked the power button, and... even the two last LEDs went dark. Not great. They did light back up a few seconds later though, so re-tried a couple of times, with the same result. The closest I got to a "fully functional and running server" was the CPU fan spinning up for 0.5 seconds.

At this point I had good news and bad news:

Good news: I found the problem! DHCP server is down because...
Bad news: ...the server is dead.

The next step was to turn on some DHCP server in the network so that the Internet actually works in the household, and to let everyone using the server know that there are problems.

Of course it's rarely that the whole computer dies – usually it's just one component. As such, the next step was to figure out which component(s) are defective.

The usual algorithm for this is:

Disconnect power and let it chill for 10-20 seconds (i.e. wait for all/most capacitors to discharge).
Disconnect all unnecessary peripherals like: all storage devices (HDDs, SSDs), all PCIe cards, all USB devices, etc. Hint: make a couple of photos of what is connected where – even if you keep detailed documentation on the setup (you do, right?), it can save some time.
Remove all RAM modules apart from one. You basically want to be left only with mobo, CPU, PSU, and one RAM stick (and PC case connectors – these are usually fine).
Connect power, attempt to turn on the computer.
If nothing boots at this moment, go to point 1 and try a different RAM module or try putting it in a different RAM slot. Repeat this until you run out of options.
If you get the computer to boot in this "minimized" state...
Power everything down (see point 1).
Add one random device or RAM module from the batch you've disconnected earlier (usually starting with the GPU makes most sense, as that way you get a display later on).
Connect power, attempt to turn on the computer.
If things boot, go to point 7 (IMPORTANT: don't do after-POST hard power offs from the moment you connect any storage device).
If things don't boot, you found the culprit (though it might be either the slot/connector, cable, or actual device; pretty easy to figure out at this point though using a similar approach to the one described below).

In my case I basically run out of options at point 5, which translates to: it's what's left, i.e. the problem lies either in the CPU, the motherboard, the PSU, or ?all the RAM dice? (unlikely, but at the end of the day anything can break). And to figure out which one is it, you have to start taking each of these components and testing them on a different setup AND/OR replacing the component in the debugged setup with a working one (worst case scenario is if doing this causes the good component(s) to also break). This requires one to have at least another (ideally similar) computer – thankfully I have some old hardware lying around.

I've started with hooking up a different PSU, since that's obviously the easiest to swap out, but also the most probable issue. And the "minimized" server actually started normally, with no issues whatsoever! So at that point I was pretty sure it's the PSU, but to double check things I've added all the PCIe peripherals, and... it booted again with no issue. Cool.

Unfortunately it turned out I don't have a PSU I could use as a replacement. While I have some modular PSUs lying around, they either were from a different manufacturer (which would require me to order new modular power cables to hook up all the HDDs), or were from the same company but didn't have all the connectors I needed (to be more exact: the PSU I had was missing one custom "SATA/Molex" PSU connector). So I had to order a new PSU from the same company.

Thankfully I did this debugging in the early morning, so the replacement PSU arrived by post by early evening. After connecting it all back together the home server booted without an issue. So problem solved. All that was left was to disable the temporary DHCP and... write a blog post about it I guess?

While things breaking can be frustrating at times, I do have to say I did enjoy this bit of relatively simple technical work – it was a nice distraction from the paperwork that awaited me for the rest of that day ;)

FAQ: The tragedy of low-level exploitation

2024年8月03日 00:13:11 +0000

Obligatory FAQ note: Sometimes I get asked questions, e.g. on my Discord/IRC, via e-mail, or during my livestreams. And sometimes I get asked the same question repeatedly. To save myself some time and be able to give the same answer instead of conflicting ones, I decided to write up selected answers in separate blog posts. Please remember that these answers aren't necessarily authoritative - they are limited by my experience, my knowledge, and my opinions on things. Do look in the comment section as well - a lot of smart people read my blog and might have a different, and likely better, answer to the same question. If you disagree or just have something to add - by all means, please do comment.

Q: I love low-level exploitation and exploit development! How can I make this my whole career?
A: So to not bury the lead, the problem is that low-level exploitation is rarely needed in cybersecurity, and jobs where one works mostly on low-level exploitation are few and far between. Furthermore, these jobs are even more rare if one wants to stay away from the gray area of hacking and away from the black market. It's more common for low-level exploitation to be a small occasional part of another role.

DISCLAIMER: The goal of this post is not to discourage anyone from pursuing a career in low-level hacking, nor do I think that it isn't an important area of cybersecurity. Rather than that, the goal is to give folks enough information to think things through and plan their approach instead of walking into this blindly.

Let's start with a bit of background...

Background

While the start of the path of learning hacking / cybersecurity changes from time to time, sooner or later it leads folks to try low-level security. This commonly starts with a bit of reverse code engineering – the one on binary / assembly level – paired up with getting to know how to use a debugger and learning the CPU architecture, and leads down the path to learning low-level vulnerability classes and eventually their successful exploitation. While a simple 1988-style stack-based buffer overflow is easy to learn, things get more and more complex as one progresses closer and closer to the newest developments. This is due to the neverending arms race between defensive and offensive sides, that results in new mitigations, as well as the inevitable new methods to bypass them or shifts in approaches.

As such, low-level exploitation is currently one of the most technically complex and challenging areas of cybersecurity. And given the pleasure one feels after successfully making a code execution exploit in a complicated and constrained scenario, it's also immensely gratifying and fulfilling.

Understandably a question like "how do I make this my job" is an obvious one.

Jobs in low-level exploitation

Let's start by stating something obvious, which I still believe must be stated (even though we don't like to hear it): companies prefer to pay for things which they believe are useful and/or beneficial for the company. Pursuing further this point, we can ask the question: how can low-level exploitation, exploit development, and low-level exploits be useful for a company? Let's go through these one by one.

Hacking into things

Starting with the obvious – fully "weaponized" exploits used for their natural purpose, i.e. to hack into things.

So who actually "hacks into things"? We have a couple of groups (in order from less to more... ethically complex if you will):

pentesters,
internal security teams (e.g. red teams, but also application security teams),
law enforcement,
military,
intelligence and espionage agencies,
and cybercriminals (and I'll skip this, since this isn't a legit career in the sense I'm using).

Let's consider pentesters first. And we have to be honest here: in the great majority of pentests folks use off-the-shelf exploits, ideally integrated into metasploit or readily available on exploit-db.com. There is just no time during a pentest to spend on making highly complex low-level exploits that operate in modern heavily-mitigated environments, which also commonly are in the prolonged "exploit superposition" state of "it may or may not work - we'll see" – especially that these can take even a week or more to make and require a lot of skill and obscure knowledge. Unless this truly was the goal of the pentest (not likely), no reasonable pentesting client would like to pay for this, given that the alternative cost is NOT spending this time on reviewing other parts of infrastructure, and also that the risk of a random attacker actually making this kind of exploit and using it to hack the company is minimal (we all know that realistically they will just phish a C-level exec).

"But wait!" you might say, "who is actually making these metasploit / exploit-db off-the-shelf exploits then?" And while what's a good question, I think a better one is "when are folks making these exploits". The common answer is: in their spare time, i.e. not at work. Also, it's pretty common for these integrated exploits to actually be the result of the original vulnerability researcher's Proof-of-Concept-exploit being adapted, integrated, or otherwise "weaponized". Admittedly this kind of adaptation is something that might be done during a pentest, as it's faster than developing everything from scratch – but also it takes out the most fun part of the process. For completeness let's add that at times the source of the initial exploit could be different – e.g. an attack observed (captured) in the wild or a leaked batch of tools from a three-letter agency.

The bottom line for a job in pentesting therefore is, that you don't really get to do much end-to-end low-level exploitation there. You might get to use a low-level exploit someone else made, and from time to time you might need to adapt some exploit or modify it a bit to actually work, but that's the extent of it.

Moving onward to internal security teams. In the case of red teams it's pretty much the same story, with the major difference being that there might be more internal custom systems written a decade or three ago in C or C++ viewed as a viable exercise vector. But there of course wouldn't be any specific long-term focus on these kinds of systems, as only some exercises would touch these. Furthermore, sooner or later the conclusion reached will be something along the lines of "oh, we know it's a weak spot; the blue team has it on their todo list, so let's ignore it for now and focus on other things." So again, rare occasional opportunities for low-level exploitation.

Beyond red-teaming or other-similar-color-teaming exercises there is rarely any need for exploits. For example, from an infrastructure or application security team's perspective, it's key for finding weak spots and vulnerabilities. This of course includes low-level vulnerabilities (a ha!). However... no exploit is usually needed, PoC or otherwise – this is because the end goal isn't to hack this or that, but rather to secure this or that. So in an ideal world, a discovered vulnerability (or even a potential vulnerability) is filed as a security bug with the appropriate dev team, which then fixes it regardless of whether someone actually proved exploitability. There is just no need for a highly skilled person to spend a week on proving exploitation if a fix is a one-liner, done, tested, and deployed in an hour of active work.

This of course points to the two cases, where making an exploit might actually come into play. The first case is when the dev team flat out denies a fix because they don't believe it's a problem, don't think it's an important enough problem, or have more important things to do. This of course is a clear signal of deeper organization problems both in communications and/or intra-team cooperation (yes, soft skills are important in tech, and even more so in IT security). Regardless, at times the decision might just be to prove the problem exists by proving exploitation (yes! we get to work on an exploit!), and therefore showcasing what potentially could happen if the problem is not addressed. I think it's fair to say that most people who are a decade or two in this area of security have or know of a story like this. These however are pretty rare occurrences and rarely more than one demonstration is ever needed.

The second case is when the root cause of a vulnerability is buried deep deep into the whole architecture and changing the offending design would be both costly and time consuming. A great example of this are e.g. Spectre/Meltdown vulnerabilities in the x86 CPUs, or the Row hammer DRAM problem. In such a case actually having a few people spend a few weeks on figuring out if exploitation is possible and how to do it is actually the cheaper option, than jumping straight from the get go to changing everything. These situations however are rare and limited to companies which actually work a lot with low-level products – maybe Microsoft, Intel, AMD, and a few others. And at times specialized vulnerability researchers are contracted to work on these instead – but we'll get to vulnerability research a bit later.

So again – yes, there is some low-level exploitation here, but it's rare and there's hardly enough of it to make a full time long term low-level exploitation career of it.

Next on the list is law enforcement. And the short answer is that no, nobody makes exploits here (UPDATE: though I'm told there are minor exceptions within at least US' FBI / Canada's RCMP; see e.g. this wiki entry; kudos Erik Cabetas!). Law enforcement does buy certain solutions, which under the hood use exploits, e.g. to hack into a suspect's smartphone, but that's it.

Situation in the military is a mix of the pentesting and law enforcement approach, with the added twist that if your country is in an active conflict, you're treated as a combatant with all the dangers that come with that.

And then we get to intelligence and espionage agencies and their suppliers – and this is where a lot of actual low-level exploitation and end-to-end exploit development happens. And at the same time this is pretty much a legal gray area – what's legal or otherwise sanctioned by the employing country, is hardly welcomed by the the target countries – so from the get go one has to make some moral and ethical decisions, and know they won't be allowed to talk too much about their work, like ever (i.e. until it's leaked).

So to summarize this section, the groups that use exploits fall into two categories: the "basically not making exploit" and the "your country's three letter agency" one.

Making, but not using

As already signaled above, making and using exploits isn't necessarily tied up, as both areas are pretty specialized and require certain unique skills and knowledge. So when is ever working on low-level exploits useful for a company enough to make it a job role? Here's a new list for us to go through:

vulnerability research,
cybersecurity marketing,
bug bounties.

Vulnerability research is a bit of a loose term, since it's understood as – depending on the context – looking for vulnerabilities, looking for new ways to look for vulnerabilities, looking for new types of vulnerabilities, looking for new ways to bypass protections, mitigations, and so on, and either exploiting or looking for new ways to exploit vulnerabilities. While admittedly there is some vulnerability research in e.g. pentesting or red teaming, this is often thought as a separate area one can specialize in. And for this or that reason when someone says "vulnerability research" they usually do mean "low-level".

Sounds great, right? "There must be a lot of low-level exploitation there! So, where can I get employed as a vulnerability researcher?"

Good news is that there are legit security research companies that employ vulnerability researchers that do not focus on selling 0-days (we'll get to these in a moment)! Such security research companies get contracted or called in when e.g. an OS developer or a a CPU manufacturer wants to verify the design or implementation of a new security feature, or to assess how hard is to exploit a bug vulnerable before committing to redesign a large piece of a system to address it (in case an internal team doesn't handle that as mentioned before). Furthermore there are other companies which might have an external-facing vulnerability research team for other reasons – probably the best known example being Google Project Zero which mission is to "make the discovery and exploitation of security vulnerabilities more difficult, and to significantly improve the safety and security of the Internet for everyone" (source).

Bad news is that these are really rare, rarely have openings, and have a very high bar to get hired into them.

Since the example above talks about "external-facing" research teams, there must also exist internal-facing vulnerability research teams, right? Correct, though these are more restricted in terms of targets one can choose. E.g. in a web-first company there might not be any low-level internal targets to choose from or they might be rare and quickly swiped by other interested folks.

It must also be added that in some companies there might be roles where vulnerability research is a small part of a larger role. For example, if a company implements specialized compilers or works on an operating system, there should be someone on the team to work on mitigations – both as in development and as in testing. And what's a better way to test a mitigation than to attempt to write an exploit which bypasses it?

Vulnerability research might also be a perk attached to another security role. For example, cybersecurity companies which offer various security services or security products might welcome some time spent on finding vulnerabilities and writing PoC exploits. Successful research gives the company a chance to get its name out there, demonstrate technical prowess, and do some good at the same time – this is why cybersecurity marketing is on the list above. Admittedly a consequence of this is the controversial topic of named vulnerabilities with logos, but let's not get into that discussion here.

And then again we get into the gray area of three-letter agencies, or rather their suppliers/contractors. Probably the biggest job market for low-level exploitation lies in the 0-day industry and exploit "factories" that sell their work to... only sanctioned allied governments and entities, of course. What must be said, is that there is little transparency and little control for an exploit author over what said exploit is later used for and by whom. This of course leads to some complex questions from both the legal and ethical side. And there can be times where one later would learn that their work has been used by a drug cartel or this or that government to hunt down some journalists (if this sounds grim, that's the intention – these are tough questions one should be aware of, esp. if the person is considering this kind of role).

Same considerations apply to indirect suppliers, e.g. folks working on 0-days as freelancers and selling them to brokers or the highest bidder on a black market – there's the same amount of transparency and control of how an exploit is used in this case, that is to say: none at all. And it's also something one will think ten times about putting in their resume, as it might attract legal trouble.

Last on my list are bug bounties and I've included them since there are some folks who actually made it their whole career. It has to be noted, that the great majority of bug bounties are pretty high on the abstraction stack (i.e. web), but at the same time low-level vulnerabilities with exploits have at times pretty high rewards (e.g. for some time Google offered 133ドルk for whole Linux kernel exploits under certain additional conditions). At the same time there are some issues with bug bounties as well, mostly related to randomness of chaotic systems (i.e. our world). First of all, one has to actually find a vulnerability, which is actually exploitable – and there might be weeks or months in-between good findings. But also one has to submit it as the first person – receiving a "duplicate / reported before" response after three weeks of work can be heartbreaking. So while this is an option, it's not smooth sailing by any means.

(UPDATE: I totally missed academia in my considerations! Please see Aurélien Francillon's comment below this post.)

Summary

The whole cybersecurity job market is huge and it seems to be still growing. However, low-level exploitation is a very very small niche in the whole industry. It's cool and awesome, but sadly rarely required. While jobs focusing fully on low-level exploitation do exist, there are very few of them, and even fewer if one doesn't want to answer any hard ethical questions. Furthermore, due to the scarcity of jobs in this segment, the hiring bar is pretty high. It's a bit easier to find a job where low-level exploitation is a small part of the role – there one gets to work on low-level stuff from time to time, even if not as often as one would like. And then we have the whole bug bounty thing, which is where high skill requirements meet the lottery.

Furthermore, the reason there are so many exploits readily available is mostly hobbyists working on this in their spare time. And it's a similar story with a good chunk of vulnerability, or more generally – security, research, which is done after work pro bono by hackers and open-source enthusiasts. This work is important for both the defensive community and pentesters, but hardly a directly paying job (there are resume-level benefits of course).

So should you pursue your dream of being a full time low-level vulnerability researcher and exploit dev? And how should you approach this? Well, these are the questions for you to answer yourself, but I do hope you're a bit more equipped with knowledge to make that choice.

--
Gynvael Coldwind

Solving Hx8 Teaser 2 highlight videos!

2024年7月21日 00:13:09 +0000

Last week I livestreamed solving Hx8 Teaser 2 challenge from the Google CTF 2024 Qualification Round's. As I know not everyone has time to watch a 3h livestream, here are highlight videos (3 parts):

Part 1: https://www.youtube.com/watch?v=6KGsshjzkEc
Part 2: https://www.youtube.com/watch?v=S6PmBvvJwUk
Part 3: https://www.youtube.com/watch?v=Hze_heJkQYQ

Enjoy!
gynvael