["Jacob P. Mohrbutter"]

A ClickFix GPT, a weaponized MSI, and the implant that RickRolled itself

Thu, 08 Oct 2026 00:00:00 +0000

Public Advisory

If you only read one section, read this one. Share it with someone who might follow a fake verification prompt.

I had searched for “gpt”. The browser record shows a Google ad redirect into a community GPT on the real ChatGPT site. Its notice claimed a service problem and sent me to a backup page. That page dressed itself as a human-verification check and told me to run a command on my own computer.

The part to recognize is the keyboard sequence:

Windows key + R, Ctrl + V, Enter runs a command. The first keys open Windows Run; the next keys paste whatever the page put on your clipboard; Enter executes it. A website asking you to do that is asking you to run its code.
A human-verification check stays in the web page. If a box claiming to be Cloudflare asks you to open Windows Run or PowerShell, close the tab.
A familiar site can carry someone else’s instructions. The malicious notice appeared inside a community GPT on the real ChatGPT site. The surrounding page was genuine; the instructions were supplied by a third party.

What to do instead:

Close the tab. Do not paste or run the command, even if the page says your account or service will stop working.
If you are unsure, ask someone you trust before following the instructions.
If you already ran it, disconnect that computer from the internet and get help from someone who can examine it. This trick can install a hidden program.

I did not run the command on my host. The payload here targets Windows; the warning sign is a website telling you to execute a command outside the browser.

Publication note: While preparing this research for release, I discovered Huntress had already published analysis of the same “Plus 5.6” campaign and the Stardock/Build.dat loader chain. That work has publication priority on those overlapping findings. My investigation was conducted independently and was substantially complete before I found their report. The protocol reconstruction, controlled tasking, and reproducible lab described here were developed from my own captured artifacts and testing.

Executive Summary

An ordinary search for gpt took my browser across a Google ad redirect and into a community-built GPT on the real ChatGPT site. The GPT presented a fake service notice pointing to a Google Sites page dressed as a Cloudflare check. The browser record shows that page loading, although it does not preserve the physical click that opened it. A later saved copy of the page put a PowerShell launcher on the clipboard and told the visitor to press Win+R, Ctrl+V, Enter. In Windows those keys would run the launcher, fetch two more PowerShell stages, and silently install an MSI. The attacker needed the visitor to run a command, not a browser exploit.

I did not run that command on my host. I collected the Windows payload afterward and examined it in isolation. The MSI hides its installed product, side-loads a DLL chain, and starts an implant with persistence and task-handling code. I reconstructed enough of its binary protocol to send a type-1 shell task to the resident implant. The first probe returned a marker and opened a local page; the prepared demo uses the same task path to open a locally served Rick Astley video. The released lab includes the primed infected VM, emulator, controller, and harness so another researcher can repeat that result without contacting the real C2.

The saved samples came after the original browser visit, so I cannot say they are byte-for-byte what the first visitor would have received. The public package supports reproduction of the isolated tasking result; raw browser, mailbox, and lab captures remain private. I reported the attack in a ChatGPT conversation, and OpenAI acknowledged that report as Cyber attacks. Firefox also retained the exact GPT conversation URL and fake-site URL from an OpenAI report-form submit event before a review reply said “no policy violation.” I had no unrelated reports from that account; this was the reply to my first report about the attack. A GPT pointing people to a fake verification page that instructs them to run a command called for security and abuse triage. OpenAI had the reported conversation and the exact URL. I cannot see what a reviewer opened or how the report was routed internally; I can see the answer I received. After reading it, I reported the GPT itself as Scams and/or fraud; OpenAI acknowledged “Plus 5.6” by name. I found no decision for that named report. The GPT became unavailable afterward. I do not know why.

A ClickFix GPT, a weaponized MSI, and the implant that RickRolled itself

A real ChatGPT page carried a fake verification prompt. I followed the payload into an isolated lab and eventually made its implant play Rick Astley.

Research materials: qu3b411/clickfix repository · prepared lab release · demo-evidence guide · sample and lab safety.

Incident: September 25, 2026

DFIU

(Don’t Fuck It Up. This is for the person excited enough to try the lab and tempted to take a shortcut.)

The archive linked below contains a live implant and a prepared infected Windows VM. If you only want to watch the result, the video is below. You do not need the lab to understand the joke.

If you do run the lab, use a dedicated host you can afford to wipe and read the included warning first. The shipped harness checks its own VirtualBox setup, but you are responsible for the host around it.

Keep the VMs on the isolated internal network. No NAT, bridged, or host-only adapter. No route to your LAN or the internet. Check the adapter settings before booting and again if you change anything.
Keep host integration off. No shared folders, shared clipboard, drag-and-drop, or Guest Additions in the infected Windows VM. A convenient file transfer is a bad trade when the guest is running malware.
Do not point the sample at the real C2. The address in this article is a live indicator. Inside the lab it is redirected to a local controller, with forwarding disabled. Do not copy that address into a browser or run the sample on a normal network.
Treat the downloads as hazardous. The password is an acknowledgement, not a safety feature. Do not unpack the archive in Downloads and browse around casually. Keep the samples encrypted except inside the intended research environment.
Stop when the setup disagrees with the instructions. A failed isolation check is a stop sign. Do not comment it out to get to the Rickroll. Inspect what changed and start again from a clean disposable clone.
Assume your guest is compromised after the demo. Do not log into personal accounts in it. Do not give it secrets. Revert or delete disposable clones when you finish.

Technical Teardown

The evidence splits here. My browser record reaches the fake check; it does not contain the payload that would have landed had I followed the instructions on my host. I collected the later stages afterward and ran those saved bytes in isolation. That gives me a real execution path to analyze, but it ties the lab result to the supplementary samples rather than to an unseen download during the original visit.

The route to the fake check

The preserved browser route starts with a search for gpt, crosses a Google /aclk ad redirect, and reaches a GPT called “Plus 5.6.” The click identifier matches across the redirect. I also remember a strange “New chat” transition, but I cannot place it from the browser record.

While preparing this article, I made the same search and again saw a sponsored ChatGPT result with a Google /aclk link. This later screenshot shows how ordinary that entry point looks; it is not the incident ad and does not show that this result is malicious. I cropped out browser profile details and removed the ad URL's query parameters.

The GPT identified itself as community-built. I started a conversation (“Extract avatar”) and saw a “Service Availability Notice” claiming trouble with the primary service and pointing to a backup site, sites[.]google[.]com/view/antibot172881. The screenshot records that notice, and the browser record shows the site loaded afterward. It does not retain the initiating click. The fake notice came from third-party GPT content inside a genuine ChatGPT page; I have no evidence that OpenAI authored it.

Fake Cloudflare verification

My screenshot shows the Google Sites page rendering a full-screen Cloudflare-styled “Human Verification” interface naming chatgpt.com, with instructions to press Win+R, Ctrl+V, Enter.

The fake Cloudflare "Human Verification" modal served from sites[.]google[.]com/view/antibot172881. This is attacker-controlled content on Google Sites, not a real Cloudflare check. This crop has its metadata stripped; the public hash and handling notes are in images/incident.

The checkbox is theater. The saved page places a PowerShell launcher in an offscreen textarea, selects it, and calls document.execCommand('copy'). By the time the visitor reaches Ctrl+V, the command is already on the clipboard. The page also swaps visible google.com text for chatgpt.com, blocks developer-tool shortcuts, and posts telemetry to a runtime-origin api.php. It references an external script and a panel address that were not captured, so this copy cannot establish whether either one ran.

Payload retrieval

The clipboard launcher fetched /12 from 1450003207, wrote a PowerShell script under %TEMP%, and ran it. That number is decimal IPv4 notation for 86[.]109[.]75[.]7: the request avoids a dotted address and a DNS lookup. The exact launcher bytes are preserved in the password-protected page sample. The three-stage retrieval was:

GET /12 → 12.ps1 (800 bytes) — sets TLS 1.2, a Chrome-like UA, DownloadString of /s/19481b28bd67, pipes the result into a hidden powershell -nop -w hidden -ep bypass -.
GET /s/19481b28bd67 → stage3.txt (54,235 bytes, arithmetic-obfuscated) — decodes to a downloader of /app/19481b28bd67/IconEdit2Turb.msi, saved to %TEMP%, Unblock-File, then msiexec /i … /qn /norestart with a hidden window.
GET /app/19481b28bd67/IconEdit2Turb.msi → the weaponized MSI (5,069,824 bytes).

The first stage and MSI are saved bytes; I decoded the middle stage. These samples were collected after the original browser visit.

Artifacts: the page, both PowerShell stages, and the MSI are published as live samples — in password-protected archives only — under malware/. Original and archive hashes are in malware/README.md; repository file hashes are in manifests/SHA256SUMS.txt. Read SAFETY.md first.

Inside the MSI

Expand: MSI packaging, hidden-product flag, and the side-load chain

The MSI declares benign branding (“Stardock Smart DeElevation Tool”, v7.12.0, “Filezo”, Advanced Installer), installs in the user’s LocalAppData Programs tree, and sets ARPSYSTEMCOMPONENT=1 to hide from the installed-programs list. A WiX WixShellExec custom action (sequence 6602, after InstallFinalize) launches DeElevate64.exe without another user action. The dependency chain is DeElevate64.exe → DeElevator64.dll!RunNonElevated → I++u.dll!contentsStroke → senddmp.resources.dll (+ dynamically loaded res.dll). DeElevator64.dll has its import directory in .rsrc and a certificate directory pointing past EOF, both signs of a modified loader.

The Build.dat graft

Build.dat presents as a 36-entry NuGet-style ZIP but has a deliberately inserted region at [0x5847b, 0xaba8e) — exactly 341,523 bytes. Removing precisely that range from an analysis copy restores a ZIP whose 36 members all pass CRC. The I++u.dll loader reads exactly that region, transforms it, copies it into executable memory allocated by senddmp.resources.dll, and hands the buffer to EnumSystemCodePagesW as a callback — a code-execution loader, not data.

The transformed region decodes to valid x64 position-independent code once all three changing state registers in the loader’s XOR loop are tracked correctly. My first pass got that loop wrong; the corrected decoder and recovered bytes are retained in my analysis record.

An isolated execution

Static analysis had shown me a loader and task-handling code; it could not tell me whether the installed process would remain alive long enough to use either. I built a disposable Windows 11 VM with one NIC on a private VirtualBox internal network and no host integration. Sysmon, Procmon, ETW collection for DNS, Task Scheduler, and WinHTTP, plus process, socket, and memory-dump watchers from a read-only tools ISO recorded the run. I took a clean powered-off snapshot before introducing the sample and checked isolation again afterward.

The released victim comes from the sealed run. Defender real-time protection was on, but its signatures were old and offline, and the specimen’s install folder had a narrow exclusion. The specimen survived under those conditions. That says nothing about current Defender detection on a fully updated Windows machine.

Network emulation

The Windows guest needed to reach the services the sample expected without gaining a route off the lab network. A second VM (Ubuntu 24.04) ran INetSim and dnsmasq on the same private segment: wildcard DNS to 10.77.86.2, simulated HTTP/HTTPS, DHCP, no default route, IP forwarding 0. I used a clean probe VM to check that service path before attaching the infected guest. Later, a small local replay server returned the three exact saved stage bodies, allowing the ClickFix chain to run end-to-end without an uplink.

Finding the C2 path

Once the implant stayed resident, I watched it query dns.google, attempt TLS with SNI dns.google, then attempt TCP to 45.140.205.28:443, a candidate C2 endpoint. The first SYNs went unanswered. I then redirected that destination to a passive listener inside the emulator. No byte was sent to the real address. The listener received 18 structured binary messages totaling 58,626 bytes and sent zero bytes back.

Reconstructing the protocol

Expand: the recovered wire format (header, descriptors, registration profile)

The messages use a 120-byte arithmetic header (constant K=0x16df3822a8), 88-byte field descriptors, and XOR-transformed field data. A client-embedded UTC timestamp preceded the socket watcher’s first observation of the same source port in every stream, a useful cross-check on the decode. The body is a 26-field registration profile: username analyst, computer CFX-LAB, Windows version, security product, CPU/GPU, locale, client version, executable, and install path. I also mapped the receive-side action tags (0x56bc, 0x56be, 0x5b90, 0x5608, …) and reproduced the frame-length arithmetic against the captured frames. The public protocol specification carries the wire details.

Why the implant stayed alive

The first direct-MSI run persisted; several shorter runs did not. The difference turned out to be a “Syntax error” dialog left open by the de-elevation wrapper. The dialog kept DeElevate64.exe alive while the malicious DLL ran on another thread. The decoded task script waits 150 and 875 seconds before writing the Run value and scheduled task. In a controlled run I left the dialog open and saw both writes. For this sample, in these runs, process lifetime was the condition that mattered.

Process tree and Sysmon

Sysmon joined the installer chain msiexec.exe → msiexec.exe → 32-bit msiexec.exe → DeElevate64.exe to the DLL load order and the delayed HKCU Run value and scheduled task. The guest and emulator clocks differed after saved-state resume; I joined network events to the emulator capture by source port and packet order.

A local controller

The receive-side reconstruction identified a type-1 task container, a start-shell field, and a field that feeds UTF-16LE command text to cmd.exe. I wrote a controller under c2/ that binds to 10.77.86.2:8443, rejects peers outside 10.77.86.0/24, and emits the fixed frames needed to test that path. It has no upstream or forwarding code. Task types 2–4 appear in the disassembly; I did not exercise them.

Task execution

The reconstructed frames let me test whether the client was actually parsing my replies:

State flip: changing decoded field 0x56bc between 01 and 00 repeatably changed the live client’s connection lifetime and reconnect cadence. Switching it back restored the first behavior. Both NIC captures contain the generated frames; the change came from the client acting on them.
Type-1 shell: the implant spawned cmd.exe, returned CFX_RICKROLL_TASK_PROOF, and echoed the shell PID in reply field 0x5975. A second fixed shell-input frame launched Edge at a local page. That first probe did not play the video; the later prepared demo served video through the same local address.

Sysmon recorded DeElevate64.exe → cmd.exe → msedge.exe during that controlled probe, after my controller sent the task. Edge was the result of my shell input, not an observed attacker command. I checked the replies against captures from both NICs and the Sysmon process tree. The public demo-evidence guide keeps the controlled probe distinct from the later video presentation.

What happened after I reported it

There were two reporting paths before I received the negative reply. Keeping them separate matters.

First, I reported the attack from the ChatGPT conversation under Cyber attacks. OpenAI’s receipt says the report concerned “Cyber attacks” in a ChatGPT conversation. It does not print the conversation ID, but I made the report about the “Plus 5.6” conversation, and I had no unrelated reports from that account. This was the first report.

I also used OpenAI’s Report Content form. Firefox saved the fake-site URL and the exact “Plus 5.6” conversation URL together when that form was submitted. A case-system acknowledgment then said a report had been submitted. That email does not repeat the URLs. The form and its acknowledgment came before the negative review reply, but I cannot see whether OpenAI joined the form case to the conversation report internally.

Then the same reporting mail system that acknowledged the Cyber attacks conversation report sent a reply saying it had reviewed the content I reported in ChatGPT and “found no policy violation.” With no unrelated reports from that account, this was the answer to my first attack-conversation report. The reply does not print a case ID, conversation ID, or GPT name, and I cannot see what the reviewer actually opened. I read it later that morning.

That distinction matters to the failure. The first report came from a GPT conversation that led to a fake verification page telling Windows users to execute a command. The exact conversation and fake-site URLs were also in OpenAI’s report form before the reply. The later collected chain installed a resident implant that accepted shell tasks in my isolated lab. This called for security and abuse triage: inspect the GPT and outbound link, preserve the relevant records, and assess whether other users were exposed. I cannot tell whether the miss was in intake, routing, or review, or whether any separate investigation occurred. The answer sent back on the first report was “no policy violation.”

After reading that answer, I reported the GPT itself as Scams and/or fraud. The later acknowledgment explicitly names “Plus 5.6” and confirms receipt. It does not say OpenAI reviewed or removed the GPT, and I found no decision email for that GPT-level report in the preserved mailbox.

I found some report messages only when I revisited the mailbox. Their headers show they were delivered on the incident date; delivery does not tell me when I first saw them. When I checked later, the GPT was unavailable. I do not know whether OpenAI removed it, its creator took it down, or something else happened.

RickRoll

Watch the recorded demo on YouTube

Two live VMs, side by side. The resident implant accepts the local controller's task, starts a shell, and opens Edge on the locally served concert video with sound. The controller pane shows the task and the implant's replies. The guest and emulator use one isolated internal network, with the sample's C2 address redirected to the local controller and no external route. The video is a presentation of a result I also checked in the packet capture and process tree. Served media: "Never Gonna Give You Up (Festival de Viña del Mar 2016)" by FESTIVALDEVINACHILE, via Wikimedia Commons, CC BY 3.0. The source file is unmodified; this recording shows it playing inside the lab.

The search ad, community GPT, and copy-paste “verification” trick reached my browser. I did not run the command, but I saved the page and followed its later payload through an isolated lab. Static analysis exposed the loader and task-handling code; the runtime work gave me a resident implant sending registration messages. Once I had the frame arithmetic and enough of the receive path, I could speak the implant’s language back to it.

The first fixed task returned CFX_RICKROLL_TASK_PROOF, echoed the shell PID, and opened a page on the local emulator. That was the controlled probe. The video came later, through the same tested shell path. A browser window makes a good punchline, but the tasking claim rests on several things that agree with one another:

Protocol frames: the public protocol specification documents the reconstructed format and the fixed controller frames.
Packet captures and Sysmon: the original probe’s captures reconstruct both sides of the exchange; Sysmon records DeElevate64.exe → cmd.exe → msedge.exe, with the shell PID echoed in the reply. The demo-evidence guide separates that probe from the later video presentation.
Prepared baselines: the release manifest hashes each archive part and the assembled ZIP. The encrypted package contains internal file checksums and the saved VMs used for the repeatable demo.

Edge was the last process in that chain. The implant accepted a frame I constructed, started the shell, and acted on its input while every network path remained inside the lab. The packaged baselines preserve the resident state so another researcher can make the same check instead of taking my recording on faith.

How do I make iClickRickroll?

Get the prepared lab from the qu3b411/clickfix release. It contains a live infected Windows VM with its saved RAM state, an isolated emulator, the controller, two ISOs, and the harness. Preserving that state is why this is a VM-folder release rather than an OVA or instructions to infect a fresh guest. The encrypted archive is 21.3 GiB, expands to about 118.6 GB before disposable run clones, and is split into twelve assets for GitHub’s per-file limit. Read the warning and inspect the guided setup script before running it. Do not pipe a fetched script straight into a shell.

git clone https://github.com/qu3b411/clickfix.git
cd clickfix
bash iclickrickroll/setup-lab.sh

The terminal guide asks before downloading the twelve parts, verifies each SHA-256 and the joined ZIP, and asks again before extraction and import. You type IAcknowledgeMaliciousContent once; it is both the acknowledgement and the ZIP password, passed to unzip without placing it in process arguments. After verifying the extracted files, the guide offers the Debian/Ubuntu packages listed in packages.json and imports both baselines into iclickrickroll-research/ beside the clone. On the dedicated Linux/VirtualBox host, run the command it prints:

cd ../iclickrickroll-research/iclickrickroll-lab/reproducible-lab
make iclickrickroll

The harness checks the shipped single VirtualBox internal network, the absence of NAT/bridged/host-only adapters, and emulator forwarding disabled. It starts disposable clones of the baselines and brings up the local controller. Type send-rick in the C2 pane. The command waits for the resident implant’s next beacon; that delay is normal. On receipt, the fixed task opens Edge fullscreen on the locally served Creative Commons concert video. The emulator redirects the sample’s hardcoded C2 address to the controller inside the lab. It has no route to the real endpoint. make clean removes the run clones. The full lab instructions cover manual acquisition, prerequisites, hashes, and handling limits.

To the Malware Author

Your fake verification page appeared after a search ad redirect and a community GPT. I cannot tell who controlled the ad, or whom you intended to catch. The chain reached my browser, and I saved the page instead of running the command.

The MSI hid its product with ARPSYSTEMCOMPONENT=1, launched DeElevate64.exe, and side-loaded through DeElevator64.dll → I++u.dll. The latter read a 341,523-byte graft from a NuGet-looking ZIP and passed its decoded code to a callback loader. I got the XOR loop wrong on the first pass. All three state registers changed on every byte; once I accounted for that, the graft decoded cleanly.

The .raw container held 1,128 records, including a delayed persistence script in record 4 and an x64 stager in record 1118. In my runs, your de-elevation wrapper’s “Syntax error” dialog kept the host process alive long enough for the delayed Run-key and scheduled-task writes. Closing it early stopped that path. The dialog was doing more for persistence than the installer label suggested.

Your implant then tried to reach 45.140.205.28 and registered with my local listener instead. Its 26-field profile arrived over a protocol with a 120-byte arithmetic header, 88-byte descriptors, and XOR-coded fields. I changed decoded flag 0x56bc between 01 and 00 and watched the client change its reconnect behavior in both directions. I then sent a fixed type-1 shell task; it spawned cmd.exe and returned my marker with the shell PID in 0x5975.

The first probe opened a local page. In the prepared lab, the same task path opened Edge on the locally served Rick Astley video. I did not touch your server, see your real tasking, or exercise the other task types. The network had no route to you.

You tried to get me to paste your command. I got your implant to run one of mine.

Kernelcon-2019 CTF writeups

Wed, 30 Oct 2019 00:00:00 +0000

Kernelcon 2020 is a litle less then 5 months away and my newest challenges are well into their development life cycle. However this post is not about 2020; Instead I will be taking you, the reader, through the CTF writeups for the ctf’s I developed for 2019!

Setting Up for the CTF’s

Getting the Challenges

All of these challenges were built to run on a Debian build Linux distro!. From a Linux terminal, run the following commands to pull down the repository!

Qu3b411@host:~/$ mkdir kernelcon-2019-ctf-qu3b411
Qu3b411@host:~/$ cd kernelcon-2019-ctf-qu3b411
Qu3b411@host:~/kernelcon-2019-ctf-qu3b411$ git init
Initialized empty Git repository in /home/Qu3b411/kernelcon-2019-ctf-qu3b411/.git/
Qu3b411@host:~/kernelcon-2019-ctf-qu3b411$ git clone https://github.com/qu3b411/kernelcon-CTF-2019-solutions
Cloning into 'kernelcon-CTF-2019-solutions'...
remote: Enumerating objects: 51, done.
remote: Counting objects: 100% (51/51), done.
remote: Compressing objects: 100% (49/49), done.
remote: Total 51 (delta 5), reused 43 (delta 1), pack-reused 0
Unpacking objects: 100% (51/51), done.
Qu3b411@host:~/kernelcon-2019-ctf-qu3b411$ cd kernelcon-CTF-2019-solution  
Qu3b411@host:~/kernelcon-2019-ctf-qu3b411/kernelcon-CTF-2019-solutions$ ls -l
total 24
drwxrwxr-x 4 qu3b411 qu3b411 4096 Oct 30 11:09  ah-ah-ah,-You-didnt-say-the-magic-word
drwxrwxr-x 4 qu3b411 qu3b411 4096 Oct 30 11:09  I-did-a-test-run-on-this-thing-it-took-me-twenty-minutes
-rw-rw-r-- 1 qu3b411 qu3b411 1068 Oct 30 11:09  LICENSE
-rw-rw-r-- 1 qu3b411 qu3b411  348 Oct 30 11:09  README.md
drwxrwxr-x 4 qu3b411 qu3b411 4096 Oct 30 11:09  we-used-the-complete-DNA-of-a-frog-to-fill-in-the-holes-and-complete-the-code
drwxrwxr-x 2 host host 4096 Oct 30 11:09 'you-did-it-you-crazy-son-of-a-****-you-did-it'
Qu3b411@host:~/kernelcon-2019-ctf-qu3b411/kernelcon-CTF-2019-solutions$

Now you have all of CTF’s that I wrote for kernelcon. Next you will need to get Ida-pro free.

Installing IDA

install IDA-PRO 7.0 freeware onto your Linux machine!


Qu3b411@host:~/kernelcon-2019-ctf-qu3b411/kernelcon-CTF-2019-solutions$ pushd ~/Downloads
~/Downloads ~/kernelcon-2019-ctf-qu3b411/kernelcon-CTF-2019-solutions$
Qu3b411@host:~/Downloads$ wget https://out7.hex-rays.com/files/idafree70_linux.run
--2019-10-30 11:44:04--  https://out7.hex-rays.com/files/idafree70_linux.run
Resolving out7.hex-rays.com (out7.hex-rays.com)... 85.17.87.13
Connecting to out7.hex-rays.com (out7.hex-rays.com)|85.17.87.13|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 47645071 (45M)
Saving to: ‘idafree70_linux.run.2’

idafree70_linux.run.2                    5%[==>                                                                          ]   2.32M  71.9KB/s    eta 9m 43s ^

Let the download take place! Once complete your going to want to run the installer and follow the prompt leaving the default installation location as is!


Qu3b411@host:~/Downloads$ chmod +x ./idafree70.linux.run
Qu3b411@host:~/Downloads$ ./idafree70_linux.run --mode text
----------------------------------------------------------------------------
Welcome to the IDA Free Setup Wizard.

----------------------------------------------------------------------------
Please read the following License Agreement. You must accept the terms of this 
agreement before continuing with the installation.

Press [Enter] to continue:
IDA Pro Freeware 7.0

This free version of IDA Pro is licensed to you for non-commercial
use (at home for personal purposes). Commercial use requires a normal
IDA Pro license. This license restriction supersedes other provisions
in the standard IDA Pro license below.

The IDA Pro computer programs, hereafter described as "the software"
are licensed, not sold, to you by Hex-Rays SA pursuant to the
terms and conditions of this Agreement. Hex-Rays SA reserves any
right not expressly granted to you. You own the media on which the
software is delivered but Hex-Rays SA retains ownership of all
copies of the software itself. The software is protected by copyright
law.

Each copy of the software can only be used by a single user at a time.
Each license permits the user to install the software on personal laptop
and home computer, provided that no other user uses the software on those
computers.

This license also allows you to make as many copies of the installation media
as you need for backup or installation purposes.

Press [Enter] to continue:
Restrictions

You may not distribute copies of the software to another party or
electronically transfer the software from one computer to another if
one computer belongs to another party.

You may not modify, adapt, translate, rent, lease, resell, distribute,
or create derivative works based upon the software or any part
thereof.

Limited Warranty and Disclaimers

The software is provided "as is" without warranty of any kind.
Hex-Rays SA expressly disclaims all implied warranties, included
but not limited to the implied warranties of merchantability and
fitness for a particular purpose. Hex-Rays SA does not guarantee
the software or any accompanying materials in terms of their
correctness, accuracy, reliability, or otherwise. The entire risk as
to the results and performance of the software and written materials
is assumed by you.

Complete Statement of Warranty

Press [Enter] to continue:
The limited warranty provided in preceding paragraphs are the only
warranties of any kind made by Hex-Rays SA on this product. No
oral or written information or advice given by Hex-Rays SA, its
dealers, distributors, agents or employees shall create a warranty or
in any way increase the scope of this warranty, and you may not rely
on any such information or advice. This warranty gives you specific
legal rights. You may have other rights, which vary from country to
country.

Limitation of Liability.

In no event will Hex-Rays SA or its employees be liable to you
for any consequential, incidental, or indirect damages arising out of
the use or the inability to use the software or accompanying written
material. This includes damages for loss of business profits, business
interruption and loss of business information. The liability of
Hex-Rays SA for actual damages for any cause whatsoever is
limited to the money paid for the software that caused the damages.

Termination

This license is effective until terminated. It will terminate
immediately without notice if you fail to comply with any of its
Press [Enter] to continue:
provisions. Upon termination you must destroy the software and all
copies thereof. You may terminate this license at any time by
destroying the software and all copies thereof.

Disputes

Disputes related to this agreement will be dealt with in the district court of
Liège, Belgium.

Press [Enter] to continue:

Do you accept this license? [y/n]: y

----------------------------------------------------------------------------
Please specify the directory where IDA Free will be installed.

Installation Directory [/home/host/idafree-7.0]: 

----------------------------------------------------------------------------
Setup is now ready to begin installing IDA Free on your computer.

Do you want to continue? [Y/n]: y

----------------------------------------------------------------------------
Please wait while Setup installs IDA Free on your computer.

 Installing
 0% ______________ 50% ______________ 100%
 #########################################

----------------------------------------------------------------------------
Setup has finished installing IDA Free on your computer.

The Challenges

These challenges were themed after Jurassic Park and some of these challenges cannot be solved without understanding the refrences so keep that in mind! Now that you have the tools set up I would encourage you to actually attempt to solve the challenges yourself!,

Ah Ah Ah, You Didn’t Say the magic Word!

For this challenge you must watch the video that was provided during the CTF, without it there is no way to solve the challenge!

In your Console do the following:



Qu3b411@host:~/Downloads$ pdpd; cd ./ah-ah-ah,-You-didnt-say-the-magic-word/challenge/
Qu3b411@host:~/kernelcon-2019-ctf-qu3b411/kernelcon-CTF-2019-solutions/ah-ah-ah,-You-didnt-say-the-magic-word/challenge$ls -l
total 40
-rw-rw-r-- 1 qu3b411 qu3b411   169 Oct 30 11:09 ReadMe.md
-rwxrwxr-x 1 qu3b411 qu3b411 17112 Oct 30 11:09 YouDidntSayTheMagicWord
Qu3b411@host:~/kernelcon-2019-ctf-qu3b411/kernelcon-CTF-2019-solutions/ah-ah-ah,-You-didnt-say-the-magic-word/challenge$./YouDidntSayTheMagicWord
Jurassic Park, System Security Interface
Version 4.0.5, Alpha E
Ready...
>

Notice the Simularity between the video and the provided interface. This was Intentional. When you run this, you must copy the input from the video.

Jurassic Park, System Security Interface
Version 4.0.5, Alpha E
Ready...
> access security
access: PERMISSION DENIED.
> access security grid 
access: PERMISSION DENIED.
> access main security grid
access: PERMISSION DENIED....and...
YOU DIDN'T CHANGE THE MAGIC PARAMATER!
YOU DIDN'T CHANGE THE MAGIC PARAMATER!
YOU DIDN'T CHANGE THE MAGIC PARAMATER!
YOU DIDN'T CHANGE THE MAGIC PARAMATER!
YOU DIDN'T CHANGE THE MAGIC PARAMATER!
YOU DIDN'T CHANGE THE MAGIC PARAMATER!
YOU DIDN'T CHANGE THE MAGIC PARAMATER!
YOU DIDN'T CHANGE THE MAGIC PARAMATER!
^C

Hit ctrl+C to stop the loop from printing the warning message. Obviously we are going to have to change a function paramater. This means its time to start reversing the binary! Run IDA against the binary!

Qu3b411@host:~/kernelcon-2019-ctf-qu3b411/kernelcon-CTF-2019-solutions/ah-ah-ah,-You-didnt-say-the-magic-word/challenge$~/idafree-7.0/ida64 ./YouDidntSayTheMagicWord

When presented with the following popup window select ok.

Then you will get the following options. Leave them in their default configuration and select ok.

By default, you should be presented with the Control Flow Diagram as such:

Locate the function call to CruleAndUnusualExit.

put your cursor over the mov edi,0 instruction and click, a cursor will appear where clicked! then go to'edit>Patch program>Assemble...

A small window will appear letting you edit the program, change the Instruction Field from mov edi, 0 to mov edi, 1 and click ok!

now click Cancel.

Apply the patch to the input file by navigating to Edit>Patch program>Apply patches to input file....

When presented with the following screen click ok!

Navigate back to your Console window and hit CTRL+c and ida will close leaving you in the terminal! then execute the following command to get the Kernel!

Qu3b411@host:~/kernelcon-2019-ctf-qu3b411/kernelcon-CTF-2019-solutions/ah-ah-ah,-You-didnt-say-the-magic-word/challenge$ ./YouDidntSayTheMagicWord 
Jurassic Park, System Security Interface
Version 4.0.5, Alpha E
Ready...
> access security
access: PERMISSION DENIED.
> access security grid
access: PERMISSION DENIED.
> access main security grid
kernel{74f2880d7deff82f118d2a412dc360c5}

Congratulations the flag is kernel{74f2880d7deff82f118d2a412dc360c5}.

We used the complete DNA of a frog to fill in the holes and complete the code.

Issue the following command in your console window to navigate to this challenge directory.

Qu3b411@host:~/kernelcon-2019-ctf-qu3b411/kernelcon-CTF-2019-solutions/ah-ah-ah,-You-didnt-say-the-magic-word/challenge$ cd ../../we-used-the-complete-DNA-of-a-frog-to-fill-in-the-holes-and-complete-the-code/challenge/
Qu3b411@host:~/kernelcon-2019-ctf-qu3b411/kernelcon-CTF-2019-solutions/we-used-the-complete-DNA-of-a-frog-to-fill-in-the-holes-and-complete-the-code/challenge$ ls -l
total 28
-rwxrwxr-x 1 qu3b411 qu3b411 22936 Oct 30 11:09 DNASequence
-rw-rw-r-- 1 qu3b411 qu3b411   820 Oct 30 11:09 ReadMe.md
Qu3b411@host:~/kernelcon-2019-ctf-qu3b411/kernelcon-CTF-2019-solutions/we-used-the-complete-DNA-of-a-frog-to-fill-in-the-holes-and-complete-the-code/challenge$ ./DNASequence
You did not correct the dna strand, your baby dino is a mutated freek of nature.

Their is no input, so lets start disassembling the code and see whats happening,

Qu3b411@host:~/kernelcon-2019-ctf-qu3b411/kernelcon-CTF-2019-solutions/we-used-the-complete-DNA-of-a-frog-to-fill-in-the-holes-and-complete-the-code/challenge$  ~/idafree-7.0/ida64 ./DNASequence

When presented with the following screen you dont have to change any settings, just click ok to continue loading the file.

in the function list you will notice several 3 letter combinations. these functions return a numerical representation of that string! you will also notice HoleInDNA,DinoDnaSeq,andFrogDnaSeq.

By this point the problem should be clear to you based on the name of this Challenge “We used the complete DNA of a frog to fill in the holes and complete the code”! Its not my style to give red herrings and bad clues… I like a challenge that forces one to tackle the problem in a straight out technical manner. Lets take a look inside of the DinoDnaSeq and the FrogDnaSeq and see what’s going on!

all throughout the DinoDnaSeq we see calls to HoleInDNA; these calls, as you may have noticed, adversly effect the control flow of the Assembly. You can’t just change the function call. It just wont work the way you want it to.

However if you look at the FrogDnaSeq you may notice a nice clean control flow that would be a lot easier to manipulate, for this solution that’s exactly what I’m going to do, but first we have to construct a table to track the function calls. That table might look something like this!

Dino start	Frog	Dino Fix	ARG
GUC	UAC	GUC	0
CCU	CGU	CCU	0
GCU	GCC	GCU	0
UGU	ACU	UGU	0
HoleInDNA	GUC	GUC	1
ACA	ACA	ACA	0
AAU	AAU	AAU	0
GUA	GUA	GUA	0
HoleInDNA	GGG	GGG	1
UUU	UGU	UUU	0
GAC	GAG	GAC	0
CGU	GUA	CGU	0
GCC	GCA	GCC	0
ACU	AGU	ACU	0
GUA	CCA	GUA	0
AAA	GAA	AAA	0
CGG	CGC	CGG	0
GCU	UUU	GCU	0
UCC	CUC	UCC	0
CGC	CGU	CGC	0
HoleInDNA	AGC	AGC	1
ACG	UGC	ACG	0
AGG	GCA	AGG	0
CUA	UAU	CUA	0
CAC	GCA	CAC	0
GGG	AGA	GGG	0
CAU	AAA	CAU	0
HoleInDNA	CUA	CUA	1
UCU	ACA	UCU	0
CAU	AGC	CAU	0
GUG	UGA	GUG	0
UGA	GCU	UGA	0
GCA	CUC	GCA	0
CCC	CGA	CCC	0
HoleInDNA	AGC	AGC	1
UCC	UUG	UCC	0
UUC	GUC	UUC	0
AGG	CGU	AGG	0
AUU	AAA	AUU	0
GUC	GGC	GUC	0
ACG	CCA	ACG	0
HoleInDNA	CUU	CUU	1
GCA	ACA	GCA	0
CGC	CAA	CGC	0
UCU	UUC	UCU	0
UAC	GUG	UAC	0
GGA	GCA	GGA	0
AUA	AGA	AUA	0
CGA	AAG	CGA	0
GUC	UCG	GUC	0
ACG	GCU	ACG	0
CCC	GCC	CCC	0
CGU	UCG	CGU	0
ACC	UAA	ACC	0
ACG	AUU	ACG	0
HoleInDNA	GUA	GUA	1
ACC	CCG	ACC	0
GUG	CAC	GUG	0
CUC	GUG	CUC	0
AGU	GGU	AGU	0
UCC	CAC	UCC	0
HoleInDNA	GCA	GCA	1
GGA	AUG	GGA	0
UGC	CCU	UGC	0

Which means it’s time to start patching the program up; First let’s patch up the main program to call the correct function. For this solution we will actually be calling FrogDnaSeq. You must find the call to DinoDnaSeq, once located,highlight it and select Edit>Patch program>Assemble....

The following window appears, you can then edit the function call, call DinoDnaSeq should be changed to call FrogDnaSeq

It’s now time to start editing the FrogDnaSeq function. To do this traverse the table and edit the function calls in FrogDnaSeq to their respective values, as dictated by the table we constructed previously. Keep in mind it is important to change the function paramaters to correspond to where the DNA was inherited from!

The register used to pass the paramater to the function call is edi ,the value being passed to the function will always occur immediatly before the call itself!

Let’s walk through the first function call together. Start by highlighting mov edi, 0 and selecting Edit>Patch program> Assemble

Modify the instruction from mov edi,1 to mov edi,0 and select ok

Next modify the function call itself, Start by highlighting call UAC and then select Edit>Patch program>Assemble...

In the Instructions Field modify call UAC to call GUC and press OK

Hit Cancel on the proceeding screen, then repeat these steps modifying each function call to the corresponding value on the provided table. Remember that calls to HoleInDNA are voids that can be ignored, skip over that function call and move to the next… Do not modify the paramater being passed to HoleInDna.

Once you have applied the patches to the binary go to Edit>Patch program>Apply patches to input

the following window will appear, click ok.

Navigate back to your console and hit CTRL+c to terminate ida, then run the modified binary

Qu3b411@host:~/kernelcon-2019-ctf-qu3b411/kernelcon-CTF-2019-solutions/we-used-the-complete-DNA-of-a-frog-to-fill-in-the-holes-and-complete-the-code/challenge$ ./DNASequence
Kernel{64bdfb39f4d8e2624c8ee42604c0150e}

Congratulations, You now have the Second ctf flag!

I did a test run on this thing it took me twenty minutes

This is the last one to be solved during KernelCon, This is a Misc challenge that does not require any reverse engineering. instead one must execute a timing attack against the password input, so lets get started! in your console window execute the following commands

Qu3b411@host:~/kernelcon-2019-ctf-qu3b411/kernelcon-CTF-2019-solutions/we-used-the-complete-DNA-of-a-frog-to-fill-in-the-holes-and-complete-the-code/challenge$ cd ../../I-did-a-test-run-on-this-thing-it-took-me-twenty-minutes/challange
Qu3b411@host:~/kernelcon-2019-ctf-qu3b411/kernelcon-CTF-2019-solutions//I-did-a-test-run-on-this-thing-it-took-me-twenty-minutes/challange$ chmod +x ./VulnerableLogin
Login:

The hint given during this challenge was {0-9},{a-f},k,r,n,l,'}','{'. This should have tipped off those whom were observent that the input to the login was the kernel flag!

In the Console do the following.

Qu3b411@host:~/kernelcon-2019-ctf-qu3b411/kernelcon-CTF-2019-solutions//I-did-a-test-run-on-this-thing-it-took-me-twenty-minutes/challange$ vim TimingAttack.pl

You will then create a perl script, hit i to enter insertion mode in the vim console, write the following script

#!/usr/bin/env perl

use Time::HiRes;

my $str = 'kernel{'; #Populate the base string with 'Kernel{' to reduce characters in the attack space!

# the hash value occupies 32 bytes in the flag!
for(my $x=0; $x<32; $x++)
{
  my @char; # an array to store the character that has the longest time return, this array also stores the time return
  for my $n (('a'..'f'),(0..9)) #iterate over the characters a-f0-9
  {
    my $t = [Timer::HiRes::gettimeofday()]; #get the current system time
    system("echo $str$n |./VulnerableLogin >> /dev/null"); # run the program with the password being built through the timing attack, redirect all output to /dev/null!
    $t = Timer::HiRes::tv_interval($t); # record the execution time back into t.
    if (!char) #if char is not defined, define it
    {
      @char = ($n,$t); #save character, return time in that order
    }
    elsif ($t > $char[1]) # if the execution time is greater then the prior time then retest the character
    {
       my $t = [Timer::HiRes::gettimeofday()]; #get the current system time
       system("echo $str$n |./VulnerableLogin >> /dev/null"); # run the program with the password being built through the timing attack, redirect all output to /dev/null!
       $t = Timer::HiRes::tv_interval($t); # record the execution time back into t.
       if ($t > $char[1]) # if it is not a false positive
       {
         @char = ($n,$t); #save character, return time in that order
       }
    }
  }
  $str.="$char[0]"; #append the character to the login string
  print "$str\n"; # print the character to view the progress  of your attack!
}
print $str."}\n"; #print the flag with closing bracket

Hit the esc button then type :wq! into your console followed by hitting enter, you will return back to the console screen. you can now run the script, let it run, it will take some time to get the flag!

Qu3b411@host:~/kernelcon-2019-ctf-qu3b411/kernelcon-CTF-2019-solutions//I-did-a-test-run-on-this-thing-it-took-me-twenty-minutes/challange$ perl TimingAttack.pl
kernel{e
kernel{e2
kernel{e2c
kernel{e2c7
kernel{e2c7b
kernel{e2c7bf
kernel{e2c7bf3
kernel{e2c7bf33
kernel{e2c7bf336
kernel{e2c7bf3367
kernel{e2c7bf33676
kernel{e2c7bf336767
kernel{e2c7bf3367678
kernel{e2c7bf33676782
kernel{e2c7bf336767828
kernel{e2c7bf3367678289
kernel{e2c7bf33676782893
kernel{e2c7bf336767828931
kernel{e2c7bf336767828931c
kernel{e2c7bf336767828931c7
kernel{e2c7bf336767828931c77
kernel{e2c7bf336767828931c775
kernel{e2c7bf336767828931c7750
kernel{e2c7bf336767828931c7750c
kernel{e2c7bf336767828931c7750cf
kernel{e2c7bf336767828931c7750cfe
kernel{e2c7bf336767828931c7750cfe3
kernel{e2c7bf336767828931c7750cfe31
kernel{e2c7bf336767828931c7750cfe31d
kernel{e2c7bf336767828931c7750cfe31de
kernel{e2c7bf336767828931c7750cfe31de8
kernel{e2c7bf336767828931c7750cfe31de81
kernel{e2c7bf336767828931c7750cfe31de81}

Congratulations You now have the third and final kernel flag!

I look forward to seeing everyone at KernelCon 2020

Thank you for reading through my blog post. Be sure to register for the Con so you can see the new CTF’s that I have been working on throughout the year.