Step 200. Webhacking.kr 16–30 — Creative Combinations of Techniques

Level 3 — Real-World CTF & Advanced Attack Skills | Difficulty ★★★★☆ | Estimated time: 8 hours (two to three days recommended)

Prerequisites: you’ve finished Step 199. The type classification and common routine from the Webhacking.kr 1–15 range are second nature.

What you need: the same tools as Step 199 (browser dev tools, Burp Suite, Python) + the takeaway table and bypass-candidate ledger you made in Step 199.
⚠️ All exercises in this chapter are for your own lab and legal platforms only. Applying them to unauthorized systems is a crime.
Legal practice grounds: Webhacking.kr is a legal wargame officially opened for solving by its operators. Do not use today’s techniques anywhere outside this site’s challenge servers.

From challenge 16 on, the game’s character changes. Problems solvable with a single technique dwindle, and problems demanding combinations of techniques — encoding bypass + SQLi, file upload + session tampering — multiply. A lock that needs two keys turned in order, not one.

This range’s real lesson is training to read "what is this problem asking?" from the problem-setter’s perspective. List the visible defenses first, build a table of bypass candidates, and eliminate them one by one — the more that ledger piles up, the more the answers to never-before-seen problems start showing themselves. Because this is an external platform, server screens are marked as screen examples, and locally verifiable techniques are confirmed with hands-on measurements.

1. Learning Objectives

By the end of this chapter, you will be able to:

List a problem’s "visible defenses," build a table of bypass candidates, and eliminate them
Break down problems layering two or more techniques into stages and conquer them
Use community hints only up to the level of direction, never answers
Reproduce "why that’s the answer" for problems whose solutions you saw, and re-solve them a week later
After finishing the 16–30 range, update your Web-track weakness types

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

Category	Details
Language/environment	Web browser + dev tools, Burp Suite (Repeater-focused), Python (payload generation, encoding)
Today’s techniques	Defense listing, candidate-table elimination, combination-problem decomposition, staged hint usage
Concepts needed	The three layers of filter bypass (character, syntax, transport), combining sessions and authentication, reading the setter’s perspective
Today’s deliverables	16–30 solve log + updated weakness-type table

2-1. Dissecting Combination Problems — Two Locks

Open a problem in the 16–30 range and you’ll experience one technique not going through. For example, the injection works but the filter strips half of it, or you bypassed the filter but the result doesn’t show on screen. This doesn’t mean the technique is wrong — it means the problem has two layers.

The standard procedure for combination problems is decomposition. Split "layer 1: what is blocking? → layer 2: what waits past layer 1?" and solve each as an independent problem. Trying to pierce both layers at once is this range’s greatest time thief.

2-2. Listing Visible Defenses and the Elimination Method

The first deliverable when you open a problem is not code — it’s a defense list.

[Screen example — defense list and bypass-candidate table]
Observed defenses:
  1. Single quote (') input gets stripped
  2. Spaces blocked even as %20
  3. Result not visible in response (only success/failure signals)

Bypass candidates:
  Candidate                       | Layer 1 pass? | Notes
  Double-quote (") substitute     | X             | caught by the same filter
  Backslash escape (\')           | X             | backslash also stripped
  /**/ space substitute           | O             | layer 1 pass confirmed → to layer 2

This table’s value is that "what I haven’t tried yet" is visible at a glance. When you feel blocked, most of the time candidates actually remain.

2-3. Reading the Problem-Setter’s Perspective

Training to read "what is this problem asking?" in reverse. A setter usually tests one concept. Lay out the materials the problem gave — the number of forms, parameter names, the tone of error messages, the challenge title — and the concept being asked reveals its outline.

If a login form and a file upload sit together, the picture is bypassing authentication with an uploaded file; if session issuance and permission checks are split across different pages, the problem asks about the gap between them. The list of materials is the problem’s blueprint.

2-4. Staged Use of Hints

From this range on, acknowledge the existence of community hints but fix the usage stages.

Stage 1: search only up to challenge number + "type" level (e.g., "is 17 in the SQLi family")
Stage 2: if still stuck, up to "direction" level (e.g., "look at the cookies")
Stage 3: never look at the answer payload — if you did, that problem is not an independent solve

For a problem whose answer you saw, you must prove "why that’s the answer" by reproducing it yourself, and it counts as solved only after you succeed at re-solving it a week later. This rule applies as-is in Step 202’s independent-solve check.

3. Follow Along

3-1. Before Entering the Range — Review Your Step 199 Takeaway Table

Before opening challenge 16, skim the takeaway table you made in the last chapter. The types you met in 1–15 (source reading, cookies, encodings, filter bypass) get rearranged as raw materials in 16–30. Your "list of known techniques" is this range’s ammunition store.

3-2. Combination Problem Demonstration — Encoding Bypass + Injection (Screen Example + Local Measurement)

Suppose a problem where a filter blocks the spaces and quotes of ' OR 1=1. The thought process of wrapping the payload in an encoding layer instead of feeding it raw. The payload conversion itself reproduces cleanly locally (measured 2026-09-09, Python 3.12.14):

import urllib.parse
raw = "' OR 1=1-- "
urlenc = urllib.parse.quote(raw)
print(f"Original payload: {raw!r}")
print(f"URL encoded: {urlenc}")
print(f"Restored check: {urllib.parse.unquote(urlenc)!r}")

Original payload: "' OR 1=1-- "
URL encoded: %27%20OR%201%3D1--%20
Restored check: "' OR 1=1-- "

How to read it: if the filter checks "before" URL decoding, the encoded form passes the filter and gets restored at the server. Conversely, if the filter checks after decoding, try double encoding (%2527). Which layer does the checking decides the bypass direction — so in the 2-2 defense list, you also jot down your "checking layer" estimate.

3-3. Problems Where the Response Hides — Creating Signals (Screen Example)

A problem where success and failure show up not as screen text but as subtle differences.

[Screen example — signal observation]
Payload A (false condition): response length 812 bytes, "try again"
Payload B (true condition):  response length 826 bytes, "try again" + one hidden comment line

How to read it: even when screens look identical, response length, response time, status code, and hidden comments can differ. Sending the same request twice in Burp Repeater and comparing "what’s the same and what’s different" is the starting point of Blind-family problems (a Step 137 instinct review).

3-4. Decomposing a Session + Upload Combination Problem (Screen Example)

Let’s decompose a problem that has an upload feature together with a permission check.

[Screen example — decomposition ledger]
Layer 1: upload filter — .php rejected; what about .php5/.phtml/.phP?
Layer 2: post-upload path — is the filename kept as-is, or randomized?
Layer 3: session check — upload works, but does the execution page demand an admin session?

How to read it: design an independent experiment per layer. Whether the layer-1 extension bypass works is confirmed by repeating only uploads in Burp; once a pass is confirmed, only then descend to layer 2. Mix layers in one experiment and you can’t tell which layer blocked you.

3-5. The Reproduction Procedure for Problems Whose Solutions You Saw

The processing procedure for a problem where you ended up seeing the answer.

Cover the solution and write three sentences in your own words about why the answer you just saw is the answer
Build the payload from scratch and pass it through the server — no copy-paste
Write "the difference between my original attempt and the correct answer" in your takeaway table
Set a reminder for a week later, and on that day re-solve with nothing to look at

Success at the re-solve is the evidence of absorption complete. On failure, that type goes onto the weakness list.

3-6. After Finishing 30 — Updating Weakness Types

When you finish the range, update your self-assessment table.

[Screen example — weakness-type update]
Type                 | 1–15 range | 16–30 range | Assessment
Source/comment reading | strong   | strong      | maintain
Cookie/session tampering | strong | medium      | retrain session-fixation family
Encoding chains      | medium     | strong      | growth
Filter bypass        | medium     | medium      | widening candidate layers, in progress
Blind/signal creation | -         | weak        | retry after Step 137 review
Combination decomposition | -     | medium      | layering works; speed is the task

How to read it: the "weak" cells of this table are the addresses of your next study. A type where "oh, it was that?" repeats after reading solutions lacks pattern-recognition data, so every time you read a solution, write down "why couldn’t I think of this."

3-7. Internal Allocation of the 2-Hour Cap

Even a 2-hour-per-problem cap, left to flow, easily gets spent all on one hypothesis. Fix the internal allocation.

0:00–0:20  Recon — write the materials list: source, parameters, cookies, JS
0:20–0:40  Complete the defense list + bypass-candidate table
0:40–1:50  Candidate elimination experiments (no more than 20 minutes per candidate)
1:50–2:00  Wrap-up — record eliminated candidates and the first attempt for the next retry

How to read it: twice as wide as the 1–15 range’s cap (30 minutes–1 hour), but the structure is the same. Spending the first 40 minutes on recon and table-building is this range’s habit — the more combined the problem, the more the front 40 minutes decides the back 80. If you can’t solve it past 2 hours, pass by the same rule as Step 199: leave an attempt list, and on to the next problem.

4. Missions & Exercises

Mission — Conquer 16–30 and Update Weaknesses

Attempt 16–30, keeping the maximum 2-hour cap per challenge
In each problem, first organize the "visible defenses," build a bypass-candidate table, then eliminate one by one
For unsolved problems, use community hints only within the stage rules of 2-4
For problems whose solutions you saw, go through the 3-5 reproduction procedure and re-solve a week later
After solving 10 or more of 16–30, complete a weakness-type update table in the 3-6 format

Exercises

Exercise 1. What is the representative time waste that arises when trying to solve a combination problem "all at once," and how does decomposition prevent it?

Exercise 2. When building a candidate table for a problem whose filter strips quotes, name one candidate each from the character layer, syntax layer, and transport layer.

Exercise 3. Explain the difference between stage 1 and stage 3 of hint usage from the perspective of "independent solving."

Exercise 4. Why re-solve, a week later, a problem whose solution you saw? Answer together with why reproduction (3-5’s step 2) alone is insufficient.

5. Model Answers & Completion Criteria

Mission Model Answer

The skeleton of a completed log (fill in actual answers and types with your own solutions):

[16–30 conquest ledger — example format]
No. | Result    | Layer structure     | Core trick                  | Re-solve
16  | solved    | filter, 1 layer     | /**/ space substitute       | n/a
17  | solved    | encoding+injection, 2 layers | injection after double URL encoding | n/a
19  | saw solution | session+upload, 3 layers | extension case mixing   | scheduled 7/9
...

How to verify: ① 10 or more solved? ② Is the "layer structure" column filled in — evidence you decomposed combination problems? ③ Do problems whose solutions you saw have re-solve dates pinned? ④ Do the "weak" cells of the weakness-update table lead to next training addresses?

Exercise Answers

Answer 1. The waste of no longer knowing which layer blocked you. Swap the whole payload and you can’t tell whether it passed layer 1 or died at layer 2. Independent per-layer experiments create a progress line — "layer 1 pass confirmed → layer 2 experiment" — so even failures leave their coordinates.

Answer 2. Character layer: case mixing (' oR '), doubling the same string (OORR). Syntax layer: /**/ for space substitution, || for OR substitution, # for comment substitution. Transport layer: URL encoding or double encoding, parameter position/method changes (GET→POST). Split the layers and candidates never dry up.

Answer 3. Stage 1 ("which type is this problem?") is only a confirmation of problem reading — the core reasoning of the solve, what’s blocking and how to bypass it, remains yours. Seeing stage 3 (the answer payload) replaces that reasoning itself, so it’s not an independent solve. That’s why problems whose answers you saw get absorbed through the separate procedure of reproduction and re-solving.

Answer 4. Because reproduction checks short-term memory, while re-solving checks long-term memory. Rebuilding an answer you just saw may be memory, not understanding. Only solving a week later with nothing to look at verifies whether the thought path of "why that’s the answer" has become yours.

Completion Criteria Checklist

[ ] I can organize a problem’s "visible defenses" into a list
[ ] I can build a bypass-candidate table across the three layers (character, syntax, transport) and eliminate candidates
[ ] I decompose combination problems per layer and design independent experiments
[ ] I used hints within the stage rules (type → direction, never answers)
[ ] I kept the reproduction procedure and one-week re-solve rule for problems whose solutions I saw
[ ] Mission: solved 10+ of 16–30 + completed the weakness-type update table

6. Common Pitfalls & Fixes

Wall 1. My 1–15 touch doesn’t solve these

Symptom: you ran the whole common routine and found no thread.
Cause: this range mixes problems that require combining the routine’s "outputs." The routine is only the entrance.
Fix: after running the routine, lay the outputs (forms found, parameters, filter lists) side by side and look at "which of these connect to which." The combination’s thread lives in the intersection of the routine’s outputs.

Wall 2. My bypass candidates really did run out

Symptom: you eliminated every candidate in the table and you’re still blocked.
Cause: possibly a wrong assumption — what you judged as "this is the filter" may not be the filter, or the entrance itself may be elsewhere.
Fix: doubt the first line of your defense list. Split the observation one level finer — "is the quote really blocked, or is the ‘context containing a quote’ blocked?" — and candidates spring up again.

Wall 3. All responses look identical

Symptom: even with a success condition fed in, the screen matches the failure condition.
Cause: you’re watching only the screen text. Signals live outside the text.
Fix: place two requests side by side in Burp Repeater and compare response length, status code, response time, and hidden comments. If even one thing differs, that’s your oracle (judgment signal).

Wall 4. Once I start reading hints, I read to the end

Symptom: meaning to see "just the type," you end up reading the answer.
Cause: search result pages structurally show the answer on the same screen.
Fix: search only the words "challenge number + type," and keep a rule of reading only the first paragraph when opening a post. If you ended up seeing the answer, admit it and switch to the 3-5 reproduction procedure — the recovery procedure matters more than hiding it.

Wall 5. I get intimidated by problems with few solvers

Symptom: your hands freeze before a problem whose "solved by" count is in the hundreds.
Cause: solve count is a difficulty signal, not a verdict on your skill.
Fix: low solve counts have varied reasons — old problems, tedious problems, confusing problems. The procedure of defense lists and candidate tables works identically on any problem. Trust the procedure and keep just the 2-hour cap.

7. Summary

Today’s Concepts

Concept	One-line explanation
Combination problem	A problem with two or more layered defenses — per-layer decomposition is the standard
Defense listing	Writing down visible defenses first — the raw material of the candidate table
Elimination method	Exploration that builds bypass candidates into a table and erases them one by one
Reading the setter’s perspective	The skill of reverse-computing the tested concept from the problem’s material list
Staged hint usage	Only up to type → direction; never look at answers
Reproduction and re-solving	Rebuild a seen answer with your own hands, then solve again a week later

Today’s Techniques & Tools

Technique/tool	What it does
Defense list + bypass-candidate table	Mapping the blockage — remaining candidates become visible
`urllib.parse.quote()`	URL-encoding payloads (apply twice for double encoding)
Burp Repeater comparison	Finding hidden signals via response length, time, codes
Per-layer independent experiments	Verifying combination problems one layer at a time
Weakness-type update table	A map that fixes the next training address after finishing a range

The Instinct That Matters More Than Commands

What the 16–30 range teaches is not techniques but structure reading. When blocked, before suspecting "there’s a technique I don’t know," ask first "have I used every material I’ve seen?" This range’s answers mostly sit inside combinations of materials on the screen. And a problem whose answer you saw is not a failure but data — as the answers to "why couldn’t I think of it" pile up, they become your very own pattern dictionary.

Once every box is checked, Step 200 is complete. Click the checkbox in the sidebar to save your progress.