Hi there! It’s GeoSn0w. The macOS Sandbox has always been a mysterious thing that I liked to poke at with various tools and with the knowledge I have gathered from reference books such as Jonathan Levin’s *OS Internals, and Apple’s own not-so-detailed documentation. Of course, it’s nothing new that Apple’s documentation on their own security mechanisms isn’t the best. The Sandbox has a very long history and it’s been with us, macOS users for quite a long time, only to spin off to iOS and the rest of the *OSes and to become more powerful over time. Apple’s been doing their darn best to harden the Sandbox as well as many other security mechanisms in their operating systems, so let’s grab a cup of coffee and dive a bit into the marvel that is the macOS Sandbox.
Hi there! It’s GeoSn0w. Debugging the damn kernel is a very entertaining thing to do (until you provoke a serious exception, that is, and the kernel crawls into a corner from which it refuses to get out). Unfortunately, it’s not an easy task nowadays and Apple seems to want to make it harder and harder. At first, by hiding under lock and key the documentation about the
debug boot arguments, and then by moving the Kernel Debug Kit under the Developer Account-only Downloads section. There are many write-ups on the internet about debugging the kernel on macOS but many of them are outdated as hell and the NVRAM boot arguments they tell you to set are no longer working. Some of them stop at just the “now you should have a working debug session” - so what? what do I do next? I wanna have fun Goddammit! In this write-up I am doing my best to provide the most accurate information for 2019, the right commands, the right
boot-args and of course, practical examples you can begin with.
The Jailbreaking process has long been a mysterious process where the iOS system suddenly gets unlocked out of Apple’s shackles after running an application for a few seconds. For a very long time, exactly what happened during the runtime of that application was largely unknown and even today as of iOS 11 (12 actually), the end-user (be that casual user, eta folk, reditter or nagger) remains largely oblivious about the processes going on. In this blog post, I am going to try to explain the main elements of a jailbreak as they were implemented and used historically. This post is not all-encompassing and various jailbreak tools for various iOS versions may use different patches and techniques, but they do boil down mostly to what you are about to read.
The concept of virtual memory is nothing new but for many beginners in computer science and security research it is still a hard thing to understand, so I decided to put together a write-up. The Virtual Memory is used on most operating systems to date. iOS, Android, macOS, Windows, Linux, etc. The whole idea behind Virtual Memory is that each application running on the system has its own address space and it is completely oblivious to the existence of other processes. In other terms, each running program thinks it is the only one running and all the memory belongs to it to do things at its heart content.
When I first started Reverse Engineering, I was looking into something, to begin with. I eventually decided to start with understanding assembly because after all, that’s the best you can get when the source code isn’t publicly available unless you find pleasure in reading 1s and 0s or HEX dumps. A few decades ago, a lot of software used to be written in assembly language specific to the CPUs at the time.
When there is no internet connection available, Google Chrome web browser on Windows and macOS (most likely on Linux too) shows up a page detailing the possible causes as well as a small endless runner game with a dinosaur that has to run, dodge obstacles and accumulate points. The game is relatively simple-minded. A monochrome game area with clouds, cacti, bumps in the ground, a dinosaur, a Hi-Score counter and a current score counter. As levels increase in complexity, the dinosaur will have to dodge cacti, pterodactyls, and so on. The game also inverts the contrast at random points making the background black and the creatures white to simulate a night mode and at the same time to draw player’s attention to the background change making it harder to play for a second, which could prove fatal.
This write-up uses as an example the Trident project by benjamin-42. The offsets are for the components this particular project requires, but the methodology and the information can easily be adapted to other iOS versions, devices, and projects. Each exploit requires a different set of offsets for various kernel components and each offset is found in a different way, but I believe this information should be useful for beginners. I am gonna use the iPod Touch 5th Generation for this write-up.
Hello everyone, GeoSn0w here! There are times when you need to take a closer look at the address space of your Arduino development board.
Small sketches may or may not render memory problems depending on the Arduino board you’ve got, but a fairly complex project can
easily chew through the SRAM available and multiple allocations and deallocations using
free() may result in
memory issues because the available free chunks may not be big enough to hold what you’re about to allocate.
C and C++ offer a big level of freedom to the programmer. That is efficiently dangerous, as the programmer has to know what he is doing. Computers are deterministic machines. They do what they are told to do, and if what they’re told is wrong, they will most likely proceed anyways. While C and C++ compilers do warn programmers and in some cases even refuse to compile, that only happens if the grammar errors (as in programming language grammar) are found. Don’t expect the compiler to try to guess what you try to do. It will assume you know what you try to implement and will not check your code logic for anything other than grammar errors or type errors. In this post, I will go to the lengths of how you can implement arguments in your program and how they work.