If you mean the part without mitigations where we execute shellcode on the stack: in the slides you see that we use the address of a BX SP instruction which will branch to the location SP points to (which is the next position on the stack after that gadget) and starts executing the instructions on that location. This is only possible if XN is not enabled, which means the stack is executable.

The address of that gadgets can be derived by looking up the base address of the library, plus the offset of the exact position of this instruction inside that library. Exploit devs use so-called ROP gadget hunters for that, which let you search for gadgets inside a binary and give you the offsets.
Now, the reason we can just statically use the base address of the library is because ASLR is not enabled, which means that the location of that library in memory stays the same. When ASLR is enabled, the base addresses change and require the hacker to predict the base address (either with brute force, info leak, or the other attacks I mentioned).

if no ASLR is used, the addresses are fixed and you can find a good target by debugging or static reverse engineering. Even with ASLR there are techniques like info leaks, slide bruteforcing or NOP sleds that can allow exploitation even when you don't know the exact target.

Hi Bruce, I’m not sure I understand your complaint. This was not an RTOS presentation. The talk was focused on Arm cortex-A devices with Rich OS (mobile phones, routers, cameras etc) and I clearly stated that in the abstract and the talk itself.

Second, you expect me to state the volume of exploits against cortex-m and cortex-r devices versus cortex-a? That was not the topic of my talk.

Third, you are wrong about RTOS devices being more secure and “a million times less likely to be exploited”. In fact, there have been many attacks against critical infrastructure using RTOS, I.e. Industrial Control Systems, Smart Grids, and IIoT, making them valuable and high impact targets.

Thanks Mel :)

Hi Blair, you're completely right, I didn't have time to cover this topic in-depth given the time constraints.
It's always recommended to use memory safe languages that make memory corruption vulnerabilities less likely. Though I don't have the context of the software you are building, it is likely that you will have code bases in your device environment that have been written in other languages. This can come in form of standard components, or even the underlying operating system you are building your software on. Even if your code base is entirely written in a memory safe language, there are many more vulnerability classes which aren't memory-corruption based. Say, race-conditions or logic bugs for example. When you develop in Rust, you need to be careful to not get a false sense of security due to its memory safety, since other bug classes need to be considered.

Thank you, Mark! I really appreciate your feedback and I'm happy you liked it. :)

Hi Alexander, thanks for you feedback! I completely understand your concerns about the disparity in communication between the developer and the security community. Like in every community, there are different groups of people with different attitudes and opinions. I agree that there are people with the looking-down attitude, however I know that the majority of security engineers and researchers are eager to help developers and vendors to fix the bugs they find and improve their security. Most often, security researchers are upset with the vendor for not fixing bugs or responding to bug reports, not the developers themselves. In my opinion, we can't expect all developers to be self-taught security experts. Which is why I talk about exploit mitigations, that make existing vulnerabilities harder to exploit. I regularly give workshops to developers who want to learn about vulnerabilities and exploit mitigations and hope that I can make these concepts more accessible to the developer community through my upcoming books.

In regards to your mention about automated tools, they do exist. There are many different tools that automatically scan for unsafe functions in either source code or via fuzzing. As other comments have mentioned, there are various scanning tools that not only look for unsafe functions in code, but also check common misconfigurations and lack of security features.

there are quite a few CI plugins already that look for unsafe functions and I have been working scripts for my developers to check for the exploit mitigation settings. The the price range for these can be free to very expensive for security scanning tools to check for vulnerablities. A lot depends on who and how someone works with the security teams. I personally don't like teams that appear to be cutting corners(pushing for sign off without complete the review) and teams that wait until the last minute before engaging tean security. It is much easier for a security team to help fix and correct issues at the start than at the end of a project since in the media it is the security team that takes the blame and it can destory our career.

You should check out polyspace. Its a good tool for checking code in place, without need for compiler linkup. Works great in a CI environment, and also allows for continual re-checks whenever a new commit gets pushed up.

Thank you! Glad you enjoyed it!

Hey Marcio, I agree, the transition cuts are awful. I'm not very good at video editing. :)

Yea, I was about to comment this too. Too bad because she was making an excellent point near 26:30.
There is a segmentation fault / the overflow flag in the status register becomes '1'. Depending on the ISA, the next instruction can point to a state where the user now has unfettered control (or the PC just resets to 0x00000000) either of which is and undesired security breach. A beautiful exposition deprived of its rightful denouement!!

You can find them on the left (they were uploaded in the middle of the talk)

There's a link to download a pdf of the slides on the left hand side of the page.

Hi Dan, thanks for your feedback. Glad to hear you were able to pick up the concepts quickly. The audience of this conference has different levels of technical experience, which is why I decided to explain it in a way that most people can understand, even if they lack knowledge in assembly. I hope you were still able to get something out of this talk. :)

I feel dumb. I wouldn't have been able to understand it if it was faster. Great talk! looking forward to the slides.

There's a link to download a pdf of the slides on the left hand side of the page.

Thanks! You can find the slides are on the left

Hi Piersh,
Yes, my first book will be a deep dive into understanding assembly and reverse engineering compiled binaries. The second book will cover various vulnerability classes, including unsafe functions (in C and assembly view) and their safer versions. It will also contain an in-depth overview of Arm exploit mitigations, how they work, what they protect against, and how hackers bypass them. The target audience for these books is both, security researchers and embedded systems developers.

You can find the slides on the left hand side

Hi Cameron, the tool you are seeing in that slide is called IDA Pro. It's a disassembler for translating compiled binaries into assembly/disassembly. If you are looking for a disassembler, I would suggest you get Ghidra (free) since IDA Pro is very expensive.