Hacker Newsnew | past | comments | ask | show | jobs | submit | cide1's commentslogin

Cymbals arent cheap per se, but relative to other instruments they are. A professional saxophone is on the order of $7000 to $20,000. A professional violin can easily be $50,000 and sought after violin's as high as $20 million. Zildjian cymbals for a few hundred dollars are one of the few places a random beginner can consider buying the same instrument used by world level talent.


1 cymbal isn't the instrument though. You're buying a drum set (5 drums typically), a handful of cymbals, stands, etc.

It's also generally accessible to get the same <guitars, bass guitars, keyboards> used by professional musicians. "Concert instruments" less so yes


Don't re-define red teaming.


Agreed. I thought this was going to be about infiltrating charities to see how corrupt they were or something.

But granted your typical charity has no idea of what the jargon is in the security (or even broader technical) field, and so "red teaming" is a vague enough phrase that could mean anything.


Seconded. This looks like a good ol' fashioned audit to me. No need to co-opt a term that means something else entirely.


Thirded. I mentally translated 'Red Teaming' to 'audited' / 'reviewed'.

To be fair, what they're doing is good. Just that the wording is a little extravagant.


Term inflation.

In half a generation, audit will be relabelled re-teaming. It's ironic.


Yes thank you. It's a pet peeve of mine when tech people start using tech terms for things that already have widely understood meanings. Like "audit" you numbskulls


As someone who's been raising teenagers for the past decade, their language confusion is driving me crazy.

E.g.: "legitimately", and "literally".

Successfully correcting them on "I" vs "me" vs "myself" is now just a distant fantasy.

Sigh.


I'd argue the title here should be changed, since the original is so (unintentionally) misleading.


Its amazing to me how few instructions it took to write this. I would love to see higher level documentation of how it all fits together.


You might like https://archive.computerhistory.org/resources/text/Fortran/1... and https://archive.computerhistory.org/resources/text/Fortran/1..., although they assume a good deal of familiarity with the machines the compiler ran on.


Thank you!


The lack of security features really limits where this can be used in commercial designs.


In general, read-out protection provides a very limited level of protection that I wouldn't rely on to stop cloning. There's quite a few firms that will extract the firmware from protected microcontrollers for a couple thousand dollars (i.e. https://russiansemiresearch.com/ ) which is a drop in the bucket considering the potential profit from industrialized cloning. Lots of microcontroller series also have exploits that can allow hobbyists with very little funding to bypass read-out protection (here's one for the STM32F0 series for example: https://github.com/racerxdl/stm32f0-pico-dump ).


Crypto key storage fuses and high-assurance boot are often more important than readout protection.


Can you explain how? Genuinely curious. The author only refers to "security theater" which seems to be when a product or system around a product makes people feel like they're safer, when actually it's not making anything more safer or more secure.

https://en.wikipedia.org/wiki/Security_theater


I suspect this mostly refers to "Code Protect" or similar functions, that are designed to stop the user for extracting the firmware from a device in the field. Typically, when this is enabled, large parts of the debug interface stop working, and turning it off requires a "secure" erase, that clears the loaded firmware.

While many CP implementations are flawed, or can be bypassed by a skilled attacker (power glitching, &c), I wouldn't say they are purely theater, as they raise the required investment from a <$10 ISP to $$$+ for something like a chipwhisperer.


Consider that in other fields of computer security we treat a device where attackers have physical access to be de facto compromised.


Even with chip security features this is still the case (if an attacker gets their hands on it it can be compromised). There's no chip that exists that I'm aware of that can't be compromised to have its firmware dumped.

It's like locks: Every time a manufacture claims to have made an unpickable lock someone goes and picks it. It's the same for chip security features.

Microcontroller "security" features really are security theater and not actual security. The only real reason they exist is because certain vendors/"big buyers" will require it as part of their parts checklists (which is silly) and it provides a way for chip manufacturers to wriggle more money out of each sale.


I suspect the use cases where MCU security features are useful is dwarfed by those that are not.


I studied that code and the comment for a good 10 minutes. As far as I can tell it just obfuscates, and is not actually implementing authenticated encryption. It would help to just come out and say that part out loud.


True fact: Salsa20 is itself a hash function, keyed, and running in a counter mode.


I agree, the instructions have improved greatly over the years. I just rebuilt some of my childhood sets from the late 80's and early 90's (mostly Town theme) and I was struggling at times. My 6 year old son does well with pretty much all the modern instructions regardless of the age (City, Batman, Speed, Technic, Jurassic Park themes).


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: