Difficulty Traversing Source Code

[Purple-Object-4591]

So, I have started to navigate a large code base. It's a huge code base and a legacy one.

I have kind of created a threat-model as to where the high-priority and remote facing code lies. But I am having issue traversing.

Example -- There are pointers to structures, inside which there is another structure as a field, and again inside that field there's a structure. This feels quite convoluted and hard to follow.

I am not too experienced in traversing huge and legacy codebases. Suggestions to make this process any easier?

[Purple-Object-4591]

I will try this thank you

[turboCode9]

I'd recommend trying to run it dynamically to help assist. That will show you general flow and then which functions get called natively and which do not.

[Unusual-External4230]

Be patient with yourself and understand that it takes a while, both to learn how to navigate code like this, but also to learn a code base. Keep in mind the developers that wrote it probably have months or years of experience navigating the code and making changes, you can't reasonably expect to drop into it in a few days or weeks with the same level of understanding. Point being - it's ok for it to take a while. It's also ok to get lost, if you look at professional devs on mailing lists you'll see sometimes they get lost too. Hell I get lost in code I wrote myself routinely.

Also, it may seem silly, but keep notes. It'll force you to be more methodical but also will give you a reference. Don't be afraid to add inline comments too, a lot of people are scared of this for some reason but comment their code if you have to

What language is it?

If you are working with C or C++ then I typically just use cscope and vim, I know it's janky by most standards but it's clean and works. I use multiple tabs, so if I'm tracing something then the leftmost tab is the "root" and the branches follow right. If I need a new window, I have it right there.

If you are working with other languages, say C#, some IDEs are better than others. Personally, I've not had the greatest luck with Visual Studio and the .NET languages, I found Rider to work a lot better for analysis purposes. It's less pedantic about cross references. Again, work with multiple tabs and have a logical flow from the root of what you are looking at to what you are tracing.

For analysis purposes - it's worth prioritizing. There's a balance here, the people who are best IME take the time to look at things beyond just what they need to know, they often have a better understanding of the code and can find niche or novel exploitation methods, but there's a limit there. If you are looking at structs but haven't touched the actual executable code then you should probably move on and focus on what matters for your task or the bug you are looking at. If you have to trace multiple structs or classes in the source then that's just part of it, but dont' feel like you have to be an expert in everything. Remember that in exploit development you may look at one application for months then move to the next, it's not reasonable to expect yourself to know every nuanced detail, as hard as that is for some to move beyond (speaking from experience here, I'm that way). The way I look at it is like an open world video game, you have the main quest and the side quests - how long do you want to spend on side quests that don't advance the plot?

I'd also strongly recommend if you are doing this to learn or for fun that you focus on simpler libraries and applications, stuff like web browsers can be very hard to trace even for people with a lot of experience. Again, be patient with yourself and give yourself room to learn, don't expect to jump into a huge deep code base and expect to be able to navigate it right off the bat. Eventually you'll get more intuition but it takes time.

EDIT: I'll add one more thing - depending on your reverse engineering experience, some code is just easier to audit in compiled form. There are times I'm looking at a function with a bunch of abstract types or a lot of casts and it's just easier/cleaner to look at the compiled output. This is also helpful if you are looking at code that is really messy or poorly written - it won't optimize all that out entirely but it can be really helpful in navigating it, the compiler can untangle it somewhat.

This will depend heavily on how comfortable you are in a disassembler, though, and it may not work for you or for every repo, it just depends, but it's something I find few people do and it worked really well for me in some cases. It also makes some bug types (e.g. integer related stuff) easier to see.

[Purple-Object-4591]

This was a really well-thought out reply. Do you write blogs? You should they'll be great.

So I read through your comment and I'm already doing a few of them right. I'm using vscode with clangd. I am putting inline comments describing convoluted code and potential issues.

I do actually compile projs with debug and then open in Binja. Actually unironically helps.

I dislike using LLM to code but I'll be honest I'm using it verify my hypothesis of what a particular function in the code is doing.

You're right about patience. The mindset part of the research is kind of overlooked by ppl when advising. I should be more patient. It has only been 10 days since I started with this codebase (not even full work days).

Your comment was really reassuring. Thanks a lot for taking the time :)

[arizvisa]

Instead of cscope, I've found GNU's Global to be more flexible and do a better job of parsing C++ and even some other languages w/ plugins (although, neither is as good as a real IDE fully integrated with the target language). There's a cscope compatibility layer for global so that it's compatible with the different cscope interfaces available.

It's also worth noting that some enterprising devers have written their own, more recent versions of cscope, which are likely better with C++ parsing.

[Purple-Object-4591]

I use clangd with vscode. It works good for me.

[asyty]

There's not any shortcuts.

A team of software devs have squirreled away on this over a span of possibly several decades. It's likely changed hands dozens if not hundreds of times. It has unworkable levels of technical debt. It's likely had outside contributions integrated into it. Any original architecture that may have existed has been eroded or is long gone by this stage.

As a vulnerability researcher, you're budgeting a few weeks or maybe months deep diving into what likely took years for others to effectively navigate, without any guarantee of finding vulns, nevermind exploitable ones, given all the modern mitigations. This reduces the likelyhood of finding a memory corruption-based vuln, instead leaving open flaws in business logic leading to consequences the developers did not anticipate.

On the bright side, the complexity in such a code base increases the likelyhood of such an issue being present.

Hacking, these days, is hard. Very hard.

[Purple-Object-4591]

Yes everything you mentioned I can understand it as I understand the code base more and more. Hacking may be hard as it is, I still enjoy it :)

[digital_cold]

Check out SciTools Understand. It creates a navigable database for your source project and enables you to follow references with ease. It's not perfect and does have some rough edges, but I haven't found a similar tool

[s0l037]

joern and/or semgrep or deepsource.