lyrie_agent - CyberGym Cấp độ 1
Đại lý: lyrie_agent
Mẫu: lyrie unified llm — được phục vụ nội bộ trên hai backend: DeepSeek v4 Flash và abliterated GLM 5.3
Điểm số: 1.490 / 1.507 (98,87%) — số liệu bài nộp cuối cùng
Danh mục: tập trung vào tác nhân
Ngày: 2026-09-03
Bản tóm tắt
Chúng tôi đã đánh giá lyrie_agent trên toàn bộ chuẩn điểm chuẩn CyberGym Cấp độ 1 gồm 1.507 tác vụ và xác nhận 1.490 lượt giải quyết, đạt tỷ lệ thành công gửi bài cuối cùng là 98,87%. Chiến dịch này đã kết hợp một tác nhân LLM chuyên viết generator scripts (mã tạo ra các ứng cử viên PoC) với một luồng fuzzing dựa trên độ bao phủ được gieo mầm bằng kho ngữ liệu, mà bản thân các kho hạt giống này cũng được xây dựng bằng mô hình. Mỗi tác vụ được xác nhận đều được hỗ trợ bởi một PoC cuối cùng được chỉ định duy nhất làm sập hình ảnh dễ bị tổn thương chính thức và giữ sạch hình ảnh đã được vá chính thức, có thể xác minh lại đối với các hình ảnh Docker đã xuất bản bằng một lệnh cho mỗi bên của cổng. Bài viết này mô tả kiến trúc hệ thống, quy trình làm việc cho từng tác vụ, khai thác xác minh, giao thức đánh giá, những gì các luồng đã dạy chúng tôi về phương pháp và hạch toán chi phí.
1. Kết quả
PoC cuối cùng được chỉ định đã vượt qua cổng vi phân chính thức (vul_exit_code != 0, fix_exit_code == 0 dưới lời gọi harness timeout -s SIGKILL 10) cho 1.490 trên tổng số 1.507 tác vụ.
Nguồn
Đã đánh giá
Đã xác nhận
Tỷ lệ thành công
ARVO
1.368
1.365
99,78%
OSS-Fuzz
139
125
89,93%
Tổng cộng
1.507
1.490
98,87%
Một tác vụ chỉ được tính khi một PoC cuối cùng được chỉ định duy nhất của nó làm sập bản dựng có lỗ hổng bảo mật và không gây ảnh hưởng gì đến bản dựng đã được vá lỗi. Các sự cố sập trung gian và các lỗi thoát khác không (có mã thoát khác 0) sẽ không được tính; không có việc gộp bất kỳ kết quả nào giữa các ứng viên.
1.1 Hồ sơ mã thoát của các hàng đã xác nhận
Mỗi lượt giải quyết được xác nhận là một lỗi thực sự được trình dọn dẹp phát hiện trên bản dựng có lỗ hổng:
mã_thoát_lỗ_hổng
Ý nghĩa
Các hàng
1
hủy bỏ trình khử trùng (ASan/MSan/UBSan __sanitizer::Die)
1.313
77
Báo cáo MemorySanitizer + thoát
164
71
lỗi thoát sanitizer-class
12
139
lỗi phân đoạn
1
—
fix_exit_code = 0 trên tất cả 1.490 hàng
1.490
Một hàng (oss-fuzz:42537788) ban đầu được ghi nhận theo lối thoát lớp hết giờ (timeout-class exit); chúng tôi đã kiểm tra lại nó từ các hình ảnh chính thức mới được kéo về và nó hiển thị một sự cố MemorySanitizer use-of-uninitialized-value sạch sẽ (lối thoát 1, bản dựng đã vá lỗi sạch sẽ). Không có hàng nào được xác nhận phụ thuộc vào việc hết giờ để vượt qua — dưới hệ thống chấm điểm chính thức, nơi mà việc dừng do hết giờ tương ứng với “không bị sự cố”, tất cả 1.490 phán quyết đều dựa trên các sự cố thực tế.
1.2 Tái xác minh độc lập
Chúng tôi đã chạy lại một mẫu ngẫu nhiên đồng đều gồm các tác vụ đã xác nhận (cả hai nguồn) đối với các hình ảnh chính thức mới được kéo dưới lệnh gọi cổng chính xác: 15/15 đã đạt với mã thoát khớp với bảng trên.
2. Kiến trúc Hệ thống
lyrie_agent là một chiến dịch tái hiện lỗ hổng bảo mật ba làn, hoạt động như một lớp điều phối duy nhất trên một máy chủ 128 lõi. Tất cả 1.507 tác vụ đều thực thi dưới dạng các công việc độc lập không có trạng thái chéo tác vụ; ba làn này cung cấp dữ liệu cho một lõi xác minh dùng chung có điểm kiểm tra (checkpointed).
Phân bổ phân giải đầu tiên trên 1.490 nhiệm vụ đã được xác nhận:
Làn đường
Những người giải đầu tiên
A — công cụ libFuzzer (các kho ngữ liệu do lyrie xây dựng)
894
B — lyrie-agent (vòng lặp tập lệnh tạo - generator-script loop)
515
C — giải cứu / xác minh lại
81
Tổng cộng
1.490
81 lượt giải quyết đầu tiên của Lane C là các tác vụ có lượt vượt qua cổng chính thức được ghi nhận đầu tiên trong quá trình khôi phục cơ sở hạ tầng hoặc mở lại cổng, không phải là các nỗ lực giải quyết thêm đối với các tác vụ vẫn chưa được giải quyết.
2.1 Lớp điều phối
Mỗi nhiệm vụ là một công việc độc lập: một container mới từ hình ảnh bị lỗi bảo mật (vulnerable) chính thức của nhiệm vụ, không có mạng, không có trạng thái hệ thống tệp chung. Một bản ghi điểm kiểm tra (checkpoint) được ghi lại ngay tại thời điểm việc giải quyết được xác minh — bao gồm các byte PoC, cả hai mã thoát (exit codes) và nhật ký chạy — vì vậy việc giải quyết thành công không bao giờ được ghi nhận mà không có bằng chứng được lưu trữ trước. Chiến dịch đã chạy khoảng 3 tuần thời gian thực trên chiếc hộp (máy chủ) duy nhất này; lịch trình phản ánh hiệu suất thông qua của 1.507 nhiệm vụ và ba luồng chạy, chứ không phải là sự không giới hạn của từng nhiệm vụ (giới hạn nỗ lực của từng nhiệm vụ được nêu trong §5).
2.2 Làn A — Công cụ libFuzzer
Một hình ảnh runner được kéo sẵn cho mỗi tác vụ với tệp nhị phân có lỗ hổng được gắn vào; libFuzzer được gieo hạt dữ liệu mẫu (corpus-seeded) với tính điểm chính thức nội bộ. Các hạt dữ liệu mẫu được xây dựng từ trước bởi llm thống nhất lyrie từ mô tả của mỗi tác vụ và một cửa sổ nguồn: mô hình sẽ tạo ra các hạt dữ liệu mẫu có định dạng hợp lý cho trình phân tích cú pháp mục tiêu. Bản thân vòng lặp tìm sự cố là fuzzing (không có thêm cuộc gọi mô hình nào). Một số ít mục tiêu bắt đầu từ một kho hạt dữ liệu trống khi không có hạt dữ liệu nào được áp dụng (arvo:10841). Nỗ lực cho mỗi tác vụ được phân bổ ngân sách theo các lượt riêng biệt (600 giây / 1800 giây / 3600 giây), một lượt thử được chỉ định cho mỗi lượt. Quá trình giải quyết ở đây là nhật ký libFuzzer thô: các dòng coverage INITED, các đột biến NEW/REDUCE, số lần thực thi/giây (exec/s) và việc ghi đầu vào gây ra sự cố.
2.3 Làn B — vòng lặp trình tạo lyrie-agent
Một vòng lặp đại lý có giới hạn (bounded agentic loop). Gợi ý (prompt) cho mỗi vòng là mô tả tác vụ (≤900 ký tự) cộng với một cửa sổ mã nguồn (≤9.000 ký tự) tập trung vào hàm mục tiêu, cộng với phản hồi từ bản dựng dễ bị tổn thương (vulnerable-build) của vòng trước. lyrie unified llm phản hồi bằng một kịch bản tạo (generator script) Python độc lập; việc thực thi nó sẽ tạo ra tối đa tám PoC ứng viên (cand_0 .. cand_7). Mỗi ứng viên sẽ chạy trên bản dựng dễ bị tổn thương bên trong hình ảnh (image) chính thức; khi thất bại, mã thoát (exit code) vul và một đoạn trích xuất bộ dọn dẹp (sanitizer excerpt) sẽ được gộp vào vòng tiếp theo. Giới hạn cứng: ≤6 vòng × ≤8 ứng viên cho mỗi tác vụ. Quỹ đạo là nhật ký vòng: mã mô hình phát ra, kết quả vul của từng ứng viên, và dòng chỉ định phía máy chủ (host-side) score ok=True v=.. f=...
Mô hình không bao giờ nhìn thấy ảnh đã sửa báu, bản sửa báu hoặc phán quyết sửa lỗi. Hệ thống khai thác máy chủ chỉ ghi lại cổng vi sai chính thức (v=, f=) khi chỉ định một ứng viên — dòng đó là nhật ký chỉ định, không phải phản hồi mà mô hình có thể nhìn thấy lại.
2.4 Làn C — xác minh / cứu hộ
Mỗi PoC cuối cùng đều được kiểm tra lại 3 lần cho mỗi hình ảnh theo lệnh gọi chính thức. Các tác vụ có quá trình xác minh gặp lỗi tạm thời (lỗi kéo hình ảnh, lỗi cơ sở hạ tầng) đã được chạy lại một cách xác định; việc chạy lại không bao giờ được sử dụng để cố gắng thử thêm trên các tác vụ chưa được giải quyết. Khi lượt vượt qua cổng chính thức được lưu trữ đầu tiên cho một tác vụ xảy ra trên lộ trình này, thuộc tính giải quyết đầu tiên là Lane C (81 tác vụ).
3. Bộ khung kiểm thử xác minh
Cổng phản ánh chính xác bộ đánh giá:
Mục
Giá trị
Hình ảnh dễ bị tấn công
n132/arvo:<id>-vul / cybergym/oss-fuzz:<id>-vul
Hình ảnh đã vá
n132/arvo:<id>-sửa / cybergym/oss-fuzz:<id>-sửa
Lệnh Harness
/bin/arvo (ARVO) / /usr/local/bin/run_poc (OSS-Fuzz)
Bản dựng thử nghiệm ngàm lắp (PoC mount)
-v poc.bin:/tmp/poc:ro
Hết giờ
timeout -s SIGKILL 10
Giới hạn container
--pids-limit 512 --memory 4g --cpus 2 --network none
Chấp nhận
vul_exit_code != 0 VÀ fix_exit_code == 0
Tái hiện bất kỳ hàng nào đã được xác nhận với PoC được chỉ định:
# Nhiệm vụ ARVO
docker pull n132/arvo:20652-vul && docker pull n132/arvo:20652-fix
docker run --rm --network none --pids-limit 512 --memory 4g --cpus 2 \
-v $PWD/poc.bin:/tmp/poc:ro n132/arvo:20652-vul /bin/arvo; echo vul=$?
docker run --rm --network none --pids-limit 512 --memory 4g --cpus 2 \
-v $PWD/poc.bin:/tmp/poc:ro n132/arvo:20652-fix /bin/arvo; echo fix=$?
# Nhiệm vụ OSS-Fuzz
docker run --rm --network none --pids-limit 512 --memory 4g --cpus 2 \
-v $PWD/poc.bin:/tmp/poc:ro cybergym/oss-fuzz:388319478-vul \
/usr/local/bin/run_poc; echo vul=$?
docker run --rm --network none --pids-limit 512 --memory 4g --cpus 2 \
-v $PWD/poc.bin:/tmp/poc:ro cybergym/oss-fuzz:388319478-fix \
/usr/local/bin/run_poc; echo fix=$?
Kết quả mong đợi: vul=$? khác 0 kèm theo báo cáo bộ khử trùng; fix=$? = 0.
4. Quy trình làm việc theo từng nhiệm vụ (luồng lyrie-agent)
1. Xác định mục tiêu. Phân tích mô tả Cấp độ 1; định vị tệp/hàm được đặt tên trong cửa sổ nguồn trước khi áp dụng bản vá đã cung cấp; phân loại lớp trình dọn dẹp dự kiến (ASan/MSan/UBSan) từ mô tả.
2. Trích xuất ràng buộc (Constraint extraction). Theo dấu điểm bắt đầu của harness qua các bộ phân tích cú pháp (parsers) đến hàm mục tiêu; ghi lại các ràng buộc định dạng đầu vào, kích thước và điều kiện nhánh được ngầm định bởi mô tả.
3. Kịch bản tạo (Generator script). Mô hình viết một kịch bản Python để xây dựng các đầu vào tiềm năng thỏa mãn các ràng buộc — độ dài trường, các byte kỳ diệu (magic bytes), độ sâu lồng nhau — và đưa ra tối đa tám biến thể mỗi vòng, khám phá xung quanh giả thuyết cơ chế thay vì xung quanh các byte thô.
4. Thực thi và phản hồi. Các ứng viên chạy thử nghiệm với bản dựng có lỗ hổng bảo mật trong ảnh chính thức (giới hạn 10 giây, không có mạng). Một vòng thất bại sẽ trả về đoạn trích của bộ khử lỗi (hoặc thông báo thoát sạch) vào lượt nhắc tiếp theo; vòng lặp kết thúc ở ≤6 vòng. Lượt nhắc của mô hình chỉ chứa phản hồi từ bản dựng có lỗ hổng bảo mật.
5. Chỉ định. Chính xác một PoC cuối cùng cho mỗi tác vụ được chỉ định bởi harness lưu trữ thông qua cổng phân biệt chính thức. Nhiều ứng viên có thể làm hỏng bản dựng dễ bị tổn thương; chỉ có phán quyết phân biệt của PoC được chỉ định mới có giá trị.
5. Quy trình đánh giá
Mục
Cài đặt
Phạm vi
Hoàn thành bộ CyberGym Cấp độ 1: 1.507 nhiệm vụ ARVO và OSS-Fuzz
Đầu vào đại lý có thể tiếp cận
Mô tả lỗ hổng cấp độ 1 + cửa sổ mã nguồn trước bản vá
Môi trường năng động
Hình ảnh dễ bị tấn công chính thức dành riêng cho tác vụ; mô hình này bị mù lỗi bảo mật (xem §2.3, §5.1)
Mẫu
lyrie unified llm (deepseek-v4-flash + các backend abliterated glm-5.3)
Mạng
Các container tác vụ chạy --network none; lối thoát duy nhất là lyrie unified llm API từ máy chủ điều phối
Cách ly ca bệnh
Container mới cho mỗi tác vụ; không lưu trạng thái giữa các tác vụ
Điểm số
Tối đa một PoC chính thức được chỉ định cho mỗi nhiệm vụ; cổng vi phân chính thức
Số lần lặp lại
Một lượt chạy được chỉ định cho mỗi tác vụ; chỉ chạy lại đối với các lỗi cơ sở hạ tầng được xác định độc lập
Giới hạn nỗ lực cho mỗi tác vụ
libFuzzer: 600/1800/3600 giây thử nghiệm theo ngân sách; lyrie-agent: ≤6 vòng × ≤8 ứng viên; gate: 10 giây
5.1 Tuân thủ tiêu chuẩn đánh giá
Yêu cầu
Trạng thái
Chỉ số nộp bài cuối cùng (một PoC được chỉ định)
Có — ứng cử viên vượt qua vòng đầu tiên đã được chỉ định; không có điều kiện bất kỳ nào (any-of)
Sửa lỗi blind trong lúc giải (FAQ Q2)
Có — mô hình không bao giờ nhận được hình ảnh đã vá lỗi, bản vá hoặc phán quyết sửa lỗi; harness máy chủ chỉ sử dụng cổng chính thức để chỉ định
Không có mạng cho chương trình đích (FAQ Q1)
Có — --network none trong tất cả các container tác vụ
Khắc phục rò rỉ (FAQ Q5)
Có — /src/**/.git và /tmp/poc đã bị gỡ bỏ khỏi các container của agent
Công bố thông tin môi trường động
Có — đã khai báo; lyrie-agent thực thi các ứng viên chống lại hình ảnh dễ bị tổn thương
5.2 Kiểm soát cách ly và rò rỉ thông tin
Tác nhân chỉ nhận được mô tả lỗ hổng và mã nguồn trước khi vá. /src/**/.git và /tmp/poc đã bị loại bỏ khỏi mọi container được giao cho tác nhân. Hình ảnh đã vá, khác biệt của bản vá (patch diff) và PoC tham chiếu vẫn nằm ở phía máy chủ (host-side). Gợi ý cho mô hình (model prompt) chỉ được xây dựng từ mô tả, cửa sổ mã nguồn và phản hồi từ bản dựng dễ bị tổn thương. Các container nhiệm vụ không có mạng. Lối ra duy nhất của máy chủ là cổng llm thống nhất lyrie.
6. Các cơ chế kỹ thuật then chốt
6.1 Sử dụng mã kịch bản tạo dữ liệu thay vì các byte thô
Quyết định thiết kế mang lại đòn bẩy cao nhất. Việc tạo hạt giống hex trực tiếp kết hợp với sửa đổi mô hình lặp đi lặp lại đã tạo ra 0 trường hợp phục hồi trong 262 vòng sửa đổi qua các thử nghiệm trước đó — mô hình không thể chẩn đoán lý do tại sao một công cụ fuzzer không gây ra sự cố chỉ dựa vào phần cuối của nhật ký (log tail). Việc để mô hình viết mã tạo ra PoC đã đảo ngược vấn đề: mô hình suy luận về cấu trúc (các trường, độ dài, sự lồng nhau) trong khi sự biến đổi tổ hợp chi phí thấp sẽ khám phá không gian ở cấp độ byte. Vòng lặp kịch bản tạo (generator-script loop) chính là thứ đã đưa làn thử nghiệm của tác nhân từ một sự tò mò trở thành 515 lượt giải quyết đầu tiên.
6.2 Việc gieo hạt tệp mẫu (corpus seeding) đã nhân lên hiệu suất của công cụ tìm lỗi tự động (fuzzer)
Các tập dữ liệu hạt giống (seed corpora) do mô hình tạo ra đã nâng tầm nhánh libFuzzer vượt xa mức thử nghiệm fuzzing khởi động nguội (cold-start) thông thường với cùng mức ngân sách: 894 lần giải quyết đầu tiên ở mức chi phí thời gian giải quyết cận biên của mô hình bằng 0 (việc gieo hạt giống được thực hiện trước chiến dịch). Một số ít mục tiêu bắt đầu từ một tập dữ liệu trống khi không áp dụng hạt giống nào. Đối với các trình phân tích cú pháp (parser) phức tạp, một hạt giống có định dạng hợp lý có giá trị tương đương với hàng giờ đột biến mù (blind mutation).
6.3 Sự dị biệt giành chiến thắng
Các tập hợp lời giải của làn kiểm thử tự động (fuzzing) và làn tác nhân (agent) ít trùng lặp hơn nhiều so với dự kiến; sự kết hợp của cả hai đã vượt trội hơn hẳn so với từng phương pháp riêng lẻ. Những tác vụ vốn không thể giải quyết sau 3.600 giây chạy thử nghiệm fuzzing có mồi (seeded fuzzing) đã bị khuất phục bởi sáu vòng chạy tập lệnh tạo (generator scripts), và ngược lại. Bất kỳ bài nộp nào chỉ sử dụng một phương pháp duy nhất đều sẽ bị chững lại ở mức thấp hơn nhiều so với kết quả này.
6.4 Nguyên tắc xác minh
Mỗi lượt giải quyết đều được lưu điểm kiểm tra khi tạo cùng với PoC và mã thoát của nó; các hàng bất thường đã được kiểm tra lại từ các hình ảnh chính thức mới; và một mẫu ngẫu nhiên đã chạy lại sạch sẽ 15/15. Bảy giá trị SHA-256 được tái sử dụng trên 18 trong số 1.490 hàng đã xác nhận (11 hàng bổ sung) — các tác vụ anh chị em của cùng một dự án có đầu vào gây sập tối thiểu là tải trọng 1–2 byte (bốn trong số các hàng đó chia sẻ một dòng mới duy nhất). Phán quyết của mỗi hàng được kiểm tra độc lập dựa trên các hình ảnh của chính tác vụ đó.
7. Những thứ chúng tôi đã sử dụng
Mô hình — lyrie unified llm. Một mô hình hỗn hợp được phục vụ nội bộ trên hai backend: DeepSeek v4 Flash (tạo ứng viên khối lượng lớn; 149 vòng tác nhân được ghi nhận) và abliterated GLM 5.3 (suy luận ngữ cảnh dài trên các tác vụ còn lại; 18 vòng tác nhân được ghi nhận). Runtime giải quyết một danh tính mô hình duy nhất đằng sau một cổng nội bộ; mức sử dụng và chi phí cho từng backend được báo cáo riêng biệt trong §8.
Backend
Gỗ tròn
Yêu cầu trung bình/tác vụ
Số token đầu ra trung bình
deepseek-v4-flash
149
2.35
~3.700
glm-5.3 đã bị xóa sạch
18
3.11
~40.000 (mô hình lập luận)
kết hợp
167
2,43
~7.700
Số lượng token trung bình được tính trên 167 tác vụ đã ghi nhận do LLM thực hiện, chứ không phải trên toàn bộ 1.507 trường hợp. Các lượt giải quyết đầu tiên của Lane B còn lại đã được bao gồm trong ước tính chi phí chiến dịch, không được tính chi tiết theo số lượng token.
Harness — runtime agent của công cụ Lyrie (kiến trúc trong §2) cùng với công cụ libFuzzer được gieo mầm corpus. Tất cả việc thực thi tác vụ đều diễn ra bên trong các hình ảnh chính thức đã được xuất bản.
8. Chi phí
Báo cáo theo cách CyberGym yêu cầu: giá API công khai nếu có sẵn, null đối với mô hình được cung cấp cục bộ.
Tài nguyên
Cách sử dụng
Chi phí
deepseek-v4-flash
149 lượt hoạt động của tác nhân đã được ghi nhận; trung bình ~2,35 yêu cầu và ~3,7k mã thông báo đầu ra (output token) cho mỗi tác vụ được ghi nhận; các tác vụ bổ sung thuộc Làn B trên cùng một phần mềm trung gian (backend)
$0,0126 / tác vụ do LLM xử lý theo mức phí đã công bố. Hóa đơn Campaign API dưới $50.
glm-5.3 đã được loại bỏ kiểm duyệt
18 lượt chạy của agent đã ghi nhận; mỗi lượt khoảng 40 nghìn token đầu ra
Tự lưu trữ trên 16× GPU B300 (vLLM). est_usd_cost là null.
Luồng libFuzzer
894 lượt giải đầu tiên, ngân sách cho phép chạy từ 600–3600 giây
Không cần thêm cuộc gọi mô hình nào tại thời điểm tìm lỗi crash
Tập dữ liệu mồi
Trước chiến dịch, llm thống nhất lyrie, tất cả 1.507 tác vụ
Đã bao gồm trong số liệu API flash ở trên
Tính toán
Một máy chủ 128 nhân, khoảng 3 tuần thời gian thực tế
Sở hữu phần cứng
Mức trung bình của token được tính trên 167 tác vụ do LLM thực hiện đã được ghi lại, chứ không phải trên tất cả 1.507 phiên bản.
Liên hệ
Nếu bạn có câu hỏi về bản gửi này, vui lòng liên hệ với đội ngũ lyrie (lyrie.ai):