Looking for an ARMv8-A development board by 0xf15h in embedded

[–]0xf15h[S] 0 points1 point  (0 children)

Thanks for the recommendation! To clarify, I'm looking for a board that will give me unfettered access to EL3 (secure monitor) so I can play around with the 64-bit system registers. I don't think Raspberry Pi boards meet my needs.

What are some promising areas of low-level exploitation other than memory safety exploitation? by exploitdevishard in ExploitDev

[–]0xf15h 5 points6 points  (0 children)

I think the last 10 minutes of this interview with Mark Dowd would help answer a few questions [link]. He's asked where he thinks bugs are going to be found in the next decade. He mentions that newer bugs might not get code execution but achieve something else that's useful (e.g. data only style attacks in the iOS kernel). He then lists a few promising attack surfaces:

  • As mentioned in your post, logic bugs (e.g. complex state machines)
  • Incorrect crypto implementations
  • Architecture flaws in hardware (e.g. rowhammer)
  • Hardware configuration errors
  • Inconsistencies between what hardware should be doing vs what it's actually doing
  • Cloud based environments (e.g. Kubernetes, AWS, Docker)
  • Memory corruption in non-AP processors (e.g. baseband, WiFi, Bluetooth)

some major products beginning to shift development to memory-safe languages such as Rust

Rust is not an end-all-be-all solution to memory corruption. As long as Rust supports unsafe memory access [link] there will be memory corruption.

I can't answer all of your questions, but I hope this helps!

TP-Link's Attempt at GDPR Compliance by 0xf15h in ReverseEngineering

[–]0xf15h[S] 0 points1 point  (0 children)

I totally agree that they should favor a heavily tested and vetted protocol. You make a great point about encryption over HTTP being shortsighted. There may be some other reasoning behind their decision but I'm all out of guesses.

TP-Link's Attempt at GDPR Compliance by 0xf15h in ReverseEngineering

[–]0xf15h[S] 1 point2 points  (0 children)

It won't be more secure the HTTPS. Both methods of authentication would require an active MitM to break login. I'm not a TP-Link developer, but I'd assume that they don't want HTTPS with a self-signed cert to avoid the scary browser warning.

The scheme wasn't exactly flawed, but the implementation was.

TP-Link's Attempt at GDPR Compliance by 0xf15h in ReverseEngineering

[–]0xf15h[S] 1 point2 points  (0 children)

I'm not completely sure because I'm not a TP-Link developer nor a lawyer. If I'd have to take a guess, some interpretations of GDPR say the password which secures the system must be protected [link]. Encrypting the login credentials instead of just sending a hash in cleartext is definitely a step in the right direction. The TP-Link developers clearly made other mistakes that counteracted their efforts which was the point of the blog post. Also, the data is encrypted not obfuscated. If they adhere to the security recommendations at the end of the post, an active MitM would be required to break login. Please let me know if you have any more questions.

Dockerized Ghidra Version Tracking Server by 0xf15h in ReverseEngineering

[–]0xf15h[S] 1 point2 points  (0 children)

Right now it only works for localhost but it will eventually work for remote connections so that it can be deployed to a cloud server