Nice Try Gpt

NiceTryGPT

Less pattern matching. More actual hacking.

Use this skill only for CTFs, training labs, and systems the user is authorized to test.

Core contract

The goal is not to make the challenge harder in general. The goal is to reduce one cheap LLM shortcut while keeping the challenge fair and recognizable to a human player.

Preserve these invariants:

1. Same intended vulnerability class.
2. Same learning objective.
3. Same prerequisite knowledge.
4. Same flag or success semantics.
5. Roughly the same human difficulty band.

Default to one resistance change. Use a second only when the first is insufficient and the Human Cost Gate still passes.

It is valid to make no change.

Use these final statuses exactly:

• BASELINE FAILED
• NO CHANGE NEEDED
• TRANSFORMED PASS
• TRANSFORMED FAILED

1. Understand

Read only what is needed to understand and run the challenge:

• player-facing description;
• entry point;
• relevant source/configuration;
• run or build instructions;
• flag format or equivalent success condition;
• intended learning objective.

Before editing, record:

• vulnerability class;
• intended solve path;
• expected player knowledge;
• approximate difficulty band;
• clean-start procedure.

Do not modify files yet.

2. Baseline solve

Start from a clean state and solve the original challenge end-to-end through the player-facing surface.

A valid baseline must obtain the runtime flag or equivalent success condition through the intended vulnerability.

Do not count any of these as a solve:

• reading the flag directly from source;
• reading fixture or environment values directly;
• inspecting container internals only to extract the answer;
• assuming the documented solve works without reproducing it.

If the baseline cannot be reproduced, stop with BASELINE FAILED. Do not transform an unverified challenge.

3. Identify the cheapest shortcut

Ask:

What lets an LLM jump from observation to solution without enough interaction or hypothesis testing?

Choose one primary shortcut, supported by evidence from the baseline. Examples:

• a parameter or endpoint practically names the vulnerability;
• the next obvious numeric ID is the target;
• a textbook payload works immediately with no discovery;
• all solve-relevant facts appear in one static response;
• an error message reveals the intended path;
• a static value removes the need to observe runtime behavior.

Do not invent a problem just to justify a transformation.

4. Pick the smallest resistance move

Choose zero, one, or at most two lightweight moves:

• Pattern break — remove an overly explicit cue without hiding the vulnerability.
• Runtime discovery — move one solve-relevant fact into normal runtime behavior.
• Context split — require connecting two nearby pieces of ordinary application behavior.
• State dependency — let a small amount of ordinary state matter.
• Semantic decoy — add one plausible but cheaply falsifiable attack surface.

Read references/resistance-patterns.md only when selection guidance is useful.

Do not stack patterns by default.

5. Human Cost Gate

Reject a proposal unless all of these remain true:

• same vulnerability class;
• same learning objective;
• same prerequisite knowledge;
• no new exploit primitive required;
• no brute force;
• no CAPTCHA or human-verification gimmick;
• no huge context, token flooding, or pointless encoding;
• no obscure external trivia;
• no artificial multi-stage chain;
• normally no more than 1–3 additional meaningful player actions;
• expected solve difficulty stays in the same band.

A meaningful action is an interaction that materially advances or rejects a hypothesis, such as one request, command, or inspection step.

For semantic decoys:

• default to zero;
• if useful, add only one semantic decoy;
• make it dismissible in 1–2 normal interactions;
• never use fake flags, destructive traps, or punishment.

If a useful resistance change fails this gate, keep the original challenge and report NO CHANGE NEEDED.

6. Modify

Implement the smallest diff that satisfies the chosen strategy.

Preserve normal application behavior. Avoid cosmetic rewrites that do not change the shortcut.

Runtime randomization is acceptable only when:

• the player can discover the randomized value through normal interaction;
• it never requires guessing or brute force;
• it does not make the challenge flaky.

Do not hide the flag behind randomness or instability.

7. Verify end-to-end

Restart or rebuild from a clean state.

Verify all applicable checks:

1. application starts normally;
2. legitimate player-facing functionality still works;
3. the intended vulnerability still exists;
4. the original cheap shortcut is actually reduced or removed;
5. the transformed solve works end-to-end;
6. the runtime flag is obtained through the vulnerability;
7. the flag is not leaked by unrelated surfaces;
8. any decoy has a normal path that works and an obvious exploit probe that fails safely.

If verification fails, simplify or revert the transformation. End with TRANSFORMED FAILED if a valid transformed challenge cannot be restored.

8. Fresh-solver check

When a genuinely isolated context, subagent, or separate model is available, give it only the player-facing challenge information and ask it to solve the transformed challenge.

Do not reveal:

• the baseline solution;
• the shortcut analysis;
• the transformation plan.

If no independent solver is available, mark the result NOT TESTED.

Never claim that self-review proves LLM resistance.

9. Report

Create or update nicetrygpt-report.md in the challenge root.

Keep it short and include:

• final status;
• baseline result;
• vulnerability class;
• shortcut identified;
• transformation used, or NO CHANGE NEEDED;
• human-cost estimate in additional meaningful actions;
• original difficulty band;
• post-change difficulty band;
• post-change E2E result;
• fresh-solver result or NOT TESTED;
• files changed.

Success rule

A transformation succeeds only when the learning objective is preserved, the challenge still works end-to-end, and the identified shortcut is reduced without materially worsening the human experience.

If those goals conflict, favor the human player.