You need both, but the decompiles do help, primary for quick analysis. I consistently find myself digging down to the actual assembly due to things getting lifted out that are relevant.
Yeah, same here. [Capstone](https://github.com/capstone-engine/capstone) has gotten pretty nice, but their API is kinda unstable from release to release.
I'm kind of in the golang swamp of malware, so it's a little more ridiculous here when it comes to analyzing go assembler as an intermediary format, because binaryninja, ghidra and IDA Pro are kinda useless tools for that.
What helped me a lot for analysis was the embedded "C like code" parts in binaryninja, because the tabs can be used to represent both hex, assembler and C in parallel which is still kinda pain in ghidra.
I wish all of those tools had better pattern recognition engines, where common code paths of e.g. known libraries or function signatures can just be replaced inline with the source that matches the assembler tree.
Unless the architecture you’re dealing with isnt well supported by the decompiler you’re using im not sure why you would opt to read the disassembly instead. I use the pseudocode view in ida and im fine 99% of the time
Would you mind elaborating some more? I’m not super familiar with assembly. I know it’s a low level language, so can you just “watch” the code executed by the kernel and work backwards from there simply based off what was executed ?
When you compile a programme using a higher level language, what you end up with is in machine code. It's fairly easy to translate machine code to assembly using a disassembler. So you can analyse the assembly code itself to understand what the programme will do when it's run. Some compilers even embed the assembly in the machine code.
You can also step through assembly to assist in your analysis, add in breakpoints etc. Assembly analysis is just one part of the reverse engineering / static analysis methodology. Decompilers will then try to turn assembly code back into a higher level language but while these are a lot better than they used to be, it's still like trying to turn a cake back into eggs, sugar, and flour.
Consider the "reverse" in reverse engineering. You start with an already compiled binary and are working your way back. That compiled binary is optimized for the machine to read, not a human like source code is. Static reverse engineering involves using a disassembler which unpacks the binary into assembly. From there you have to do a lot of work to piece together what the original source code intended the program to do. Decompilers attempt to do this for you and give you code (Hexrays or the free Ghidra include these), however you can't get exactly what was written, the comments, or the original variable names etc. This is a very manual process and there's only so much automation available, still requires a human's analysis.
That was very insightful, thank you.
Just rambling: I wonder if the hacker groups that 'crack' premium games for pirating/torrenting work off this same basis. I can also hypothesize (correct me if I'm wrong) you could obfuscate your original source code; so if someone attempts to decompile/reverse engineer it - it becomes much, much more difficult to piece together.
AI LLM's also could be levied to do rapid analysis for reverse engineering in the future. Sort've a concerning thought. Still, I can see why cybersecurity engineers who work in reverse-engineering projects are probably damn well paid and desired.
Yes most programs and games that are cracked are first reverse engineered and normally either gets the DRM / auth system patched or removed or gets the auth system fully reversed to make keygens.
Yes, you can obfuscate both the source code and the compiled binaries of your program to make it harder to reverse engineer. For obfuscation methods for the source code just look up the language and add obfuscation and you will get some examples. For obfuscating compiled binaries you can look into themida and vmprotect. However there are unpackers and methods that you can use to unpack these obfuscated things both automatically and manually depends on how complex the obfuscation and the protected program is
/u/tranminhdang366 is on the money. To add, /u/astray488 you are asking the right questions for your introduction into the world of malware reverse engineering. Malware authors will attempt many things to hide or obfuscate the programs capabilities and intentions. Ultimately, they can only slow down a reverser for any binary the researcher has already captured. That bought time COULD be valuable for the malware author or it could just enable basic defeats to get past automated antivirus products, they may know it won't stand up to human scrutiny. Binaries that are purposefully masking their functions (or using a "packer" as /u/tranminhdang366 said) actually stand out as suspicious for that exact reason.
As for those who cracked games, yes the same methods are involved as part of the cat and mouse game, although most modern DRM/authentication utilizes internet connected services as well which adds another realm of knowledge/reversing outside assembly. Aside from pirating games, the world surrounding cheating in online games and the defeats companies implement is a fascinating topic to dive into.
Thank you. Sidenote: I'm familiar with the tenets of IT, C#/C++ and in school for my BA in Comp. Sys. Engineering. Yet in just 4 Reddit comments, feel like I just had a revelation about a whole different world in the vast IoT.
Always wondered how the cleverest of hackers bypass esteemed anti-cheats (and make big money then off selling their hacks to players). How said esteemed anti-cheats like VAC or Riot Vanguard work and catch players.
..Then into Antivirus programs (I used to like Kaspersky until 2022) & how malware like StuxNet were seemingly genius in their engineering. NTM things like Pegasus, PrIsm, Lavender, etc.
I agree this is a fascinating topic because it takes such an array of skills and ingenuity to win; even if you're pro at low level language and assembly. Truly like some Spy v.s. Spy. God, I wonder how many unknown exploits and potentially engineer-able hacks/malware are possible - but nobody has yet realize.
You may find episode [7 and 8](https://darknetdiaries.com/episode/7/) of Darknet Diaries entertaining. It's focused on a story of the early days of video game hacking and the use of reverse engineering. When the first episodes of DD came out I was suspicious because the subjects seemed to glorify the hackers too much, but my opinion changed around this episode. The later episodes about [Xbox hacking](https://darknetdiaries.com/episode/45/) were also really interesting and some of the best in the series.
You can still study and learn at your own pace freely you know. It's not even hard for my degree was never in CS. Like all other skills it just takes time and patience. Seriously, C is not hard for parsing is forgiving. Want to feel distress? C++
That said, you may get a job programming or in infosec before you feel confident, but just know that many programmers and practitioners in infosec did not feel ready on their job.
Great news, you don't need a degree to validate your skills if your skills are self-evident.
Beyond the occasional Excel or GSheets formula I didn't start actually learning how to write code from scratch until I was 27, and in the worst circumstances. I was 2nd chair for a murder trial in a small county and this being when anyone could scrape Facebook, we needed to root out jurors that had either a closer connection to the county sheriff's office than they would admit to and any anti-hispanic bias. Client was Hispanic, most of the county was white, and we were tensions and we were not far from Ruby Ridge. I spent 2 weeks piecing together code from github and put it all together over a weekend and somehow it managed to work well enough that we got a hung jury. Prosecutor had threatened seeking the death penalty at some point, but ended up not even getting a conviction, and managed to walk into a self-own by dismissing the last minority juror, basis for a Batson challenge. Somehow the prosecutor never figured out our voir dire strategy and so, he scheduled the retrial during my finals - yes, that means that effectively I was doing legal work for free as a side hustle since the ABA won't let me get paid when school was happening - but it taught me 2 things that I really hadn't contemplated before:
a) Code as a means to an end can be incredibly powerful and generally applicable, and
b) If my terrible in hindsight code potentially kept someone off death row, better code by more competent people can definitely achieve more.
All that was validated quite soon. Code can literally save lives even when the person writing the code had to trial and error for 2 weeks. You can definitely do much more and it would take less time to learn as well.
Full disclosure: I was obviously familiar with tech and computing in general and had built PCs in high school, but I was more of a "super user" than anything else. I was also told that my math skills were never going to cut it and, well, I don't think my math skills are any good, but it's the pedagogy more than anything else. And since it's a means to an end, it's transferrable in ways you probably haven't imagined. I was heavily recruited by IP firms upon graduation and literally haven't needed to interview for a job since. Meritocracy is still alive, you just need to put your work out there, show not tell is a good rule that applies to far more situations. I can't even get a proper copy of my transcript now since my small liberal arts college was merged into an art school and so if my records were kept, it'd show that I got a history degree from an art school. But turns out, nobody really cares. Just keep on writing code and don't be afraid to ask questions or put your work into the public. I mean, what else do you have on your calendar anyway, right?
Didn't really expect it to get upvoted so much. If people are interested in this branch of cyber, Ghidra and GNU debugger gdb(or pwndbg) are great tools to get started in basic binaries. Assembly is vital to learn, and depending on what you're reversing, C and C++ are good to have knowledge of in terms of computer engineering and about how the stack and heap really work. Python is great to get scripts going quick as well. Depending on what you're working on, other skill sets are required. For example, I work on smart devices, so a little bit of knowledge about electrical engineering and proprietary protocol analysis comes in handy. This is one of the best guides I can recommend that is free. https://github.com/mytechnotalent/Reverse-Engineering. Also to practice on binaries, crackmes are helpful. Check this out too. https://github.com/wtsxDev/reverse-engineering
to add to this, there is typically varying degrees of actual coding you can do as a reverse engineer. it ranges pretty far between making just quick python scripts to do something like XOR some stuff together, to making plugins for tools, to building even almost full programs like inetsim/fakenet to feed malware network traffic it is looking for. there's also creating stuff like emulators with unicorn engine and making config extractors.
it really depends on what you are reverse engineering and the goals/customers you have, but there is a lot of opportunity to code stuff almost daily if you really want to.
And this is really a "better mousetrap" kind of situation. Even if there's code written out there, you can always improve it if you see a way to do so. I mean, Google's python client is literally built on httplib2 still. It works, but it's 2024, you can use async, you may need to connect through a jump host, or a bunch of stuff that is pretty normal today that wasn't back then. So people write their own clients. They're not obvious, but there as a better mousetrap to be made, and a ton of people did just that. I bet there are a ton of projects that can use a pull request that takes not all that much effort but can make a huge difference for the end user.
Yah was gonna say this, you need to create a lot of fuzzing tools and I know those require deep depth knowledge on how memory works cuz how else you gonna fuzz something if you don’t understand how it works.
Anything that falls under security engineering really.
It ranges from building solutions on API of popular cyber tools like Qualys, integrating data and building out the observability and search optimization in Splunk, own the core OS image and hardening automation for all endpoints in the business, owning the DLP tech stack like Microsoft Purview, and up to seriously full blown CSPM/CWPP solutions on the back of Wiz, AWS Organizations guardrails, Azure Defender for cloud, etc.
Edit: typo
Im an AppSec Engineer at the mid level and this is accurate. Even within Appsec, most of my coding was scripting for the automation of tasks. Engineering handles the building of the product, we (at least in my current role) blue team the environment that the application resides in. THis is not the same for all "Appsec roles", this is just my experience. I've recently described my work as 70% political and 30% technical. I love getting my hands dirty but unfortunately a lot of leg work with collaboration and communication occurs before then.
In my last job I was mostly doing developer tooling (around secrets, certificates, etc) and scripting. At my current job I actually work on the user facing product in addition to operational work and it's been really fun! Would be hard for me to go back to not mostly writing code.
From interviewing at other places I think it comes down to org size and industry. If you work for a smaller company or a company where security is part of the product you may end up doing more "normal" software engineering.
I will agree with appsec, but it depends on the company. I have a team of appsec engineers who are all developers/ come from development. They will build libraries so that we have a common way to implement security controls for all dev teams. They will also help dev teams and sometimes to development for vulnerability remediation. In top of that they build automation to help integrate security tools and to build processes for our team.
This is how it works imo, otherwise your sort of a devsecops function. Lots of buzzwords I’ll agree but yeah in my mind appsec should provide the ability for developers to implement security into their work: tools and services (SAST,Dast) and secure libraries and frameworks if required.
If you do infrastructure as code, that probably.
In business systems, erp, and fintech there are also a lot of data engineer, automation and inhouse coding roles. In the bigger firms these will have a security requirement.
There are also Security / QA type roles in app / web dev.
PS: How did I not mention Malware Analysis?!
I feel like powershell was overlooked during college and sec+ as far as coding goes. Now that I am employed in the field it is by far my most used coding language.
Detection Engineering and Security Automation come to mind. Detection engineering actually requires top tier coding ability. Logging systems are Tier 1 services that must maintain 100% uptime. Also your event source can’t knock over the host or service it’s installed on.
Also red teams can have a significant amount of coding depending on whether the team develops their own malware. That requires in depth knowledge of OS internals and syscalls
No one mentioning red teaming is a bit weird but here we go:
Red team is actually just software engineering on steroids. You'll require to code up proof-of-concepts tools and/or actually full blown tools. You also get to do ops as well, so it's best of both worlds - coding and hacking at the same time.
Up against new EDR? Time to code a new stage1 loader and let's see what happens.
Seems like a lot of our clients are now using solution XYZ in their environment... Cool, let's code a .NET post-ex tool that can programmatically enumerate, manipulate, priv-esc, and do post-ex with the solution. After creating that .NET tool, let's convert it to BOF for more opsec.
Company keylogger got flagged last week? Before I deploy mine, let's make a new one. Or maybe let's just pick up nim or rust just to mess with the blue teamers so the shelf-life of the keylogger is longer this time. Since I have 3 weeks left for this op, let's just learn nim/rust, code a keylogger, convert it to BOF (off-hours since business hours is for client ops work).
New EDR bypass technique came out? Time to update our loaders and post-ex stagers. While at it, let's just update the company CI/CD pipeline (jenkins or azure pipeline, etc) so we get most up-to-date payloads every time.
New lateral movement technique that uses some DCOM magic? I don't know what DCOM is, but let's learn that. After learning, let's create a lateral movement tool that utilizes DCOM, and some opsec magic into it so we don't get caught. After creating the tool, let's just refresh by scripting an aggressor script for our C2.
Almost at the end of an op, the client wants to test their detection on some advanced powershell tooling. We barely use powershell because of opsec, but the client wants it. Sure, we can code up some powershell tool, we have time left anyways.
New LOTS (Living of Trusted Sites) dropped? Hmm, I wonder if I can code a stage1 agent and C2 backend for a proof-of-concept, and eventually use it in an op?
The list goes on!
Some of these are not super serious coding like proof-of-concept tools or one-off tools, but others can turn into serious engineering. For example google up C2s, post-ex tools, and loaders like: Cobalt Strike, NightHawk, Sliver, BloodHound, Nanodump, ROADTools, NetExec, GraphRunner, etc. CS and NightHawk is closed-source, but others are all open-source.
If you want intensive coding, your only real choice is software development. You can focus on making security tools, both offensive and defensive.
Malware research and application security both require in depth knowledge of coding and software development, but general isn't about writing code vs reading / reverse engineering it.
Most roles will require some coding.
For example if you're a security engineer, you'll be writing a lot of reports, alerts, and building queries using Kusto in an Azure Analytics/Sentinel environment.
Agreed and Kusto for even basic SOC analyst roles for advanced threat hunting, SIEM querying, etc. Powershell is vital.
Sadly in my experience, I've encountered too many in SOC and Engineering roles that are unable or unwilling to learn the basics with scripting for their projects and tasks. We need more who enjoy scripting in the field.
I think people don't know where or how to start learning how to script. Instead of nailing down a language that has some good mileage (E.g. Python), people are given a slew of recommendations that overwhelm.
I'm my arena, I work with lots of SOAR SMEs. They swear by Python for most SOAR tools.
I'm at a middle management level, I go back and forth myself on learning Python. Even if I learned it, not sure if I'd use it enough on the job to keep it sharp.
Once my job gave us all subscriptions to ChatGPT, a lot of scripting started happening lol (of course we know not to input proprietary data). Manager said “It’s the future, go nuts”.
Knowing the fundamentals of programming helps drastically with prompt engineering. Some of the people who refuse to at least learn the basics still struggle.
Here's what a lot of people fail to understand: most cybersecurity (and more broadly, IT) roles today already "require" "a lot" of coding *if you want to excel*. Sure there are roles that just don't, and there are ways to avoid it, but automation and the ability to make things work exactly the way you need is immensely valuable. And TBH, I've found the bar to be extremely low. The number of people that are left in awe when I script the simplest tasks is mind-blowing. Dude, it took me 15 minutes lol
Thanks for this comment, I was losing my fuckin mind reading the comments here. Coding is a veritable requirement for all tech roles to various extents currently.
There is no room in the industry for double clickers and manual analysis of data (cough, spreadsheet cowboys)
The game has changed in the last decade, coding and scripting is now a requirement
Depends on the company. Appsec in mine doesn’t do as much coding directly (though there are definitely opportunities), but places like google I’ve talked to security engineers and they’re basically committing every other day.
Yes. Lots of roles.
The biggest and most important part is the Linux software which underpins almost every security device in existence. Within Linux there would be SSH, various transport protocols, DNS, email and firewalls. You then have special purpose applications like Nessus, nmap, fail2ban. Then there are images like honeypots which have their own special code to play a game of pretend and collect samples for analysis and blocking.
Next are the various python scripts that run behind the scenes….kali Linux for example
Then there are the various scripts that are written to lockdown servers, switches etc. Some companies use software like ainsible, puppet, etc others use scripts, others use a combination.
Coding is also used a lot in firmware and exploit analysis.
There are many more than this but these are just a few that I have been involved with.
Making cybersecurity software, find a task or something that most analysts deal with on a day to day basis, and find a way to either automate it or make software that makes it 10x easier/faster
In OpSec we do a lot of coding towards automation: click on a button to get the last month worth of admin access logs, check for connection out of standard working hours, compair it to the on-call schedule, find service ticket associated with time period and return an excel with anything out of the ordinary with all info needed to investigate.
I'm not sure I correctly understood you question.
Are you referring basic scripting to simple one liners and in depth coding to an aggregation of basic script?
I think it really depends on the team culture and mission. I’m in AppSec, and my team is really focusing on automating the s*** out of everything. We build our own rule engine, and a full stack web app to interact with it. Multiple modular integrations between all of our scanners and custom packages to support them. Everything is deployed through CI/CD pipelines. So we’re our own DevOps/QA as well. Coding is about 70-85% of my time (about 60-75% for our Senior and Principal engineers). I think this is mainly because the decision makers in our team were all developers in the past lives, so they set this culture up. And it’s been wonderful.
A lot of security professionals have written tools out of need, not because it was part of the job description. And a lot of open source efforts can lead to career success: Metasploit, Security Onion, GreyNoise, etc
Security engineering, secdevops, etc. Technically most positions require some depth of scripting, save for GRC related roles and management / supervisory / CISO roles.
I work as a security engineer at a software product company. I’m responsible for regular code audits and remediating vulnerabilities. It’s not “loads of coding” but it requires deep knowledge of secure coding practices, especially in cases where fixing an issue could mean rewriting entire features.
Hello,
Writing security software such as antivirus, encryption, multifactor authentication, plus the management tools for these, their various back ends, etc., are all full-time programming jobs. These are software development jobs in the computer security industry and typically make use of high-level programming languages like C/C++, sometimes with some assembly language thrown in for performance reasons (although that is much rarer these days because compilers are so much better at optimizing code).
Regards,
Aryeh Goretsky
It’s highly dependent on the company. Security engineers at some places are more focused on operations and automation with little coding, whereas others create and own product functionality that have security considerations. The latter ends up looking pretty much like a software engineer with security subject matter expertise.
Security engineers in non tech companies _tend_ to fit the first description, whereas smaller and bleeding edge software companies _tend_ to fit the second. There are always exceptions though.
App-sec, dev secops side. But it’s mostly working with the devs to figure out vulns detected by static analysis and learning how packages and dependencies work (package.Json, Pom.xml)
I come from a heavy infra side. But I enjoy it as a subset of my overall security role.
Python, PowerShell and bash for CICD. Because Sometimes devops people do dumb shit to get the job done and move on to the next ticket.
edit -grammer
I’m a security architect and spent close to ten years without _needing_ to do much coding. Like it’d be small python scripts or powershell at most. However, the amount of coding increased as I began working on automation stuff.
Also, more of a preference than a need, it’s picked up as I began diving much more deeply into our SIEM. We’re using Elastic and all the code is in GitHub. I’ll reach out to our support for issues with our cluster but if there’s a bug I’ll do as much troubleshooting as I can and file an issue on Github. If I can, I’ll submit the PR myself.
I figure it saves everyone time as this is something support would need to escalate, with the devs having to find the cause. I also get a lot out of it as I end up with a deeper understanding of what’s happening in any of our pipelines or how some feature functions deep down.
Code is the building-block of all things Cyber. So if you’re in a code-less security role it’s probably management, governance, risk, compliance or physical security.
As soon as this whole internet fad blows over, coding will be much less critical.
I think most people hiring for security got no idea wtf they hiring for, so usually I just walk into whatever role and do engineering shit anyway.
Otherwise Security Engineering, whether AppSec, Incident Response or Red Teaming. It's more API-based development though. Like querying your SAST/DAST tools and building data dashboards.
For example, Sonatype has pretty lame reporting capabilities but you can query the APIs and build your own reports instead. I built a pipeline backed by SQLite3 and/or PostgreSQL. SQLAlchemy and Python. Then you can use stuff like Dash or just PowerBI for presentation.
I've implemented a few different SIEMs which can be fun. Properly setting them up for your environment can be a proper challenge. Once I took out a whole FortiSIEM instance during a regular update, and decided to just go ahead and rebuild it from scratch instead of fixing it. That was pretty funny, and nobody properly understood that I both destroyed their SIEM and then proceeded to rebuild it.
Otherwise malware analysis can be super fun. Often you will implement your own versions of functions you've reverse-engineered to see how they tick. Then there's a whole lot of C2 infrastructure that you can build out from organisation to organisation.
Finally there are thousands of open source security tools you can use. If you really want to build shit you're better off joining these kinds of projects than expecting some corporate job to give you meaningful work. Half the time they're too busy shooting themselves in the foot.
Configuration/patch management. Work in a large enough enterprise environment and your automation for configurations and patches turns into custom software real quick
CSE/ISSE, cyber security engineer, basically implement, verify, and do all the hands on work for the grc folks. It's better than SOC, but it's also pretty niche if you want coding. I had a client who didn't want to pay for an ELK stack, so they requested we create one from freeware... took 8 months, and I learned more coding than I ever wanted.
Any Security role at a FAANG or FAANG like company.
I'm at a fintech startup and we only hire coders now on my team of Security Engineers. There's been a level up requirement, so the non-coders around aren't being let go, but the new one's all good coder pretty well.
Right now I'm developing something like ConductorOne internally and things like this definitely need you to know how to code.
Cloud based security roles and application security roles.
There is a lot of developing scripts and middleware to make processes easier(like vulnerability management and such).
This is a good question that many computer science grads face when graduating and entering the workforce. The distinction to keep your eye on is what team and what org you are joining. Is it one within engineering or is it external to engineering (for example within ops or it). There are some positions that may be in neither, for example a "labs" team doing R&D work that have a mix of engineers and analysts. But again, great question, if you've invested in a degree in engineering and are now considering roles like analyst or threat hunter, it's an important one. If you'd like to further discuss, send me a DM. I've been there, and hadn't any guidance. Would love to help someone navigate these issues before they've committed one way or another.
Hello. It appears as though you are requesting someone to DM you, or asking if you can DM someone. Please consider just asking/answering questions in the public forum so that other people can find the information if they ever search and find this thread.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/cybersecurity) if you have any questions or concerns.*
Cybersecurity product development. You can be basically a developer, but create things ranging from a backend for a SOAR (written in python or js) to a ultra-high performance DPI (written in low-level stuff like C++).
But besides that, any cybersecurity role, some more and some less, requires you to automate your routine tasks in order to stay productive. Bash/Powershell, python or golang will always be your friends, whether you are an SOC analyst or hardcore reverse engineer.
“Paperwork security” stays aside, but be sure, there are also lots to be automated: once you’ll realize you can’t afford making reports and collecting stats manually anymore.
If you want intensive coding, i'd suggest finding a startup that develops products and go with them. If not, there are some roles that have coding related tasks.
I love hiring a couple peeps into our teams who can code. Always stuff we can script / code. Tons of what we do involves data ingestion, massaging and reporting. Having teammates who can automate and make sense of big data are some of my favorites.
Threat hunter, CSIRT/DFIR, SOC analyst. But it saddens me to hear this, what don't you like about code? Is it just writing it, or do you also not like reverse engineering it?
Not really coding, but reverse engineering/exploit development requires a lot of in-depth knowledge about coding.
I wish I had studied harder for C in college for this reason.
Reverse engineering involves more assembly tbh
Are decompilers like Binary Ninja useful for getting something closer to C? Or do you really need to "read" assembly to do advanced static analysis?
You need both, but the decompiles do help, primary for quick analysis. I consistently find myself digging down to the actual assembly due to things getting lifted out that are relevant.
Yeah, same here. [Capstone](https://github.com/capstone-engine/capstone) has gotten pretty nice, but their API is kinda unstable from release to release. I'm kind of in the golang swamp of malware, so it's a little more ridiculous here when it comes to analyzing go assembler as an intermediary format, because binaryninja, ghidra and IDA Pro are kinda useless tools for that. What helped me a lot for analysis was the embedded "C like code" parts in binaryninja, because the tabs can be used to represent both hex, assembler and C in parallel which is still kinda pain in ghidra. I wish all of those tools had better pattern recognition engines, where common code paths of e.g. known libraries or function signatures can just be replaced inline with the source that matches the assembler tree.
Yeah advanced static analysis involves assembly but I believe something like IDA makes it much easier to convert to pseudo C (by yourself obviously)
fyi to anyone reading this, IDA is crazy expensive. Ghidra is free
Sorry I’ve only used ida free hence the recommendation
IDA does do assembly to C but it's not particularly useful most of the time unless you have the PDB
Or are a capable reverse engineer. Plenty of reverse engineering is done without symbols
A competent reverse engineer doesn't need the conversion in most cases
Unless the architecture you’re dealing with isnt well supported by the decompiler you’re using im not sure why you would opt to read the disassembly instead. I use the pseudocode view in ida and im fine 99% of the time
I guess it might be person to person. I haven't done RE in years but the pseudocode always confused me more for some reason.
Been looking for ones where I can disassemble and check the code in other languages. The C REs give me a ? because the program isn't in C.
Would you mind elaborating some more? I’m not super familiar with assembly. I know it’s a low level language, so can you just “watch” the code executed by the kernel and work backwards from there simply based off what was executed ?
When you compile a programme using a higher level language, what you end up with is in machine code. It's fairly easy to translate machine code to assembly using a disassembler. So you can analyse the assembly code itself to understand what the programme will do when it's run. Some compilers even embed the assembly in the machine code. You can also step through assembly to assist in your analysis, add in breakpoints etc. Assembly analysis is just one part of the reverse engineering / static analysis methodology. Decompilers will then try to turn assembly code back into a higher level language but while these are a lot better than they used to be, it's still like trying to turn a cake back into eggs, sugar, and flour.
Really?! What's the basis for this (knowing/working assembly)?
Consider the "reverse" in reverse engineering. You start with an already compiled binary and are working your way back. That compiled binary is optimized for the machine to read, not a human like source code is. Static reverse engineering involves using a disassembler which unpacks the binary into assembly. From there you have to do a lot of work to piece together what the original source code intended the program to do. Decompilers attempt to do this for you and give you code (Hexrays or the free Ghidra include these), however you can't get exactly what was written, the comments, or the original variable names etc. This is a very manual process and there's only so much automation available, still requires a human's analysis.
That was very insightful, thank you. Just rambling: I wonder if the hacker groups that 'crack' premium games for pirating/torrenting work off this same basis. I can also hypothesize (correct me if I'm wrong) you could obfuscate your original source code; so if someone attempts to decompile/reverse engineer it - it becomes much, much more difficult to piece together. AI LLM's also could be levied to do rapid analysis for reverse engineering in the future. Sort've a concerning thought. Still, I can see why cybersecurity engineers who work in reverse-engineering projects are probably damn well paid and desired.
Yes most programs and games that are cracked are first reverse engineered and normally either gets the DRM / auth system patched or removed or gets the auth system fully reversed to make keygens. Yes, you can obfuscate both the source code and the compiled binaries of your program to make it harder to reverse engineer. For obfuscation methods for the source code just look up the language and add obfuscation and you will get some examples. For obfuscating compiled binaries you can look into themida and vmprotect. However there are unpackers and methods that you can use to unpack these obfuscated things both automatically and manually depends on how complex the obfuscation and the protected program is
/u/tranminhdang366 is on the money. To add, /u/astray488 you are asking the right questions for your introduction into the world of malware reverse engineering. Malware authors will attempt many things to hide or obfuscate the programs capabilities and intentions. Ultimately, they can only slow down a reverser for any binary the researcher has already captured. That bought time COULD be valuable for the malware author or it could just enable basic defeats to get past automated antivirus products, they may know it won't stand up to human scrutiny. Binaries that are purposefully masking their functions (or using a "packer" as /u/tranminhdang366 said) actually stand out as suspicious for that exact reason. As for those who cracked games, yes the same methods are involved as part of the cat and mouse game, although most modern DRM/authentication utilizes internet connected services as well which adds another realm of knowledge/reversing outside assembly. Aside from pirating games, the world surrounding cheating in online games and the defeats companies implement is a fascinating topic to dive into.
Thank you. Sidenote: I'm familiar with the tenets of IT, C#/C++ and in school for my BA in Comp. Sys. Engineering. Yet in just 4 Reddit comments, feel like I just had a revelation about a whole different world in the vast IoT. Always wondered how the cleverest of hackers bypass esteemed anti-cheats (and make big money then off selling their hacks to players). How said esteemed anti-cheats like VAC or Riot Vanguard work and catch players. ..Then into Antivirus programs (I used to like Kaspersky until 2022) & how malware like StuxNet were seemingly genius in their engineering. NTM things like Pegasus, PrIsm, Lavender, etc. I agree this is a fascinating topic because it takes such an array of skills and ingenuity to win; even if you're pro at low level language and assembly. Truly like some Spy v.s. Spy. God, I wonder how many unknown exploits and potentially engineer-able hacks/malware are possible - but nobody has yet realize.
You may find episode [7 and 8](https://darknetdiaries.com/episode/7/) of Darknet Diaries entertaining. It's focused on a story of the early days of video game hacking and the use of reverse engineering. When the first episodes of DD came out I was suspicious because the subjects seemed to glorify the hackers too much, but my opinion changed around this episode. The later episodes about [Xbox hacking](https://darknetdiaries.com/episode/45/) were also really interesting and some of the best in the series.
Hey, it’s not too late!
You can still study and learn at your own pace freely you know. It's not even hard for my degree was never in CS. Like all other skills it just takes time and patience. Seriously, C is not hard for parsing is forgiving. Want to feel distress? C++ That said, you may get a job programming or in infosec before you feel confident, but just know that many programmers and practitioners in infosec did not feel ready on their job.
Never too late to learn.
Never too late
Now it's definetly too late. If i were to pass the C exam I would get a zero.
Great news, you don't need a degree to validate your skills if your skills are self-evident. Beyond the occasional Excel or GSheets formula I didn't start actually learning how to write code from scratch until I was 27, and in the worst circumstances. I was 2nd chair for a murder trial in a small county and this being when anyone could scrape Facebook, we needed to root out jurors that had either a closer connection to the county sheriff's office than they would admit to and any anti-hispanic bias. Client was Hispanic, most of the county was white, and we were tensions and we were not far from Ruby Ridge. I spent 2 weeks piecing together code from github and put it all together over a weekend and somehow it managed to work well enough that we got a hung jury. Prosecutor had threatened seeking the death penalty at some point, but ended up not even getting a conviction, and managed to walk into a self-own by dismissing the last minority juror, basis for a Batson challenge. Somehow the prosecutor never figured out our voir dire strategy and so, he scheduled the retrial during my finals - yes, that means that effectively I was doing legal work for free as a side hustle since the ABA won't let me get paid when school was happening - but it taught me 2 things that I really hadn't contemplated before: a) Code as a means to an end can be incredibly powerful and generally applicable, and b) If my terrible in hindsight code potentially kept someone off death row, better code by more competent people can definitely achieve more. All that was validated quite soon. Code can literally save lives even when the person writing the code had to trial and error for 2 weeks. You can definitely do much more and it would take less time to learn as well. Full disclosure: I was obviously familiar with tech and computing in general and had built PCs in high school, but I was more of a "super user" than anything else. I was also told that my math skills were never going to cut it and, well, I don't think my math skills are any good, but it's the pedagogy more than anything else. And since it's a means to an end, it's transferrable in ways you probably haven't imagined. I was heavily recruited by IP firms upon graduation and literally haven't needed to interview for a job since. Meritocracy is still alive, you just need to put your work out there, show not tell is a good rule that applies to far more situations. I can't even get a proper copy of my transcript now since my small liberal arts college was merged into an art school and so if my records were kept, it'd show that I got a history degree from an art school. But turns out, nobody really cares. Just keep on writing code and don't be afraid to ask questions or put your work into the public. I mean, what else do you have on your calendar anyway, right?
Didn't really expect it to get upvoted so much. If people are interested in this branch of cyber, Ghidra and GNU debugger gdb(or pwndbg) are great tools to get started in basic binaries. Assembly is vital to learn, and depending on what you're reversing, C and C++ are good to have knowledge of in terms of computer engineering and about how the stack and heap really work. Python is great to get scripts going quick as well. Depending on what you're working on, other skill sets are required. For example, I work on smart devices, so a little bit of knowledge about electrical engineering and proprietary protocol analysis comes in handy. This is one of the best guides I can recommend that is free. https://github.com/mytechnotalent/Reverse-Engineering. Also to practice on binaries, crackmes are helpful. Check this out too. https://github.com/wtsxDev/reverse-engineering
to add to this, there is typically varying degrees of actual coding you can do as a reverse engineer. it ranges pretty far between making just quick python scripts to do something like XOR some stuff together, to making plugins for tools, to building even almost full programs like inetsim/fakenet to feed malware network traffic it is looking for. there's also creating stuff like emulators with unicorn engine and making config extractors. it really depends on what you are reverse engineering and the goals/customers you have, but there is a lot of opportunity to code stuff almost daily if you really want to.
And this is really a "better mousetrap" kind of situation. Even if there's code written out there, you can always improve it if you see a way to do so. I mean, Google's python client is literally built on httplib2 still. It works, but it's 2024, you can use async, you may need to connect through a jump host, or a bunch of stuff that is pretty normal today that wasn't back then. So people write their own clients. They're not obvious, but there as a better mousetrap to be made, and a ton of people did just that. I bet there are a ton of projects that can use a pull request that takes not all that much effort but can make a huge difference for the end user.
Yah was gonna say this, you need to create a lot of fuzzing tools and I know those require deep depth knowledge on how memory works cuz how else you gonna fuzz something if you don’t understand how it works.
[pwn.college](https://pwn.college)
Anything that falls under security engineering really. It ranges from building solutions on API of popular cyber tools like Qualys, integrating data and building out the observability and search optimization in Splunk, own the core OS image and hardening automation for all endpoints in the business, owning the DLP tech stack like Microsoft Purview, and up to seriously full blown CSPM/CWPP solutions on the back of Wiz, AWS Organizations guardrails, Azure Defender for cloud, etc. Edit: typo
You can always code compliance, patches, audits, reports, and risk analysis. So kinda everything 😂. It's all code!
If you use LaTeX, it literally is!
Appsec
[удалено]
Im an AppSec Engineer at the mid level and this is accurate. Even within Appsec, most of my coding was scripting for the automation of tasks. Engineering handles the building of the product, we (at least in my current role) blue team the environment that the application resides in. THis is not the same for all "Appsec roles", this is just my experience. I've recently described my work as 70% political and 30% technical. I love getting my hands dirty but unfortunately a lot of leg work with collaboration and communication occurs before then.
Did a little appsec and this was my experience too. A little scripting and scraping with GitHub Actions to our vuln management solution
In my last job I was mostly doing developer tooling (around secrets, certificates, etc) and scripting. At my current job I actually work on the user facing product in addition to operational work and it's been really fun! Would be hard for me to go back to not mostly writing code. From interviewing at other places I think it comes down to org size and industry. If you work for a smaller company or a company where security is part of the product you may end up doing more "normal" software engineering.
I will agree with appsec, but it depends on the company. I have a team of appsec engineers who are all developers/ come from development. They will build libraries so that we have a common way to implement security controls for all dev teams. They will also help dev teams and sometimes to development for vulnerability remediation. In top of that they build automation to help integrate security tools and to build processes for our team.
This is how it works imo, otherwise your sort of a devsecops function. Lots of buzzwords I’ll agree but yeah in my mind appsec should provide the ability for developers to implement security into their work: tools and services (SAST,Dast) and secure libraries and frameworks if required.
If you do infrastructure as code, that probably. In business systems, erp, and fintech there are also a lot of data engineer, automation and inhouse coding roles. In the bigger firms these will have a security requirement. There are also Security / QA type roles in app / web dev. PS: How did I not mention Malware Analysis?!
Which language is most important to learn in cybersec?
Probably Python, but possibly Powershell.
+ Bash
I feel like powershell was overlooked during college and sec+ as far as coding goes. Now that I am employed in the field it is by far my most used coding language.
Maybe VBscript! :)
Powershell >= python > C > Assembly depending on how deep ya wanna get IMO
Thanks
Python. We use it heavily in CTI Bonus: bash, rust, PowerShell
What are you using rust for?
Mainly if a script we want to use isn't written in python, usually it will be in Go or Rust.
Detection Engineering and Security Automation come to mind. Detection engineering actually requires top tier coding ability. Logging systems are Tier 1 services that must maintain 100% uptime. Also your event source can’t knock over the host or service it’s installed on.
Also red teams can have a significant amount of coding depending on whether the team develops their own malware. That requires in depth knowledge of OS internals and syscalls
Blue team custom automation I do lots of python
No one mentioning red teaming is a bit weird but here we go: Red team is actually just software engineering on steroids. You'll require to code up proof-of-concepts tools and/or actually full blown tools. You also get to do ops as well, so it's best of both worlds - coding and hacking at the same time. Up against new EDR? Time to code a new stage1 loader and let's see what happens. Seems like a lot of our clients are now using solution XYZ in their environment... Cool, let's code a .NET post-ex tool that can programmatically enumerate, manipulate, priv-esc, and do post-ex with the solution. After creating that .NET tool, let's convert it to BOF for more opsec. Company keylogger got flagged last week? Before I deploy mine, let's make a new one. Or maybe let's just pick up nim or rust just to mess with the blue teamers so the shelf-life of the keylogger is longer this time. Since I have 3 weeks left for this op, let's just learn nim/rust, code a keylogger, convert it to BOF (off-hours since business hours is for client ops work). New EDR bypass technique came out? Time to update our loaders and post-ex stagers. While at it, let's just update the company CI/CD pipeline (jenkins or azure pipeline, etc) so we get most up-to-date payloads every time. New lateral movement technique that uses some DCOM magic? I don't know what DCOM is, but let's learn that. After learning, let's create a lateral movement tool that utilizes DCOM, and some opsec magic into it so we don't get caught. After creating the tool, let's just refresh by scripting an aggressor script for our C2. Almost at the end of an op, the client wants to test their detection on some advanced powershell tooling. We barely use powershell because of opsec, but the client wants it. Sure, we can code up some powershell tool, we have time left anyways. New LOTS (Living of Trusted Sites) dropped? Hmm, I wonder if I can code a stage1 agent and C2 backend for a proof-of-concept, and eventually use it in an op? The list goes on! Some of these are not super serious coding like proof-of-concept tools or one-off tools, but others can turn into serious engineering. For example google up C2s, post-ex tools, and loaders like: Cobalt Strike, NightHawk, Sliver, BloodHound, Nanodump, ROADTools, NetExec, GraphRunner, etc. CS and NightHawk is closed-source, but others are all open-source.
App sec is a lot of reading code, not so much writing
If you want intensive coding, your only real choice is software development. You can focus on making security tools, both offensive and defensive. Malware research and application security both require in depth knowledge of coding and software development, but general isn't about writing code vs reading / reverse engineering it.
Threat hunting
Most roles will require some coding. For example if you're a security engineer, you'll be writing a lot of reports, alerts, and building queries using Kusto in an Azure Analytics/Sentinel environment.
Agreed and Kusto for even basic SOC analyst roles for advanced threat hunting, SIEM querying, etc. Powershell is vital. Sadly in my experience, I've encountered too many in SOC and Engineering roles that are unable or unwilling to learn the basics with scripting for their projects and tasks. We need more who enjoy scripting in the field.
I think people don't know where or how to start learning how to script. Instead of nailing down a language that has some good mileage (E.g. Python), people are given a slew of recommendations that overwhelm. I'm my arena, I work with lots of SOAR SMEs. They swear by Python for most SOAR tools. I'm at a middle management level, I go back and forth myself on learning Python. Even if I learned it, not sure if I'd use it enough on the job to keep it sharp.
Start with as small a project is useful to you. Automate every stupid boring thing you have to do.
Good advice. With Python?
With powershell, or anything really.
Once my job gave us all subscriptions to ChatGPT, a lot of scripting started happening lol (of course we know not to input proprietary data). Manager said “It’s the future, go nuts”. Knowing the fundamentals of programming helps drastically with prompt engineering. Some of the people who refuse to at least learn the basics still struggle.
Are you wanting to do coding or trying to avoid it!
Wanting
I guess depends on your existing experience. There are lot of roles within teams where you develop tools, they aren’t necessarily entry level jobs.
Here's what a lot of people fail to understand: most cybersecurity (and more broadly, IT) roles today already "require" "a lot" of coding *if you want to excel*. Sure there are roles that just don't, and there are ways to avoid it, but automation and the ability to make things work exactly the way you need is immensely valuable. And TBH, I've found the bar to be extremely low. The number of people that are left in awe when I script the simplest tasks is mind-blowing. Dude, it took me 15 minutes lol
I’m asking about roles that are more coding intensive than scripting and simple automations.
Ok, then. The only thing that will truly satisfy you is being a developer of security tools. You’ll need to work for a vendor.
Thanks for this comment, I was losing my fuckin mind reading the comments here. Coding is a veritable requirement for all tech roles to various extents currently. There is no room in the industry for double clickers and manual analysis of data (cough, spreadsheet cowboys) The game has changed in the last decade, coding and scripting is now a requirement
Depends on the company. Appsec in mine doesn’t do as much coding directly (though there are definitely opportunities), but places like google I’ve talked to security engineers and they’re basically committing every other day.
Reverse engineering/malware analysis, advanced pentesting/red teaming, exploit development, SAST/DAST(appsec)
Yes. Lots of roles. The biggest and most important part is the Linux software which underpins almost every security device in existence. Within Linux there would be SSH, various transport protocols, DNS, email and firewalls. You then have special purpose applications like Nessus, nmap, fail2ban. Then there are images like honeypots which have their own special code to play a game of pretend and collect samples for analysis and blocking. Next are the various python scripts that run behind the scenes….kali Linux for example Then there are the various scripts that are written to lockdown servers, switches etc. Some companies use software like ainsible, puppet, etc others use scripts, others use a combination. Coding is also used a lot in firmware and exploit analysis. There are many more than this but these are just a few that I have been involved with.
I’m a security engineer and I basically write code most of the time. It’s going to be company dependant, engineer means different to different people.
Making cybersecurity software, find a task or something that most analysts deal with on a day to day basis, and find a way to either automate it or make software that makes it 10x easier/faster
developer on an antivirus
In OpSec we do a lot of coding towards automation: click on a button to get the last month worth of admin access logs, check for connection out of standard working hours, compair it to the on-call schedule, find service ticket associated with time period and return an excel with anything out of the ordinary with all info needed to investigate.
Is it mainly basic scripting? Or in depth coding?
I'm not sure I correctly understood you question. Are you referring basic scripting to simple one liners and in depth coding to an aggregation of basic script?
No. I meant: **Scripting:** one liners and aggregation of scripts **In depth Coding:** coding level and depth comparable to software engineering
Ok I get it. We have a lot of scripting and a couple of in depth code bases.
Sure, e.g. exploit development and application security.
Appsec, security engineering, GRC dev are the big three that come to mind.
DevSecOps
DevSecOps
Application security
DevSecOps
I think it really depends on the team culture and mission. I’m in AppSec, and my team is really focusing on automating the s*** out of everything. We build our own rule engine, and a full stack web app to interact with it. Multiple modular integrations between all of our scanners and custom packages to support them. Everything is deployed through CI/CD pipelines. So we’re our own DevOps/QA as well. Coding is about 70-85% of my time (about 60-75% for our Senior and Principal engineers). I think this is mainly because the decision makers in our team were all developers in the past lives, so they set this culture up. And it’s been wonderful.
SOAR use case engineering.
A lot of security professionals have written tools out of need, not because it was part of the job description. And a lot of open source efforts can lead to career success: Metasploit, Security Onion, GreyNoise, etc
So, in other words, opportunities are everywhere, though they’re often not required
Security engineering, secdevops, etc. Technically most positions require some depth of scripting, save for GRC related roles and management / supervisory / CISO roles.
i think GRC is more into theory path in security aspect and policy
I work as a security engineer at a software product company. I’m responsible for regular code audits and remediating vulnerabilities. It’s not “loads of coding” but it requires deep knowledge of secure coding practices, especially in cases where fixing an issue could mean rewriting entire features.
Hello, Writing security software such as antivirus, encryption, multifactor authentication, plus the management tools for these, their various back ends, etc., are all full-time programming jobs. These are software development jobs in the computer security industry and typically make use of high-level programming languages like C/C++, sometimes with some assembly language thrown in for performance reasons (although that is much rarer these days because compilers are so much better at optimizing code). Regards, Aryeh Goretsky
It’s highly dependent on the company. Security engineers at some places are more focused on operations and automation with little coding, whereas others create and own product functionality that have security considerations. The latter ends up looking pretty much like a software engineer with security subject matter expertise. Security engineers in non tech companies _tend_ to fit the first description, whereas smaller and bleeding edge software companies _tend_ to fit the second. There are always exceptions though.
There are always opportunities to write code during a pentest. You can even make time between tests to work on tools.
Security software engineering, obviously. DevSecOps, not so obviously.
App-sec, dev secops side. But it’s mostly working with the devs to figure out vulns detected by static analysis and learning how packages and dependencies work (package.Json, Pom.xml) I come from a heavy infra side. But I enjoy it as a subset of my overall security role. Python, PowerShell and bash for CICD. Because Sometimes devops people do dumb shit to get the job done and move on to the next ticket. edit -grammer
Look into reverse engineering
Nope but you should know terraform and python if you are in cloud security
Hardware security
I’m a security architect and spent close to ten years without _needing_ to do much coding. Like it’d be small python scripts or powershell at most. However, the amount of coding increased as I began working on automation stuff. Also, more of a preference than a need, it’s picked up as I began diving much more deeply into our SIEM. We’re using Elastic and all the code is in GitHub. I’ll reach out to our support for issues with our cluster but if there’s a bug I’ll do as much troubleshooting as I can and file an issue on Github. If I can, I’ll submit the PR myself. I figure it saves everyone time as this is something support would need to escalate, with the devs having to find the cause. I also get a lot out of it as I end up with a deeper understanding of what’s happening in any of our pipelines or how some feature functions deep down.
Code is the building-block of all things Cyber. So if you’re in a code-less security role it’s probably management, governance, risk, compliance or physical security. As soon as this whole internet fad blows over, coding will be much less critical.
I think most people hiring for security got no idea wtf they hiring for, so usually I just walk into whatever role and do engineering shit anyway. Otherwise Security Engineering, whether AppSec, Incident Response or Red Teaming. It's more API-based development though. Like querying your SAST/DAST tools and building data dashboards. For example, Sonatype has pretty lame reporting capabilities but you can query the APIs and build your own reports instead. I built a pipeline backed by SQLite3 and/or PostgreSQL. SQLAlchemy and Python. Then you can use stuff like Dash or just PowerBI for presentation. I've implemented a few different SIEMs which can be fun. Properly setting them up for your environment can be a proper challenge. Once I took out a whole FortiSIEM instance during a regular update, and decided to just go ahead and rebuild it from scratch instead of fixing it. That was pretty funny, and nobody properly understood that I both destroyed their SIEM and then proceeded to rebuild it. Otherwise malware analysis can be super fun. Often you will implement your own versions of functions you've reverse-engineered to see how they tick. Then there's a whole lot of C2 infrastructure that you can build out from organisation to organisation. Finally there are thousands of open source security tools you can use. If you really want to build shit you're better off joining these kinds of projects than expecting some corporate job to give you meaningful work. Half the time they're too busy shooting themselves in the foot.
Configuration/patch management. Work in a large enough enterprise environment and your automation for configurations and patches turns into custom software real quick
CSE/ISSE, cyber security engineer, basically implement, verify, and do all the hands on work for the grc folks. It's better than SOC, but it's also pretty niche if you want coding. I had a client who didn't want to pay for an ELK stack, so they requested we create one from freeware... took 8 months, and I learned more coding than I ever wanted.
Any Security role at a FAANG or FAANG like company. I'm at a fintech startup and we only hire coders now on my team of Security Engineers. There's been a level up requirement, so the non-coders around aren't being let go, but the new one's all good coder pretty well. Right now I'm developing something like ConductorOne internally and things like this definitely need you to know how to code.
Which coding language mostly
I write a lot of powershell code to create custom tools that integrates with Tenable API since their web GUI can't do everything.
I know of a role if you’re in the Bay Area and have experience. But it might be a lot of column A.
DevSecOps
Malware development or anything connected with automation. If you count scripting, then any advanced red teaming too
Cloud based security roles and application security roles. There is a lot of developing scripts and middleware to make processes easier(like vulnerability management and such).
This is a good question that many computer science grads face when graduating and entering the workforce. The distinction to keep your eye on is what team and what org you are joining. Is it one within engineering or is it external to engineering (for example within ops or it). There are some positions that may be in neither, for example a "labs" team doing R&D work that have a mix of engineers and analysts. But again, great question, if you've invested in a degree in engineering and are now considering roles like analyst or threat hunter, it's an important one. If you'd like to further discuss, send me a DM. I've been there, and hadn't any guidance. Would love to help someone navigate these issues before they've committed one way or another.
Hello. It appears as though you are requesting someone to DM you, or asking if you can DM someone. Please consider just asking/answering questions in the public forum so that other people can find the information if they ever search and find this thread. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/cybersecurity) if you have any questions or concerns.*
Cybersecurity product development. You can be basically a developer, but create things ranging from a backend for a SOAR (written in python or js) to a ultra-high performance DPI (written in low-level stuff like C++). But besides that, any cybersecurity role, some more and some less, requires you to automate your routine tasks in order to stay productive. Bash/Powershell, python or golang will always be your friends, whether you are an SOC analyst or hardcore reverse engineer. “Paperwork security” stays aside, but be sure, there are also lots to be automated: once you’ll realize you can’t afford making reports and collecting stats manually anymore.
If you want intensive coding, i'd suggest finding a startup that develops products and go with them. If not, there are some roles that have coding related tasks.
I love hiring a couple peeps into our teams who can code. Always stuff we can script / code. Tons of what we do involves data ingestion, massaging and reporting. Having teammates who can automate and make sense of big data are some of my favorites.
Threat intel, threat hunting, SOC analyst, red team can all have 0 coding to a lot of coding, just depends on how you approach it.
Honestly, most cybersecurity jobs should know how to code. Everyone should.
Year 5 of security engineering. Dont know how to code 🤷🏾♂️
Developer for firewalls I guess. Firewalls are freaking complex.
CNO developer
In contrary, which role requires the least amount of coding? I dislike coding.
Threat hunter, CSIRT/DFIR, SOC analyst. But it saddens me to hear this, what don't you like about code? Is it just writing it, or do you also not like reverse engineering it?