This is such a turn-off to the industry. I'm not going to accidentally login to an unencrypted URL and get jail time because it's considered unauthorized. I'd love to be a hacker, but the thought of prison is too much.
That's not what happened here. They did extensive infiltration of computer networks, including the US military. They exfiltrated source code from those networks and sold it and used stolen hardware schematics to make clones of unreleased hardware.
They did not attempt to let the targeted companies know so they could improve their security. They were hacking for profit.
IANAL, but the UK's copyright laws appear to me to have many of the same restrictions as the DMCA when it comes to circumventing copyright protection measures. And it wouldn't surprise me to find other countries had passed similar laws.
Have you considered looking into white hat hacking? You could essentially be paid by companies to hack their own product entirely legally for the purpose of better securing it against potentially malicious hackers.
> Have you considered looking into white hat hacking?
In my observation, this is a branch of industry that is very hard to get into.
> You could essentially be paid by companies to hack their own product entirely legally for the purpose of better securing it against potentially malicious hackers.
For this purpose, one uses quite different techniques than for blackhat hacking. E.g. in the whitehat case, the source code is often available etc.. So brutal code reviews, which require rather different skills (e.g. knowing all the subtle details of the language standard (e.g. C/C++)), are much more effective to secure applications than using the typical "blackhat techniques" (reverse engineering, knowing subtle details of CPU behaviour etc.).
As someone who works as a "white hat hacker", allow me to shine some light on the industry. There are many branches, distinctly divided into two categories: Red team/Attackers and Blue team/Defenders. Within the attacking side is what most people think of when they hear "hacker", key among them is penetration testing (pentesting). Pentesting breaks down into distinct categories that target different scopes: internal/external network, web application, mobile app, thick client, IoT, SCADA, Social Engineering, and physical. The list shifts over time, but that's the gist of it. Those that interact with software/hardware rarely have the benefit of white box testing, which includes having the source available, nor do the tests often go deep enough to require subtle CPU behavior or assembly-level reverse engineering. All of these pentests are dynamic, where as what you've described falls under the static analysis camp which involves a different set of skills and tools.
There are some who work in reverse engineering, CPU interactions or static analysis but those are often more senior positions within a company, are more research focused or specifically marketed as such; my role as a pentester is focused on dynamic testing from a blackbox perspective. Sometimes we are lucky to have architecture diagrams, API docs, or source code but they only serve to benefit the test from an external perspective. I don't analyze the code and report vulnerabilities there, I report findings from a perspective of breaking the application in runtime; the code only makes that easier.
Anyone here wishing to break into security to "be a hacker" might find web app pentesting to be the most familiar for developers (it's not far from skills used for UAT, QA and debugging) and provides a pathway down the OSI model. There are companies that will take strongly motivated and technical people to train into pentesters, as the field is vastly understaffed and it's easier to train someone on your methodology from day 1. However, this normally starts as Web App (it's where the money and clients are) and one can move into other areas over time.
I'm more than happy to provide more details or resources to those interested. My knowledge is more in the attacker area, but its possible to start in either side and pivot into the other. Time, patience, and a willingness to learn.
I agree it's not easy to get a job where your role is exclusively reversing software, but I don't think it's all that hard to get in if you're willing to take on a wider variety of projects. If can do code review, web app security, hunt for bugs in big Java or .NET codebases, and so on then there's work definitely work available. There will be cool projects that require serious reverse engineering, and if you deliver results on those then you'll tend to get that type of work more often. But yeah, consulting means billing hours, so you have to work on stuff that's less interesting to earn money for your company, especially when you're new.
> But yeah, consulting means billing hours, so you have to work on stuff that's less interesting to earn money for your company, especially when you're new.
I know some people (myself included) who would work as consultant but have no idea how to even get hold of consulting jobs. Yes, I often ask people who are much much successful in getting those, how they got them. These successful consultants eventually admit that they themselves have no real idea. People just approached them etc. I (and lots of other people) are not the kind of people "that are simply approached".
TLDR: I would not even know how to start to get consulting jobs (and lots of people have a similar problem).
Disclaimer: I am talking about the situation in Germany. In the USA, it might be different.
First of all, forget about the "situation in Germany". Work is everywhere, so be willing to accept work anywhere. There's definitely a pecking order in consulting firms and you can get projects because the company gets a one off engagement with a new client who wants the work done on site. The company has some really awesome full time employees who could do it in their sleep, but they're busy on long term contracts with key clients. Be willing to go, as a subcontractor, to some unglamorous location for a week long project to pentest some shitty internal application that nobody has ever heard of. Get a few of those under your belt and you'll know how it works.
Second, understand that there's more to it than your technical skills. Make friends who work in the industry. Talk with them about what they're working on. Find any interesting bugs or behavior in what you're working on? Chat with them about that. Doesn't really matter if it's security related or not. The people who do the work in the industry are all generally interested in the details of software. If you're into that, then you belong.
Keep reminding your friends that you're hungry for work. Keeping in touch will keep you in mind when they need an extra guy to help out.
Once you start getting work be sure you contribute well. Everyone wants to have the most high severity findings, and obviously you will need to produce those if you wanna keep getting work, but also be that guy who goes the extra mile to help put the report together, write up extra recommendations that would be helpful.
Keep in touch with the people you work with. Be cool to the sales/project management/accounting people. It's simple things like getting your expenses/timesheets/invoices filed in a timely manner. There's more to the business than finding vulnerabilities. Everyone wants to close out the job, get paid, and move on. Show everyone that you know how to behave like a professional. Remember that the people responsible for staffing are asking themselves: Who do we know that we can send in there to take care of this work, so that we can bill them and collect this revenue, who will get the job done and be easy to work with?
Be that guy, and you will be approached too, and you can find full time work in the industry if you want.
> For this purpose, one uses quite different techniques than for blackhat hacking. E.g. in the whitehat case, the source code is often available etc..
I used to work at a company that did pentests (although I never did any myself). This was never the case. Every single one was approached in the same way an unprivileged attacker would approach it, apart from, when testing a production instance of an application:
- dummy accounts are set up, so that if user data must be extracted it doesn't come from real users
- you're not allowed to do anything that risks taking the application offline, destroying data, etc.
> used to work at a company that did pentests (although I never did any myself). This was never the case.
brandonjm wrote above (emphasis by me): "You could essentially be paid by companies to hack their own product entirely legally".
It would be a massive waste of time and ressources not to give the internal whitehead team any internal information possible to secure the application. For this I stand by my point that the methods that I stated are usually much more effective.
Pentesting is typically applied in very different scenarios (not a company hacking their own product as in brandonjm's scenario).
In my experience the reverse engineering type jobs tend to involve targeted malware and related forensics or code review of software the client doesn't own but is forced to depend on for some reason or another. And of course there's research but that's not something most security firms generate revenue from directly.
You are absolutely right about the massive waste of resources that holding back info causes. It's way better to give consultants complete control of a working test system with the full build environment. And they might as well just let you do it remotely. But many companies don't do that. Instead they would rather eat your travel and accommodation costs, and then when you show up you're being paid to sit around for a week because they don't even have things ready, so you sit around reading bullshit documentation so you look busy and your contact doesn't look bad. And when you finally do get something you spend lots of billable hours figuring out how to get it up and running, which provides absolutely no value to them and wasted valuable time you could have been finding bugs. But that's just how it goes.
