So, the problem with USB tokens that we basically have two choices: - Unauditable black boxes built on *supposedly* more secure ICs that require NDAs to develop for - Open and auditable, but definitely pwnable off the shelf microcontrollers. Which poison do you prefer?
-
Show this thread
-
Open IC, because of you master assembly language and code everything with it, you can code things that can resist usual pwn techniques.
1 reply 0 retweets 0 likes -
No. Coding in assembler has nothing to do with writing secure software (in fact it's a lot worse most of the time), and certainly has nothing to do with the physical attacks I'm talking about, which cannot be mitigated in any programming language.
3 replies 0 retweets 1 like -
For example, in assembly language, there are technics from assembly language jedi knights like me to mitigate stack & buffer overflow, but also ROP and maybe JOP (I'd have to review JOP's white paper to ensure my tricks can work). It's all a matter of being an advanced highly
1 reply 0 retweets 0 likes -
Or you could just code in Rust and never have to worry about buffer overflows. Sorry, I would never hire you. You don't know what you're talking about if that's your mindset. If you think coding in assembler means you write more secure code, I am certain your code is not secure.
5 replies 0 retweets 0 likes -
Do I won't argue with you. Code in Rust, it's an option, but coding in Rust makes you dependant of an OS, of a kernel, of libraries, full of security breaches. When I code in assembly language, usually for embedded systems, 100% of the code is my own code. I use no library.
1 reply 0 retweets 0 likes -
If you had actually looked into Rust, you'd know it works standalone without an OS, a kernel, or anything but a tiny subset of the standard library, which is itself written in Rust and thus largely free of security flaws by design. Rust works fine on embedded systems.
3 replies 0 retweets 1 like -
What you said is good to know. But don't spit on those who have the skills and long experience to do it manually in assembly language, with very specific coding constraints.
1 reply 0 retweets 0 likes -
It doesn't matter how specific your constraints are. Humans make mistakes and violate constraints. By delegating those constraints to the compiler, which only needs to have those constraints encoded once and then apply to all software, you improve the overall code quality.
2 replies 0 retweets 1 like -
Yes this is true. But it has the draw back that if your compiler is 200 millions lines of code like GCC, even free, you'll have an issue checking the compiler integrity all by yourself.
1 reply 0 retweets 0 likes
In general compiler bugs are rare, and are a lot less likely to result in exploitable code and a lot more likely to cause runtime issues that are easily detectable. You're going to avoid a lot more bugs using a compiler than you're going to introduce from the compiler itself.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.