jt3

Would anyone want to support a third party which audits popular dependencies, and digitally signs off after being reviewed? I currently audit source code for private companies, would be cool to pivot and focus on open source projects.

Feel free to email me, [email protected]

Users may wish to log out sooner than 30 minutes too.

Would be bad if a DoS attack could occur by killing the chip at a certain date or on command. Imagine electronic devices going down, and only way to fix is to get new hardware...ouch.

Maybe this will open up more manufacturing jobs in the US.

Being an application security consultant, I see this stuff a lot unfortunately. Just takes a missing authorization check on the feature, then you got the keys to the kingdom.

You can have more than one running at the same time?

“I’ve had several authors find their own software and thank me for preserving it. One author even apologized for the copy protection. He understood it was a “necessary evil” at the time, but he was so glad that someone had finally bothered to cut through it. He said it was so exciting to be able to experience his own work again, for the first time in decades.”

That’s cool.

Disclaimer: I’m a security engineering consultant, focusing on code review. I’ve been writing software for 15+ years.

Industry knowledge and following trends is useful. Following CVEs reveal problem areas in software. Some industries or entities may not devote much time to security review, leading to buggy code. Some see security only as an expense unfortunately.

Looking for vulns in locations where others have not or are unlikely to look, due to effort or domain knowledge requirements, can be very fruitful.

Directed fuzzing can yield great results. Any sort of parser in a lower language like c or c++ are good targets. Spend manual review time for areas that are unlikely to be reached by the fuzzer. Keep in mind fuzzers aren’t a silver bullet though, and won’t catch everything.

Running static analayzers or grepping for common errors can find quick hits often.

Complex specifications often have many errors when implemented. I’ve heard a few stories of RCE vulns due to buggy X.509 parsers.

Developing a threat model is helpful to find high impact vulns.

Knowledge is also key. Understanding components at the unit and integration level is a must.

After doing security reviews for a while, you develop an intuition of where to look. Every once in a while though, you bump into a SQL injection on a login page, so don’t overlook the simple things.