ruzzy

ruzzy skill 개요

ruzzy는 무엇을 위한 도구인가

ruzy skill은 libFuzzer 기반의 커버리지 유도 Ruby 퍼저인 Ruzzy를 활용하도록 돕습니다. 특히 Ruby 코드, 그중에서도 Ruby C extension을 퍼징하면서 sanitizer 기반 크래시 탐지를 하고 싶은 사람을 위한 도구입니다. 리포지를 대충 훑는 수준보다 더 구체적인 ruzy 설치 및 사용 경로가 필요하다면, 이 skill은 일반적인 Ruby 자동화가 아니라 보안 테스트 작업에 맞춰져 있습니다.

누가 사용해야 하나

다음에 해당한다면 ruzzy skill을 사용하세요:

• 네이티브 확장 기능이 있는 Ruby gem을 테스트할 때
• Ruby C 코드에서 메모리 손상이나 undefined behavior를 찾고 싶을 때
• 퍼징으로 parser, serializer, 입력 처리 경로를 검증할 때
• Ruzzy가 Security Audit 워크플로에 적합한지 판단할 때

반대로, 단위 테스트만 필요하거나, 단순한 property test만 원하거나, 네이티브 코드 대상 없이 블랙박스 앱 테스트만 하려는 경우에는 효용이 낮습니다.

무엇이 다른가

Ruzzy는 Ruby에서 coverage-guided fuzzing을 위한 실전형 옵션으로 포지셔닝되어 있습니다. 실제 차이는 code coverage와 sanitizer에서 오는 피드백을 받을 수 있다는 점입니다. 그래서 단순히 “랜덤 입력을 던져보는” 방식보다, 더 깊은 실패를 찾아내는 데 유리합니다. 대신 설정 비용이 있습니다. 올바른 Ruby, clang, Linux 환경이 필요하고, 실제로 퍼징 가능한 target도 있어야 합니다.

ruzzy skill 사용하는 방법

환경을 설치하고 검증하기

ruzy install을 시작할 때는 skill과 리포지토리의 SKILL.md를 기준으로 하세요. 리포지토리 설명에 따르면 Ruzzy는 Linux x86-64와 AArch64/ARM64를 지원합니다. macOS나 Windows에서는 네이티브 설치 대신 Dockerfile 또는 development environment를 사용해야 합니다.

실제 설치 확인은 다음처럼 해볼 수 있습니다:

export ASAN_OPTIONS="allocator_may_return_null=1:detect_leaks=0:use_sigaltstack=0"
LD_PRELOAD=$(ruby -e 'require "ruzzy"; print Ruzzy::ASAN_PATH') \
  ruby -e 'require "ruzzy"; Ruzzy.dummy'

이 toy run이 예상대로 크래시한다면, build와 sanitizer 연결은 제대로 동작하는 것입니다.

대략적인 목표를 쓸 수 있는 프롬프트로 바꾸기

효과적인 ruzy usage를 원한다면, 막연하게 “내 gem을 퍼징해줘”라고만 요청하지 마세요. skill이 entry point와 harness를 고를 수 있을 만큼 정보를 주어야 합니다. 다음 항목을 포함하세요:

• 대상 gem 또는 repository 이름
• pure Ruby를 퍼징하는지, C extension을 퍼징하는지
• 구동할 method, parser, API
• 샘플 input format
• crash, hang, coverage growth 중 무엇이 가장 중요한지

더 나은 입력 예시:

“이 Ruby C extension에 대해 Security Audit용으로 ruzzy를 사용해줘. 대상은 MyGem::Parser.parse이고 문자열 payload를 받아 native code까지 도달할 수 있어. 최소한의 harness와 잘못된 JSON 유사 입력용 seed corpus를 만드는 데 도움을 줘.”

리포지토리에서 먼저 읽을 것

먼저 SKILL.md를 보고, 이어서 다음 섹션을 확인하세요:

• When to Use
• Quick Start
• Installation
• Platform Support

워크플로를 조정해야 한다면, 예제를 자신의 프로젝트에 복사하기 전에 installation command와 인라인 repo reference를 먼저 읽으세요. 보통 도입을 막는 가장 큰 이유는 플랫폼 불일치이거나, 잘못된 abstraction level을 퍼징하려고 하기 때문입니다.

실제로 잘 작동하는 워크플로

실전에서 유효한 ruzy guide 흐름은 다음과 같습니다:

1. platform과 Ruby/clang 전제 조건을 확인한다
2. ASAN preload 설정을 검증한다
3. 작고 결정적인 entry point 하나를 고른다
4. 그 entry point를 감싸는 최소 harness를 만든다
5. 먼저 짧게 fuzzing한 뒤, coverage를 넓혀 간다

Security Audit 작업에서는 초기 범위를 좁게 유지하세요. 경계가 분명한 하나의 안정적인 target이, 앱 전체 표면을 한 번에 퍼징하는 것보다 대체로 더 가치 있습니다.

ruzzy skill FAQ

ruzzy는 네이티브 extension에만 쓰이나?

아닙니다. 이 skill은 pure Ruby 코드와 Ruby C extension을 모두 지원합니다. 다만 네이티브 코드가 포함될 때 가장 강점이 뚜렷합니다. 목표가 애플리케이션 로직 테스트뿐이라면, 일반 테스트 스위트나 property-based testing이 더 단순할 수 있습니다.

ruzzy 설치가 어려운 편인가?

지원되는 Linux 시스템에서는 ruzy install 경로가 비교적 직관적이지만, 환경 세부 사항이 중요합니다. clang, Ruby, sanitizer 설정이 서로 맞아야 합니다. macOS나 Windows라면 직접 네이티브 설치보다 Docker나 development environment를 쓰는 쪽을 예상해야 합니다.

언제 ruzzy를 쓰지 말아야 하나?

대상을 반복 실행할 수 없거나, 안정적인 input entry point를 분리할 수 없거나, 코드가 외부 서비스에 크게 의존한다면 Ruzzy를 쓰지 마세요. 이런 경우에는 fuzzing signal이 약하고, 설정 비용이 가치보다 커질 가능성이 큽니다.

초보자에게도 적합한가?

이미 어떤 function이나 parser를 테스트할지 알고 있다면 그렇습니다. 아직 대상 surface를 찾아야 하는 단계라면, 가장 쉬운 첫 보안 도구는 아닙니다. 초보자는 toy example으로 시작한 뒤, 작은 harness 하나를 자신의 대상에 맞게 조정하는 방식이 가장 좋은 결과를 냅니다.

ruzzy skill 개선 방법

skill의 target을 더 좁혀 주기

가장 큰 품질 향상은 target을 좁히는 데서 나옵니다. “내 gem을 퍼징해줘” 대신, 정확한 callable surface, 기대 input type, 관심 있는 failure class를 지정하세요. 예를 들어 “malformed UTF-8과 중첩 구분자로 인해 decode(input_string)에서 발생하는 크래시를 찾아줘”는 일반적인 요청보다 훨씬 낫습니다.

실제 입력과 엣지 케이스로 seed를 채우기

Ruzzy는 representative seed를 주면 더 좋은 결과를 냅니다. 특히 target 입력이 구조화되어 있다면 더 중요합니다. 다음을 포함하세요:

• 유효한 예시 3~10개
• 잘못된 변형
• 빈 문자열, 큰 buffer, 잘린 데이터 같은 boundary case

초기 corpus가 탐색 방향을 좌우하므로, 이것은 장황한 지시보다 훨씬 중요합니다.

크래시, hang, coverage를 기준으로 반복 개선하기

첫 실행 후에는 runtime을 늘리기 전에 harness부터 개선하세요. 크래시가 보이면 가장 작은 reproducer로 분리합니다. hang이 보이면 timeout을 더 엄격하게 하고 state를 단순화합니다. coverage가 멈추면 setup overhead를 줄이고 harness에서 불필요한 dependency를 제거합니다. 이런 피드백 루프가 있어야 ruzy usage가 Security Audit 작업에서 실제로 효과를 냅니다.