bdelay

How much notification did you give the developers before you disclosed? Did you enforce a timeline?

If you're new, it's the same advice as any other field. Find a way to stand out. Build a portfolio, have great grades, come from a good university program, ping contacts from your alumni network, do bug bounties, find and fix issues in open-source, etc.

It looks like you made the best of a frustrating situation and, at the very least, have an excellent piece for your portfolio.

With the rise in number of new security engineers all competing for few "security research" jobs (security research/hacking is the "I want to be a game developer" of security), you start getting into these convoluted hiring processes. Unlike standard software engineering, there aren't even remotely enough positions to accommodate everyone, so the bar can get absurdly high.

Honestly, if the team is asking CTF questions, they clearly want hires with previous CTF experience and should just do targeted hiring from the top teams at different conferences.

At least send people a free t-shirt if they complete the challenge.

I took Seacord's virtual class (CMU SEI? Can't remember) on Secure C coding a few years back and own, love, and regularly use the The CERT C Secure Coding Standard.

I learned from K&R, but highly recommend Seacord's books if you're looking for how to write secure C and a more modern take on some of the trickier parts of C.

See the Note from Harman section.

Hence, as the check wasn't working, I never ran into the check. Dat file signatures may very well be in the header or stored somewhere else.

Thanks! I wish there was a service I could pay for where I could ask lawyers vague security-research related questions like this. Right now I wouldn't even know where to begin looking for a lawyer that would be an authority on this type of stuff. If I found that person, I'm also not sure I could afford their time.

Not sure. Have an extra Tesla you can send me?

Okay, that's really cool. Tempted to see if I can get some AWS credits or spend a bit of cash and throw an 8xGPU instance at this for a few days...

Never assume anything. Well done. :)

I agree, but I don't have a consulting-firm/reputation/team of lawyers etc. to hide behind. Reporting flaws to companies related to embedded is often still scary today.

The point of this is that hey, this isn't actually that hard if you're willing to put in the time. If you're moderately talented, you can probably learn it too!

As opposed to the standard exploit write-up/security conference circuit thing, where a lot of the details are kept secret and it seems like the entire point is to make other people think you're cool instead of teaching something. :)

You are correct. I don't believe those accounts worked over ssh due to a lack of password, just local serial.

Two reasons I didn't do that:

1. I believe Harman had a previous device hacked back around 2014 due to a weak shadow hash. My guess was that they learned their lesson and made the password more complex. An easy way to test would be to diff the latest shadow file in the updated Subaru images (assuming they exist) -- if it changed, you may be right, if not, I'd still wager it is strong enough.

I don't like the idea of a backdoor like that available, but it is what it is.

2. The QNX6 hashing mechanism, to the best of my knowledge, isn't fully understood. Upstream changes to JTR seem to indicate that it has some form of bug in it or isn't fully reverse-engineered. That, along with having to spend presumably a large amount of time learning about contributing to hashcat & gpu programming, made this seem like a potential dead end without massive time investment.

So, is it possible it is crackable? Almost certainly, but I'm one guy doing this and you have to spend your time carefully in these ventures.