take 2026-08-09 by Stephan Schielke / sc7a516f / llm.md

Reverse Engineering and Cracking Sublime Text 4

Why I cracked Sublime Text 4

Most devs know Sublime as a "free" text editor / IDE. Technically, Sublime Text can be evaluated for free but requires a license for continued use, which IMO is more than fair. However, I wanted to write an OSS Sublime Text 4 package (extension/plugin), and naturally wanted to use the latest version of the SDK to make it future-proof. With version 4205, after a decade, Sublime finally upgraded the Python plugin host to version 3.14. That is a huge jump, and it breaks a lot of contracts and interfaces between Sublime Text and packages. So, to properly test my new package, I had to install, run and test it against version 4205 — which is a dev version. Unbeknownst to me, ALL Sublime dev versions require a license to start and are not covered by the "evaluation" exception.

That left three choices:

  • Wait until version 4206 to get the new Python 3.14 SDK change
  • Write the plugin against soon-to-be-deprecated SDK functions
  • Buy a license to write an open-source package

I chose the fourth option: reverse-engineer the binary and write a crack and patcher, so I could test my package against the latest SDK.

Cracking Sublime Text 4

There are dozens of patchers for Sublime Text, but all of them are "dumb" and only ever provide a one-time solution for one specific Sublime binary. Given the massive internal core changes planned for Sublime Text 4205+, none of the existing patchers worked for such a recent (and dev) version. The previous reverse-engineering attempts of others did, however, offer some insight into how to approach the problem. Most binary patchers changed the return value of the "Enter your license" window so it would be accepted as valid.

I then had a look at the Executable and Linkable Format (ELF) binary and extracted all raw string literals embedded in it, using llvm-strings and llvm-objdump, to find anything related to the license window. Next, pyelftools and objdump helped me identify the individual functions involved in the registration and license-check processes. Then I wrote a little helper using strace to trace what happens when you start the software and enter a license.

Equipped with that information, I sent out an Large Language Model (LLM) agent to give me a visual representation of the program flow, the function signatures involved, and the expected return values. That is where most people stop: binary patching by hand, overwriting some hex values to change those "expected" values and trick the software into thinking it is registered.

Sublime Text 4 About dialog showing Registered status on Build 4206 after patching
Post-patch state — the About dialog reports "Registered to / Unlimited User License" on Dev Channel Build 4206.

However, I noticed Sublime Text also tries to "phone home" for license checks, version update checks, and crash reports. So I decided to dig deeper and find ways to block those requests as well.

Going from dumb patcher to universal crack

I had already built a helper script to download any main or dev binary from scratch, so I could iterate over my hex changes always starting from a fresh binary. That raised the obvious question: why not patch ALL versions and make this future-proof (and history-proof)?

So I sent out an agent to locate signature patterns and caller fingerprints for the relevant patch sites structurally, instead of using hardcoded offsets. That makes the patcher build-agnostic across builds 4176 through 4206 (30+ builds, multiple architectures).

The patcher also supports optional hardening flags: --hosts (blocks phone-home), --no-update (silences the update popup), and --no-crash (prevents minidump upload). None of these touch the license patch itself; they are independent opt-ins.

How to use

uv run st4patch \
    --src 4206 \
    --out /tmp/sublime_text.patched \
    --hosts --no-update --no-crash

The pipeline:

  1. Locate — five patch sites resolved via byte signatures (not hardcoded offsets)
  2. Patch — NUL-padded, size-preserving rewrites at each site
  3. Verify — self-checks patched bytes against expected signatures
  4. Report — MD5 hash + per-site status printed to stdout

The locator uses Capstone disassembly to fingerprint call-site prologues and resolve the valid-return convention per build. Below build 4176 the binary shape changes completely; above 4206 the approach should hold, but is untested.

Links

Glossary (9)
Platform
GitHub (GH) Web-based Git hosting platform and developer collaboration service, acquired by Microsoft in 2018.
Tool
Capstone Multi-architecture disassembly framework that turns raw machine code back into readable assembly instructions. Widely used in reverse engineering, binary analysis, and security tooling.
llvm-strings LLVM utility that extracts printable string literals embedded in a binary. The LLVM counterpart to GNU strings, often the first step when mapping out what a closed-source binary does.
pyelftools Pure-Python library for parsing and analysing ELF binaries and DWARF debug information. Gives programmatic access to sections, symbols, and relocations without shelling out to binutils.
strace Linux diagnostic tool that traces the system calls and signals a process makes. Used to observe what a program actually does at runtime — file access, network calls, and process control.
Language
Python High-level programming language known for readability and extensive standard library. Dominant in data science, automation, scripting, and increasingly used for security research and exploit development.
Standard
Binary patching Modifying a compiled program directly at the byte level, without access to its source code. Used for hot-fixes, compatibility shims, and reverse engineering — typically by rewriting specific instructions or return values in place.
Large Language Model (LLM) AI model trained on large text datasets that generates human-like text responses. Examples: GPT, Claude, Gemma, Llama. Used for coding assistance, text analysis, and increasingly for autonomous system administration.
Format
Executable and Linkable Format (ELF) Standard binary file format for executables, object code, and shared libraries on Linux and most Unix systems. Defines how code, data, and symbol tables are laid out so the kernel and linker can load them.
keyboard_command_key
/search for stuff Send a prompt to my LLMs /summarize a page Open a chat Use a /command Send a /dm to my phone Ask the /chat assistant Smash your head against the keyboard Hire me /search for stuff
...
CTRL+K