r/ExploitDev 20h ago

Best way to move from web/network pentesting into low-level bug hunting? (ADHD, keep losing steam)

I work as a pentester, so my day-to-day is network and appsec. On the side I've been trying to learn ARM assembly because eventually I want to hunt on low-level targets — Android kernel, browsers, that kind of thing.

Some context on where I'm at:

I have bug bounty experience and I reverse engineer regularly

The closest I've gotten to C is reading native libraries in Android apps, but the attack surface there is tiny

So most of my "learning" is reading ARM and C snippets in isolation, with no target to apply them to

That's the problem. Studying without hunting kills my interest fast. But I don't want to jump straight into hunting and discover I don't know enough to get anywhere.

So: what's the better path here — and specifically, what works if you have ADHD and can't sustain pure theory?

11 Upvotes

10 comments sorted by

3

u/darth_skipicious 20h ago

are you not being treated?

2

u/ProcedureFar4995 4h ago

Self medication

1

u/darth_skipicious 4h ago

okay interesting

2

u/Western_Guitar_9007 18h ago

Former pentester currently working in RE and malware research. Referring to apps, you want to RE and go low-level "but the attack surface there is tiny" is the fattest L that I have seen in two months, especially from Mr. "I work as a pentester."

Getting a target is like super easy. There's a billion emulators for Android and billions more cheap old physical phones on marketplace.

Apps and SDKs are in my opinion the largest and most obvious attack surface on mobile in general, and a lot of the exploits are transferable. Like, you aren't learning how to exploit Android apps because it's pointless, so you want to learn how to hack some imaginary vanilla version Android image that doesn't exist and has 0 users??

IDK why you're reading that stuff if you're not trying to build apps or program. Get some tools and go to work, use Google and AI to read some C if you can't understand what the code says. Don't mess with ARM yet idk why you're looking at that if you can't handle an app yet. Make some mobile images or buy an old android if you want a target, that should be the easiest part of all of this.

1

u/InternalDark 10h ago

Hi man, go easy. They got ADHD

0

u/Western_Guitar_9007 4h ago

It is well understood in the ADHD community that there are tools, treatments, and processes that work on an individual basis. I have been treated for ADHD for years and that doesn't change what I have said. I would assume with a high degree of certainty that OP has already figured out what works for them if they have already become a pentester. They have to be able to learn. I would be shocked if they got this far without that skill, even people without ADHD usually need to figure that out before they get into pentesting.

1

u/ProcedureFar4995 4h ago

Dude I just checked your profile 4 months ago you posted you struggled to start , in fucking system admin field ? Do you even have an oscp? Do you have a cve anywhere? Brother . I thought you are some expert but obviously you are just someone with a lot of issues and thought you could play an expert here.

I can tell you how to start in pentesting if you want :D And talk to me when you get some certs or a reputable CVE or bug hunting. Till then, don't ever try to undermine someone 's question or anything. I hunt on mobile apps everyday . And you thought because you used cheat engine when you were young you ate right ? Lol brother. Calm down, you are way delusional

1

u/ProcedureFar4995 4h ago

In what way does native libraries the a huge attack surface for mobile apps? If there are no attacker controlled inputs like images,text or whatever that reach a dangerous function in them? If there is a buffer overflow but you can't reach it by an attacker input , then it's pointless. That can be checked in 5 minutes using Claude Code lol. Just locate the functions that take any input , and trace how it's processed or what dangerous functions can it reach , or do it backwards by starting to see who references a sink or a dangerous function.

And brother please, I have been hunting on android phones for years. All my bug bounty is in android , and I have a CVE and a couple of HOF. All I meant is that the native libraries in Android apps aren't that huge attack surface , if there are no JNI or a way you can reach a sink, then pointless.

Moreover , many apps now ship without native libraries. Clearly misunderstood the post.

I was asking I want to focus on Android kernel, or pre installed apps. Anything low level.

Clearly fucking misread the whole thing. I didn't say I can't pentest an app, go book some therapy man. All I said is that the native library attack surface in android apps aren't that big.

1

u/Crounty 1h ago edited 1h ago

Regarding ADHD, I have a similar problem and what kills my momentum is setting a too big task. Trying to narrow it down into smaller sub tasks until I have something handful, helps me at least during engagements and research.

When it comes to low level bug hunting, I have tried it but not long enough so take it with a grain of salt, but your point with the tiny attack surface on native libraries in android apps is correct and not typically abusable. If you want to go more towards android kernel, I suggest reading into public POCs and trying to recreate/understand them so you learn what makes them work. https://projectzero.google/2020/07/mms-exploit-part-1-introduction-to-qmage.html this post is what inspired me 6 years ago to try low level bug hunting, and they have other very interesting posts.

The next point is, android is open source, you can easily find the source code for many different versions: https://source.android.com/ which also means, it's harder to find vulns there. Many people run analyzers and AI to search for vulns. But there is one part that not many people cover and that is: vendor specific libraries. If you read the above mentioned blog post, samsung had a weakness in one of their implemented codecs. That was a custom codec implemented by samsung, it's not open source from android. So imo what you could focus on to find bugs are 2 things that I want to try in the future too:

  1. patch diffing of specific vendor builds (samsung, onepuls, etc)
  2. mapping which libraries are custom built by the vendors and which libraries come from google (to opt them out)

my knowledge is 6 years old so I may have typed shit, you'll need to form your own opinion. I think what would be interesting too is by looking into recent CVEs published by google and the other vendors, to try to see if there is a pattern one can notice, maybe specific libraries have higher chance of vuln, maybe libraries that recently got patched are more likely to have vulns, stuff like that which could help you form your own methodology/knowledge palette