What's reverse engineering like on a Mac? Have you ever written about it? I had a lot of experience reverse engineering things on windows (win32 + x86, before 64bit was a thing) using OllyDbg and patching binaries and/or (ab)using dlls. If I had to use windows again and wanted to customize something, I'd probably use windhawk nowadays [0].
On Linux, I can just compile software myself if I need to make changes. But usually most software is configurable enough that I don't need too.
On OSX, I feel like I'm helpless. I've found very little people writing about their experiences, the tools they use, their workflows, the reverse engineered data structures etc. Can you share how you approached this?
The fact that title bars on OSX aren't a fixed size drives me crazy every single day. I looked into it briefly and realized somehow everything I know about other platforms is basically useless.
Here is my 2 cents:
You can run these days macOS as a virtual machine. I have some experience reverse engineering iMessage. Here I only needed to look into the network requests with some SSL pinning removal.
There are some decompiled libraries of Apple's libraries so it helps. Many tried to reverse engineer macOS/iOS before so there is a helpful amount of knowledge out.
I think the best way is just to open up a decompiler program and just start RE. The decompiled source code contains some metadata such as function names so it is readable.
I have not written about it yet. I use Hopper (https://www.hopperapp.com) to disassemble related binaries and frameworks. It's a great way to explore whats actually happening within macOS or Apple apps.
My current workflow is to run Hopper, export assembly files and then throw various agents (Gemini, Claude etc) at them to learn more or validate my theories. It's surprisingly effective! Maybe I'll write about it.
Please do!
> The fact that title bars on OSX aren't a fixed size drives me crazy every single day.
Are you talking about standalone titlebars or are you including merged/unified titlebars+toolbars? Plain titlebars have a single height and merged unified toolbars have a little bit of variance but not a lot.
Any significant variance beyond those is due to third party developers hiding the standard window chrome and drawing their own. You could probably tweak NSWindow instances to bring back the standard chrome, but it’s going to look strange since it’ll show in addition to the custom chrome.
I am so uneducated that I cannot even answer your question properly. But for example, the default terminal in OSX has a really nice thin bar. VSCode/Cursor have a _slightly_ thicker one. Google Chrome and Firefox are huge. The red/yellow/green buttons also don't have a consistent position between those applications.
Do you happen to know which are custom chrome and which are "unified"? It didn't occur to me that other programs could be drawing their own chrome, since they look _mostly_ native(at least to me). On windows, if something was using custom stuff it would just look completely different (i.e winamp).
I guess part of the problem is that I've never done native OSX development, so I don't know what the APIs or native toolkits are like.
Safari is one example of a native AppKit “unified” titlebar+toolbar, as is the Finder.
And yep, all those listed (VS Code/Cursor, Chrome, and Firefox) are examples of fully custom third party window chrome, which is why they’re so variable. A lot of cross-platform software does this. It’s worth noting that Firefox at least lets you toggle on the standard titlebar — right click the toolbar, click “Customize Toolbar…”, and toggle the “Title Bar” checkbox in the bottom left corner.
Heh, so really I just need to go with the Linux approach and recompile everything with "fixed" titlebars.
For some reason it didn't occur to me that it's non native since they do such a good job at matching the native stuff.
On a side note, I'm glad I don't use finder or safari, because those titlebars are even larger than Chrome and Firefox! Absolute insanity.