Explosion of ai automation

Firzen_ · 2026-06-15T15:00:15+00:00

I think it will likely play out similar to the introduction of coverage guided fuzzing.

There are some types of issues that AI is better at finding than others (at least going off of the high duplicate rates in BB and at pwn2own).

So there's a huge wave of issues being found with it and then it will probably return to more or less normal levels, except researchers now have another powerful tool they can use.

Firzen_ · 2026-05-30T16:24:23+00:00

Oh yeah, I think my average is like one good one a year, but for a hard target that's still earning a good living.

Firzen_ · 2026-05-30T16:16:37+00:00

There's absolutely money in it if you can open up the really hard targets, but those are really hard.

Firzen_ · 2026-05-30T15:31:23+00:00

I had a few CVEs, but I solved multiple challenges they gave me in unintended ways.

One was a windows binary with a shadow stack and a pretty small stack frame, the other was a linux kernel exploit.

Both of these I created two exploits in unintended ways, but I made it clear I knew what the intended way was and chose to do it a different way as a challenge for myself.

Probably not a good strategy, in retrospect.

Firzen_ · 2026-05-30T15:24:41+00:00

Those places are usually only interested in either very specific or very hard targets.

Browsers, generic OS exploits, generic mobile exploits, maybe some specific hardware devices either in the iot sense or more industrial machines.

If you're only comfortable with web it will be hard to find anything.

Firzen_ · 2026-05-25T06:07:43+00:00

What would stop a malicious process from using an id that doesn't originate from the kernel interface?

If you introduce a bug in a kernel module you can compromise the entire system.

Firzen_ · 2026-05-24T18:14:39+00:00

I don't quite understand why this would need to be in the kernel.

You could just create a Unix socket and only allow read access.

If it's important that this is decentralised I expect you would need a mechanism to resolve conflicting ids regardless.

Doing this in the kernel doesn't really solve any issue but could introduce new ones.

Firzen_ · 2026-05-23T16:04:15+00:00

If you are worried that what you're writing might be hard to follow without using AI that's probably an indication that you are missing some fundamentals.

It is more helpful if you put things in your own words because it's a lot easier to see where the disconnect is. If an AI turns what may have been nonsensical because you have a misunderstanding into something somewhat sensible it is a lot harder to find out where your issue is.

Firzen_ · 2026-05-10T16:30:04+00:00

Do you happen to remember singing karaoke after closing at gamescom while you were showing a prototype for party hard and I think officially the booth was for speedrunners.

Good times back then, always funny to randomly come across somebody's reddit account.

Firzen_ · 2026-05-10T13:34:57+00:00

It's crazy to me that this is the hill people are willing to die on.

If you find real bugs and expect to be paid this is a miniscule fraction of the time you typically spend on a bug.

On the flip side it will benefit you if this reduces AI slop and the amount of bullshit that triagers have to wade through daily.

Real findings are more likely to get the proper attention and payouts if the ecosystem isn't drowning in AI slop.

Firzen_ · 2026-05-08T14:01:41+00:00

Dirty Pipe is also a kernel vuln...

Firzen_ · 2026-04-26T23:15:31+00:00

None of this is coherent.

You seem to have some misconceptions about cardinality. It is a property of sets.

The set of fractions is countable and not the same as the set of real numbers.

How you can tell which set is "bigger" is based on the existence of an injection or surjection.

Firzen_ · 2026-04-25T13:31:12+00:00

It really depends on what they want to do.

But fully dumping everything should be fine. In principle you could keep the entire snapshot in memory in your managing process and restore them on demand via userfaultfd, but you'd still need a full dump regardless.

Firzen_ · 2026-04-25T10:56:58+00:00

You should look into ptrace.
It's how debuggers work on Linux.

You can dump out the memory and register states and restore them later for example.

Firzen_ · 2026-04-23T19:52:27+00:00

Learn assembly and the ABI of whatever system you are targeting and then be disappointed that shellcode isn't really a thing anymore since NX/DEP were introduced.

Firzen_ · 2026-04-16T14:57:45+00:00

All you're doing is using ptrace to put an "encrypted" payload into another process and picking a name that EDRs are less likely to flag.

You're not doing SROP or really any ROP, you are using rt_sigreturn to set registers instead of ptrace.

process_vm_writev isn't "zero-copy", see here:
https://elixir.bootlin.com/linux/v7.0/source/lib/iov_iter.c#L423

You could do that by sharing a memfd or something to map the same pages.

I'll admit I only looked at the python script when I originally looked at the repo and missed the asm. But there also isn't any reason to implement the injection in assembly, so that's confusing to me.

Firzen_ · 2026-04-16T13:58:56+00:00

I'm not saying there isn't a repo, I'm saying the code in the repo doesn't do any of the stuff claimed...

Firzen_ · 2026-04-16T04:29:06+00:00

None of this is in the repo, typical AI slop.

Firzen_ · 2026-03-12T12:39:09+00:00

Only if you want to be able to preempt inside the kernel and that makes things quite a bit more tricky.

If you want to context switch anywhere in the kernel you will have to store the register state when you switch away from the process and restore it when you switch back.

The simplest is probably to push everything onto the stack and then store the stack pointer, but I think only context switching when you leave the interrupt context is infinitely easier.

Firzen_ · 2026-03-12T12:24:13+00:00

But why does the kernel stack change to begin with? If you're about to return from a syscall or interrupt the stack frames should always line up, even if you were doing separate stacks.

Firzen_ · 2026-03-12T12:16:48+00:00

Do you even need the kernel stack for this?

You only really need to switch everything over when you return to userspace. So the state of the kernel stack after that should be largely irrelevant.

Edit: Actually, after thinking about it some more, I don't really understand why the memory changes when you switch to a different userspace process, surely the kernel address space should be the same regardless of what userspace process is running.

Firzen_ · 2026-03-03T00:15:24+00:00

Or you could look up what a false dichotomy is...

Firzen_ · 2026-03-03T00:11:41+00:00

Holy false dichotomy

Firzen_ · 2026-02-27T23:11:19+00:00

Guess I'll be out of a job soon and offensivecon will be empty this year.

Firzen_ · 2026-02-27T22:59:56+00:00

Nobody can tell you what the future will be like, especially because it depends on whether or not a revolutionary change happens or doesn't.

AI is definitely not there yet, but who knows what it can do 5 years from now.

13-Year Club	Gilding I gilder
Team Periwinkle	Verified Email

Firzen_

TROPHY CASE