«XBOW submitted nearly 1,060 vulnerabilities. All findings were fully automated, though our security team reviewed them pre-submission to comply with HackerOne’s policy on automated tools»
That seems a bit unethical. I’ve thought companies specifically deny usage of automated tools. A bit too late ey…?
The policies states it’s not allowed to use automated tools, not to submit report using automated tools alone. Human review does not really change that.
I looked through most of the charts, and I it seems like you cannot get the best of two worlds. Can you get good edge retention, ease of sharpening and toughness at the same time?
It would be nice with an example on how knife steel properties work. I assume there are balanced tradeoffs.
"Edge retention" is mostly achieved through high abrasion resistance. Sharpening is removing material by abrasion until the edge has a small radius, so ease of sharpening is mostly achieved through low abrasion resistance.
Being soft or brittle can also make forming a sharp edge difficult, requiring very light pressure in the final phases of sharpening to remove or avoid creating a burr in the case of softness, and to avoid chipping in the case of brittleness.
Of course all of these properties are affected by the heat treatment, which is often more important to the performance of the knife than the composition of the steel.
The point of a graph like that in this case is merely so that you can choose which aspects you need for a given application.
You decide which aspects you can live without to get the ones you can not live without, for a given application. Because it's either that or have a dull knife, or a broken knife, or a rusty knife, etc.
My favorite kitchen knife is tough and sharp but rusts easily. It's ok since it doesn't live in a tackle box on a boat, or in my leatherman.
At best you can have "good all-season tire" which at least doesn't completely suck to the point of failuire in any dimension but doesn't excell in any either.
that is correct, edge retention, ease of sharpening and toughness usually come at a trade off to one another.
A harder blade is more brittle (less tough) and keeps its edge longer... but is also more difficult to sharpen once it gets dull.... generally speaking.
H1 and H2 seems to fare well on all properties except edge retention.
I would probably be interested in a knife that has high corrosion resistance, toughness, and edge retention; ease of sharpening might not be that much of a concern, personally, but correct me if I am wrong and it actually matters despite toughness.
One I can't put in print: Rick's rant about how he described Mr. Needful's microscope and its effect. The wordplay is <chef's kiss> but unfortunately it's unrepeatable.
It it possible to create firmware that is encrypted and cannot be read out. Espressif state there is no security issues, but I have a feeling that these debug commands may be used to read out the flash of a properly secured esp32 that otherwise would not be possible…
You need arbitrary code execution on the main cpu to execute the debug commands. Once you have that, it's game over anyway. Why not just post the data to a url rather than trying to smuggle it out in Bluetooth headers? Or just broadcast it via normal Bluetooth packets?
Tarlogics blog post, it is mentioned “modifying chips arbitrarily”, “infecting chips with malicious code”, “obtain confidential information stored on them”.
Even though they rephrased the backdoor wording, the remaining statements make me believe the undocumented functions can be used to gain code execution on the main cpu.
why do we believe their documentation, when they didn't list this in the first place?
they're either lying, or failed to disclose details previously.
why do you think they're doing a better job this time around? there may in fact be no serious threat, but now anything and everything is called into question.
The bluetooth HCI has a section for Vendor-specific HCI commands that are primarily used for custom hardware initialization on control as well as for debugging purposes. All manufacturers have undocumented commands. It's why the spec allows vendor specific commands.
If you're at the point where an undocumented bit of functionality in a product takes into question the entire company, you must not trust Intel or AMD or Raspberry PI, or all other chip manufacturers. There's nothing malicious here. There's no security issue. It's fully specification compliant. Why are you so concerned?
Frankly, I feel that if you are so concerned, you should work with the specifications to eliminate the vendor specific extensions if you feel their existence is so damning, rather then shitting on a company for following the defined specifications.
The problem is that Tarlogic went full nuclear with "There is a Backdoor in ESP32!!" all over the tech media based on logic that aligns with yours. "They had a feeling."
This is not a backdoor. It is arguably poor security design as one might like it if the BTLE controller was a separate permissions domain. But it isn't, and doesn't have to be, and there isn't even a theoretical vulnerability demonstrated.
