yonasabeselom
BSc CS | IT Dip • Independent Security Researcher focusing on low-level storage architecture and ASIC/firmware interactions.
I am the architect of the Abeselom ASIC-Direct 50 (AAD... Show moreBSc CS | IT Dip • Independent Security Researcher focusing on low-level storage architecture and ASIC/firmware interactions.
I am the architect of the Abeselom ASIC-Direct 50 (AAD-50) data sanitization specification—an open-source, firmware-enforced protocol designed to bypass fundamentally flawed vendor "Crypto Erase" commands. I recently contributed the core hardware-verification logic for this protocol into the global Linux `nvme-cli` master branch, closing a 15-year vulnerability in SSD data destruction.
My mission is to secure highly sensitive global data while drastically reducing e-waste by allowing enterprise NVMe drives to be safely repurposed rather than physically shredded.
✉️ yonas_abeselom@protonmail.com Show less
Hardware Security
•
Data Sanitization
•
NVMe
•
Solid State Drives (SSD)
•
ASIC Architecture
•
Digital Forensics
•
Cryptography
Deep-dive forensic analysis of NAND flash wear out and multi-cycle physical data destruction under the AAD-50 architecture. Currently refining hardware-level verification loop methodologies to bypass unreliable vendor firmware and optimize cryptographic key destruction protocols on modern enterprise NVMe SSDs.
* Author & Creator of the Abeselom ASIC-Direct 50 (AAD-50) data sanitization specification.
* Successfully designed and contributed core hardware-verification logic into the official Linux NVMe toolchain (`linux-nvme/nvme-cli`) master branch to eliminate silent vendor firmware failures.
* Developed an open-source, GPL-licensed reference implementation bridging advanced forensic erasure protocols with standard third-party utility deployment pipelines.
I design protocols that violently exhaust SSD silicon cells—specifically to save millions of drives from physical e-waste shredders. Also, I managed to close a 15-year-old global storage security gap in just 14 days from my desk in Addis Ababa.
"Never trust the vendor firmware's 'Success' flag. If the silicon can't cryptographically prove the data is destroyed, it isn't."
| Aug | Sep | Oct | Nov | Dec | Jan | Feb | Mar | Apr | May | Jun | Jul |
| Mon | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| Tue | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| Wed | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| Thu | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| Fri | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| Sat | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| Sun | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |