Recent content on A lazy blog
Overview oci2bin converts any Docker (OCI) container image into a single, self-contained executable. It doesn’t require any Docker daemon, no container runtime, and no installation on the target machine as the binary is static. Just copy the file over and run it.
A small tool I built is makethlm , a command-line task runner in the tradition of Make and Just, but where the task body is natural language executed by an LLM.
This is part two of the RSA Public Key Manipulation series . See also Part 1: How to Hide Data Inside RSA Public Keys
This is part one of the RSA Public Key Manipulation series . See also Part 2: Encrypting and Chunking Data in RSA Keys
This is part four of the Certificate Transparency series . See also previous parts: Part 1: Certificate Transparency 101 Part 2: Certificate Transparency Info Leaks Part 3: Certificate Transparency as Communication Channel Introduction Described here is a way to leverage the infrastructure used to store SBOM ( Software Bill of Materials ) certificates in order to distribute messages via the…
This is part three of the Certificate Transparency series . Introduction Described here is a way to leverage the infrastructure used to validate certificates in order to distribute messages through the Certificate Transparency Logs.
This is part two of the Certificate Transparency series . Crtificate Transparency logs are leaking valuable information about companies due to either unfamiliarity or obliviousness from companies’ IT or DevOps teams.
This is part one of the Certificate Transparency series . Certificate Transparency (CT) is a public, append-only logging system for TLS certificates. It was created to make certificate issuance observable so that mis-issuance can be detected quickly and independently. Instead of relying only on trust, CT lets anyone audit which certificates were issued for a domain and when they appeared in a…
1. Operate on root files without sudo password We all know that docker access is basically root access , but examples are critical to understanding.
Below a list of points I believe should be handled when writing shell tools. Exit Status Exit status ( exit(0) or exit(1) ) is the way for letting the caller know the execution has failed.
Refactoring ideas suggested long time ago from previous jobs Libraries are too tightly coupled with each other Libraries should not depend on each other too much, otherwise you have to update all libraries which misses the entire idea of decoupling.
Say we want to measure the number of user space instructions a process is spending at a function. There are number of ways to do so: gettimeofday , times , clock and getrusage , but they give you time and not CPU cycles and not very accurate.
Note: This won’t work anymore, Apple has pretty much disabled any ability to work with kernel extensions. This is just an old blog post. Kext are no longer supported, use System Extensions and similar approach
The compilers Let’s see if we can crash some compilers. python3 -c 'print('{' * 99999)' > test.c && clang test.c Clang SEGFAULT but GCC has made it :)
It’s a known fact (at least to me), that static inline functions in C++ will generate multiple instances of a function if used in a different translation unit (a file, why call it differently?).
Getting current information Get current task with: #include <kern/task.h> task_t cur_task = current_task(); Get current thread with:
Get sleep notification in your IOKit kext IOReturn yourIOKitDriverClass :: powerStateHandler( void * target, void * refCon, UInt32 messageType, IOService * service, void * messageArgs, vm_size_t argSize) { IOPMSystemCapabilityChangeParameters * params; if ( messageType != kIOMessageSystemCapabilityChange ) { // We are not interested in anything other than cap change. return kIOReturnSuccess; }…
Introduction If you ever need to debug a newly (Yosemite) OSX kernel using firewire here is a small tutorial to help you through.