- Joined
- Dec 30, 2024
- Messages
- 242
- Reaction score
- 183
- Points
- 62
- Website
- blackhatpakistan.net
- Points
- 334
- USD
- 334
OPENBULLET MASTERY COURSE 2026 — PART 3 OF 5 LoliScript — The Complete Scripting Language Guide, From First Line to Full Config
BlackHatPakistan.net | Official Course Series | Updated September 2026 | 18 Min Read
EDUCATIONAL COURSE — For authorized testing on systems you own or have permission to test. You are 100% responsible for your own actions.
COURSE PROGRESS: PART 3 OF 5 — LOLISCRIPT SCRIPTINGPart 1: Setup
| Part 2: Config Anatomy | Part 3: LoliScript ← YOU ARE HERE | Part 4: Testing & Debugging | Part 5: Ecosystem & DefenseHey fellows, welcome back to the course.
Part 2 taught you to read configs. Today you learn to write them — in the language that separates the drag-and-drop crowd from the builders: LoliScript.
Here's the thing the visual editor never tells you: Stacks view and Script view are two translations of the same logic, and once you can write LoliScript, the visual designer becomes optional. Everything the drag-and-drop designer does — requests, parsing, conditions, functions, keychecks — has a text form, and text is faster to write, faster to fix, faster to share, and infinitely easier to debug. When a config breaks at 2 AM, you don't want to re-click forty blocks. You want to read forty lines and find the wrong one. That's the skill this part installs.
The approach today is the same as every part of this course: documentation-level teaching against test endpoints, with every example runnable against your own test pages or public practice endpoints like httpbin. The house rules haven't changed since Part 1: authorized targets only, and never purchase CC from anyone — including anyone selling "LoliScript packs," because by the end of today you'll write better than what they sell.
In This Part: LoliScript syntax fundamentals → request statements → parse statements → functions & variables → conditions → keychecks → a full config written line by line → syntax debugging → homework.
1. LOLISCRIPT FUNDAMENTALS — THE GRAMMAR OF THE LANGUAGE
LoliScript is a line-based language: each statement occupies one line, begins with a block keyword, and carries its settings. The grammar is brutally simple once you see the skeleton. Every line answers three questions in order: what block, with what settings, in what order.
The general shape of a statement:
BLOCKNAME Label "Some label text" setting1:value1 setting2:value2
Breaking that apart: the keyword at the front (uppercase, the block type), an optional label for readability, quoted strings where text contains spaces, and key:value setting pairs separated by spaces. Some settings take quoted values, some take bare values, some take lists. Read a few lines and the grammar becomes muscle memory — read a hundred and you stop seeing syntax and start seeing logic.
Three grammar rules carry you through ninety percent of the language:
Rule 1 — One statement per line. Every block is a line; lines run top to bottom in the order written. There is no magic ordering system — your file's line order IS your execution order, exactly like the visual stack.
Rule 2 — Quotation marks wrap text with spaces. Values containing spaces sit inside double quotes. A URL with no spaces doesn't need them; a parse boundary like "Logged in as" does.
Rule 3 — Variables live in angle brackets. Data pool fields and parsed values are referenced as <USER>, <PASS>, or any custom variable name — the placeholder system from Part 2, now in its native habitat.
One more fundamental — the comment. Lines you want the engine to ignore sit in single quotes at the line start, letting you annotate your configs. Annotated configs are readable configs, and readable configs are the ones that get maintained. The professionals' configs read like tutorials because they're commented like tutorials; write for the reader, and that reader is mostly you.
2. REQUEST STATEMENTS — SPEAKING HTTP IN TEXT
The request statements are where every config starts, and in LoliScript they read like a description of what the browser does. The two workhorses:
The GET statement fetches a page. The essential form:
REQUESTGET "Step 1 - open page" URL:"https://test.example.local/login"
That single line: a request block labeled "Step 1 - open page," hitting the login page of a test host. The response lands in the attempt's context, ready for parsing or keychecks. Common settings you'll add as you grow: headers for user-agent strings, cookie handling, and redirects-followed flags — each a setting pair on the same line, appended as the logic needs them.
The POST statement submits data — the login form, the API payload. The essential form adds a body and a content type:
REQUESTPOST "Step 2 - submit login" URL:"https://test.example.local/login" CONTENTTYPE:"application/x-www-form-urlencoded" STRINGDATA:"username=<USER>&password=<PASS>"
Read that line like Part 2 taught you to: it's Stage 2 of the login skeleton, written down. The STRINGDATA carries the form fields with the placeholder system injecting this attempt's USER and PASS values. The content-type declaration tells the server what shape of data to expect — and mismatching it is the classic beginner bug from Part 2, now visible in your own handwriting.
Two professional habits attach to request statements from day one. First, label every statement — "Step 1 - open page" costs two seconds to write and saves two minutes of confusion in a fifty-line config. Second, build stages one at a time and test each against your test endpoint before adding the next. A five-line config that works beats a fifty-line config that almost works, every single time.
3. PARSE STATEMENTS — EXTRACTION AS ONE-LINERS
Part 2 taught the three extraction minds — LRON boundaries, CSS selectors, regex. In LoliScript each mind is a PARSE statement flavor, and the syntax makes the extraction visible in a single line.
LRON parsing — the boundary workhorse:
PARSE "capture display name" LRON:<div class="displayname"> </div> VAR:"NAME"
Read it aloud: parse, using left-right boundary mode, between this opening text and this closing text, store the result in variable NAME. The response from the previous request statement is searched, the captured text is saved, and every later line can reference <NAME>. One line, one variable, one handoff in the relay race from Part 2.
CSS selector parsing for HTML responses walks structure instead of text, and regex parsing handles the variable-shape responses — same statement shape, different mode flag, per the official documentation's block reference. The course discipline from Part 2 applies verbatim: choose stable boundaries, prefer the simplest mind that works, and parse from real captured responses, never imagined ones.
And the parse statement carries one professional flag worth learning early: the option to require the capture or continue gracefully when it's missing. A parse that must succeed should stop the attempt when it fails — otherwise your config marches to the keychecks with empty variables and produces verdicts based on nothing. Whether a missing capture is fatal or forgivable is a per-parse decision, and thinking about it for five seconds per parse separates careful configs from confetti.
4. FUNCTIONS & VARIABLES — THE UTILITY BELT
The FUNCTION statement is LoliScript's utility belt — one keyword, many tools, selected by a mode. The ones you'll use constantly in real configs:
Constant: create a variable with a fixed value. FUNCTION Constant VAR:"API_BASE" "https://test.example.local" — and now every later line can reference <API_BASE>, which means an endpoint change is a one-line edit instead of a config-wide hunt. This is the clean-setup habit from Part 1, now in language form.
String utilities: replace text inside a variable, join values, slice substrings, change case. Real responses arrive dirty — trailing spaces, HTML entities, inconsistent capitalization — and the string functions are the cleaning station before parsing and comparing.
Encoding & hashing: base64 encode and decode, URL encode, MD5/SHA hashing. The moment a target's flow includes encoded values (and they all do eventually), these functions turn what would be a manual detour into a single statement.
Random generation: random strings and numbers — for testing input validation, generating unique test data inline, and the thousand small cases where a fixed value isn't enough.
Math & date: arithmetic on variables and date math for anything time-based. Less glamorous, quietly essential.
The mental model for FUNCTION statements: every one reads a variable or a literal, performs one clear operation, and writes the result to a variable. Utilities are the connective tissue between requests and parses — and like parse statements, they're one line each, so your configs stay readable while gaining capability.
5. CONDITIONS — WHEN YOUR CONFIG THINKS
Until now, every line ran every time, top to bottom. The IF statement introduces decision-making — the point where configs stop being lists and become programs:
IF " <STATUS> == 403 " → the lines between IF and ENDIF run only when the condition is true.
Conditions compare variables and literals with equality, inequality, contains, greater/less-than, and combinations. The practical uses fill every real config: if the response status is a block, jump to cleanup; if the parsed balance is empty, mark the attempt differently; if the target served a challenge page, route to a different flow. IF/ELSE and nested IFs extend the same idea — conditions inside conditions — and the language supports it cleanly.
One structural rule keeps condition-heavy configs sane: keep IF blocks short. A condition that wraps forty lines of logic is a condition nobody can verify by reading. The professional pattern is to make the IF decide and delegate — the condition sets a flag or jumps to a labeled section, and the heavy logic lives in flat, readable runs elsewhere. Nested labyrinths impress nobody at 2 AM.
6. KEYCHECKS IN LOLISCRIPT — THE VERDICT, WRITTEN DOWN
Part 2 called keychecks the config's confession. In LoliScript, the confession is literal lines at the end of the file. The KEYCHECK statement family declares the verdict conditions:
KEYCHAIN "SUCCESS" KEY:"logout" KEY:"welcome back" — mark SUCCESS if the response contains either marker.
KEYCHAIN "FAILURE" KEY:"invalid credentials" — and similarly for BAN, RETRY, and custom flags. Multiple KEY lines inside one KEYCHAIN statement are OR conditions; multiple KEYCHAIN statements are separate verdict rules evaluated in order.
The two laws of keychecks, restated in text form because they're twice as important when they're this easy to edit: specific before general (the captcha condition must be tested before the generic failure condition, or challenges get mislabeled), and every verdict needs evidence (capture on success, or the hit is a claim without proof).
And one LoliScript-specific superpower: because keychecks are text, you can maintain a library of verdict blocks per target type and paste them in. Your personal style becomes your template. That's how experienced builders produce consistent configs at speed — they're not typing from memory, they're assembling from a well-organized past.
7. FULL CONFIG WALKTHROUGH — A COMPLETE LOLISCRIPT FILE, LINE BY LINE
Everything from sections 1-6 assembles into one complete, runnable educational config. Here it is in full — a login-flow test against a hypothetical local test host — with every line commented. This is the shape of your first self-written config:
Code:
'— OPENBULLET MASTERY COURSE: educational login config (test host only) —
'constants: change these once, affects whole config
FUNCTION Constant VAR:"HOST" "https://test.example.local"
'— STAGE 1: open the login page, collect session cookies —
REQUESTGET "Step 1 - open login page" URL:"<HOST>/login"
'— STAGE 2: submit credentials with cookies attached —
REQUESTPOST "Step 2 - submit login" URL:"<HOST>/login" CONTENTTYPE:"application/x-www-form-urlencoded" STRINGDATA:"username=<USER>&password=<PASS>"
'— STAGE 3: capture the display name if present —
PARSE "capture display name" LRON:<span id="user-name"> </span> VAR:"NAME"
'— STAGE 4: verdicts, specific before general —
KEYCHAIN "SUCCESS" KEY:"logout"
KEYCHAIN "FAILURE" KEY:"invalid credentials"
KEYCHAIN "BAN" KEY:"unusual activity"
[CENTER]Eleven active lines, counting comments. Read it top to bottom and it narrates itself: constants, open page, submit, capture, judge. This is what "I can write configs" looks like in practice — not fifty clever blocks, but eleven honest lines that do exactly what their labels claim. Copy this skeleton against your own test host, swap the endpoints and markers, and you've built your first config. The milestone is real, and it's closer than it was when this part started.
8. DEBUGGING LOLISCRIPT SYNTAX — WHEN THE LANGUAGE FIGHTS BACK
Everyone's first LoliScript config has syntax errors, and everyone's errors are the same five. Learn them now and skip the evening of confusion:
1. Missing quotes around spaced values. A boundary containing spaces must sit in double quotes — unquoted, the engine splits your statement at the space and everything after becomes garbage settings. Symptom: the config editor highlights the line red or the run ignores the setting.
2. Wrong placeholder spelling. <USER> vs <user> vs <USERNAME> — if the variable name doesn't match the data split or the parse output, the placeholder injects empty. Symptom: requests that look right but contain holes.
3. Unclosed IF blocks. Every IF needs its ENDIF. Symptom: everything after the condition behaves like it's inside it.
4. Statement keywords misspelled or lowercased. The language is case-sensitive at the keyword level — REQUESTPOST, not RequestPost, not requestpost. Symptom: the line doesn't render as a block at all.
5. Smart quotes from copy-pasting. Code pasted from formatted websites carries curly quotes, and the engine only reads straight ones. Symptom: a line that looks identical to a working line but isn't. The fix: retype the quotes by hand, and paste code only into plain-text editors.
The debugging method that resolves everything else: binary search your file. Comment out the second half. Does it run? The fault lives below. Comment out half of the remaining half. Ten minutes of halving locates any broken line in any config ever written. It's the oldest debugging technique in computing because it works.
12. ADVANCED REQUEST SETTINGS — THE PARTS OF THE LINE I SKIPPED
The request statements in section 2 showed their essential form. The full form carries more settings, and the difference between a config that works in a lab and one that works against real authorized targets is usually these settings. The ones that earn their place on your desk card:
Custom headers. Real browsers send a small biography with every request — user-agent, accepted languages, references. A config's GET that arrives without them looks like a script to any endpoint with basic hygiene. The HEADER settings on request statements let you declare them line by line, and the professional habit is a constants block holding a realistic header set, injected into every request statement in the config. Your Part 1 lab hygiene plus your Part 2 constants block plus this equals requests indistinguishable from a real browser's first visit.
Cookie control. Automatic cookie handling covers most flows — the container keeps what the server sets. But some flows need explicit control: a cookie captured in one stage and forced into a later stage, or a specific cookie value overridden. The request statements accept cookie settings for exactly these cases, and the parse-plus-inject pattern from Part 2's variable relay is how you feed them.
Redirect behavior. By default, requests follow redirects — the server says "go to this new address" and the tool goes. Most flows want that. Some verdict logic needs the redirect NOT followed, because the redirect target is the verdict (a login that redirects to a dashboard means success; the dashboard itself is a second request you may not want). The redirect flag on the request statement is how you choose, and deciding deliberately instead of accepting defaults is the difference between a config and a hope.
Timeouts. Every request waits a maximum time for an answer. Defaults exist, but slow authorized targets and long-polling endpoints need adjusted timeouts — and tuning them per stage (short for the opening GET, longer for heavy POSTs) keeps runs fast without breaking slow stages.
13. LOLISCRIPT VS THE VISUAL DESIGNER — CHOOSING YOUR WEAPON
Now that you can do both, the honest question: which view should you live in? The answer changes with the task, and pretending otherwise is how people develop superstitious workflows. Here's the real division of labor:
Write in LoliScript when: creating new configs from scratch, editing existing logic, sharing fixes (a line pastes; a block stack doesn't), reviewing anything for safety (you can grep text; you can't grep cards), and building anything longer than fifteen blocks. The text view keeps the whole logic on one screen and in one mind.
Use the visual designer when: learning a new block type (the designer shows available settings with descriptions — it's a built-in reference), explaining logic to a beginner in a reply, or auditing an unfamiliar config's shape at a glance. The designer is the best READER in the tool even though it's a mediocre WRITER.
Switch between them constantly. This is the actual answer. Draft the logic in LoliScript, flip to Stacks to verify the visual shape reads correctly, back to Script for the next stage. The two views keep each other honest — text catches visual sloppiness, visuals catch text typos. Students who marry one view never develop the double-vision that makes veterans fast.
And the meta-point that this whole course keeps returning to: the config file is the source of truth, and both views are windows onto it. When you understand that, tool debates dissolve. The file doesn't care which window you looked through — it executes what's written, and what's written is what you can read.
14. THE EXAMPLE GALLERY — SIX PATTERNS YOU'LL STEAL FROM
Six short LoliScript patterns from real educational configs. None of them are complete configs — they're the moves, the riffs, the licks you'll combine into your own solos. Read each one and narrate to yourself what it does before reading the explanation:
Pattern 1 — The safety constants block:
Code:
FUNCTION Constant VAR:"HOST" "https://test.example.local"
FUNCTION Constant VAR:"UA" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
FUNCTION Constant VAR:"LOGIN_ENDPOINT" "<HOST>/api/session"Three constants at the top of every config: the host, the browser identity, and the derived endpoint. Change HOST once and the derived value follows. This is the self-configuring config pattern — and it costs three lines.
Pattern 2 — The capture-or-die parse:
Code:
PARSE "capture session token" LRON:"token":" " VAR:"SESSION_TOKEN"A parse whose captured variable is referenced by every later stage. If the response format changed, this parse comes back empty, later stages build broken requests, and the failure appears where the failure IS — not three stages later where it's unrecognizable. Failing loudly and early is a feature; build configs that do it.
Pattern 3 — The conditional detour:
Code:
IF " <RESPONSECODE> == 403 "
'— this attempt hit a wall; log it differently and stop here
FUNCTION Constant VAR:"VERDICT" "WALL"
ENDIFA condition that catches the weird case early and labels it, instead of letting it flow into the keychecks and confuse the verdicts. The lab-hygiene principle applied inside the file: isolate the anomaly.
Pattern 4 — The encoding round-trip:
Code:
FUNCTION Base64 DECODE INPUT:"<RAW_TOKEN>" VAR:"DECODED_TOKEN"
FUNCTION UrlEncode INPUT:"<DECODED_TOKEN>" VAR:"SAFE_TOKEN"The two-step cleaning station: decode what the server handed you, re-encode it the way the next request needs it. Any target that passes values through multiple encodings (and they all do eventually) is handled by this pattern with the function names swapped.
Pattern 5 — The human-timing delay:
Code:
FUNCTION Random VAR:"WAIT_MS" MIN:"800" MAX:"2400"Randomized delays between stages — because testing at machine speed teaches you about the target's rate limiting instead of its behavior. A config that paces itself like a human measures what a human would see. Part 4 tunes this against real targets; the pattern is born here.
Pattern 6 — The evidence capture:
Code:
PARSE "capture plan type" LRON:"plan":" " VAR:"CAP_PLAN"
PARSE "capture account status" LRON:"status":" " VAR:"CAP_STATUS"Two parses on a success response, capturing the fields that make a hit meaningful. This is the evidence habit from Part 2's seven sins — a SUCCESS verdict with captures is a finding; without them it's a rumor.
15. THE ENVIRONMENT SYSTEM — GLOBAL VARIABLES FOR CLEAN SETUPS
One more system belongs in this part because it changes how your configs grow up: the global environment. Beyond the variables inside a single config, OB2 maintains environment-level variables that any config can reference — and using them well is what turns a folder of configs into a managed system.
The concept: values you reuse across configs — endpoints, identifiers, testing parameters — live in the environment instead of being hardcoded into each file. A config declares which environment variables it expects, and the tool feeds them in at runtime. Change the value once in the environment, and every config that references it updates together.
Why this matters grows with your collection. Three configs with hardcoded endpoints are manageable; thirty are a maintenance nightmare; three hundred are a security incident waiting to happen, because stale values in forgotten files are how testing infrastructure leaks. The environment is the answer to "how do professionals maintain fifty configs without losing their minds" — the answer is that the values live in one place and the configs are logic-only.
The security angle doubles the importance. Secrets — credentials for your testing infrastructure, API keys for solving services, anything sensitive — belong in environment storage, not in config text. A config file with a hardcoded secret is a secret waiting to be shared by accident: posted in a reply, attached to a support question, screenshotted into a tutorial. The scene is full of "I leaked my own key in a screenshot" stories, and every one of them was preventable by this paragraph.
16. SCRIPT BLOCKS — THE CEILING OF THE LANGUAGE
One honest paragraph about the ceiling, so this part ends without overselling: everything LoliScript covers makes up the overwhelming majority of real configs. But OB2 also supports full script blocks — sections of actual programming code embedded in the flow, for the cases where blocks genuinely can't express the logic. Complex parsing arithmetic, custom encoding schemes, stateful logic across attempts — the rare five percent.
The course position on script blocks, stated plainly: they're Part 5-adjacent territory, they require actual programming background to use safely, and ninety percent of students should file them under "know it exists" rather than "need it now." The LoliScript you learned today covers login flows, API tests, monitors, and multi-stage patterns — the entire practical vocabulary of the tool. Learn the five percent last, and only when the ninety-five percent feels small under your hands.
What this part DID give you is the complete working language: requests, parsing, functions, conditions, keychecks, constants, patterns, debugging, and the environment. That's not a taste of LoliScript. That's the meal.
A final word before homework, because Part 3 is the part where most students either fall in love with this tool or bounce off it, and the difference is purely one of expectation. LoliScript will feel slow for your first two configs. Your fingers will forget the keywords, the quotes will misbehave, the placeholders will come out empty for reasons that feel personal. That is not you failing; that is the grammar installing. Every builder whose configs you admire has a folder full of broken first drafts exactly like the ones you're about to write. The language takes an evening to learn and a week to feel natural, and then it is yours permanently — a skill that transfers to every version of every tool in this category for the rest of your time in this field. That return on one week of practice is, frankly, the best trade this scene offers. Take the trade. Do the homework. And I'll see you in Part 4, where your first config finally meets real traffic.
17.
THE STUDENT VAULT — REPLY TO UNLOCKBehind this lock: the extended LoliScript reference — the full statement catalog with every commonly used setting, plus a second complete walkthrough config (multi-stage flow with conditions and jumps), plus my personal annotated skeleton templates for the four config patterns from Part 2. Reply to the thread and it opens:
18. HOMEWORK — YOUR ASSIGNMENT BEFORE PART 4
1. Rebuild the eleven-line walkthrough config from section 7 yourself, character by character, against a test host — no copy-paste. Typing it is where the grammar installs.
2. Add a Stage 3 parse for a second field of your choosing, and reference it in a comment explaining where it would matter.
3. Break your config on purpose — remove one quote, misspell a keyword — and read the failure symptoms. Ten minutes of deliberate breaking teaches more than an hour of careful building.
4. Answer in the replies: which of the five syntax errors from section 8 did you commit, and how did it present? The confessions thread becomes this course's best study guide.
5. Write your constants block for a real flow you're authorized to test — endpoints in, magic strings named.
19. FAQ — LOLISCRIPT QUESTIONS EVERYBODY ASKS
What is LoliScript?
OpenBullet's text-based scripting language — the written form of config logic. Every visual block has a LoliScript equivalent, and the Script view of any config shows the translation.
Do I need LoliScript if the visual designer exists?
For learning, no — for building, yes. Text is faster to write, debug, share, and diff. Professionals write in LoliScript and use Stacks view for reading other people's work.
Is LoliScript hard to learn?
It's a recipe format with strict grammar — one statement per line, quotes around spaced text, placeholders in angle brackets. A weekend of deliberate practice installs it. The eleven-line walkthrough in section 7 is the whole language in miniature.
Where is LoliScript documented?
The official OpenBullet documentation site carries the full block reference. This course teaches the thinking; the docs carry the complete setting lists.
Can LoliScript do everything the visual editor can?
Yes — they're two views of the same config. Script blocks and advanced functions extend past the visual blocks entirely, which is the Part 3 superpower.
Why do my placeholders come out empty?
A variable-name mismatch — between the data split, the parse output, or the placeholder spelling. Section 8, error number two. Check the names character by character.
How do I debug a LoliScript config that won't run?
Binary search: comment out half the file, test, halve again. Ten minutes finds any broken line. Section 8's five common errors cover ninety percent of what you'll find.
Should I learn LoliScript or just download configs?
Downloaded configs are someone else's homework — unreadable, unmaintainable, and occasionally malicious. The skill takes a week and lasts forever. That comparison is the entire business model of Part 5.
COURSE LINKS — THE FULL SERIES
| Part | Topic | Status |
|---|---|---|
| Part 1 | Setup & First Launch | Available here |
| Part 2 | Config Anatomy | Available here |
| Part 3 | LoliScript — THIS THREAD | Available |
| Part 4 | Testing & Debugging — proxies, bots, verdict proof | Available here |
| Part 5 | The Ecosystem — markets, scams, automation defense | Available here |
Related reading while Part 4 drops: OpenBullet Config Making 2026 — the community thread where the questions that shaped this course were first asked — and the Proxies guide, which becomes required reading the moment Part 4 starts.
FINAL REMINDER: NEVER PURCHASE CC FROM ANYONE. NEVER BUY LOLISCRIPT PACKS. THE LANGUAGE IS FREE, THE KNOWLEDGE IS FREE, THE COURSE IS FREE. This course is for educational purposes and authorized testing only. Blackhat Pakistan does not promote illegal activity. Follow your local laws and regulations.
Join the community: Blackhat Pakistan | Telegram Channel
Reply with your eleven-line configs and your syntax confessions — homework review lives in the replies.
Last Updated: September 11, 2026 | OpenBullet Mastery Course 2026 | Blackhat Pakistan Community
Last edited:
