Lately, I’ve been diving deeper into Validity Proofs and Zero-Knowledge (ZK) circuits. It's fascinating stuff, especially with its relevance to scaling solutions like the zkEVM (zkRollups). I wanted to jot down some thoughts, examples, and potential vulnerabilities / attack vectors – partly notes for myself, partly sharing my research. The core idea is proving a computation happened correctly, often without revealing all the inputs, which is key for both privacy and scalability.

The Basics: Sorting Numbers (From Code to Constraints)

Let's start with a familiar task: sorting three numbers, A, B, C.

In Python, it's procedural:

# Assume A, B, C are defined
if A > B:
  A, B = B, A
if A > C:
  A, C = C, A
if B > C:
  B, C = C, B

# Now A, B, C are sorted
print(A, B, C)

This code executes the sort.

Now, think about proving this sort happened correctly using a ZK circuit, similar to how computations are verified in various Ethereum Layer 2 networks. We shift from how to sort to enforcing properties of the result.

// Circuit: SortVerifier
input: A, B, C // Public inputs

// Witness: A', B', C' (Provided by the ZK prover)
// These represent the claimed sorted output

// Constraint 1: Permutation Check
// Ensures the output contains the same elements as the input
enforce({A', B', C'} is a permutation of {A, B, C})

// Constraint 2: Ordering Check
// Ensures the output is actually sorted
enforce(A' <= B')
enforce(B' <= C')

output: A', B', C' // The claimed sorted values

The key difference? The circuit defines constraints. These enforce statements are the heart of it – they get compiled down into polynomial equations or other mathematical forms that the underlying ZK-SNARK or ZK-STARK system uses. The prover finds the witness values (A', B', C') that satisfy these constraints and generates a compact ZK proof. The verifier (e.g., a smart contract on L1 for a zkEVM rollup) just needs to check this proof against the public inputs and the circuit definition, without re-executing the sort.

Our goal is to design constraints such that:

1. Valid executions always satisfy all constraints (allowing a proof).

2. Invalid executions can never satisfy all constraints (preventing a proof).

A More Involved Example: Data Validation in ZK

Let's apply this to data validation. Imagine validating a data structure h composed of 'B' and 'V' elements (max 5 of each, maybe zero).

Step 1: Decomposition Circuit

Break down h – the prover provides the components as witness data.

// Circuit: Decomposer
input: data_structure h // Public input

// Witness: B[], V[] (Private data provided by prover)
output: elements_B B[], elements_V V[]

// Constraint: h must be composed *only* from the provided B and V arrays
enforce(h is composed from B[] and V[]) // Constraint on inputs & witness

Step 2: Element Validation Circuit (Type B)

Check each 'B' element against a property, say is_valid(b). This involves state transitions, much like stepping through execution traces in a zkEVM.

// Circuit: CheckerB
input: elements_B B[] // Could be output from Decomposer

// Uses intermediate variables (part of the witness)
// Assume max 5 elements

for i in range(5) {
  // Intermediate witness: flag_i, current_b_i, remaining_B_i+1
  // State B_i transitions to B_i+1

  // Constraint: Set flag based on whether B_i is non-empty
  enforce(if B_i is nonempty then flag_i is true, else flag_i is false)

  // Constraint: Pop element if flag is true
  enforce(if flag_i is true, then (current_b_i, B_i+1) = pop(B_i))

  // Constraint: Check validity if flag is true
  enforce(if flag_i is true, then is_valid(current_b_i) is true)
}

// No explicit output; satisfaction of constraints IS the result.
output: None

These intermediate variables (flag_i, current_b_i, etc.) are crucial parts of the witness the prover must generate. They don't exist in the original Python code but are necessary to link the steps together arithmetically for the proof system.

We'd need a similar CheckerV circuit.

Step 3: The Main Validation Circuit (Composition)

Combine the circuits. fit(circuit, input, output) means the inputs/outputs satisfy that circuit's constraints. This composition is fundamental in complex ZK systems like zkEVMs, where proofs for individual opcodes or steps are combined to prove a whole transaction or block.

// Circuit: MainValidator
input: data_structure h // Public input

// Intermediate witness: B[], V[] from Decomposer
intermediate: elements_B B[], elements_V V[]

// Constraint 1: Decompose h correctly using Decomposer circuit
enforce(fit(Decomposer, h, (B[], V[])))

// Constraint 2: Check B elements if needed, using CheckerB circuit
enforce(if B[] is nonempty, then fit(CheckerB, B[], ()))

// Constraint 3: Check V elements if needed, using CheckerV circuit
enforce(if V[] is nonempty, then fit(CheckerV, V[], ()))

output: None // Validity proven by the existence of the ZK proof itself

Why output: None Still Makes Sense

In ZK proofs, you don't typically get a boolean "true/false" output from the circuit logic itself. The ZK proof is the output:

• If the prover can generate a valid proof that the verifier accepts, it means all constraints were satisfied for the given public inputs and the (potentially private) witness. The statement is implicitly "true".

• If no such proof can be generated (because constraints conflict), the statement is implicitly "false".

Here's a point to consider:

Look at CheckerB / CheckerV and MainValidator. Assumption: max 5 elements each. Where's the potential bug in this setup?

Pause and think... what if the input data violates the assumptions?

…

Consider the loop boundary

…

Have an idea?

The potential vulnerability here is related to assumptions. The bug hinges on that "max 5 elements" assumption. What if the actual input h can yield 6 'B' elements, and the 6th one is invalid (is_valid(b6) is false)?

Our CheckerB only loops 5 times. It checks b0 through b4 and stops. The 6th invalid element b6 is never examined. A prover could still potentially satisfy all constraints for the first 5 steps and generate a proof, effectively vouching for an invalid h.

This is a soundness bug. An invalid state/input can lead to an accepted proof. In a zkEVM context, this would be catastrophic – allowing invalid transactions or state changes to be finalized on L1.

The "Fix" and its Trade-off

What if we add enforce(B5 is empty) to CheckerB? Now, the 6-element invalid input fails the check. Good.

But... what if a valid h genuinely has 6 valid 'B' elements? Now, our modified circuit cannot prove this valid input, because B5 won't be empty.

This is a completeness bug. A valid state/input cannot be proven. For a zkEVM, this means valid transactions could be unfairly rejected or censored. Balancing soundness and completeness under all input conditions is critical.

A ZK Processing Pipeline

Let's model a simple processing pipeline, analogous to proving sequential operations in a zkEVM (like executing EVM opcodes one after another). Max limit 5 again.

Inputs: raw_B[], raw_V[]

Circuits:

1. ProcessorB: Processes raw_B[] -> cooked_B[]. (Think: Prove execution of some function/opcode)

2. ProcessorV: Processes raw_V[] -> cooked_V[].

3. Assembler: Combines cooked_B[], cooked_V[] -> output_H. (Think: Prove final state assembly)

// Circuit: ProcessorB
input: raw_elements_B rB[]
// ... (loop 5 times, process rb_i -> cb_i, push to cB) ...
// Constraints define the state transition for each step
enforce(if flag_i is true, then cb_i = process_element_B(rb_i)) // The core logic
enforce(if flag_i is true, then cB_i+1 = cB_i.push(cb_i)) // State update
// ... other constraints for flags, popping, empty checks ...
output: cooked_elements_B cB[]

// Circuit: ProcessorV (Similar)
input: raw_elements_V rV[]
output: cooked_elements_V cV[]

// Circuit: Assembler
input: cooked_elements_B cB[], cooked_elements_V cV[]
enforce(output_H is assembled_from(cB[], cV[])) // Final check
output: final_structure output_H

The Main Pipeline Circuit (Composition)

This circuit proves the correct sequence and data flow between the processing steps.

// Circuit: MainPipeline
input: raw_elements_B rB[], raw_elements_V rV[] // Initial state/input

// Intermediate witness: cB[], cV[] (Results of processing steps)
intermediate: cooked_elements_B cB[], cooked_elements_V cV[]

// Constraint: Prove ProcessorB execution if needed
// Recall: fit(Circuit, inputs, outputs) checks constraint satisfaction
enforce(if rB[] is nonempty, then fit(ProcessorB, rB[], cB[]))
// Add constraint: if rB[] is empty, enforce cB[] is empty too?

// Constraint: Prove ProcessorV execution if needed
enforce(if rV[] is nonempty, then fit(ProcessorV, rV[], cV[]))
// Add constraint: if rV[] is empty, enforce cV[] is empty too?

// Constraint: Prove Assembler execution using intermediate results
enforce(fit(Assembler, (cB[], cV[]), output_H))

output: final_structure output_H // Final proven state/output

Now, let's examine the pipeline:

Focus on this processing structure. Assume process_element_B, process_element_V, assembled_from are correct in isolation.

Where might a bug lie in the composition or state handling between these provable steps?

It's not the length bug again. Think about what the prover supplies and what constraints ensure the integrity across the steps. This kind of inter-circuit consistency is a major challenge when building complex systems like any of the various Ethereum Layer 2 networks.

(Hint: What guarantees that the cB[] used by the Assembler is actually the one produced by ProcessorB?)

The potential issue here is subtle and relates to the composition of these circuits. Think about the guarantees (or lack thereof) regarding data passed between them.

Can you spot the bug?

(Since this is an open scenario, you might find some answers that seem reasonable. However, if you're not 100% confident in your answer, it's likely you haven't found the one I hope you to find.)

That's the brain dump for now! Building robust ZK circuits, especially for something as complex as a zkEVM, requires meticulous handling of constraints, witness data, assumptions, and the composition of proofs. It's where cryptography, logic, and software engineering meet security.

zkevm.dev

However, Cursor typically auto-updates, and the official website doesn't always provide easy access to older installers or even the latest installers immediately upon release. This can be frustrating if you encounter a bug in a new version, prefer an older UI, need a specific feature set, or simply can't find the download link easily.

This post aims to solve that problem by serving as a living archive of official download links for various Cursor AI versions. Whether you need to downgrade, rollback, or simply find a specific stable release, you should find the links you need here for Mac, Windows, and Linux.

What is Cursor?

Cursor is an innovative code editor built upon the foundation of VS Code but heavily modified to prioritize AI integration. It helps developers write, understand, debug, and refactor code faster using built-in AI chat, code generation, and analysis tools. Learn more at cursor.com.

Why This Archive Exists (And Why You Might Need It)

Maintaining this archive / list is crucial because:

1. Official Older Versions Are Hard to Find: Cursor's site focuses on the latest release.

2. Release Access: Sometimes even the newest links aren't immediately prominent or easy to locate for all users after a release.

3. Stability: Rollback to a known stable version if a new release introduces issues.

4. User Preference: Stick with a version whose UI or features you prefer.

5. Bug Avoidance: Downgrade to avoid specific bugs present in a newer version.

6. Controlled Updates: Manually installing allows you (at least temporarily) to control your version, although you may need to manage update settings to prevent auto-updates if you wish to stay on an older version long-term.

This archive empowers users to choose the exact Cursor AI version that fits their needs.

Cursor Changelog

For the most detailed release notes, always consult the Official Cursor Changelog.

Important Security Notice

Your security is paramount. Download links have not been altered in any way:

• ✅ Official Links: All links compiled here point directly to official binaries published by the Cursor team (hosted on downloads.cursor.com or downloader.cursor.sh).

• 💾 Backups: Before installing any version (older or newer), it's strongly advised to back up your Cursor settings and critical projects. Better safe than sorry!

Official Cursor Version Download Archive

Find the version you need below. Use Ctrl+F or Cmd+F in your browser to quickly search for a specific version number (e.g., 0.48.7).

Cursor’s AI features are a game-changer, supercharging development on top of the familiar VS Code base. That intelligent code completion, the quick refactoring, the chat-based assistance – it feels like magic... until the magic runs out.

For Linux users running the AppImage version, there's a common hurdle: the free trial limit. Hit that quota (currently seems to be 3 accounts) tied to your unique machine ID, and you're suddenly staring at that frustrating message:

You’ve exceeded the number of free trial accounts allowed for machine-id: 12345XXXXX-XXXXXXX…

Suddenly, your options narrow:

1. Jump through hoops setting up your entire dev environment on a new machine and enjoy a few more free trial accounts before having to do it all over again (assuming you even have access to an unlimited number of dev servers).

2. Shell out for a subscription, (around $384/per user/per year at the time of writing).

or watch your powerful AI assistant revert to a standard VS Code experience.

Sound familiar? I hit this wall too. Faced with losing the AI capabilities or paying up, and considering Cursor's relationship with the open-source community, I got curious. How exactly does Cursor's AppImage identify a machine? Could that mechanism be... adjusted? After some digging into the AppImage internals, I found that the answer was yes. The vulnerability involves more than just clearing config files, touching on how the application itself references system identifiers.

The good news? I've automated the entire reset process into a Python script. This post is your deep dive into how that script works, exploiting the way Cursor handles machine IDs to give you a fresh start with a single command, and how you can use it yourself. Let's get started.

II. What is a Machine ID? How Cursor Identifies Your Machine

Software often needs a way to distinguish between different installations or machines. On Linux, a common system-wide unique identifier is found in /etc/machine-id. Applications might read this file directly or use libraries that access it.

Cursor, based on its configuration file (storage.json), appears to use several identifiers:

• telemetry.machineId: Likely a primary identifier for telemetry.

• telemetry.macMachineId: Another ID, potentially mimicking a MAC address format.

• telemetry.devDeviceId: Seems like a standard device identifier (UUID).

• telemetry.sqmId: Another UUID, often related to software quality metrics.

These values are stored in ~/.config/Cursor/User/globalStorage/storage.json. If Cursor also uses the static /etc/machine-id directly within its code, simply changing storage.json might not be enough for a complete identity reset. The script I developed addresses both the stored configuration and how the application determines one of these IDs internally.

III. Under the Hood: How the Script Works

The script tackles the machine ID reset with a two-pronged attack / approach: it generates new IDs and updates the configuration file, and it patches the Cursor application code within the AppImage itself.

Part 1: Refreshing the Configuration (storage.json)

1. Generate New IDs: The script uses Python's uuid module to create fresh, random identifiers:

   • A long random ID for telemetry.machineId (combining two UUIDv4 hex strings).

   • A MAC-like ID for telemetry.macMachineId (using parts of a UUIDv4).

   • Standard UUIDv4s for telemetry.devDeviceId and telemetry.sqmId.

2. Locate & Backup: It finds the storage.json file in the standard Cursor config path. Crucially, it creates a backup (storage.json.bak) before making any changes.

3. Update JSON:

   • It reads the existing JSON data.

   • It updates the values for the four specific keys (telemetry.machineId, telemetry.macMachineId, telemetry.devDeviceId, telemetry.sqmId) with the newly generated IDs.

   • It offers an option to use the external command-line tool jq for this update if it's installed and the user prefers it (as jq can sometimes be more robust for complex JSON manipulation via CLI).

   • If jq isn't used or available, it falls back to Python's built-in json module to write the updated data back to storage.json, ensuring proper formatting.

Part 2: Patching the Application (AppImage Internals)

This is the more invasive, but potentially necessary, step.

1. Extract AppImage: The script runs the Cursor AppImage file with the --appimage-extract argument. This unpacks the entire application into a temporary directory, typically named squashfs-root.

2. Modify JavaScript: It targets specific JavaScript files within the extracted application core, namely:

   • squashfs-root/usr/share/cursor/resources/app/out/main.js

   • squashfs-root/usr/share/cursor/resources/app/out/vs/code/node/cliProcessMain.js (Note: These paths might change in future Cursor versions)

3. Apply Regex Patch: Using Python's re.sub (regular expressions), it searches these files for code patterns that look like string literals containing /etc/machine-id (e.g., ".../etc/machine-id..."). It replaces these occurrences with the literal string "uuidgen".

   • Why? This changes Cursor's behavior. Instead of trying to read the static system ID from /etc/machine-id, the modified code will now execute the uuidgen command whenever it needs that specific ID. uuidgen generates a brand new random UUID each time it's run, effectively decoupling this part of Cursor's identification from the static system ID.

4. Repack AppImage: The script uses the appimagetool utility (it downloads a compatible version using requests if not found at /tmp/appimagetool) to repack the modified squashfs-root directory back into an AppImage. This newly created AppImage overwrites the original one provided by the user.

Behind the Scenes: Helper Functions

The script also includes several helper functions: argparse to handle the --appimage command-line argument; os, pwd, and shutil for file operations (path validation, finding home dir, copying backups, checking for uuidgen/jq); psutil to find and forcefully kill any running Cursor processes before making changes (to prevent conflicts); and time.sleep for brief pauses.

IV. Get Started: Running the Reset Script

Ready to give it a try? Here's how:

Prerequisites: What You'll Need

• A Linux environment.

• Python 3 installed.

• The Python libraries psutil and requests. Install them if needed:

    pip install psutil requests
  

• Your downloaded Cursor AppImage file (e.g., Cursor-0.xx.x.AppImage).

  You can download the official Cursor AppImage here

• The uuidgen command available (usually installed by default on most Linux distributions).

• (Optional) The jq command-line JSON processor if you want to use that update method.

Here is the complete Python script cursor_reset.py):

Step-by-Step Guide

1. Save the Script: Copy the Python script code (you can copy it directly from the gist embed above 👆) and save it to a file, for cursor_reset.py.

2. Close Cursor: Ensure Cursor is completely closed. The script tries to kill processes, but it's best practice to close it manually first.

3. Open Terminal: Launch your terminal.

4. Navigate: Use cd to go to the directory where you saved cursor_reset.py.

5. Run the Command: Execute the script, providing the path to your Cursor AppImage:

    python cursor_reset.py --appimage /path/to/your/Cursor-0.xx.x.AppImage
   

   (Replace /path/to/your/Cursor-0.xx.x.AppImage with the actual path).

6. Follow Prompts: If jq is detected, the script will ask if you want to use it (Y/N).

7. Wait: The script will output its progress (killing processes, extracting, modifying, repacking). Extraction and repacking can take a minute or two.

8. Check Success Message: Look for the "Successfully updated all IDs" message and the list of new IDs printed at the end.

9. Launch Modified AppImage: Run your modified Cursor AppImage file as usual. It should now appear as a fresh installation regarding these specific IDs. Most importantly, you should now be able to create and use new free trial accounts over and over again on the same machine, even after hitting your initial trial account limit.

   Remember to run the Python script to patch your Cursor AppImage anytime you:

   • Exceed your machine's trial account limit

   • Update or download a new Cursor AppImage version.

Quick Notes:

• The script will attempt to kill running Cursor processes. Save your work first!

• It modifies your original AppImage file in place. Consider backing up the original AppImage beforehand if you're cautious.

• A backup of your configuration is created (storage.json.bak) in the same directory as storage.json.

V. Behind the Code: Design Decisions

Why go through the trouble of patching the AppImage?

Why Patch the AppImage Directly?

Simply changing storage.json is not sufficient. This leads me to believe that Cursor's code also directly reads the static /etc/machine-id (or uses a library that does) for identification. The patch intercepts this retrieval within the application code, forcing it to use the dynamic uuidgen command instead, making that part of the identity reset more robust.

Python: The Right Tool for the Job

Python excels at this kind of task: managing files (os, shutil), handling JSON (json), running external processes (subprocess, psutil), making web requests (requests), and text manipulation (re).

Adding Robustness (jq, psutil, requests)

Using psutil provides a reliable way to find and terminate processes. Offering jq gives an alternative, often very robust, method for CLI JSON editing. Downloading appimagetool via requests makes the script more self-contained for users who don't have it installed system-wide.

VI. Read Before Running: Risks and Responsibilities

Before you run this script, please understand:

• Potential Instability: Modifying application internals (the JavaScript files) carries risks. Future Cursor updates might change the code structure, breaking the script or causing the modified AppImage to become unstable or fail to launch. Use at your own risk.

• App Updates: When you download a new Cursor AppImage version, this patch will be gone. You will need to re-run the script on the new AppImage file if you want to apply the changes again.

• Terms of Service: Using scripts like this specifically to circumvent trial limitations or usage restrictions almost certainly violates Cursor's Terms of Service. Be aware of this. This post provides the script for technical exploration and understanding; how you use it is your responsibility.

• Linux AppImage Only: This script is tailored specifically for the Linux AppImage distribution of Cursor. It relies on Linux paths (/etc/machine-id), AppImage structure, and tools (uuidgen, appimagetool). It have not tested it on Windows, macOS, or other installation methods.

• Security Note: The script downloads appimagetool directly from its official GitHub releases page if needed. While this is standard practice for obtaining appimagetool, be aware you are downloading and executing code from the internet.

VII. Wrapping Up

This Python script offers a way to reset various identifiers (machine IDs) used by Cursor Linux AppImage, employing a combination of configuration file updates and direct patching of the application code. It automates a process that would be tedious and error-prone to do manually.

It serves as an interesting proof of concept for a vulnerability I found within Cursor’s Linux AppImages as well as exploiting that vulnerability and effectively modifying application behavior through Python scripting. However, remember the caveats – particularly regarding potential instability and the Terms of Service. Use it responsibly and understand the risks involved.