4. Security Engineering · 실제 시험 Abschnitt 4.1
4.1. Multiple Choice
Security Engineering MC 8개를 CVE부터 fuzzing oracle까지 시험지 a–h 순서 그대로 학습합니다.
이 페이지는 비슷한 주제를 임의로 다시 묶지 않고 실제 시험지의 Chapter → subsection → 소문제 순서를 그대로 따릅니다.
ACTUAL EXAM · VERBATIM TRANSCRIPT
시험지 원문 1:1 전사
아래 내용은 해설자가 바꿔 쓴 요약이 아닙니다. 실제 시험 전사본의 문장·순서·수치·배점·코드·표를 그대로 두고, Markdown 기호만 읽기 쉬운 제목·표·코드 모양으로 표시했습니다.
4.1. Multiple Choice (16 Punkte)
Bitte kreuzen Sie für jede der folgenden Aussagen „Wahr“ oder „Falsch“ an.
Nur eine der beiden Auswahlmöglichkeiten ist richtig.
Jede korrekte Antwort gibt zwei Punkte und erfordert keine weitere Begründung.
| Nr. | Wahr | Falsch | Aussage |
|---|---|---|---|
| a) | ☐ | ☐ | CVE (Common Vulnerabilities and Exposures) klassifiziert allgemeine Schwachstellenarten und typische Fehlerquellen in der Softwareentwicklung. |
| b) | ☐ | ☐ | CWE (Common Weakness Enumeration) beschreibt konkrete, eindeutig identifizierte Sicherheitslücken in bestimmten Softwareprodukten. |
| c) | ☐ | ☐ | Ein Off-by-One-Fehler ist ein verbreiteter Programmierfehler, bei dem eine Schleifen- oder Array/Index-Grenze um genau 1 verschoben ist. |
| d) | ☐ | ☐ | Programmierer fügen manuell Stack Canaries zwischen lokalen Variablen und sicherheitskritischen Daten ein, um die sicherheitskritischen Daten vor Manipulation zu schützen. |
| e) | ☐ | ☐ | JavaScript-Packing und Binary Stripping sind Obfuskationsmethoden, die Reverse Engineering und damit die Quellcode-Rekonstruktion erschweren. |
| f) | ☐ | ☐ | Das NX bit ist ein Schutzmechanismus, der die Ausführung von injiziertem Code verhindern kann. |
| g) | ☐ | ☐ | Die Forensik für besondere IT-Systeme wie Geldautomaten, Unterhaltungselektronik, Fahrzeugelektronik und IoT gehört nicht zu den Arbeitsgebieten der klassischen IT-Forensik. |
| h) | ☐ | ☐ | Ein Orakel beim Fuzzing ist ein Mechanismus, der Rückmeldung über das Verhalten des Programms gibt. |
근거: CSS_Altklausur_WiSe_2526.pdf 및 computersystemsicherheit_wise25-26_questions_only.md · Abschnitt 4.1
VISUAL MAP
Security Engineering MC 분류 왼쪽에서 오른쪽으로 읽은 뒤 아래 실제 소문제에서 같은 순서를 반복합니다.- 01 용어 종류
- 02 구체 사례·일반 유형
- 03 방어·분석
- 04 보장 범위
- 05 판정
FIXED SOLVING METHOD
이 묶음의 고정 풀이 순서
- 문장이 식별자·오류 유형·완화책·분석법 중 무엇인지 분류합니다.
- 용어를 한 문장으로 정의합니다.
- 주체가 개발자·compiler·OS·분석 도구 중 누구인지 확인합니다.
- ‘수동’, ‘완전’, ‘해당하지 않는다’ 같은 표현을 반례로 검사합니다.
- Wahr/Falsch를 정합니다.
ZERO-BASE CONCEPT LESSONS
이 묶음을 풀기 전에 필요한 개념
카드를 열고 닫는 방식 대신 한 방향으로 이어지는 글로 구성했습니다. 비유 → 용어의 쉬운 뜻 → 실제 작동 → 시험에서의 경계 순서로 천천히 읽으세요.
기초 개념 01
C의 buffer와 length 없는 sprintf
먼저 장면으로 이해해 봅시다. 10칸짜리 서랍에 30개 물건을 밀어 넣으면 옆 서랍의 물건까지 밀어내는 것과 같다. C는 자동으로 벽을 만들어 막아 주지 않는다.
이제 전문 용어를 붙이면 다음과 같습니다. Buffer은(는) 프로그램이 byte나 문자를 잠시 저장하도록 확보한 연속 memory 공간입니다. Boundary / Bounds은(는) Buffer가 합법적으로 사용할 수 있는 시작과 끝 범위입니다. Null terminator은(는) C 문자열의 끝을 표시하는 값 `\0`으로, 저장 공간 1바이트를 차지합니다. Stack frame은(는) 한 함수 호출의 local variable, 저장된 register, return 관련 정보가 놓이는 stack 영역입니다. Buffer overflow은(는) 확보한 buffer 범위를 넘어 write하여 인접 memory를 손상시키는 오류입니다.
실제 시스템에서는 이렇게 작동합니다. C의 char array는 정해진 크기의 연속된 memory 공간이다. Buffer에 들어갈 문자열 길이를 확인하지 않고 sprintf로 쓰면 경계를 넘어 인접 memory를 덮을 수 있다. 이를 buffer overflow라고 하며 crash, data corruption, 경우에 따라 code execution으로 이어질 수 있다. snprintf는 최대 길이를 받지만 반환값과 null termination 조건도 확인해야 한다.
- 목적지 buffer 크기를 확인한다.
- 공격자가 제어하는 문자열의 최대 길이를 확인한다.
- Format 후 필요한 길이가 buffer보다 큰지 계산한다.
- Bounded API와 반환값 검사, 명시적 길이 검증을 적용한다.
여기서 넘지 말아야 할 경계: sprintf의 format string이 고정되어 있어도 출력 전체 길이가 제한되지 않으면 overflow가 생길 수 있다.
21. C memory·Buffer boundary 독립 강의 →기초 개념 02
Fuzzing: 이상한 입력을 자동으로 계속 넣어 보는 시험
먼저 장면으로 이해해 봅시다. 문 손잡이를 정상적으로 한 번 돌리는 대신 아주 빠르게, 반대로, 반쯤, 여러 번 돌려 어떤 조작에서 문이 망가지는지 자동 실험하는 것과 같다.
이제 전문 용어를 붙이면 다음과 같습니다. Fuzzer은(는) 많은 test input을 자동 생성·변형하고 target program에 실행하는 도구입니다. Seed corpus은(는) Fuzzing을 시작할 때 기본 구조를 제공하는 초기 입력 모음입니다. Mutation은(는) 기존 입력의 byte·길이·구조를 변경해 새 test case를 만드는 과정입니다. Oracle은(는) Crash, sanitizer report, output mismatch 등 실패 여부를 판정하는 관찰 기준입니다. Coverage은(는) 특정 입력이 program code의 어느 부분을 실행했는지 나타내는 정보입니다.
실제 시스템에서는 이렇게 작동합니다. Fuzzing은 프로그램에 매우 많은 비정상·경계·무작위 입력을 자동 생성해 넣고 crash, hang, sanitizer error, assertion failure 같은 이상 동작을 찾는 dynamic testing 기법이다. Seed corpus는 시작 입력 모음이고 mutation은 입력을 변형하는 과정이다. Coverage-guided fuzzer는 새 code path를 실행한 입력을 보존해 더 깊은 상태를 탐색한다.
- 정상적인 seed input을 준비한다.
- 입력을 반복해서 mutate하거나 grammar에 맞게 생성한다.
- Program을 실행하고 crash, timeout, coverage를 관찰한다.
- 실패 입력을 재현하고 가장 작은 testcase로 줄인다.
- 원인을 수정한 뒤 그 testcase를 regression test로 남긴다.
여기서 넘지 말아야 할 경계: Fuzzing이 모든 입력을 증명하거나 취약점이 없음을 보장하지는 않는다. 좋은 oracle, instrumentation, corpus가 필요하다.
24. Fuzzing 독립 강의 →기초 개념 03
Digital evidence의 무결성과 chain of custody
먼저 장면으로 이해해 봅시다. 범죄 현장의 물건을 봉인하고 사진과 지문을 남기며, 경찰관 A에서 분석관 B로 넘어갈 때마다 시간과 서명을 기록하는 것과 같다.
이제 전문 용어를 붙이면 다음과 같습니다. Digital evidence은(는) 사건을 입증하거나 반박하는 데 사용될 수 있는 digital data입니다. Forensic image은(는) 파일만이 아니라 매체의 sector를 bit 단위로 복제한 분석용 image입니다. Write blocker은(는) 원본 저장매체로 write command가 전달되지 않게 막는 장치나 절차입니다. Chain of custody은(는) 누가 언제 어디서 어떤 목적으로 증거를 인수·접근·인계했는지 남기는 연속 기록입니다.
실제 시스템에서는 이렇게 작동합니다. Digital forensics는 장치와 파일을 조사해 재현 가능한 증거를 만드는 과정이다. 원본을 직접 분석하면 조사 행위가 metadata나 내용을 바꿀 수 있으므로 write blocker 또는 read-only 방식으로 forensic image를 만들고 복사본을 분석한다. Cryptographic hash는 원본과 image가 같은지 확인하는 지문 역할을 한다. Chain of custody는 누가 언제 어디서 증거를 받아 어떤 행동을 했는지 이어서 기록한 문서다.
- Evidence ID와 수집 당시 상태를 기록한다.
- Write blocker로 원본 변경을 줄이고 bitwise image를 만든다.
- 원본과 image의 hash, 도구, 시각을 기록한다.
- 모든 인계의 handler, timestamp, purpose, seal state를 기록한다.
- Working copy를 분석하고 방법·결과·한계를 보고한다.
여기서 넘지 말아야 할 경계: Hash 일치만으로 누가 증거를 다뤘는지나 수집 절차의 법적 신뢰성까지 증명되지는 않는다.
25. Forensic image·Hash·Chain of custody 독립 강의 →ACTIVE RECALL
이 페이지를 닫기 전 확인
- CVE와 CWE의 차이는?
- NX bit가 막는 것은?
- Fuzzing oracle은 무엇을 알려 주나요?
QUESTION-BY-QUESTION COMMENTARY
실제 시험 소문제별 해설
시험지의 번호와 순서를 그대로 유지했습니다. 각 항목을 열어 원문 → 쉬운 개념 설명 → 이번 문제의 단계별 풀이 → 답안 → 함정 순서로 읽으세요.
ACTUAL EXAM SUBSECTION 4.1
4.1. Multiple Choice
8개 학습 항목 · 16점
4.1 a) CVE는 일반 취약점 유형과 개발 오류를 분류한다. 기존 71문항 학습 번호 57 · 2점 Wahr/Falsch
4.1 a) · 실제 시험 원문
한국어로 요구사항만 풀어 읽기
CVE는 일반 취약점 유형과 개발 오류를 분류한다.
TERMS FOR 4.1 a)
이 소문제의 중요한 용어부터 이해하기
전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.
특정 제품이나 버전에서 실제로 발견된 개별 보안 취약점에 붙이는 공개 식별자입니다. 사건의 고유 번호에 가깝습니다.
작은 예: Log4Shell의 CVE-2021-44228처럼 ‘어느 제품의 어떤 취약점인가’를 가리킵니다.
여러 프로그램에서 반복해서 나타나는 일반적인 약점 유형을 분류한 목록입니다. 개별 사건이 아니라 실수의 종류를 뜻합니다.
작은 예: SQL Injection은 여러 제품에서 생길 수 있는 약점 유형이므로 CWE로 분류할 수 있습니다.
공격자로부터 지키려는 대상입니다. 파일, 비밀번호, 서비스 가용성, 사람의 개인정보가 모두 asset이 될 수 있습니다.
허가받지 않은 사람이 내용을 읽지 못하게 하는 기밀성입니다.
데이터나 시스템이 허가 없이 바뀌지 않았음을 보장하려는 무결성입니다.
정당한 사용자가 필요할 때 서비스와 데이터에 접근할 수 있는 가용성입니다.
이 소문제만을 위한 0부터 시작하는 미니 강의
아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.
1 · 먼저 알아야 할 개념
소프트웨어 보안에서는 ‘문제의 종류’와 ‘실제로 발견된 사건’을 구분해야 합니다. 같은 종류의 실수가 여러 제품에서 반복될 수 있고, 반대로 한 제품의 한 취약점에는 발견 시점과 영향을 받는 버전이 따로 있습니다.
CVE(Common Vulnerabilities and Exposures)는 공개된 개별 취약점에 붙는 고유 식별자입니다. 보통 CVE-연도-번호 형태이며, 어떤 제품의 어떤 버전에서 발견된 어떤 사건인지를 다른 데이터베이스와 문서가 같은 이름으로 가리키게 합니다.
CWE(Common Weakness Enumeration)는 buffer overflow, SQL injection처럼 취약점을 만들어 내는 일반적인 약점 유형을 분류합니다. 따라서 ‘일반 종류·개발 실수’라는 표현이 보이면 CWE, ‘특정 제품·버전의 실제 취약점’이라는 표현이 보이면 CVE를 먼저 떠올립니다.
2 · 일상 장면으로 먼저 잡기
자동차 업계에서 ‘브레이크 호스가 쉽게 마모되는 설계 유형’과 ‘2026년형 A사 X모델 3만 대의 실제 리콜 사건’을 구분한다고 생각해 봅시다.
비유의 경계 CVE 번호 자체가 원인 유형을 완전히 설명하는 것은 아닙니다. 한 CVE가 여러 CWE와 연결될 수도 있고 분류가 아직 없을 수도 있습니다.
일반 약점 유형: 원인이 어떤 종류인가?
특정 제품·버전에서 약점이 실제 코드로 나타남
공개된 개별 취약점: 어느 사건인가?
CVE를 종류표라고 부르면 두 역할이 뒤바뀜
왼쪽의 일반 원인(CWE)이 특정 구현에서 실제 사건으로 나타나면 오른쪽의 CVE 식별자가 붙을 수 있습니다.
종류표와 사건표를 나누기
주어진 것과 목표 ‘웹 입력이 SQL 문법으로 해석되는 실수’와 ‘ShopApp 4.2의 /login에서 발견된 실제 취약점’이 있습니다. 어느 쪽이 CWE이고 어느 쪽이 CVE인지 구합니다.
첫 문장에서 제품명·버전을 찾습니다.
왜? 개별 사건인지 일반 유형인지 판별하기 위해서입니다.
중간 결과 제품명이 없고 반복 가능한 실수이므로 일반 약점 유형입니다.
둘째 문장에서 제품과 버전을 표시합니다.
왜? 특정 구현에서 실제로 발견된 사건의 표지입니다.
중간 결과 ShopApp 4.2의 구체적 취약점이므로 CVE 대상입니다.
두 기록을 연결합니다.
왜? 실제 사건에는 원인이 된 일반 약점 분류가 붙을 수 있기 때문입니다.
중간 결과 한 CVE 사건이 SQL injection 계열 CWE에 매핑될 수 있습니다.
예제 결론 CVE는 사건의 이름표이고 CWE는 사건을 만든 실수의 종류표입니다.
실제 시험으로 옮기기 시험 문장은 CVE가 ‘일반 취약점 유형과 오류 원인’을 분류한다고 역할을 뒤바꿨으므로 Falsch입니다.
이번 문제는 이 단계로 풀어야 했습니다
먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.
먼저 문제를 식과 조건으로 정리하기
계산을 시작하기 전에 주어진 것과 구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.
강사가 문제의 요구사항을 쉬운 말로 바꾸면
시험 문장이 요구하는 것: CVE는 일반 취약점 유형과 개발 오류를 분류한다.
이 문제의 풀이 전략: 이 소문제에서는 문장의 주어를 고정한다 → CVE의 정의를 대입한다 → 문장의 술어와 실제 담당을 비교한다 → 판정과 교정 문장을 쓴다 순서로 진행합니다. 마지막에는 ‘CWE는 종류, CVE는 사건이라는 비교축으로 기억합니다.’라는 교정 기준으로 답을 다시 확인합니다.
문제에서 주어진 정보
CVE는 일반 취약점 유형과 개발 오류를 분류한다.
주어는 CVE이고 술어는 ‘일반 취약점 유형과 전형적 오류 원인을 분류한다’입니다.
CVE와 CWE라는 두 약어를 아직 서로 바꾸지 않았는지 확인합니다.
최종적으로 구해야 하는 것
Falsch. CVE는 개별 취약점 식별자이고, 일반 약점 유형은 CWE가 분류한다고 씁니다.
정답은 Falsch입니다. 문장이 CVE와 CWE의 역할을 바꾸어 적었습니다. CVE는 특정 제품·버전의 공개된 개별 취약점에 공통 이름을 주고, CWE는 취약점을 만들어 내는 일반 약점 유형을 분류합니다. 예를 들어 한 구체적 CVE가 buffer overflow라는 CWE 범주와 연결될 수 있습니다.
사용할 공식·판정 관계
문장의 주어를 고정한다 → CVE의 정의를 대입한다 → 문장의 술어와 실제 담당을 비교한다 → 판정과 교정 문장을 쓴다
왼쪽의 일반 원인(CWE)이 특정 구현에서 실제 사건으로 나타나면 오른쪽의 CVE 식별자가 붙을 수 있습니다.
문장의 주어를 고정한다
구체적으로 주어는 CVE이고 술어는 ‘일반 취약점 유형과 전형적 오류 원인을 분류한다’입니다.
여기서 검산 CVE와 CWE라는 두 약어를 아직 서로 바꾸지 않았는지 확인합니다.
다음 단계로 여기서 확인한 내용을 다음 ‘CVE의 정의를 대입한다’ 단계의 출발점으로 사용합니다.
CVE의 정의를 대입한다
구체적으로 CVE는 특정 제품·버전에서 공개된 개별 취약점을 공통 식별자로 가리키는 체계입니다.
여기서 검산 정의에 ‘특정 제품·개별 사건’이 들어갔는지 확인합니다.
다음 단계로 여기서 확인한 내용을 다음 ‘문장의 술어와 실제 담당을 비교한다’ 단계의 출발점으로 사용합니다.
문장의 술어와 실제 담당을 비교한다
구체적으로 일반 약점 유형과 개발 오류의 분류는 CWE의 역할이므로 시험 문장의 술어가 CVE 정의와 맞지 않습니다.
여기서 검산 반례가 아니라 역할 자체의 불일치를 찾았습니다.
다음 단계로 여기서 확인한 내용을 다음 ‘판정과 교정 문장을 쓴다’ 단계의 출발점으로 사용합니다.
판정과 교정 문장을 쓴다
구체적으로 Falsch. CVE는 개별 취약점 식별자이고, 일반 약점 유형은 CWE가 분류한다고 씁니다.
여기서 검산 Falsch만 쓰지 않고 올바른 두 역할을 모두 적었는지 확인합니다.
다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.
정답과 해설
Falsch. CVE는 특정 제품·버전의 공개된 개별 취약점에 식별자를 준다. 일반 약점 유형 분류는 CWE다.
시험 답안 골격
정답이 이렇게 되는 이유
정답은 Falsch입니다. 문장이 CVE와 CWE의 역할을 바꾸어 적었습니다. CVE는 특정 제품·버전의 공개된 개별 취약점에 공통 이름을 주고, CWE는 취약점을 만들어 내는 일반 약점 유형을 분류합니다. 예를 들어 한 구체적 CVE가 buffer overflow라는 CWE 범주와 연결될 수 있습니다.
초보자가 가장 자주 뒤집는 지점
잘못된 생각 CVE와 CWE 모두 번호가 있으므로 둘 다 특정 사건 번호다.
왜 틀렸나 번호 형식이 있다는 사실과 분류 대상은 별개입니다. CWE 번호는 일반 약점 범주를, CVE 번호는 개별 공개 취약점을 가리킵니다.
고쳐 말하면 CWE는 종류, CVE는 사건이라는 비교축으로 기억합니다.
한 문제만 더: 개념이 정말 연결됐는지 확인
질문 ‘특정 라이브러리 2.1의 취약점’과 ‘경계 검사 누락’ 중 어느 것이 CVE이고 어느 것이 CWE입니까?
정답 특정 라이브러리 2.1의 실제 취약점은 CVE, 경계 검사 누락이라는 일반 약점 유형은 CWE입니다.
이 문제의 오답 함정
이 소문제를 점수로 바꾸는 6개의 작은 훈련
해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.
해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.
막힐 때만 첫 단서 열기
CVE는 특정 제품·버전의 공개된 개별 취약점에 식별자를 준다. 일반 약점 유형 분류는 CWE다.
CVE는 일반 취약점 유형과 개발 오류를 분류한다.
정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.
작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.
답안 작성 후 채점 기준 열기
답안 슬롯 자가 점검 — 실제로 말하거나 쓴 항목만 체크하세요.
0/2 slots
조건 변형: 원문의 강한 표현(예: muss, immer, vollständig)을 조건부 표현으로 하나 고쳐 쓰고, 그 변경 뒤에는 판정이 왜 달라지거나 유지되는지 반례와 함께 설명하세요.
고칠 답안: CVE와 CWE의 역할을 서로 바꾸지 않는다.
복구 힌트: CVE는 특정 제품·버전의 공개된 개별 취약점에 식별자를 준다. 일반 약점 유형 분류는 CWE다.
오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.
채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인
Falsch. CVE는 특정 제품·버전의 공개된 개별 취약점에 식별자를 준다. 일반 약점 유형 분류는 CWE다.
4.1 b) CWE는 특정 제품의 개별 취약점을 설명한다. 기존 71문항 학습 번호 58 · 2점 Wahr/Falsch
4.1 b) · 실제 시험 원문
한국어로 요구사항만 풀어 읽기
CWE는 특정 제품의 개별 취약점을 설명한다.
TERMS FOR 4.1 b)
이 소문제의 중요한 용어부터 이해하기
전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.
특정 제품이나 버전에서 실제로 발견된 개별 보안 취약점에 붙이는 공개 식별자입니다. 사건의 고유 번호에 가깝습니다.
작은 예: Log4Shell의 CVE-2021-44228처럼 ‘어느 제품의 어떤 취약점인가’를 가리킵니다.
여러 프로그램에서 반복해서 나타나는 일반적인 약점 유형을 분류한 목록입니다. 개별 사건이 아니라 실수의 종류를 뜻합니다.
작은 예: SQL Injection은 여러 제품에서 생길 수 있는 약점 유형이므로 CWE로 분류할 수 있습니다.
사용자 입력이 SQL 데이터가 아니라 SQL 문법으로 해석되어 query 구조를 바꾸는 취약점입니다.
작은 예: 문자열 결합 query에 `' OR 1=1 -- `을 넣으면 조건식과 주석 문법이 생길 수 있습니다.
Stack의 고정 크기 buffer 경계 밖까지 데이터를 써서 인접 변수나 제어 정보를 덮는 오류입니다.
작은 예: 8-byte buffer에 20-byte 입력을 복사하면 뒤의 saved frame pointer나 return address까지 손상될 수 있습니다.
공격자로부터 지키려는 대상입니다. 파일, 비밀번호, 서비스 가용성, 사람의 개인정보가 모두 asset이 될 수 있습니다.
허가받지 않은 사람이 내용을 읽지 못하게 하는 기밀성입니다.
데이터나 시스템이 허가 없이 바뀌지 않았음을 보장하려는 무결성입니다.
정당한 사용자가 필요할 때 서비스와 데이터에 접근할 수 있는 가용성입니다.
이 소문제만을 위한 0부터 시작하는 미니 강의
아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.
1 · 먼저 알아야 할 개념
CWE는 코드와 설계에서 반복되는 약점의 ‘종류’를 모아 놓은 분류 체계입니다. 개발자와 분석가는 서로 다른 제품에서 발견된 문제도 같은 원인 범주로 묶어 이야기할 수 있습니다.
CVE는 반대로 실제 제품에서 공개된 개별 취약점을 구별하기 위한 식별자입니다. 제품명, 영향받는 버전, 공개 시점 같은 구체적 사건 정보가 따라옵니다.
따라서 시험에서 ‘konkret(구체적)’, ‘bestimmtes Softwareprodukt(특정 소프트웨어 제품)’, ‘eindeutig identifiziert(고유하게 식별)’가 CWE와 함께 나오면 역할을 뒤집은 함정인지 확인해야 합니다.
2 · 일상 장면으로 먼저 잡기
병원에서 ‘골절’이라는 질환 분류와 ‘환자 Kim의 2026-07-30 오른팔 골절 진료기록’을 구분하는 장면입니다.
비유의 경계 보안 분류는 의학 진단과 달리 법적 환자 기록이 아니며, 한 취약점에 복수 약점 원인이 함께 있을 수 있습니다.
제품을 가리지 않는 일반 원인 범주
AppA 1.0의 구체적 발견
AppB 3.4의 별도 발견
CWE를 개별 사건이라 부른 문장은 거짓
위의 한 약점 유형이 아래의 여러 실제 취약점 사건에서 나타날 수 있습니다.
한 약점 유형에 두 사건 연결하기
주어진 것과 목표 AppA 1.0과 AppB 3.4에서 모두 배열 경계를 넘는 쓰기가 발견되었습니다.
공통 원인을 추립니다.
왜? 제품과 무관하게 반복되는 약점 유형을 찾기 위해서입니다.
중간 결과 두 사건 모두 out-of-bounds write 계열의 CWE로 묶일 수 있습니다.
제품별 사건을 분리합니다.
왜? 영향 버전과 수정 일정이 서로 다르기 때문입니다.
중간 결과 AppA 사건과 AppB 사건에는 각각 별도 CVE가 붙을 수 있습니다.
문장의 ‘특정 제품의 개별 취약점’을 어느 체계가 담당하는지 확인합니다.
왜? 시험의 주어가 CWE이기 때문입니다.
중간 결과 그 설명은 CWE가 아니라 CVE에 맞습니다.
예제 결론 여러 개별 CVE가 하나의 CWE 약점 유형을 공유할 수 있습니다.
실제 시험으로 옮기기 CWE가 특정 제품의 개별 취약점을 설명한다는 시험 문장은 Falsch입니다.
이번 문제는 이 단계로 풀어야 했습니다
먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.
먼저 문제를 식과 조건으로 정리하기
계산을 시작하기 전에 주어진 것과 구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.
강사가 문제의 요구사항을 쉬운 말로 바꾸면
시험 문장이 요구하는 것: CWE는 특정 제품의 개별 취약점을 설명한다.
이 문제의 풀이 전략: 이 소문제에서는 구체성을 나타내는 단어를 표시한다 → CWE의 분류 대상을 적는다 → 대조되는 CVE를 대입한다 → Falsch와 교정 문장을 완성한다 순서로 진행합니다. 마지막에는 ‘분류 페이지에 사례가 있다는 것과 사례에 고유 번호를 부여하는 것은 다릅니다.’라는 교정 기준으로 답을 다시 확인합니다.
문제에서 주어진 정보
CWE는 특정 제품의 개별 취약점을 설명한다.
‘konkrete’, ‘eindeutig identifizierte’, ‘bestimmten Softwareprodukten’은 특정 사건을 가리킵니다.
문장이 일반 유형이 아니라 제품별 사건을 말하는지 확인합니다.
최종적으로 구해야 하는 것
Falsch. CWE는 일반 약점 유형이고 특정 제품의 개별 공개 취약점은 CVE라고 씁니다.
정답은 Falsch입니다. CWE는 특정 제품의 사건 목록이 아니라 공통 약점 유형의 분류입니다. 특정 제품·버전에서 확인된 개별 취약점을 공통 식별자로 가리키는 체계는 CVE입니다. 이 문항은 앞 문항과 반대 방향으로 같은 역할 뒤집기를 검사합니다.
사용할 공식·판정 관계
구체성을 나타내는 단어를 표시한다 → CWE의 분류 대상을 적는다 → 대조되는 CVE를 대입한다 → Falsch와 교정 문장을 완성한다
위의 한 약점 유형이 아래의 여러 실제 취약점 사건에서 나타날 수 있습니다.
구체성을 나타내는 단어를 표시한다
구체적으로 ‘konkrete’, ‘eindeutig identifizierte’, ‘bestimmten Softwareprodukten’은 특정 사건을 가리킵니다.
여기서 검산 문장이 일반 유형이 아니라 제품별 사건을 말하는지 확인합니다.
다음 단계로 여기서 확인한 내용을 다음 ‘CWE의 분류 대상을 적는다’ 단계의 출발점으로 사용합니다.
CWE의 분류 대상을 적는다
구체적으로 CWE는 buffer overflow나 SQL injection 같은 일반적인 weakness class를 분류합니다.
여기서 검산 제품명과 버전이 CWE 정의의 핵심이 아님을 확인합니다.
다음 단계로 여기서 확인한 내용을 다음 ‘대조되는 CVE를 대입한다’ 단계의 출발점으로 사용합니다.
대조되는 CVE를 대입한다
구체적으로 특정 제품에서 고유하게 식별된 취약점이라는 설명은 CVE에 해당합니다.
여기서 검산 두 약어의 역할을 한 문장씩 나란히 적습니다.
다음 단계로 여기서 확인한 내용을 다음 ‘Falsch와 교정 문장을 완성한다’ 단계의 출발점으로 사용합니다.
Falsch와 교정 문장을 완성한다
구체적으로 Falsch. CWE는 일반 약점 유형이고 특정 제품의 개별 공개 취약점은 CVE라고 씁니다.
여기서 검산 판정과 이유가 모두 채점 가능한 형태인지 봅니다.
다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.
정답과 해설
Falsch. CWE는 buffer overflow, SQL injection 같은 약점 유형의 분류다. 특정 취약점 식별은 CVE다.
시험 답안 골격
정답이 이렇게 되는 이유
정답은 Falsch입니다. CWE는 특정 제품의 사건 목록이 아니라 공통 약점 유형의 분류입니다. 특정 제품·버전에서 확인된 개별 취약점을 공통 식별자로 가리키는 체계는 CVE입니다. 이 문항은 앞 문항과 반대 방향으로 같은 역할 뒤집기를 검사합니다.
초보자가 가장 자주 뒤집는 지점
잘못된 생각 CWE 설명 페이지에 제품 예시가 있으므로 CWE도 제품 취약점 식별자다.
왜 틀렸나 예시가 연결될 수는 있지만 CWE의 분류 대상 자체는 일반 약점입니다.
고쳐 말하면 분류 페이지에 사례가 있다는 것과 사례에 고유 번호를 부여하는 것은 다릅니다.
한 문제만 더: 개념이 정말 연결됐는지 확인
질문 한 CVE가 두 CWE와 연결될 수 있습니까?
정답 가능합니다. 한 구체적 취약점이 입력 검증 실패와 경계 밖 쓰기처럼 여러 일반 약점과 관련될 수 있습니다.
이 문제의 오답 함정
이 소문제를 점수로 바꾸는 6개의 작은 훈련
해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.
해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.
막힐 때만 첫 단서 열기
CWE는 buffer overflow, SQL injection 같은 약점 유형의 분류다. 특정 취약점 식별은 CVE다.
CWE는 특정 제품의 개별 취약점을 설명한다.
정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.
작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.
답안 작성 후 채점 기준 열기
답안 슬롯 자가 점검 — 실제로 말하거나 쓴 항목만 체크하세요.
0/2 slots
조건 변형: 원문의 강한 표현(예: muss, immer, vollständig)을 조건부 표현으로 하나 고쳐 쓰고, 그 변경 뒤에는 판정이 왜 달라지거나 유지되는지 반례와 함께 설명하세요.
고칠 답안: CWE 번호를 제품 사건 번호로 보지 않는다.
복구 힌트: CWE는 buffer overflow, SQL injection 같은 약점 유형의 분류다. 특정 취약점 식별은 CVE다.
오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.
채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인
Falsch. CWE는 buffer overflow, SQL injection 같은 약점 유형의 분류다. 특정 취약점 식별은 CVE다.
4.1 c) off-by-one은 loop/index 경계가 정확히 1 어긋난 오류다. 기존 71문항 학습 번호 59 · 2점 Wahr/Falsch
4.1 c) · 실제 시험 원문
한국어로 요구사항만 풀어 읽기
off-by-one은 loop/index 경계가 정확히 1 어긋난 오류다.
TERMS FOR 4.1 c)
이 소문제의 중요한 용어부터 이해하기
전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.
반복 횟수나 배열 경계를 정확한 값보다 하나 많거나 하나 적게 계산하는 오류입니다.
작은 예: 크기가 8인 배열의 마지막 index는 7인데 index 8까지 접근하면 경계를 한 칸 넘습니다.
프로그램이 byte나 문자를 잠시 저장하도록 확보한 연속 memory 공간입니다.
Buffer가 합법적으로 사용할 수 있는 시작과 끝 범위입니다.
C 문자열의 끝을 표시하는 값 `\0`으로, 저장 공간 1바이트를 차지합니다.
한 함수 호출의 local variable, 저장된 register, return 관련 정보가 놓이는 stack 영역입니다.
확보한 buffer 범위를 넘어 write하여 인접 memory를 손상시키는 오류입니다.
이 소문제만을 위한 0부터 시작하는 미니 강의
아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.
1 · 먼저 알아야 할 개념
배열(array)은 같은 종류의 값을 연속된 칸에 저장합니다. 길이가 n이면 유효한 index는 0부터 n-1까지이며, n은 이미 배열 바깥 첫 칸입니다.
반복문(loop)의 경계 조건에서
<를<=로 쓰거나 시작·끝 값을 한 칸 잘못 잡으면 의도보다 정확히 한 번 더 또는 덜 실행될 수 있습니다. 이를 off-by-one error라고 합니다.한 칸 차이라도 배열 밖 메모리를 읽거나 쓰면 crash, 정보 노출, 인접 데이터 변조로 이어질 수 있으므로 영향이 작다고 볼 수 없습니다.
2 · 일상 장면으로 먼저 잡기
좌석이 0번부터 4번까지 다섯 개뿐인 버스에서 직원이 ‘0번부터 5번까지’ 승객을 앉히려는 상황입니다.
비유의 경계 실제 메모리에서는 바깥 한 칸이 비어 있다는 보장이 없고, 다른 변수나 제어 정보가 놓일 수 있습니다.
유효
유효
유효
유효·마지막
경계 밖·off-by-one
길이 4에서 숫자 4는 길이이지만 유효 index는 아닙니다.
길이 4 배열의 마지막 반복
주어진 것과 목표
int a[4]와for (i=0; i<=4; i++) a[i]=0;가 있습니다.유효 index를 적습니다.
왜? 배열 경계를 숫자로 고정하기 위해서입니다.
중간 결과 길이 4의 유효 index는 0,1,2,3입니다.
조건이 허용하는 i를 나열합니다.
왜?
<=가 마지막에 무엇을 포함하는지 보기 위해서입니다.중간 결과 i=0,1,2,3,4가 실행됩니다.
마지막 접근을 비교합니다.
왜? 정확히 한 칸의 차이를 확인하기 위해서입니다.
중간 결과 a[4]는 첫 번째 범위 밖 접근입니다.
예제 결론
i < 4로 고치면 네 번만 실행되어 0..3을 처리합니다.실제 시험으로 옮기기 loop/index 경계가 정확히 1 어긋나는 오류라는 문장은 정의에 맞으므로 Wahr입니다.
이번 문제는 이 단계로 풀어야 했습니다
먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.
먼저 문제를 식과 조건으로 정리하기
계산을 시작하기 전에 주어진 것과 구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.
강사가 문제의 요구사항을 쉬운 말로 바꾸면
시험 문장이 요구하는 것: off-by-one은 loop/index 경계가 정확히 1 어긋난 오류다.
이 문제의 풀이 전략: 이 소문제에서는 off-by-one의 정의를 회상한다 → 대표 경계식을 대입한다 → 시험 문장과 정의를 비교한다 → Wahr와 짧은 근거를 쓴다 순서로 진행합니다. 마지막에는 ‘오차의 크기와 보안 영향의 크기를 분리해서 판단합니다.’라는 교정 기준으로 답을 다시 확인합니다.
문제에서 주어진 정보
off-by-one은 loop/index 경계가 정확히 1 어긋난 오류다.
의도한 반복 횟수나 index 경계가 정확히 하나 많거나 적은 오류입니다.
단순히 ‘작은 오류’라고 정의하지 않았는지 봅니다.
최종적으로 구해야 하는 것
Wahr. `<`와 `<=` 혼동 등으로 한 번 더/덜 반복하거나 한 칸 밖을 접근하는 오류라고 씁니다.
정답은 Wahr입니다. Off-by-one은 반복 횟수나 배열 경계를 정확히 한 단위 잘못 계산한 오류입니다. 전형적인 예는 길이 n 배열에 index n으로 접근하는 것입니다. 차이는 한 칸이지만 그 칸이 다른 데이터일 수 있어 보안 영향은 클 수 있습니다.
사용할 공식·판정 관계
off-by-one의 정의를 회상한다 → 대표 경계식을 대입한다 → 시험 문장과 정의를 비교한다 → Wahr와 짧은 근거를 쓴다
길이 4에서 숫자 4는 길이이지만 유효 index는 아닙니다.
off-by-one의 정의를 회상한다
구체적으로 의도한 반복 횟수나 index 경계가 정확히 하나 많거나 적은 오류입니다.
여기서 검산 단순히 ‘작은 오류’라고 정의하지 않았는지 봅니다.
다음 단계로 여기서 확인한 내용을 다음 ‘대표 경계식을 대입한다’ 단계의 출발점으로 사용합니다.
대표 경계식을 대입한다
구체적으로 길이 n 배열에서
i < n대신i <= n을 쓰면 i=n일 때 한 번 더 접근합니다.여기서 검산 마지막 유효 index가 n-1임을 확인합니다.
다음 단계로 여기서 확인한 내용을 다음 ‘시험 문장과 정의를 비교한다’ 단계의 출발점으로 사용합니다.
시험 문장과 정의를 비교한다
구체적으로 문장은 loop 또는 array/index 경계가 정확히 1 이동한 오류라고 설명하므로 정의와 일치합니다.
여기서 검산 문장에 과장된 ‘항상 exploit’ 같은 조건이 없음을 봅니다.
다음 단계로 여기서 확인한 내용을 다음 ‘Wahr와 짧은 근거를 쓴다’ 단계의 출발점으로 사용합니다.
Wahr와 짧은 근거를 쓴다
구체적으로 Wahr.
<와<=혼동 등으로 한 번 더/덜 반복하거나 한 칸 밖을 접근하는 오류라고 씁니다.여기서 검산 판정이 Wahr인지 확인합니다.
다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.
정답과 해설
Wahr. `<=`와 `<`를 혼동해 한 번 더 또는 덜 반복하거나 배열 경계를 한 칸 넘는 전형적인 오류다.
시험 답안 골격
정답이 이렇게 되는 이유
정답은 Wahr입니다. Off-by-one은 반복 횟수나 배열 경계를 정확히 한 단위 잘못 계산한 오류입니다. 전형적인 예는 길이 n 배열에 index n으로 접근하는 것입니다. 차이는 한 칸이지만 그 칸이 다른 데이터일 수 있어 보안 영향은 클 수 있습니다.
초보자가 가장 자주 뒤집는 지점
잘못된 생각 한 칸만 틀리므로 단순 표시 오류일 뿐 보안 문제는 아니다.
왜 틀렸나 메모리 경계의 한 칸은 다른 변수나 제어 데이터일 수 있어 읽기·쓰기 침범이 발생할 수 있습니다.
고쳐 말하면 오차의 크기와 보안 영향의 크기를 분리해서 판단합니다.
한 문제만 더: 개념이 정말 연결됐는지 확인
질문 길이 8인 배열의 마지막 유효 index는 무엇이며
i <= 7은 몇 번 실행됩니까?정답 마지막 index는 7이고, i가 0에서 시작하면 0..7까지 총 8번 실행됩니다.
이 문제의 오답 함정
이 소문제를 점수로 바꾸는 6개의 작은 훈련
해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.
해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.
막힐 때만 첫 단서 열기
`<=`와 `<`를 혼동해 한 번 더 또는 덜 반복하거나 배열 경계를 한 칸 넘는 전형적인 오류다.
off-by-one은 loop/index 경계가 정확히 1 어긋난 오류다.
정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.
작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.
답안 작성 후 채점 기준 열기
답안 슬롯 자가 점검 — 실제로 말하거나 쓴 항목만 체크하세요.
0/2 slots
조건 변형: 원문의 강한 표현(예: muss, immer, vollständig)을 조건부 표현으로 하나 고쳐 쓰고, 그 변경 뒤에는 판정이 왜 달라지거나 유지되는지 반례와 함께 설명하세요.
고칠 답안: 작은 숫자 차이라 영향도 작다고 생각하지 않는다.
복구 힌트: `<=`와 `<`를 혼동해 한 번 더 또는 덜 반복하거나 배열 경계를 한 칸 넘는 전형적인 오류다.
오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.
채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인
Wahr. `<=`와 `<`를 혼동해 한 번 더 또는 덜 반복하거나 배열 경계를 한 칸 넘는 전형적인 오류다.
4.1 d) programmer가 stack canary를 수동으로 끼워 넣는다. 기존 71문항 학습 번호 60 · 2점 Wahr/Falsch
4.1 d) · 실제 시험 원문
한국어로 요구사항만 풀어 읽기
programmer가 stack canary를 수동으로 끼워 넣는다.
TERMS FOR 4.1 d)
이 소문제의 중요한 용어부터 이해하기
전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.
함수의 stack frame에 넣어 두는 감시값입니다. 함수가 끝날 때 값이 바뀌었으면 buffer overflow 가능성을 감지하고 중단합니다.
작은 예: 광산의 카나리아처럼 중요한 return address가 덮이기 전에 주변 훼손을 알려 줍니다.
프로그램이 byte나 문자를 잠시 저장하도록 확보한 연속 memory 공간입니다.
Buffer가 합법적으로 사용할 수 있는 시작과 끝 범위입니다.
C 문자열의 끝을 표시하는 값 `\0`으로, 저장 공간 1바이트를 차지합니다.
한 함수 호출의 local variable, 저장된 register, return 관련 정보가 놓이는 stack 영역입니다.
확보한 buffer 범위를 넘어 write하여 인접 memory를 손상시키는 오류입니다.
이 소문제만을 위한 0부터 시작하는 미니 강의
아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.
1 · 먼저 알아야 할 개념
함수가 호출되면 stack frame에 local variable, 저장된 제어 정보, return address 등이 놓일 수 있습니다. Local buffer를 넘쳐 쓰면 뒤쪽의 return address까지 변조할 가능성이 있습니다.
Stack canary는 buffer와 중요한 제어 정보 사이에 놓는 예측하기 어려운 값입니다. 함수가 반환하기 전에 값이 그대로인지 검사하여 overflow가 지나갔는지를 탐지합니다.
일반적으로 개발자가 각 함수에 직접 canary 변수를 작성하는 것이 아니라 compiler의 stack-protector 옵션과 runtime 지원이 적절한 함수의 prologue·epilogue에 삽입합니다. 이는 탐지 방어이며 모든 memory corruption을 예방하는 만능 장치는 아닙니다.
2 · 일상 장면으로 먼저 잡기
창고의 일반 상자와 비상구 열쇠 사이에 봉인 스티커를 붙이고, 퇴실할 때 스티커가 찢어졌는지 검사합니다.
비유의 경계 봉인을 우회하거나 값을 미리 알면 공격할 수 있고, 봉인까지 닿지 않는 다른 memory corruption은 탐지하지 못할 수 있습니다.
공격 입력이 먼저 채우는 영역
변조 여부를 검사하는 guard
frame pointer·return address
불일치 시 중단
연속 overflow가 return address로 가기 전에 canary를 지나도록 배치해 변조를 탐지합니다.
컴파일러가 추가하는 두 지점
주어진 것과 목표
char name[16]을 가진 함수가 stack protector와 함께 컴파일됩니다.함수 진입 시 canary를 stack frame에 복사합니다.
왜? 나중에 원래 값과 비교할 기준이 필요하기 때문입니다.
중간 결과 buffer와 return address 사이에 guard 값이 놓입니다.
과도한 입력이 buffer 뒤로 이어져 쓰입니다.
왜? 경계 검사가 없는 복사를 가정합니다.
중간 결과 return address 전에 canary가 먼저 변조됩니다.
함수 반환 전에 canary를 검사합니다.
왜? 변조된 제어 정보로 return하기 전에 중단하기 위해서입니다.
중간 결과 불일치하면 runtime이 프로그램을 종료합니다.
예제 결론 삽입과 검사는 보통 compiler/runtime이 자동 생성합니다.
실제 시험으로 옮기기 programmer가 수동으로 끼운다는 시험 문장의 주체가 틀렸으므로 Falsch입니다.
이번 문제는 이 단계로 풀어야 했습니다
먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.
먼저 문제를 식과 조건으로 정리하기
계산을 시작하기 전에 주어진 것과 구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.
강사가 문제의 요구사항을 쉬운 말로 바꾸면
시험 문장이 요구하는 것: programmer가 stack canary를 수동으로 끼워 넣는다.
이 문제의 풀이 전략: 이 소문제에서는 문장에서 행위 주체를 찾는다 → 일반적인 구현을 적는다 → 보호 범위를 구분한다 → Falsch와 교정문을 완성한다 순서로 진행합니다. 마지막에는 ‘개발자는 옵션을 선택할 수 있고, 삽입·검사는 compiler/runtime이 수행한다고 구분합니다.’라는 교정 기준으로 답을 다시 확인합니다.
문제에서 주어진 정보
programmer가 stack canary를 수동으로 끼워 넣는다.
문장은 programmer가 canary를 수동 삽입한다고 주장합니다.
canary의 효과가 아니라 삽입 주체를 묻는 함정임을 확인합니다.
최종적으로 구해야 하는 것
Falsch. Stack canary는 보통 compiler/runtime이 자동 삽입·검사한다고 답합니다.
정답은 Falsch입니다. 일반적인 stack protector에서는 compiler가 canary 저장·검사 코드를 만들고 runtime이 실패 시 중단합니다. 개발자가 보호 옵션을 켤 수는 있지만 각 local variable 사이에 canary를 손으로 작성한다는 설명은 맞지 않습니다. 또한 canary는 일부 stack overwrite 탐지 장치이지 모든 공격의 완전한 방어가 아닙니다.
사용할 공식·판정 관계
문장에서 행위 주체를 찾는다 → 일반적인 구현을 적는다 → 보호 범위를 구분한다 → Falsch와 교정문을 완성한다
연속 overflow가 return address로 가기 전에 canary를 지나도록 배치해 변조를 탐지합니다.
문장에서 행위 주체를 찾는다
구체적으로 문장은 programmer가 canary를 수동 삽입한다고 주장합니다.
여기서 검산 canary의 효과가 아니라 삽입 주체를 묻는 함정임을 확인합니다.
다음 단계로 여기서 확인한 내용을 다음 ‘일반적인 구현을 적는다’ 단계의 출발점으로 사용합니다.
일반적인 구현을 적는다
구체적으로 compiler option과 runtime이 함수 진입 때 canary를 놓고 반환 전에 비교 코드를 삽입합니다.
여기서 검산 ‘항상 모든 함수’라고 과장하지 않습니다.
다음 단계로 여기서 확인한 내용을 다음 ‘보호 범위를 구분한다’ 단계의 출발점으로 사용합니다.
보호 범위를 구분한다
구체적으로 canary는 특정 stack overwrite를 탐지하지만 overflow 자체나 모든 memory corruption을 없애지는 않습니다.
여기서 검산 예방과 탐지를 혼동하지 않습니다.
다음 단계로 여기서 확인한 내용을 다음 ‘Falsch와 교정문을 완성한다’ 단계의 출발점으로 사용합니다.
Falsch와 교정문을 완성한다
구체적으로 Falsch. Stack canary는 보통 compiler/runtime이 자동 삽입·검사한다고 답합니다.
여기서 검산 수동이라는 핵심 오류를 바로잡았는지 봅니다.
다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.
정답과 해설
Falsch. 보통 compiler 옵션과 runtime이 stack frame에 canary를 자동 삽입하고 return 전에 변조를 검사한다.
시험 답안 골격
정답이 이렇게 되는 이유
정답은 Falsch입니다. 일반적인 stack protector에서는 compiler가 canary 저장·검사 코드를 만들고 runtime이 실패 시 중단합니다. 개발자가 보호 옵션을 켤 수는 있지만 각 local variable 사이에 canary를 손으로 작성한다는 설명은 맞지 않습니다. 또한 canary는 일부 stack overwrite 탐지 장치이지 모든 공격의 완전한 방어가 아닙니다.
초보자가 가장 자주 뒤집는 지점
잘못된 생각 개발자가 compiler flag를 켜므로 canary를 수동으로 삽입하는 것이다.
왜 틀렸나 방어 기능을 활성화하는 선택과 각 stack frame에 값·검사 코드를 실제 삽입하는 동작은 다릅니다.
고쳐 말하면 개발자는 옵션을 선택할 수 있고, 삽입·검사는 compiler/runtime이 수행한다고 구분합니다.
한 문제만 더: 개념이 정말 연결됐는지 확인
질문 공격자가 canary 값을 정보 노출로 알아내면 왜 방어가 약해집니까?
정답 overflow payload에 같은 canary 값을 다시 써 넣으면 반환 전 비교가 통과할 가능성이 생기기 때문입니다.
이 문제의 오답 함정
이 소문제를 점수로 바꾸는 6개의 작은 훈련
해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.
해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.
막힐 때만 첫 단서 열기
보통 compiler 옵션과 runtime이 stack frame에 canary를 자동 삽입하고 return 전에 변조를 검사한다.
programmer가 stack canary를 수동으로 끼워 넣는다.
정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.
작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.
답안 작성 후 채점 기준 열기
답안 슬롯 자가 점검 — 실제로 말하거나 쓴 항목만 체크하세요.
0/2 slots
조건 변형: 원문의 강한 표현(예: muss, immer, vollständig)을 조건부 표현으로 하나 고쳐 쓰고, 그 변경 뒤에는 판정이 왜 달라지거나 유지되는지 반례와 함께 설명하세요.
고칠 답안: canary가 모든 memory corruption을 막는다고 쓰지 않는다.
복구 힌트: 보통 compiler 옵션과 runtime이 stack frame에 canary를 자동 삽입하고 return 전에 변조를 검사한다.
오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.
채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인
Falsch. 보통 compiler 옵션과 runtime이 stack frame에 canary를 자동 삽입하고 return 전에 변조를 검사한다.
4.1 e) JS packing과 binary stripping은 reverse engineering을 어렵게 하는 obfuscation 방법이다. 기존 71문항 학습 번호 61 · 2점 Wahr/Falsch
4.1 e) · 실제 시험 원문
한국어로 요구사항만 풀어 읽기
JS packing과 binary stripping은 reverse engineering을 어렵게 하는 obfuscation 방법이다.
TERMS FOR 4.1 e)
이 소문제의 중요한 용어부터 이해하기
전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.
JavaScript를 압축하거나 복잡하게 변환해 사람이 읽기 어렵게 만드는 기법입니다.
작은 예: 긴 변수 이름을 한 글자로 바꾸고 문자열을 인코딩하면 동작은 유지되지만 분석은 어려워집니다.
실행 파일에서 함수 이름이나 debug symbol처럼 분석에 도움이 되는 정보를 제거하는 작업입니다.
작은 예: 지도에서 건물 이름을 지우면 길은 남지만 분석자는 각 위치의 역할을 알아내기 어려워집니다.
프로그램의 동작은 유지하면서 구조와 의미를 일부러 이해하기 어렵게 만드는 기법입니다.
작은 예: 문장을 암호문으로 바꾸는 것이 아니라 같은 내용을 매우 난해하게 다시 쓰는 것에 가깝습니다.
소스 코드가 없는 프로그램의 실행 파일이나 동작을 관찰해 내부 구조와 기능을 추론하는 작업입니다.
작은 예: 완성된 기계를 분해해 설계 원리를 알아내는 것과 비슷합니다.
공격자로부터 지키려는 대상입니다. 파일, 비밀번호, 서비스 가용성, 사람의 개인정보가 모두 asset이 될 수 있습니다.
허가받지 않은 사람이 내용을 읽지 못하게 하는 기밀성입니다.
데이터나 시스템이 허가 없이 바뀌지 않았음을 보장하려는 무결성입니다.
정당한 사용자가 필요할 때 서비스와 데이터에 접근할 수 있는 가용성입니다.
이 소문제만을 위한 0부터 시작하는 미니 강의
아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.
1 · 먼저 알아야 할 개념
Reverse engineering은 실행 파일이나 난독화된 코드를 관찰해 프로그램의 구조와 동작을 역으로 이해하는 작업입니다.
Obfuscation은 동작은 유지하면서 사람이 읽고 분석하기 어렵게 표현을 바꾸는 기법입니다. JavaScript packing은 코드를 압축·인코딩하고 작은 unpacker로 실행 시 복원하게 만들 수 있습니다.
Binary stripping은 실행에 꼭 필요하지 않은 symbol name과 debug information을 제거합니다. 분석을 어렵게 하지만 CPU가 실행할 machine code는 남아 있으므로 암호학적 비밀 보장과 같지 않습니다.
2 · 일상 장면으로 먼저 잡기
요리법의 재료 이름을 A, B로 바꾸고 문장을 한 줄로 압축하며, 완성된 요리에는 조리사의 메모와 목차를 떼어 내는 상황입니다.
비유의 경계 표현을 어렵게 할 뿐 원리를 숨기는 암호화가 아니므로 충분한 시간과 도구가 있으면 분석할 수 있습니다.
이름·구조·debug 정보가 풍부
표현 압축·인코딩·runtime 복원
symbol·debug 정보 제거
실행 가능하지만 분석 비용 증가
분석 불가능·암호화는 아님
기능은 유지되고 분석에 도움이 되는 표현과 표지만 줄어듭니다.
이름이 사라져도 명령은 남는다
주어진 것과 목표
checkPassword()함수가 있는 프로그램을 strip하고 JavaScript 코드는 packed 문자열로 배포합니다.symbol 이름과 debug line을 제거합니다.
왜? 분석가에게 친절한 표지를 줄이기 위해서입니다.
중간 결과
checkPassword라는 이름은 사라질 수 있지만 명령 자체는 남습니다.JavaScript 표현을 압축·치환합니다.
왜? 원래 제어 흐름을 바로 읽기 어렵게 하기 위해서입니다.
중간 결과 브라우저는 unpacking 후 같은 기능을 실행합니다.
분석 가능성을 평가합니다.
왜? obfuscation과 confidentiality를 구분하기 위해서입니다.
중간 결과 debugger·disassembler로 동작을 계속 관찰할 수 있습니다.
예제 결론 두 기법 모두 분석 비용을 높이는 obfuscation 계열이며 완전한 비밀화는 아닙니다.
실제 시험으로 옮기기 시험 문장은 ‘reverse engineering을 어렵게 한다’고만 했으므로 Wahr입니다.
이번 문제는 이 단계로 풀어야 했습니다
먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.
먼저 문제를 식과 조건으로 정리하기
계산을 시작하기 전에 주어진 것과 구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.
강사가 문제의 요구사항을 쉬운 말로 바꾸면
시험 문장이 요구하는 것: JS packing과 binary stripping은 reverse engineering을 어렵게 하는 obfuscation 방법이다.
이 문제의 풀이 전략: 이 소문제에서는 두 용어의 실제 변화를 정의한다 → 공통 목표를 찾는다 → 보호 경계를 확인한다 → Wahr와 근거를 쓴다 순서로 진행합니다. 마지막에는 ‘obfuscation은 시간과 비용을 높이고 encryption은 적절한 key 없이는 내용을 얻기 어렵게 하는 별도 목표입니다.’라는 교정 기준으로 답을 다시 확인합니다.
문제에서 주어진 정보
JS packing과 binary stripping은 reverse engineering을 어렵게 하는 obfuscation 방법이다.
Packing은 code 표현을 압축·변환하고 stripping은 symbol/debug 정보를 제거합니다.
두 기법을 똑같은 동작으로 설명하지 않습니다.
최종적으로 구해야 하는 것
Wahr. Packing은 표현을 변형하고 stripping은 분석 표지를 제거해 역공학을 어렵게 한다고 씁니다.
정답은 Wahr입니다. JavaScript packing은 코드를 압축·변형하고 실행 시 복원하도록 만들어 읽기 어렵게 합니다. Binary stripping은 함수명·debug 정보 같은 분석 단서를 제거합니다. 두 방법 모두 reverse engineering 비용을 높이는 obfuscation 방법이지만, 실행 코드가 남기 때문에 분석을 불가능하게 하거나 기밀성을 보장하지는 않습니다.
사용할 공식·판정 관계
두 용어의 실제 변화를 정의한다 → 공통 목표를 찾는다 → 보호 경계를 확인한다 → Wahr와 근거를 쓴다
기능은 유지되고 분석에 도움이 되는 표현과 표지만 줄어듭니다.
두 용어의 실제 변화를 정의한다
구체적으로 Packing은 code 표현을 압축·변환하고 stripping은 symbol/debug 정보를 제거합니다.
여기서 검산 두 기법을 똑같은 동작으로 설명하지 않습니다.
다음 단계로 여기서 확인한 내용을 다음 ‘공통 목표를 찾는다’ 단계의 출발점으로 사용합니다.
공통 목표를 찾는다
구체적으로 둘 다 원래 구조와 의미를 즉시 읽기 어렵게 해 reverse engineering 비용을 높입니다.
여기서 검산 시험 문장은 ‘불가능하게 한다’가 아니라 ‘어렵게 한다’고 했습니다.
다음 단계로 여기서 확인한 내용을 다음 ‘보호 경계를 확인한다’ 단계의 출발점으로 사용합니다.
보호 경계를 확인한다
구체적으로 실행에 필요한 code는 남으므로 분석이 가능하고 암호학적 confidentiality를 보장하지는 않습니다.
여기서 검산 경계가 문장의 Wahr 판정을 깨지 않는지 봅니다.
다음 단계로 여기서 확인한 내용을 다음 ‘Wahr와 근거를 쓴다’ 단계의 출발점으로 사용합니다.
Wahr와 근거를 쓴다
구체적으로 Wahr. Packing은 표현을 변형하고 stripping은 분석 표지를 제거해 역공학을 어렵게 한다고 씁니다.
여기서 검산 두 용어 각각의 이유를 한 번씩 언급합니다.
다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.
정답과 해설
Wahr. packing은 코드를 압축·변형하고 stripping은 symbol/debug 정보를 제거해 분석과 원래 구조 복원을 어렵게 한다.
시험 답안 골격
정답이 이렇게 되는 이유
정답은 Wahr입니다. JavaScript packing은 코드를 압축·변형하고 실행 시 복원하도록 만들어 읽기 어렵게 합니다. Binary stripping은 함수명·debug 정보 같은 분석 단서를 제거합니다. 두 방법 모두 reverse engineering 비용을 높이는 obfuscation 방법이지만, 실행 코드가 남기 때문에 분석을 불가능하게 하거나 기밀성을 보장하지는 않습니다.
초보자가 가장 자주 뒤집는 지점
잘못된 생각 packing은 암호화이므로 key 없이는 코드를 실행하거나 읽을 수 없다.
왜 틀렸나 클라이언트가 실행해야 하는 code는 복원 로직과 함께 전달되므로 분석가도 그 과정을 관찰할 수 있습니다.
고쳐 말하면 obfuscation은 시간과 비용을 높이고 encryption은 적절한 key 없이는 내용을 얻기 어렵게 하는 별도 목표입니다.
한 문제만 더: 개념이 정말 연결됐는지 확인
질문 Stripped binary에서도 disassembly가 가능한 이유는 무엇입니까?
정답 CPU가 실행할 machine instructions는 제거할 수 없고, 주로 이름과 debug metadata가 제거되기 때문입니다.
이 문제의 오답 함정
이 소문제를 점수로 바꾸는 6개의 작은 훈련
해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.
해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.
막힐 때만 첫 단서 열기
packing은 코드를 압축·변형하고 stripping은 symbol/debug 정보를 제거해 분석과 원래 구조 복원을 어렵게 한다.
JS packing과 binary stripping은 reverse engineering을 어렵게 하는 obfuscation 방법이다.
정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.
작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.
답안 작성 후 채점 기준 열기
답안 슬롯 자가 점검 — 실제로 말하거나 쓴 항목만 체크하세요.
0/2 slots
조건 변형: 원문의 강한 표현(예: muss, immer, vollständig)을 조건부 표현으로 하나 고쳐 쓰고, 그 변경 뒤에는 판정이 왜 달라지거나 유지되는지 반례와 함께 설명하세요.
고칠 답안: obfuscation을 cryptographic confidentiality와 동일시하지 않는다.
복구 힌트: packing은 코드를 압축·변형하고 stripping은 symbol/debug 정보를 제거해 분석과 원래 구조 복원을 어렵게 한다.
오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.
채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인
Wahr. packing은 코드를 압축·변형하고 stripping은 symbol/debug 정보를 제거해 분석과 원래 구조 복원을 어렵게 한다.
4.1 f) NX bit는 주입된 code 실행을 막을 수 있다. 기존 71문항 학습 번호 62 · 2점 Wahr/Falsch
4.1 f) · 실제 시험 원문
한국어로 요구사항만 풀어 읽기
NX bit는 주입된 code 실행을 막을 수 있다.
TERMS FOR 4.1 f)
이 소문제의 중요한 용어부터 이해하기
전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.
특정 memory page를 데이터 전용으로 표시해 그 위치의 byte를 CPU 명령으로 실행하지 못하게 하는 보호 기능입니다.
작은 예: 입력 데이터가 stack에 들어가더라도 그 stack을 실행 금지 구역으로 만들 수 있습니다.
Shell에서 명령 연결·redirection 등 특별한 문법 의미를 갖는 문자입니다.
작은 예: 세미콜론 `;`은 앞 명령을 끝내고 다음 명령을 시작할 수 있습니다.
프로그램이 byte나 문자를 잠시 저장하도록 확보한 연속 memory 공간입니다.
Buffer가 합법적으로 사용할 수 있는 시작과 끝 범위입니다.
C 문자열의 끝을 표시하는 값 `\0`으로, 저장 공간 1바이트를 차지합니다.
한 함수 호출의 local variable, 저장된 register, return 관련 정보가 놓이는 stack 영역입니다.
확보한 buffer 범위를 넘어 write하여 인접 memory를 손상시키는 오류입니다.
이 소문제만을 위한 0부터 시작하는 미니 강의
아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.
1 · 먼저 알아야 할 개념
운영체제는 virtual memory를 page 단위로 관리하며 각 page에 읽기, 쓰기, 실행 권한을 설정할 수 있습니다.
NX(No-eXecute) bit 또는 DEP는 stack·heap처럼 데이터를 저장하는 page를 실행 불가로 표시합니다. 공격자가 그곳에 machine code(shellcode)를 주입해도 CPU가 해당 주소에서 instruction을 실행하려 하면 차단됩니다.
NX는 주입 자체나 memory corruption을 고치는 것이 아니며, 이미 실행 권한이 있는 code 조각을 재사용하는 ROP 같은 공격은 별도 방어가 필요합니다.
2 · 일상 장면으로 먼저 잡기
회사 건물에서 종이를 보관하는 자료실과 직원이 작업하는 작업장을 구분하고, 자료실에서는 어떤 작업 지시도 수행하지 못하게 하는 규칙입니다.
비유의 경계 공격자가 이미 작업장에 있는 합법적 도구를 순서만 바꿔 쓰는 ROP는 자료실 실행 금지만으로 완전히 막히지 않습니다.
원래 program instruction 실행 가능
stack·heap data 저장, 실행 불가
data page에 공격 byte 기록
그 주소에서 실행하려 할 때 차단
NX의 핵심은 byte가 악성인지 판별하는 것이 아니라 해당 page에서 실행 자체를 허용하지 않는 것입니다.
Stack에 들어간 byte와 실행 권한
주어진 것과 목표 Buffer overflow로 공격 byte가 stack 주소 0x7fff...에 저장되고 return address가 그곳을 가리키게 되었습니다.
stack page의 권한을 확인합니다.
왜? 저장된 byte를 instruction으로 실행할 수 있는지 결정하기 위해서입니다.
중간 결과 NX가 켜져 있으면 read/write이고 execute 권한은 없습니다.
CPU가 변조된 return address로 이동합니다.
왜? 공격 시도에서 실제 실행 단계입니다.
중간 결과 NX page에서 instruction fetch가 발생합니다.
운영체제의 반응을 판단합니다.
왜? NX가 막는 정확한 지점을 확인하기 위해서입니다.
중간 결과 실행 권한 위반으로 fault가 발생해 injected code의 직접 실행이 차단됩니다.
예제 결론 NX는 data page에 주입된 code의 직접 실행을 막을 수 있습니다.
실제 시험으로 옮기기 문장은 ‘막을 수 있다(kann)’고 제한적으로 주장하므로 Wahr입니다.
이번 문제는 이 단계로 풀어야 했습니다
먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.
먼저 문제를 식과 조건으로 정리하기
계산을 시작하기 전에 주어진 것과 구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.
강사가 문제의 요구사항을 쉬운 말로 바꾸면
시험 문장이 요구하는 것: NX bit는 주입된 code 실행을 막을 수 있다.
이 문제의 풀이 전략: 이 소문제에서는 NX가 제어하는 대상을 정한다 → 주입 공격의 실행 단계를 추적한다 → NX가 끊는 연결을 찾는다 → 문장의 제한된 표현을 판정한다 순서로 진행합니다. 마지막에는 ‘overflow는 여전히 가능하지만 주입한 data를 code로 실행하는 다음 단계가 막힌다고 씁니다.’라는 교정 기준으로 답을 다시 확인합니다.
문제에서 주어진 정보
NX bit는 주입된 code 실행을 막을 수 있다.
Memory page의 execute permission을 제어해 data 영역을 non-executable로 만듭니다.
입력 validation 기술로 잘못 설명하지 않습니다.
최종적으로 구해야 하는 것
‘주입된 code 실행을 막을 수 있다’는 정확한 범위이므로 Wahr입니다.
정답은 Wahr입니다. NX는 stack과 heap 같은 data page의 execute 권한을 제거해 그곳에 주입된 shellcode를 직접 실행하지 못하게 할 수 있습니다. 다만 memory corruption 자체를 제거하지 않고, 기존 executable code를 재사용하는 ROP 같은 우회가 있어 완전한 방어는 아닙니다.
사용할 공식·판정 관계
NX가 제어하는 대상을 정한다 → 주입 공격의 실행 단계를 추적한다 → NX가 끊는 연결을 찾는다 → 문장의 제한된 표현을 판정한다
NX의 핵심은 byte가 악성인지 판별하는 것이 아니라 해당 page에서 실행 자체를 허용하지 않는 것입니다.
NX가 제어하는 대상을 정한다
구체적으로 Memory page의 execute permission을 제어해 data 영역을 non-executable로 만듭니다.
여기서 검산 입력 validation 기술로 잘못 설명하지 않습니다.
다음 단계로 여기서 확인한 내용을 다음 ‘주입 공격의 실행 단계를 추적한다’ 단계의 출발점으로 사용합니다.
주입 공격의 실행 단계를 추적한다
구체적으로 공격자가 stack/heap에 shellcode를 쓰고 control flow를 그 주소로 돌리려 합니다.
여기서 검산 주입과 실행을 두 단계로 나눕니다.
다음 단계로 여기서 확인한 내용을 다음 ‘NX가 끊는 연결을 찾는다’ 단계의 출발점으로 사용합니다.
NX가 끊는 연결을 찾는다
구체적으로 CPU가 non-executable page에서 instruction을 가져오려는 순간 fault가 발생합니다.
여기서 검산 주입 byte 저장 자체를 막는다고 쓰지 않습니다.
다음 단계로 여기서 확인한 내용을 다음 ‘문장의 제한된 표현을 판정한다’ 단계의 출발점으로 사용합니다.
문장의 제한된 표현을 판정한다
구체적으로 ‘주입된 code 실행을 막을 수 있다’는 정확한 범위이므로 Wahr입니다.
여기서 검산 ROP까지 모두 막는다는 과장을 답안에 넣지 않습니다.
다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.
정답과 해설
Wahr. data page를 non-executable로 표시해 stack/heap에 넣은 shellcode의 직접 실행을 차단한다.
시험 답안 골격
정답이 이렇게 되는 이유
정답은 Wahr입니다. NX는 stack과 heap 같은 data page의 execute 권한을 제거해 그곳에 주입된 shellcode를 직접 실행하지 못하게 할 수 있습니다. 다만 memory corruption 자체를 제거하지 않고, 기존 executable code를 재사용하는 ROP 같은 우회가 있어 완전한 방어는 아닙니다.
초보자가 가장 자주 뒤집는 지점
잘못된 생각 NX가 켜지면 buffer overflow 자체가 일어나지 않는다.
왜 틀렸나 NX는 memory write의 경계를 검사하지 않고 page의 실행 권한만 제한합니다.
고쳐 말하면 overflow는 여전히 가능하지만 주입한 data를 code로 실행하는 다음 단계가 막힌다고 씁니다.
한 문제만 더: 개념이 정말 연결됐는지 확인
질문 NX와 ASLR은 각각 무엇을 어렵게 합니까?
정답 NX는 data page에서의 실행을, ASLR은 code·stack·library 주소의 예측을 어렵게 합니다.
이 문제의 오답 함정
이 소문제를 점수로 바꾸는 6개의 작은 훈련
해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.
해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.
막힐 때만 첫 단서 열기
data page를 non-executable로 표시해 stack/heap에 넣은 shellcode의 직접 실행을 차단한다.
NX bit는 주입된 code 실행을 막을 수 있다.
정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.
작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.
답안 작성 후 채점 기준 열기
답안 슬롯 자가 점검 — 실제로 말하거나 쓴 항목만 체크하세요.
0/2 slots
조건 변형: 원문의 강한 표현(예: muss, immer, vollständig)을 조건부 표현으로 하나 고쳐 쓰고, 그 변경 뒤에는 판정이 왜 달라지거나 유지되는지 반례와 함께 설명하세요.
고칠 답안: ROP처럼 기존 executable code 재사용 공격까지 모두 막는다고 하지 않는다.
복구 힌트: data page를 non-executable로 표시해 stack/heap에 넣은 shellcode의 직접 실행을 차단한다.
오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.
채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인
Wahr. data page를 non-executable로 표시해 stack/heap에 넣은 shellcode의 직접 실행을 차단한다.
4.1 g) ATM·차량·IoT 같은 특수 시스템 forensics는 고전 IT forensics 영역에 속하지 않는다. 기존 71문항 학습 번호 63 · 2점 Wahr/Falsch
4.1 g) · 실제 시험 원문
한국어로 요구사항만 풀어 읽기
ATM·차량·IoT 같은 특수 시스템 forensics는 고전 IT forensics 영역에 속하지 않는다.
TERMS FOR 4.1 g)
이 소문제의 중요한 용어부터 이해하기
전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.
사건을 입증하거나 반박하는 데 사용될 수 있는 digital data입니다.
파일만이 아니라 매체의 sector를 bit 단위로 복제한 분석용 image입니다.
원본 저장매체로 write command가 전달되지 않게 막는 장치나 절차입니다.
누가 언제 어디서 어떤 목적으로 증거를 인수·접근·인계했는지 남기는 연속 기록입니다.
이 소문제만을 위한 0부터 시작하는 미니 강의
아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.
1 · 먼저 알아야 할 개념
Digital forensics는 digital device와 data를 수집·분석해 재현 가능한 증거를 만드는 분야입니다. 이 문항에서는 현실의 일반적인 분류를 추측하는 것이 아니라 강의 슬라이드가 제시한 작업 영역(Arbeitsgebiete)의 계층을 그대로 읽어야 합니다.
강의의 ‘IT-Forensik – Arbeitsgebiete’ 슬라이드에는 상위 bullet ‘Klassische IT-Forensik’이 있고, 그 아래에 Datenträger-, Memory-, Netzwerk-Forensik과 ‘Forensik für besondere IT-Systeme’가 같은 수준의 하위 bullet로 열거됩니다.
‘Forensik für besondere IT-Systeme’ 뒤의 예시는 Geldautomaten, Unterhaltungselektronik, Fahrzeugelektronik, IoT입니다. 따라서 이 강의 분류에서는 바로 그 대상들이 classical IT-Forensik의 작업 영역 안에 있습니다.
시험 문장은 ‘gehört nicht’, 즉 ‘속하지 않는다’고 주장합니다. 강의의 포함 관계와 정확히 반대이므로 정답은 Falsch입니다.
2 · 일상 장면으로 먼저 잡기
파일 탐색기에서 ‘Klassische IT-Forensik’ 폴더를 펼치는 장면을 떠올립니다. 폴더 안에 저장매체, 메모리, 네트워크와 함께 ‘특수 IT 시스템’ 항목이 보입니다.
비유의 경계 실제 PDF는 폴더가 아니라 글머리표와 들여쓰기로 계층을 표현합니다. 업계의 다른 분류 체계가 아니라 이 강의 슬라이드의 들여쓰기를 근거로 삼아야 합니다.
강의 슬라이드의 상위 bullet
같은 부모 아래의 작업 영역
역시 같은 부모 아래의 작업 영역
특수 IT 시스템의 예시
위 포함 관계를 부정하므로 틀린 주장
핵심은 장치의 특성이 아니라 bullet의 부모–자식 관계입니다.
슬라이드의 들여쓰기를 포함 관계로 바꾸기
주어진 것과 목표 다음 축약 목록을 읽습니다: ‘Klassische IT-Forensik → Datenträger / Memory / Netzwerk / besondere IT-Systeme: ATM, Fahrzeug, IoT’.
가장 왼쪽의 상위 항목을 찾습니다.
왜? 하위 목록의 소속을 결정해야 하기 때문입니다.
중간 결과 상위 범주는 ‘Klassische IT-Forensik’입니다.
그 아래 같은 들여쓰기의 항목을 묶습니다.
왜? 같은 깊이의 bullet은 같은 부모에 속하기 때문입니다.
중간 결과 Datenträger, Memory, Netzwerk, besondere IT-Systeme가 모두 하위 작업 영역입니다.
특수 시스템 뒤의 예시를 연결합니다.
왜? 시험에 나온 장치가 어느 항목에 속하는지 확인하기 위해서입니다.
중간 결과 ATM·차량·IoT가 ‘besondere IT-Systeme’의 예시입니다.
시험 문장의 부정과 대조합니다.
왜? 참/거짓은 강의 관계와 문장 관계가 같은지로 판단하기 때문입니다.
중간 결과 강의는 포함, 문장은 불포함이므로 Falsch입니다.
예제 결론 특수 IT 시스템 forensics는 이 강의 슬라이드에서 classical IT-Forensik 아래에 포함됩니다.
실제 시험으로 옮기기 문장의 ‘gehört nicht’가 슬라이드 계층과 반대이므로 Falsch를 고릅니다.
이번 문제는 이 단계로 풀어야 했습니다
먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.
먼저 문제를 식과 조건으로 정리하기
계산을 시작하기 전에 주어진 것과 구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.
강사가 문제의 요구사항을 쉬운 말로 바꾸면
시험 문장이 요구하는 것: ATM·차량·IoT 같은 특수 시스템 forensics는 고전 IT forensics 영역에 속하지 않는다.
이 문제의 풀이 전략: 이 소문제에서는 판정할 관계를 표시한다 → 강의의 상위 bullet을 찾는다 → 특수 시스템의 들여쓰기를 확인한다 → 시험의 장치 예시를 연결한다 → 포함과 불포함을 대조한다 순서로 진행합니다. 마지막에는 ‘이 시험에서는 ‘Klassische IT-Forensik ⊃ Forensik für besondere IT-Systeme ⊃ ATM·차량·IoT 예시’라는 강의 계층을 그대로 적용합니다.’라는 교정 기준으로 답을 다시 확인합니다.
문제에서 주어진 정보
ATM·차량·IoT 같은 특수 시스템 forensics는 고전 IT forensics 영역에 속하지 않는다.
문장의 핵심은 ATM·차량·IoT forensics가 classical IT-Forensik의 Arbeitsgebiete에 ‘속하지 않는다(gehört nicht)’는 주장입니다.
부정어 nicht를 빠뜨리지 않았는지 확인합니다.
최종적으로 구해야 하는 것
슬라이드는 포함 관계인데 문장은 불포함이라고 하므로 둘이 모순됩니다.
정답은 Falsch입니다. 강의 슬라이드에서 ‘Forensik für besondere IT-Systeme’는 ‘Klassische IT-Forensik’의 하위 작업 영역이며, Geldautomaten·Unterhaltungselektronik·Fahrzeugelektronik·IoT가 그 예시로 명시됩니다. 따라서 이들이 classical IT-Forensik의 작업 영역에 속하지 않는다는 시험 문장은 강의의 계층과 반대입니다.
사용할 공식·판정 관계
판정할 관계를 표시한다 → 강의의 상위 bullet을 찾는다 → 특수 시스템의 들여쓰기를 확인한다 → 시험의 장치 예시를 연결한다 → 포함과 불포함을 대조한다
핵심은 장치의 특성이 아니라 bullet의 부모–자식 관계입니다.
판정할 관계를 표시한다
구체적으로 문장의 핵심은 ATM·차량·IoT forensics가 classical IT-Forensik의 Arbeitsgebiete에 ‘속하지 않는다(gehört nicht)’는 주장입니다.
여기서 검산 부정어 nicht를 빠뜨리지 않았는지 확인합니다.
다음 단계로 여기서 확인한 내용을 다음 ‘강의의 상위 bullet을 찾는다’ 단계의 출발점으로 사용합니다.
강의의 상위 bullet을 찾는다
구체적으로 ‘IT-Forensik – Arbeitsgebiete’ 슬라이드에서 ‘Klassische IT-Forensik’을 부모 항목으로 잡습니다.
여기서 검산 일반적인 업계 분류가 아니라 시험 강의 자료를 보고 있는지 확인합니다.
다음 단계로 여기서 확인한 내용을 다음 ‘특수 시스템의 들여쓰기를 확인한다’ 단계의 출발점으로 사용합니다.
특수 시스템의 들여쓰기를 확인한다
구체적으로 ‘Forensik für besondere IT-Systeme’는 Datenträger-, Memory-, Netzwerk-Forensik과 함께 그 부모 아래에 열거됩니다.
여기서 검산 같은 들여쓰기 수준의 항목들이 같은 부모를 갖는지 확인합니다.
다음 단계로 여기서 확인한 내용을 다음 ‘시험의 장치 예시를 연결한다’ 단계의 출발점으로 사용합니다.
시험의 장치 예시를 연결한다
구체적으로 Geldautomaten, Unterhaltungselektronik, Fahrzeugelektronik, IoT가 바로 ‘besondere IT-Systeme’의 예시로 적혀 있습니다.
여기서 검산 시험 문장의 네 장치군이 모두 슬라이드 목록과 대응하는지 검산합니다.
다음 단계로 여기서 확인한 내용을 다음 ‘포함과 불포함을 대조한다’ 단계의 출발점으로 사용합니다.
포함과 불포함을 대조한다
구체적으로 슬라이드는 포함 관계인데 문장은 불포함이라고 하므로 둘이 모순됩니다.
여기서 검산 따라서 최종 표시는 Falsch입니다.
다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.
정답과 해설
Falsch. 특수 IT 시스템 forensics는 강의 슬라이드에서 classical IT-Forensik의 작업 영역으로 포함되어 있다.
시험 답안 골격
정답이 이렇게 되는 이유
정답은 Falsch입니다. 강의 슬라이드에서 ‘Forensik für besondere IT-Systeme’는 ‘Klassische IT-Forensik’의 하위 작업 영역이며, Geldautomaten·Unterhaltungselektronik·Fahrzeugelektronik·IoT가 그 예시로 명시됩니다. 따라서 이들이 classical IT-Forensik의 작업 영역에 속하지 않는다는 시험 문장은 강의의 계층과 반대입니다.
초보자가 가장 자주 뒤집는 지점
잘못된 생각 특수 장치는 전문 도구가 필요하므로 classical IT-Forensik과 별개의 범주일 것이다.
왜 틀렸나 현실적으로 그럴듯한 추측을 강의 슬라이드의 명시적 bullet 계층보다 우선한 오류입니다.
고쳐 말하면 이 시험에서는 ‘Klassische IT-Forensik ⊃ Forensik für besondere IT-Systeme ⊃ ATM·차량·IoT 예시’라는 강의 계층을 그대로 적용합니다.
한 문제만 더: 개념이 정말 연결됐는지 확인
질문 왜 이 문항은 장치별 도구의 차이를 길게 논증하는 것보다 슬라이드의 들여쓰기를 확인하는 것이 더 직접적인가요?
정답 문항이 강의가 정한 Arbeitsgebiete의 포함 관계를 묻고 있고, 슬라이드가 ‘besondere IT-Systeme’를 ‘Klassische IT-Forensik’ 아래에 직접 열거하기 때문입니다.
이 문제의 오답 함정
이 소문제를 점수로 바꾸는 6개의 작은 훈련
해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.
해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.
막힐 때만 첫 단서 열기
강의 슬라이드의 글머리표 들여쓰기를 보라. ‘Forensik für besondere IT-Systeme’의 상위 bullet은 무엇인가?
ATM·차량·IoT 같은 특수 시스템 forensics는 고전 IT forensics 영역에 속하지 않는다.
정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.
작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.
답안 작성 후 채점 기준 열기
답안 슬롯 자가 점검 — 실제로 말하거나 쓴 항목만 체크하세요.
0/2 slots
조건 변형: 원문의 강한 표현(예: muss, immer, vollständig)을 조건부 표현으로 하나 고쳐 쓰고, 그 변경 뒤에는 판정이 왜 달라지거나 유지되는지 반례와 함께 설명하세요.
고칠 답안: 현실에서 별도 전문 분야로 부르는 관행만 보고 시험 강의의 포함 관계를 뒤집는 것.
복구 힌트: 강의 슬라이드의 글머리표 들여쓰기를 보라. ‘Forensik für besondere IT-Systeme’의 상위 bullet은 무엇인가?
오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.
채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인
Falsch. 특수 IT 시스템 forensics는 강의 슬라이드에서 classical IT-Forensik의 작업 영역으로 포함되어 있다.
4.1 h) fuzzing oracle은 program 동작에 대한 feedback을 준다. 기존 71문항 학습 번호 64 · 2점 Wahr/Falsch
4.1 h) · 실제 시험 원문
한국어로 요구사항만 풀어 읽기
fuzzing oracle은 program 동작에 대한 feedback을 준다.
TERMS FOR 4.1 h)
이 소문제의 중요한 용어부터 이해하기
전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.
Fuzzing 중 프로그램의 비정상 동작을 판정하는 관찰 기준입니다.
작은 예: Crash, timeout, sanitizer 경고, 잘못된 응답을 보고 ‘흥미로운 입력’이라고 판단합니다.
정상·비정상 입력을 대량으로 생성하거나 변형해 프로그램에 넣고 crash나 이상 동작을 찾는 테스트 기법입니다.
작은 예: PNG parser에 길이가 깨진 파일 수천 개를 넣고 sanitizer crash를 수집합니다.
많은 test input을 자동 생성·변형하고 target program에 실행하는 도구입니다.
Fuzzing을 시작할 때 기본 구조를 제공하는 초기 입력 모음입니다.
기존 입력의 byte·길이·구조를 변경해 새 test case를 만드는 과정입니다.
Crash, sanitizer report, output mismatch 등 실패 여부를 판정하는 관찰 기준입니다.
특정 입력이 program code의 어느 부분을 실행했는지 나타내는 정보입니다.
이 소문제만을 위한 0부터 시작하는 미니 강의
아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.
1 · 먼저 알아야 할 개념
Fuzzing은 많은 입력을 자동으로 생성하거나 변형해 실제 program에 실행하고 이상 동작을 찾는 dynamic testing 기법입니다.
이때 oracle은 ‘이번 실행이 정상인지 실패인지’를 판정하는 관찰 기준입니다. Crash, sanitizer report, timeout, assertion failure, 예상값과 실제값의 불일치가 oracle 신호가 될 수 있습니다.
Coverage feedback은 어떤 code path를 새로 실행했는지를 알려 주어 다음 입력 선택을 돕고, bug oracle은 그 실행이 잘못되었는지를 판정합니다. 둘은 관련 있지만 같은 질문에 답하지 않습니다.
2 · 일상 장면으로 먼저 잡기
자동으로 수천 개의 열쇠를 자물쇠에 넣는 로봇 옆에서 경보등, 파손 센서, 열린 문을 관찰하는 검사원입니다.
비유의 경계 좋은 oracle이 없으면 program이 조용히 잘못된 결과를 내도 발견하지 못할 수 있습니다.
새 입력 생성
program 실제 실행
crash·timeout·mismatch 판정
실패 입력 저장·재현
관찰하지 않는 오류는 놓칠 수 있음
입력 생성만으로는 bug가 되지 않으며 oracle이 실행 결과를 판정해야 합니다.
나눗셈 parser의 두 종류 feedback
주어진 것과 목표 입력
10/0을 계산기 program에 fuzzing합니다.Fuzzer가
10/2를10/0으로 변형합니다.왜? 경계값 0을 시험하기 위해서입니다.
중간 결과 새 testcase가 target에 전달됩니다.
Program을 실제 실행합니다.
왜? 동적 행동을 관찰해야 하기 때문입니다.
중간 결과 divide-by-zero exception 또는 crash가 발생합니다.
Oracle이 실행 결과를 판정합니다.
왜? 단순 실행과 bug 발견을 연결하기 위해서입니다.
중간 결과 crash signal을 실패로 분류하고 입력을 보존합니다.
예제 결론 Oracle은 program 행동을 관찰해 관심 있는 실패 여부를 알려 줍니다.
실제 시험으로 옮기기 시험 문장은 oracle이 program behavior에 관한 feedback을 준다고 했으므로 Wahr입니다.
이번 문제는 이 단계로 풀어야 했습니다
먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.
먼저 문제를 식과 조건으로 정리하기
계산을 시작하기 전에 주어진 것과 구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.
강사가 문제의 요구사항을 쉬운 말로 바꾸면
시험 문장이 요구하는 것: fuzzing oracle은 program 동작에 대한 feedback을 준다.
이 문제의 풀이 전략: 이 소문제에서는 Fuzzing의 구성 요소를 분리한다 → Feedback의 예를 대입한다 → 시험 문장의 범위를 확인한다 → Wahr와 기능을 쓴다 순서로 진행합니다. 마지막에는 ‘Generator는 입력을 만들고 oracle은 실행 결과가 실패인지 판단합니다.’라는 교정 기준으로 답을 다시 확인합니다.
문제에서 주어진 정보
fuzzing oracle은 program 동작에 대한 feedback을 준다.
입력 생성기, 실행 대상, 실행 결과를 판정하는 oracle이 있습니다.
oracle을 입력 생성기라고 부르지 않습니다.
최종적으로 구해야 하는 것
Wahr. Oracle은 실행 결과를 관찰해 실패 여부를 판정하는 feedback을 제공합니다.
정답은 Wahr입니다. Fuzzing oracle은 program 실행에서 crash, sanitizer 오류, timeout, 잘못된 출력 같은 신호를 관찰해 testcase가 문제를 드러냈는지 판정합니다. Coverage도 feedback이 될 수 있지만 새 path 발견과 bug 판정은 구분해야 합니다. Oracle이 관찰하지 못하는 조용한 논리 오류는 놓칠 수 있습니다.
사용할 공식·판정 관계
Fuzzing의 구성 요소를 분리한다 → Feedback의 예를 대입한다 → 시험 문장의 범위를 확인한다 → Wahr와 기능을 쓴다
입력 생성만으로는 bug가 되지 않으며 oracle이 실행 결과를 판정해야 합니다.
Fuzzing의 구성 요소를 분리한다
구체적으로 입력 생성기, 실행 대상, 실행 결과를 판정하는 oracle이 있습니다.
여기서 검산 oracle을 입력 생성기라고 부르지 않습니다.
다음 단계로 여기서 확인한 내용을 다음 ‘Feedback의 예를 대입한다’ 단계의 출발점으로 사용합니다.
Feedback의 예를 대입한다
구체적으로 Crash, sanitizer report, invariant violation, output mismatch가 program behavior의 관찰 신호입니다.
여기서 검산 적어도 하나의 구체적 신호를 듭니다.
다음 단계로 여기서 확인한 내용을 다음 ‘시험 문장의 범위를 확인한다’ 단계의 출발점으로 사용합니다.
시험 문장의 범위를 확인한다
구체적으로 문장은 oracle이 완벽히 모든 bug를 찾는다고 하지 않고 behavior에 관한 feedback을 준다고만 합니다.
여기서 검산 과장 표현이 없는지 확인합니다.
다음 단계로 여기서 확인한 내용을 다음 ‘Wahr와 기능을 쓴다’ 단계의 출발점으로 사용합니다.
Wahr와 기능을 쓴다
구체적으로 Wahr. Oracle은 실행 결과를 관찰해 실패 여부를 판정하는 feedback을 제공합니다.
여기서 검산 coverage와 bug 판정을 혼동하지 않습니다.
다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.
정답과 해설
Wahr. crash, sanitizer report, invariant violation, output mismatch 등으로 입력이 실패를 유발했는지 판정한다.
시험 답안 골격
정답이 이렇게 되는 이유
정답은 Wahr입니다. Fuzzing oracle은 program 실행에서 crash, sanitizer 오류, timeout, 잘못된 출력 같은 신호를 관찰해 testcase가 문제를 드러냈는지 판정합니다. Coverage도 feedback이 될 수 있지만 새 path 발견과 bug 판정은 구분해야 합니다. Oracle이 관찰하지 못하는 조용한 논리 오류는 놓칠 수 있습니다.
초보자가 가장 자주 뒤집는 지점
잘못된 생각 Oracle은 다음에 넣을 random input을 생성하는 component다.
왜 틀렸나 입력 생성과 결과 판정은 서로 다른 역할입니다.
고쳐 말하면 Generator는 입력을 만들고 oracle은 실행 결과가 실패인지 판단합니다.
한 문제만 더: 개념이 정말 연결됐는지 확인
질문 새 branch를 실행했지만 출력은 정상이라면 coverage feedback과 bug oracle은 각각 무엇을 말합니까?
정답 Coverage는 새 경로라고 말하지만 bug oracle은 관찰된 실패가 없다고 말할 수 있습니다.
이 문제의 오답 함정
이 소문제를 점수로 바꾸는 6개의 작은 훈련
해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.
해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.
막힐 때만 첫 단서 열기
crash, sanitizer report, invariant violation, output mismatch 등으로 입력이 실패를 유발했는지 판정한다.
fuzzing oracle은 program 동작에 대한 feedback을 준다.
정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.
작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.
답안 작성 후 채점 기준 열기
답안 슬롯 자가 점검 — 실제로 말하거나 쓴 항목만 체크하세요.
0/2 slots
조건 변형: 원문의 강한 표현(예: muss, immer, vollständig)을 조건부 표현으로 하나 고쳐 쓰고, 그 변경 뒤에는 판정이 왜 달라지거나 유지되는지 반례와 함께 설명하세요.
고칠 답안: oracle을 미래를 예측하는 AI로 이해하지 않는다.
복구 힌트: crash, sanitizer report, invariant violation, output mismatch 등으로 입력이 실패를 유발했는지 판정한다.
오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.
채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인
Wahr. crash, sanitizer report, invariant violation, output mismatch 등으로 입력이 실패를 유발했는지 판정한다.