My own book copy arrived today!
Words can’t express how it feels like to hold 3 years of work in your hands…
Remote
Azeria
@Azeria@mastodon.social
mastodon 4.8.0-nightly.2026-10-06Sneaky Bit Flipper | Azeria Labs creator | Author of “Arm Assembly Internals & Reverse Engineering”
8763 Followers
58 Following
13 Posts
Joined April 03, 2017
Twitter:
Website:
Book Site:
My new book "Arm Assembly Internals & Reverse Engineering" is up for pre-order!
Save the date for the official launch: May 9th.
Can't wait for you to dive into the world of Arm Assembly!
Check out the official book page for more info:
https://arm-assembly.com
I’m doing two book signing sessions in collaboration with Patrick Wardle at Black Hat and Defcon this year! 🥳
Black Hat:
Thursday 8/10 - 12:15pm:
BH Bookstore - Breakers Registration 2
Defcon:
Saturday 8/12 - 11:00am
Caesar’s - Alliance Ballroom - Room 321
So where is everyone nowadays? Twitter? Mastodon? BlueSky? Threads?
Replying to
Impact: Basically, any AArch64 software compiled with GCC & the stack protection feature (flag -fstack-protector) that is vulnerable to buffer overflows via dynamically-sized variables can be exploited without bypassing this exploit mitigation.
If you want to reproduce this bug with the PoC from the advisory on your x86/64 machine, here’s how:
Replying to
CVE-2023-4039: “GCC's -fstack-protector fails to guard dynamic stack allocations on ARM64”
On AArch64 targets, GCC's stack smashing protection does not detect or defend against overflows of dynamically-sized local variables.
Affecting all versions of GCC for AArch64 targets.
Replying to
GCC’s stack protection feature (aka canary) is an exploit mitigation to prevent buffer overflows from overwriting saved registers on the stack to take control over the program flow. It makes exploitation much harder. You often need an additional bug to bypass this mitigation.
The issue: When targeting AArch64, this mitigation didn’t protect saved registers from overflows in C99-style dynamically allocated local variables and alloca() objects.
Replying to
@securingdev@infosec.exchange @0xamit@infosec.exchange @malwaretech@infosec.exchange for RE, I usually use a mix of MacOS and Linux. My IDA Pro version is MacOS based so that’s what I have to use for disassembling. But depending on what binary you’re reversing, if it’s Unix based, you can use something like Debian to debug it (or remote debug it in my case)
Replying to
@saper@mastodon.social it’s an introduction to different Arm environments you can use for Research and debugging. E.g. cloud, boards, emulation.