4. Security Engineering · 실제 시험 Abschnitt 4.3
4.3. Software und Hardwaresicherheit
Buffer overflow, input sanitization, fuzzing, static/dynamic analysis, forensic evidence를 시험지 1–5번 순서 그대로 학습합니다.
이 페이지는 비슷한 주제를 임의로 다시 묶지 않고 실제 시험지의 Chapter → subsection → 소문제 순서를 그대로 따릅니다.
ACTUAL EXAM · VERBATIM TRANSCRIPT
시험지 원문 1:1 전사
아래 내용은 해설자가 바꿔 쓴 요약이 아닙니다. 실제 시험 전사본의 문장·순서·수치·배점·코드·표를 그대로 두고, Markdown 기호만 읽기 쉬운 제목·표·코드 모양으로 표시했습니다.
4.3. Software und Hardwaresicherheit (12 Punkte)
1. Beschreiben Sie kurz die Funktionsweise eines Stack-based Buffer Overflow. (2 Punkte)
2. Was ist Input Sanitization? (2 Punkte)
3. Was ist Fuzzing? (2 Punkte)
4. Was ist der Unterschied zwischen statischer und dynamischer Analyse? (2 Punkte)
5. Nennen Sie zwei Maßnahmen zur Sicherung der Integrität der Beweiskette bei der forensischen Datensammlung. (4 Punkte)
근거: CSS_Altklausur_WiSe_2526.pdf 및 computersystemsicherheit_wise25-26_questions_only.md · Abschnitt 4.3
VISUAL MAP
오류 발견에서 증거 보존까지 왼쪽에서 오른쪽으로 읽은 뒤 아래 실제 소문제에서 같은 순서를 반복합니다.- 01 경계 밖 write
- 02 입력 검증
- 03 Fuzzing
- 04 Static·Dynamic
- 05 Image·Hash·Custody
FIXED SOLVING METHOD
이 묶음의 고정 풀이 순서
- 문항이 오류 원리·입력 처리·테스트·분석·증거 보존 중 무엇인지 분류합니다.
- 정의를 주체→행동→결과 순서로 씁니다.
- 작은 실제 예를 하나 대입합니다.
- 기법이 보장하지 못하는 한계를 한 문장 붙입니다.
- 2점 문항은 핵심 두 요소, 4점 문항은 서로 다른 두 조치를 명확히 분리합니다.
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
Browser, server, HTTP, HTML parser
먼저 장면으로 이해해 봅시다. 같은 기호도 일반 편지 본문에서는 글자지만 계산식 칸에서는 연산자로 읽힌다. Browser도 입력이 HTML text, attribute, script 중 어디에 들어갔는지에 따라 다르게 해석한다.
이제 전문 용어를 붙이면 다음과 같습니다. HTTP request은(는) Browser나 client가 server에 method, path, headers, body를 담아 보내는 message입니다. HTTP response은(는) Server가 status, headers, body를 담아 client에 돌려주는 message입니다. Parser / Interpreter은(는) 문자열을 HTML, JavaScript, SQL, shell 같은 문법으로 해석하는 구성요소입니다. Context은(는) 같은 문자가 어느 문법의 어느 위치에 놓였는지를 뜻하며 올바른 encoding 방법을 결정합니다.
실제 시스템에서는 이렇게 작동합니다. Browser는 사용자의 client 프로그램이고 web server는 request를 받아 response를 만드는 프로그램이다. HTTP request에는 method, URL, header, body가 있고 response에는 status, header, body가 있다. Browser는 response body를 단순 글자가 아니라 HTML, JavaScript 같은 문법으로 해석(parse)한다. 외부 입력이 처음 들어오는 곳을 source, 그 입력이 실제 기능에 사용되는 위험한 도착점을 sink라고 부른다. 따라서 입력이 어느 문법 위치와 sink에 들어가는지가 보안에 매우 중요하다.
- 사용자 입력이 들어오는 source를 찾는다.
- 입력이 출력·DB·명령으로 들어가는 sink를 찾는다.
- 그 sink를 어떤 parser가 어떤 context로 읽는지 확인한다.
- 공격 영향과 context에 맞는 방어를 연결한다.
여기서 넘지 말아야 할 경계: 입력 문자열 자체만 보고 취약점을 이름 붙이지 말고 source에서 sink까지 실제 흐름을 추적한다.
15. HTTP request·GET·POST·TLS 독립 강의 →기초 개념 03
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 독립 강의 →기초 개념 04
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 독립 강의 →기초 개념 05
보안이란 무엇을 지키는 것인가
먼저 장면으로 이해해 봅시다. 봉투에 넣어 내용을 가리는 것은 기밀성, 봉인 스티커로 개봉 여부를 확인하는 것은 무결성, 발신인의 도장을 확인하는 것은 진위성, 우체국이 문을 열어 편지를 계속 전달하는 것은 가용성에 가깝다.
이제 전문 용어를 붙이면 다음과 같습니다. Asset은(는) 공격자로부터 지키려는 대상입니다. 파일, 비밀번호, 서비스 가용성, 사람의 개인정보가 모두 asset이 될 수 있습니다. Confidentiality은(는) 허가받지 않은 사람이 내용을 읽지 못하게 하는 기밀성입니다. Integrity은(는) 데이터나 시스템이 허가 없이 바뀌지 않았음을 보장하려는 무결성입니다. Availability은(는) 정당한 사용자가 필요할 때 서비스와 데이터에 접근할 수 있는 가용성입니다.
실제 시스템에서는 이렇게 작동합니다. 컴퓨터 보안은 막연히 ‘안전하게 만들기’가 아니라 지켜야 할 성질을 구분하는 일에서 시작한다. 기밀성(Vertraulichkeit, confidentiality)은 허가받지 않은 사람이 내용을 읽지 못하게 하는 것, 무결성(Integrität, integrity)은 내용이 몰래 바뀌지 않았음을 확인하는 것, 진위성(Authentizität, authenticity)은 상대나 데이터의 출처가 주장과 맞는지 확인하는 것이다. 서비스가 필요할 때 계속 동작하는 성질은 가용성(Verfügbarkeit, availability)이라고 한다.
- 문제에서 숨김, 변조 탐지, 신원 확인, 서비스 중단 중 무엇을 묻는지 찾는다.
- 한 기술이 네 목표를 모두 자동으로 제공한다고 가정하지 않는다.
- 공격자가 무엇을 할 수 있는지와 지켜야 할 목표를 한 문장씩 분리한다.
여기서 넘지 말아야 할 경계: TLS, 암호화, 서명, hash처럼 익숙한 단어가 나오더라도 그 기술이 제공하지 않는 목표까지 확대해서 쓰면 안 된다.
01. 평문·암호문·키 독립 강의 →ACTIVE RECALL
이 페이지를 닫기 전 확인
- Stack overflow에서 무엇이 경계 밖에 덮이나요?
- Static과 dynamic의 기준은 실행 여부인가요?
- Hash와 custody log의 역할 차이는?
QUESTION-BY-QUESTION COMMENTARY
실제 시험 소문제별 해설
시험지의 번호와 순서를 그대로 유지했습니다. 각 항목을 열어 원문 → 쉬운 개념 설명 → 이번 문제의 단계별 풀이 → 답안 → 함정 순서로 읽으세요.
ACTUAL EXAM SUBSECTION 4.3
4.3. Software und Hardwaresicherheit
5개 학습 항목 · 12점
4.3.1 stack-based buffer overflow의 작동을 설명하시오. 기존 71문항 학습 번호 67 · 2점 단답형
4.3.1 · 실제 시험 원문
한국어로 요구사항만 풀어 읽기
stack-based buffer overflow의 작동을 설명하시오.
TERMS FOR 4.3.1
이 소문제의 중요한 용어부터 이해하기
전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.
Stack의 고정 크기 buffer 경계 밖까지 데이터를 써서 인접 변수나 제어 정보를 덮는 오류입니다.
작은 예: 8-byte buffer에 20-byte 입력을 복사하면 뒤의 saved frame pointer나 return address까지 손상될 수 있습니다.
프로그램이 byte나 문자를 잠시 저장하도록 확보한 연속 memory 공간입니다.
Buffer가 합법적으로 사용할 수 있는 시작과 끝 범위입니다.
C 문자열의 끝을 표시하는 값 `\0`으로, 저장 공간 1바이트를 차지합니다.
한 함수 호출의 local variable, 저장된 register, return 관련 정보가 놓이는 stack 영역입니다.
확보한 buffer 범위를 넘어 write하여 인접 memory를 손상시키는 오류입니다.
이 소문제만을 위한 0부터 시작하는 미니 강의
아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.
1 · 먼저 알아야 할 개념
Stack은 함수 호출마다 local variable과 함수가 끝난 뒤 돌아갈 주소(return address) 같은 정보를 저장하는 memory 영역입니다. Stack frame은 한 번의 함수 호출에 해당하는 묶음입니다.
고정 크기 local buffer에 용량보다 많은 byte를 쓰고 언어·함수가 경계를 검사하지 않으면 뒤의 stack data까지 연속해서 덮을 수 있습니다. 이것이 stack-based buffer overflow입니다.
덮인 대상에 따라 crash, local variable 변조, return address 변경이 생길 수 있습니다. 공격자가 control flow를 바꿀 가능성은 있지만 모든 overflow가 반드시 code execution으로 이어지는 것은 아닙니다.
2 · 일상 장면으로 먼저 잡기
칸막이가 약한 서랍장 첫 칸에 물건을 계속 밀어 넣어 옆 칸의 메모와 ‘퇴실할 문 번호’ 카드까지 밀어내는 상황입니다.
비유의 경계 현대 compiler와 ABI에서 실제 배치·방어는 달라질 수 있으며, 단순 그림이 정확한 모든 address 순서를 보장하지는 않습니다.
허용된 8 byte
초과 byte가 먼저 침범할 수 있음
호출 상태 정보
변조 시 control flow 영향
crash 또는 잘못된 주소로 이동 가능
입력 byte가 buffer 용량을 넘으면 같은 stack frame의 인접 영역으로 이어져 쓰일 수 있습니다.
8-byte buffer에 12 byte 복사
주어진 것과 목표
memcpy(buf, "ABCDEFGHIJKL", 12)처럼char buf[8]에 raw 12 byte를 길이 확인 없이 복사합니다.strcpy라면 끝의 NUL까지 13 byte가 쓰인다는 점은 별도로 셉니다.Buffer 용량을 셉니다.
왜? 경계 안과 밖을 구분하기 위해서입니다.
중간 결과 A부터 H까지 8 byte만 buf 안에 들어갑니다.
남은 입력을 추적합니다.
왜? overflow가 어느 방향으로 진행되는지 보기 위해서입니다.
중간 결과 I, J, K, L 네 byte가 인접 stack 영역을 덮습니다.
인접 대상의 의미를 판단합니다.
왜? 보안 영향을 설명하기 위해서입니다.
중간 결과 인접 variable이면 값이 바뀌고 control data이면 crash나 control-flow 변경이 가능합니다.
경계 검사를 적용합니다.
왜? 원인인 초과 쓰기를 제거하기 위해서입니다.
중간 결과 Destination capacity를 알고 복사 길이를 제한하거나 memory-safe abstraction을 사용합니다.
예제 결론 정의의 핵심은 stack의 fixed buffer 경계를 넘어 인접 데이터를 쓰는 것입니다.
실제 시험으로 옮기기 2점 답안에는 경계 밖 쓰기, 인접 control data, crash/control-flow 영향의 세 요소를 짧게 담습니다.
이번 문제는 이 단계로 풀어야 했습니다
먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.
먼저 문제를 식과 조건으로 정리하기
계산을 시작하기 전에 주어진 것과 구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.
강사가 문제의 요구사항을 쉬운 말로 바꾸면
시험 문장이 요구하는 것: stack-based buffer overflow의 작동을 설명하시오.
이 문제의 풀이 전략: 이 소문제에서는 저장 위치와 경계를 정의한다 → 초과 byte의 이동을 설명한다 → 영향을 조건부로 연결한다 → 대표 방어를 원인과 연결한다 순서로 진행합니다. 마지막에는 ‘용량 초과 입력 → 경계 밖 write → 인접 data 변조의 사슬로 설명합니다.’라는 교정 기준으로 답을 다시 확인합니다.
문제에서 주어진 정보
stack-based buffer overflow의 작동을 설명하시오.
함수의 stack frame에 고정 크기 local buffer가 있고, write가 그 capacity를 넘는 상황이라고 시작합니다.
heap overflow와 구분해 stack을 명시합니다.
최종적으로 구해야 하는 것
Length-aware API와 정확한 bounds check로 초과 write를 막고, canary·NX·ASLR은 exploitation을 어렵게 하는 보조 방어입니다.
Stack-based buffer overflow는 fixed-size local stack buffer보다 많은 data를 경계 검사 없이 써 인접 stack data를 덮는 현상입니다. 덮인 영역에는 local variable, saved frame pointer, return address가 포함될 수 있습니다. 결과는 crash나 data corruption일 수 있고, control data를 통제하면 control flow를 바꿀 가능성이 있습니다.
사용할 공식·판정 관계
저장 위치와 경계를 정의한다 → 초과 byte의 이동을 설명한다 → 영향을 조건부로 연결한다 → 대표 방어를 원인과 연결한다
입력 byte가 buffer 용량을 넘으면 같은 stack frame의 인접 영역으로 이어져 쓰일 수 있습니다.
저장 위치와 경계를 정의한다
구체적으로 함수의 stack frame에 고정 크기 local buffer가 있고, write가 그 capacity를 넘는 상황이라고 시작합니다.
여기서 검산 heap overflow와 구분해 stack을 명시합니다.
다음 단계로 여기서 확인한 내용을 다음 ‘초과 byte의 이동을 설명한다’ 단계의 출발점으로 사용합니다.
초과 byte의 이동을 설명한다
구체적으로 경계 검사가 없으면 초과 byte가 인접 local variable, saved frame pointer, saved return address 방향으로 덮을 수 있습니다.
여기서 검산 단순히 ‘buffer가 커진다’고 쓰지 않습니다.
다음 단계로 여기서 확인한 내용을 다음 ‘영향을 조건부로 연결한다’ 단계의 출발점으로 사용합니다.
영향을 조건부로 연결한다
구체적으로 데이터 손상·crash가 생기며 return address 같은 control data가 통제되면 control-flow hijack이 가능할 수 있습니다.
여기서 검산 항상 RCE라고 단정하지 않습니다.
다음 단계로 여기서 확인한 내용을 다음 ‘대표 방어를 원인과 연결한다’ 단계의 출발점으로 사용합니다.
대표 방어를 원인과 연결한다
구체적으로 Length-aware API와 정확한 bounds check로 초과 write를 막고, canary·NX·ASLR은 exploitation을 어렵게 하는 보조 방어입니다.
여기서 검산 예방과 완화의 역할을 구분합니다.
다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.
정답과 해설
고정 크기 local stack buffer보다 많은 데이터를 쓰면 인접한 local data, saved frame pointer, return address까지 덮을 수 있다. 공격자는 control flow를 바꾸거나 crash를 일으킬 수 있다.
시험 답안 골격
정답이 이렇게 되는 이유
Stack-based buffer overflow는 fixed-size local stack buffer보다 많은 data를 경계 검사 없이 써 인접 stack data를 덮는 현상입니다. 덮인 영역에는 local variable, saved frame pointer, return address가 포함될 수 있습니다. 결과는 crash나 data corruption일 수 있고, control data를 통제하면 control flow를 바꿀 가능성이 있습니다.
초보자가 가장 자주 뒤집는 지점
잘못된 생각 Buffer overflow는 buffer의 크기가 자동으로 늘어나는 현상이다.
왜 틀렸나 C의 고정 배열은 자동 확장되지 않으며 초과 write가 다른 memory object를 침범합니다.
고쳐 말하면 용량 초과 입력 → 경계 밖 write → 인접 data 변조의 사슬로 설명합니다.
한 문제만 더: 개념이 정말 연결됐는지 확인
질문 Canary, NX, ASLR은 각각 overflow 공격의 어느 부분을 어렵게 합니까?
정답 Canary는 특정 stack overwrite를 탐지하고, NX는 data page의 code 실행을 막으며, ASLR은 유용한 주소 예측을 어렵게 합니다. 어느 것도 올바른 bounds check를 대체하지 않습니다.
이 문제의 오답 함정
이 소문제를 점수로 바꾸는 6개의 작은 훈련
해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.
해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.
막힐 때만 첫 단서 열기
작은 서랍에 물건을 계속 밀어 넣어 옆 서랍의 주소표까지 덮어쓰는 상황이다.
stack-based buffer overflow의 작동을 설명하시오.
정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.
작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.
답안 작성 후 채점 기준 열기
답안 슬롯 자가 점검 — 실제로 말하거나 쓴 항목만 체크하세요.
0/3 slots
조건 변형: 원문의 핵심 조건 하나를 반대로 바꾸고, 기존 정답에서 어느 문장과 근거를 수정해야 하는지 두 문장으로 설명하세요.
고칠 답안: 모든 overflow가 반드시 즉시 code execution으로 이어진다고 단정하지 않는다.
복구 힌트: 작은 서랍에 물건을 계속 밀어 넣어 옆 서랍의 주소표까지 덮어쓰는 상황이다.
오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.
채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인
고정 크기 local stack buffer보다 많은 데이터를 쓰면 인접한 local data, saved frame pointer, return address까지 덮을 수 있다. 공격자는 control flow를 바꾸거나 crash를 일으킬 수 있다.
4.3.2 input sanitization이란? 기존 71문항 학습 번호 68 · 2점 단답형
4.3.2 · 실제 시험 원문
한국어로 요구사항만 풀어 읽기
input sanitization이란?
TERMS FOR 4.3.2
이 소문제의 중요한 용어부터 이해하기
전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.
입력이 기대한 형식·길이·범위인지 검사하고 부적절한 값을 거부하거나 정규화하는 처리입니다.
작은 예: 나이는 숫자이며 0–130 범위인지 검사할 수 있습니다. 이것만으로 SQLi나 XSS 방어가 모두 해결되지는 않습니다.
Browser나 client가 server에 method, path, headers, body를 담아 보내는 message입니다.
Server가 status, headers, body를 담아 client에 돌려주는 message입니다.
문자열을 HTML, JavaScript, SQL, shell 같은 문법으로 해석하는 구성요소입니다.
같은 문자가 어느 문법의 어느 위치에 놓였는지를 뜻하며 올바른 encoding 방법을 결정합니다.
이 소문제만을 위한 0부터 시작하는 미니 강의
아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.
1 · 먼저 알아야 할 개념
외부 입력은 사용자가 입력한 글자뿐 아니라 URL parameter, HTTP header, file, network packet처럼 program 밖에서 들어오는 모든 data를 포함합니다.
Input validation은 값을 parse한 뒤 기대한 type·형식·길이·범위인지 검사하여 입력 전체를 accept 또는 reject합니다. 예를 들어 나이를 strict integer로 parse하고 0..130 밖이면 거부하는 것이 validation입니다.
Normalization(canonicalization)은 같은 의미의 여러 표현을 비교 가능한 한 형태로 바꿉니다. Sanitization은 허용할 content model을 정한 뒤 그 안에서 위험하거나 허용되지 않은 부분을 제거·변환해 사용할 수 있는 결과를 만듭니다. 예를 들어 제한된 rich text에서
<script>를 제거하되 허용된<b>는 보존하는 작업입니다.SQL parameterization, HTML output encoding, shell-free process API는 최종 parser 경계의 sink-specific control입니다. 이것들을 validation·normalization·sanitization과 한 단어로 뭉개면 각 방어가 어디에서 무엇을 보장하는지 놓치게 됩니다. ‘모든 특수문자 삭제’라는 하나의 필터로 모든 injection을 막을 수 없습니다.
2 · 일상 장면으로 먼저 잡기
사진 공모전 접수처를 생각합니다. 파일 형식과 크기가 틀리면 작품 전체를 돌려보내고(validation), 회전 방향 표기를 하나로 맞추며(normalization), 공개 설명문에서 금지된 active content만 제거합니다(sanitization). 전시장에서는 별도의 안전한 액자에 넣습니다(sink control).
비유의 경계 비유와 달리 실제 parser는 중첩 문법·encoding·canonicalization 차이를 가지므로 검증된 sanitizer와 sink별 방어가 필요합니다.
형식·범위가 아직 보장되지 않음
parse·형식·길이·범위 → accept/reject
비교 전 canonical representation
허용 content model에 맞게 제거·변환
SQL parameter·HTML encode·shell-free API
특수문자 일괄 삭제는 우회·기능 손상
네 단계는 관련되지만 동의어가 아닙니다. 특히 sanitization이 최종 parser의 구조적 방어를 자동으로 대신하지 않습니다.
Validation·sanitization·sink control을 분리하기
주어진 것과 목표 나이
17, rich-text 댓글<b>안녕</b><script>alert(1)</script>, 그리고 DB 저장 작업이 있습니다.나이를 strict integer로 parse하고 범위를 검사합니다.
왜? 숫자 필드는 고쳐서 추측하기보다 계약에 맞는지 accept/reject해야 하기 때문입니다.
중간 결과
17은 validation을 통과하고17abc나900은 거부됩니다.댓글의 허용 content model을 정합니다.
왜? Plain text인지 제한된 rich text인지에 따라 보존할 markup이 다르기 때문입니다.
중간 결과 예를 들어
<b>만 허용하고 script·event handler·위험 URL scheme은 금지합니다.검증된 HTML sanitizer로 금지된 node와 attribute를 제거합니다.
왜? 문자 몇 개의 blacklist로는 browser parser의 문법을 안전하게 처리할 수 없기 때문입니다.
중간 결과 허용된
<b>안녕</b>는 남고<script>…</script>는 제거됩니다.DB와 browser 경계에 각각 전용 제어를 적용합니다.
왜? Sanitized content도 다른 parser 문맥에서 자동으로 안전한 것은 아니기 때문입니다.
중간 결과 DB에는 parameter binding을 쓰고, plain-text 출력이라면 HTML encoding을 적용합니다.
예제 결론 Validation은 accept/reject, normalization은 canonical form, sanitization은 허용 content model로의 안전한 변환이며, sink control은 최종 parser에서 구조를 분리합니다.
실제 시험으로 옮기기 정의 답안에는 ‘정해진 허용 모델에 맞도록 위험·불허 content를 제거하거나 변환한다’고 쓰고, validation 및 sink-specific control과 구분합니다.
이번 문제는 이 단계로 풀어야 했습니다
먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.
먼저 문제를 식과 조건으로 정리하기
계산을 시작하기 전에 주어진 것과 구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.
강사가 문제의 요구사항을 쉬운 말로 바꾸면
시험 문장이 요구하는 것: input sanitization이란?
이 문제의 풀이 전략: 이 소문제에서는 입력의 신뢰 상태를 정의한다 → Sanitization의 동작을 정확히 정의한다 → Normalization과도 경계를 긋는다 → 문맥 의존성을 덧붙인다 → 두 문장 시험 답안을 만든다 순서로 진행합니다. 마지막에는 ‘Validation·normalization·검증된 context-aware sanitizer를 구분하고, 최종 sink에 맞는 parameterization/encoding/shell 회피를 적용합니다.’라는 교정 기준으로 답을 다시 확인합니다.
문제에서 주어진 정보
input sanitization이란?
Program 밖에서 온 값은 기대한 형식과 범위를 만족하는지 아직 검증되지 않은 data입니다.
사용자 키보드 입력만으로 범위를 좁히지 않습니다.
최종적으로 구해야 하는 것
첫 문장에 허용 model에 맞춘 제거·변환 정의를 쓰고, 둘째 문장에 validation·normalization 및 sink-specific control과 다르다는 한계를 씁니다.
Input sanitization은 정해진 허용 content model과 사용 문맥에 맞도록 위험하거나 허용되지 않은 입력 부분을 제거 또는 변환하는 과정입니다. 입력 전체를 parse·검사해 accept/reject하는 validation, 표현을 canonical form으로 바꾸는 normalization과는 역할이 다릅니다. 또한 SQL parameterization이나 HTML output encoding 같은 sink-specific control을 대체하는 만능 특수문자 필터가 아닙니다.
사용할 공식·판정 관계
입력의 신뢰 상태를 정의한다 → Sanitization의 동작을 정확히 정의한다 → Normalization과도 경계를 긋는다 → 문맥 의존성을 덧붙인다 → 두 문장 시험 답안을 만든다
네 단계는 관련되지만 동의어가 아닙니다. 특히 sanitization이 최종 parser의 구조적 방어를 자동으로 대신하지 않습니다.
입력의 신뢰 상태를 정의한다
구체적으로 Program 밖에서 온 값은 기대한 형식과 범위를 만족하는지 아직 검증되지 않은 data입니다.
여기서 검산 사용자 키보드 입력만으로 범위를 좁히지 않습니다.
다음 단계로 여기서 확인한 내용을 다음 ‘Sanitization의 동작을 정확히 정의한다’ 단계의 출발점으로 사용합니다.
Sanitization의 동작을 정확히 정의한다
구체적으로 정해진 허용 content model에 맞추기 위해 위험하거나 허용되지 않은 부분을 제거 또는 변환해 사용할 결과를 만듭니다.
여기서 검산 입력 전체를 accept/reject하는 validation과 구분합니다.
다음 단계로 여기서 확인한 내용을 다음 ‘Normalization과도 경계를 긋는다’ 단계의 출발점으로 사용합니다.
Normalization과도 경계를 긋는다
구체적으로 Normalization은 동등 표현을 canonical form으로 바꾸는 것이고, 그것만으로 위험 content가 제거되었다고 볼 수 없습니다.
여기서 검산 canonicalization을 곧 안전화라고 쓰지 않습니다.
다음 단계로 여기서 확인한 내용을 다음 ‘문맥 의존성을 덧붙인다’ 단계의 출발점으로 사용합니다.
문맥 의존성을 덧붙인다
구체적으로 HTML, SQL, shell은 서로 다른 parser이므로 검증된 sanitizer와 parameterization·output encoding·shell-free API 같은 전용 방어가 필요합니다.
여기서 검산 적어도 한 가지 sink-specific control을 듭니다.
다음 단계로 여기서 확인한 내용을 다음 ‘두 문장 시험 답안을 만든다’ 단계의 출발점으로 사용합니다.
두 문장 시험 답안을 만든다
구체적으로 첫 문장에 허용 model에 맞춘 제거·변환 정의를 쓰고, 둘째 문장에 validation·normalization 및 sink-specific control과 다르다는 한계를 씁니다.
여기서 검산 2점에 맞게 짧지만 정확한지 확인합니다.
다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.
정답과 해설
정해진 허용 content model과 사용 문맥에 맞도록 위험하거나 불허된 입력 부분을 제거 또는 변환하는 과정이다. 입력 전체를 accept/reject하는 validation, canonical form으로 바꾸는 normalization, SQL parameterization이나 output encoding 같은 sink-specific control과는 역할이 다르다.
시험 답안 골격
정답이 이렇게 되는 이유
Input sanitization은 정해진 허용 content model과 사용 문맥에 맞도록 위험하거나 허용되지 않은 입력 부분을 제거 또는 변환하는 과정입니다. 입력 전체를 parse·검사해 accept/reject하는 validation, 표현을 canonical form으로 바꾸는 normalization과는 역할이 다릅니다. 또한 SQL parameterization이나 HTML output encoding 같은 sink-specific control을 대체하는 만능 특수문자 필터가 아닙니다.
초보자가 가장 자주 뒤집는 지점
잘못된 생각
<,',;를 전부 삭제하면 모든 injection이 해결된다.왜 틀렸나 정상 data를 손상시키고, encoding·다른 parser·대체 문법으로 우회될 수 있으며, 문맥마다 안전한 표현이 다릅니다.
고쳐 말하면 Validation·normalization·검증된 context-aware sanitizer를 구분하고, 최종 sink에 맞는 parameterization/encoding/shell 회피를 적용합니다.
한 문제만 더: 개념이 정말 연결됐는지 확인
질문 숫자 ID를 strict integer로 parse하고 canonical decimal로 직렬화했다면 그 필드에 SQL 문법을 주입할 수 있습니까? 그래도 parameter binding을 권장하는 이유는 무엇입니까?
정답 그 변환이 정확히 강제되면 해당 숫자 필드에는 quote나 SQL token을 남길 수 없어 주입이 차단될 수 있습니다. 그래도 parameter binding은 query 구조와 data를 API 수준에서 분리해 변환 누락·향후 type 변경·다른 필드의 실수를 줄이므로 구조적으로 더 안전하고 권장됩니다.
이 문제의 오답 함정
이 소문제를 점수로 바꾸는 6개의 작은 훈련
해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.
해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.
막힐 때만 첫 단서 열기
제한된 rich text에서 허용한 굵은 글씨는 남기고 script와 위험 attribute만 제거하는 편집기와 같다.
input sanitization이란?
정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.
작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.
답안 작성 후 채점 기준 열기
답안 슬롯 자가 점검 — 실제로 말하거나 쓴 항목만 체크하세요.
0/3 slots
조건 변형: 원문의 핵심 조건 하나를 반대로 바꾸고, 기존 정답에서 어느 문장과 근거를 수정해야 하는지 두 문장으로 설명하세요.
고칠 답안: 모든 특수문자를 무조건 삭제하는 것으로만 정의하지 않는다.
복구 힌트: 제한된 rich text에서 허용한 굵은 글씨는 남기고 script와 위험 attribute만 제거하는 편집기와 같다.
오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.
채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인
정해진 허용 content model과 사용 문맥에 맞도록 위험하거나 불허된 입력 부분을 제거 또는 변환하는 과정이다. 입력 전체를 accept/reject하는 validation, canonical form으로 바꾸는 normalization, SQL parameterization이나 output encoding 같은 sink-specific control과는 역할이 다르다.
4.3.3 fuzzing이란? 기존 71문항 학습 번호 69 · 2점 단답형
4.3.3 · 실제 시험 원문
한국어로 요구사항만 풀어 읽기
fuzzing이란?
TERMS FOR 4.3.3
이 소문제의 중요한 용어부터 이해하기
전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.
정상·비정상 입력을 대량으로 생성하거나 변형해 프로그램에 넣고 crash나 이상 동작을 찾는 테스트 기법입니다.
작은 예: PNG parser에 길이가 깨진 파일 수천 개를 넣고 sanitizer crash를 수집합니다.
많은 test input을 자동 생성·변형하고 target program에 실행하는 도구입니다.
Fuzzing을 시작할 때 기본 구조를 제공하는 초기 입력 모음입니다.
기존 입력의 byte·길이·구조를 변경해 새 test case를 만드는 과정입니다.
Crash, sanitizer report, output mismatch 등 실패 여부를 판정하는 관찰 기준입니다.
특정 입력이 program code의 어느 부분을 실행했는지 나타내는 정보입니다.
이 소문제만을 위한 0부터 시작하는 미니 강의
아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.
1 · 먼저 알아야 할 개념
Software test는 입력을 주고 program의 실제 결과가 기대와 맞는지 확인하는 과정입니다. 사람이 몇 개 사례만 고르는 대신 computer가 매우 많은 입력을 자동 생성·변형하게 할 수 있습니다.
Fuzzing은 정상 seed input에서 byte를 바꾸거나, grammar에 맞춰 경계·비정상 입력을 만들고, target program을 반복 실행하는 dynamic analysis 기법입니다.
Crash, hang, sanitizer report, assertion failure, output mismatch 같은 oracle로 이상을 찾습니다. Coverage-guided fuzzer는 새로운 code path를 실행한 입력을 보존해 더 깊은 상태를 탐색하지만, 오래 실행해도 bug가 없음을 증명하지는 못합니다.
2 · 일상 장면으로 먼저 잡기
로봇이 문 손잡이를 정상 방향뿐 아니라 반대로, 반쯤, 매우 빠르게, 동시에 밀면서 수천 번 시험하고 파손 센서가 울린 동작을 보존합니다.
비유의 경계 센서가 감지하지 않는 잘못된 결과나 매우 긴 상태 순서가 필요한 bug는 놓칠 수 있습니다.
기본 구조를 통과하는 시작 입력
경계·비정상 입력 생성
실제 program 반복 실행
coverage와 failure oracle
재현 입력 축소 후 regression test
찾지 못함은 bug 없음의 증명이 아님
실행 결과가 다시 다음 입력 선택에 영향을 주는 반복 고리로 읽습니다.
Image parser의 crash 파일 찾기
주어진 것과 목표 정상 PNG 세 개를 seed로 주고 parser를 coverage-guided fuzzing합니다.
정상 seed를 실행합니다.
왜? Parser가 기본 header와 구조를 통과하는 시작점을 얻기 위해서입니다.
중간 결과 기본 coverage와 seed corpus가 생깁니다.
Length field와 byte를 mutate합니다.
왜? 경계 계산과 드문 branch를 시험하기 위해서입니다.
중간 결과 많은 새 image 후보가 만들어집니다.
각 후보로 parser를 실행하고 coverage를 관찰합니다.
왜? 새 code path로 간 입력을 다음 세대에 남기기 위해서입니다.
중간 결과 새 branch 입력이 corpus에 추가됩니다.
Sanitizer crash를 oracle로 판정합니다.
왜? Memory error를 조용한 정상 종료와 구분하기 위해서입니다.
중간 결과 실패 입력과 stack trace가 저장됩니다.
입력을 최소화하고 회귀 시험으로 남깁니다.
왜? 원인을 분석하고 수정 뒤 재발을 막기 위해서입니다.
중간 결과 작은 reproducible testcase가 됩니다.
예제 결론 Fuzzing은 자동 입력 생성, 실제 실행, oracle 관찰의 feedback loop입니다.
실제 시험으로 옮기기 정의 문항에는 자동 생성/변형 입력, running program, 이상 동작 oracle의 세 축을 반드시 씁니다.
이번 문제는 이 단계로 풀어야 했습니다
먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.
먼저 문제를 식과 조건으로 정리하기
계산을 시작하기 전에 주어진 것과 구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.
강사가 문제의 요구사항을 쉬운 말로 바꾸면
시험 문장이 요구하는 것: fuzzing이란?
이 문제의 풀이 전략: 이 소문제에서는 입력 생성의 자동성을 말한다 → 실제 실행을 명시한다 → 관찰 기준을 구체화한다 → Feedback과 후처리를 연결한다 → 한계를 덧붙인다 순서로 진행합니다. 마지막에는 ‘Generate/mutate → run → observe → keep/minimize의 반복 과정으로 정의합니다.’라는 교정 기준으로 답을 다시 확인합니다.
문제에서 주어진 정보
fuzzing이란?
Fuzzer가 많은 정상·비정상·경계 입력을 생성하거나 기존 seed에서 mutate합니다.
완전히 random byte만으로 정의를 좁히지 않습니다.
최종적으로 구해야 하는 것
실행한 입력과 관찰 가능한 oracle에만 근거하므로 bug 부재를 증명하지 못합니다.
Fuzzing은 많은 자동 생성 또는 변형 입력, 특히 경계·비정상 입력을 실제 program에 반복 실행하고 crash나 sanitizer 오류 같은 oracle을 관찰해 bug를 찾는 dynamic testing 기법입니다. Coverage feedback으로 새로운 path를 연 입력을 선호할 수도 있습니다. 다만 탐색하지 못한 상태와 oracle이 보지 못한 오류가 있어 완전성 증명은 아닙니다.
사용할 공식·판정 관계
입력 생성의 자동성을 말한다 → 실제 실행을 명시한다 → 관찰 기준을 구체화한다 → Feedback과 후처리를 연결한다 → 한계를 덧붙인다
실행 결과가 다시 다음 입력 선택에 영향을 주는 반복 고리로 읽습니다.
입력 생성의 자동성을 말한다
구체적으로 Fuzzer가 많은 정상·비정상·경계 입력을 생성하거나 기존 seed에서 mutate합니다.
여기서 검산 완전히 random byte만으로 정의를 좁히지 않습니다.
다음 단계로 여기서 확인한 내용을 다음 ‘실제 실행을 명시한다’ 단계의 출발점으로 사용합니다.
실제 실행을 명시한다
구체적으로 만든 입력을 running target program에 반복해서 넣으므로 dynamic analysis입니다.
여기서 검산 Source만 읽는 static analysis와 구분합니다.
다음 단계로 여기서 확인한 내용을 다음 ‘관찰 기준을 구체화한다’ 단계의 출발점으로 사용합니다.
관찰 기준을 구체화한다
구체적으로 Crash, timeout, sanitizer report, assertion, output mismatch 같은 oracle로 실패를 찾습니다.
여기서 검산 적어도 두 가지 oracle 예를 듭니다.
다음 단계로 여기서 확인한 내용을 다음 ‘Feedback과 후처리를 연결한다’ 단계의 출발점으로 사용합니다.
Feedback과 후처리를 연결한다
구체적으로 새 coverage 입력은 보존하고 실패 입력은 재현·최소화하여 원인을 수정하고 regression test로 남깁니다.
여기서 검산 입력 발견 뒤 과정도 설명할 수 있는지 봅니다.
다음 단계로 여기서 확인한 내용을 다음 ‘한계를 덧붙인다’ 단계의 출발점으로 사용합니다.
한계를 덧붙인다
구체적으로 실행한 입력과 관찰 가능한 oracle에만 근거하므로 bug 부재를 증명하지 못합니다.
여기서 검산 ‘모든 취약점을 찾는다’고 과장하지 않습니다.
다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.
정답과 해설
많은 비정상·경계·변형 입력을 자동 생성해 프로그램에 넣고 crash, hang, sanitizer 오류, 잘못된 결과를 oracle로 관찰해 bug를 찾는 동적 testing 기법이다.
시험 답안 골격
정답이 이렇게 되는 이유
Fuzzing은 많은 자동 생성 또는 변형 입력, 특히 경계·비정상 입력을 실제 program에 반복 실행하고 crash나 sanitizer 오류 같은 oracle을 관찰해 bug를 찾는 dynamic testing 기법입니다. Coverage feedback으로 새로운 path를 연 입력을 선호할 수도 있습니다. 다만 탐색하지 못한 상태와 oracle이 보지 못한 오류가 있어 완전성 증명은 아닙니다.
초보자가 가장 자주 뒤집는 지점
잘못된 생각 Fuzzing은 무작위 문자열을 한 번 넣어 보는 테스트다.
왜 틀렸나 실제 fuzzer는 seed, mutation, grammar, coverage feedback, 반복 실행, oracle, minimization을 포함할 수 있습니다.
고쳐 말하면 Generate/mutate → run → observe → keep/minimize의 반복 과정으로 정의합니다.
한 문제만 더: 개념이 정말 연결됐는지 확인
질문 Coverage-guided fuzzer가 새 branch를 실행한 입력을 보존하는 이유는?
정답 그 입력이 이전에는 닿지 못한 program state의 출발점이 되어 추가 mutation으로 더 깊은 path를 탐색할 가능성이 높기 때문입니다.
이 문제의 오답 함정
이 소문제를 점수로 바꾸는 6개의 작은 훈련
해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.
해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.
막힐 때만 첫 단서 열기
수천 종류의 이상한 열쇠를 자동으로 자물쇠에 넣어 어디서 깨지거나 멈추는지 관찰하는 시험이다.
fuzzing이란?
정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.
작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.
답안 작성 후 채점 기준 열기
답안 슬롯 자가 점검 — 실제로 말하거나 쓴 항목만 체크하세요.
0/3 slots
조건 변형: 원문의 핵심 조건 하나를 반대로 바꾸고, 기존 정답에서 어느 문장과 근거를 수정해야 하는지 두 문장으로 설명하세요.
고칠 답안: random input만 뜻한다고 좁히지 않는다. mutation·coverage-guided도 있다.
복구 힌트: 수천 종류의 이상한 열쇠를 자동으로 자물쇠에 넣어 어디서 깨지거나 멈추는지 관찰하는 시험이다.
오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.
채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인
많은 비정상·경계·변형 입력을 자동 생성해 프로그램에 넣고 crash, hang, sanitizer 오류, 잘못된 결과를 oracle로 관찰해 bug를 찾는 동적 testing 기법이다.
4.3.4 static analysis와 dynamic analysis의 차이는? 기존 71문항 학습 번호 70 · 2점 정의 비교
4.3.4 · 실제 시험 원문
한국어로 요구사항만 풀어 읽기
static analysis와 dynamic analysis의 차이는?
TERMS FOR 4.3.4
이 소문제의 중요한 용어부터 이해하기
전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.
프로그램을 실제로 실행하면서 입력에 따른 memory, system call, crash 등의 동작을 관찰하는 분석입니다.
작은 예: Debugger나 AddressSanitizer로 특정 입력에서 생기는 overflow를 관찰합니다.
공격자로부터 지키려는 대상입니다. 파일, 비밀번호, 서비스 가용성, 사람의 개인정보가 모두 asset이 될 수 있습니다.
허가받지 않은 사람이 내용을 읽지 못하게 하는 기밀성입니다.
데이터나 시스템이 허가 없이 바뀌지 않았음을 보장하려는 무결성입니다.
정당한 사용자가 필요할 때 서비스와 데이터에 접근할 수 있는 가용성입니다.
이 소문제만을 위한 0부터 시작하는 미니 강의
아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.
1 · 먼저 알아야 할 개념
Program analysis는 코드가 어떤 행동을 할 수 있는지 조사하는 작업입니다. 핵심 비교축은 분석 중 program을 실제로 실행하는지 여부입니다.
Static analysis는 실행하지 않고 source code나 binary의 syntax, type, control flow, data flow를 검사합니다. 실행 가능한 여러 경로를 넓게 추정할 수 있지만 실제로 불가능한 경로까지 경고하는 false positive가 생길 수 있습니다.
Dynamic analysis는 특정 입력으로 실제 program을 실행하면서 memory access, system call, trace, crash를 관찰합니다. 실제 행동을 정밀하게 볼 수 있지만 실행하지 않은 path는 알 수 없다는 coverage 한계가 있습니다.
2 · 일상 장면으로 먼저 잡기
자동차 설계도와 배선도를 책상에서 검사하는 일과, 실제 자동차를 시험 주행하며 센서와 소리를 측정하는 일을 비교합니다.
비유의 경계 Static이 반드시 사람이 하고 dynamic이 반드시 자동이라는 뜻은 아닙니다. 두 분석 모두 자동 도구와 수동 해석을 사용할 수 있습니다.
실행 없이 source/binary 구조와 가능한 flow 분석
여러 가능한 path를 넓게 검사
불가능한 경로 경고·false positive
특정 입력으로 실제 실행과 trace 관찰
실행하지 않은 path는 보지 못함
넓은 가능성 추론과 구체적 실행 관찰은 서로 대체 관계가 아니라 보완 관계입니다.
0으로 나누는 분기 분석
주어진 것과 목표
if (admin) y = 10 / x;라는 코드에서 x=0 가능성을 조사합니다.Static analyzer가 변수 흐름을 추적합니다.
왜? 실행 없이 가능한 위험 경로를 찾기 위해서입니다.
중간 결과 admin=true이고 x=0일 수 있는 경로를 경고할 수 있습니다.
실제 입력 admin=false, x=0으로 실행합니다.
왜? Dynamic 분석이 구체 입력의 행동만 본다는 것을 확인하기 위해서입니다.
중간 결과 분기 안에 들어가지 않아 오류가 관찰되지 않습니다.
admin=true, x=0으로 다시 실행합니다.
왜? 위험 path를 coverage하기 위해서입니다.
중간 결과 divide-by-zero failure를 실제 trace로 관찰합니다.
결과를 결합합니다.
왜? 두 방식의 장점을 활용하기 위해서입니다.
중간 결과 Static 경고로 testcase를 만들고 dynamic run으로 재현합니다.
예제 결론 Static은 가능한 경로를 넓게 보고 dynamic은 실행한 경로를 깊게 봅니다.
실제 시험으로 옮기기 답안은 실행 여부를 먼저 비교하고 false positive와 coverage 한계를 한 줄씩 덧붙이면 완전합니다.
이번 문제는 이 단계로 풀어야 했습니다
먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.
먼저 문제를 식과 조건으로 정리하기
계산을 시작하기 전에 주어진 것과 구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.
강사가 문제의 요구사항을 쉬운 말로 바꾸면
시험 문장이 요구하는 것: static analysis와 dynamic analysis의 차이는?
이 문제의 풀이 전략: 이 소문제에서는 첫 비교축을 실행 여부로 고정한다 → Static이 보는 것을 설명한다 → Dynamic이 보는 것을 설명한다 → 각 한계를 대칭적으로 쓴다 → 두 문장 비교 답안을 만든다 순서로 진행합니다. 마지막에는 ‘Program 실행 여부와 관찰 범위를 기준으로 비교합니다.’라는 교정 기준으로 답을 다시 확인합니다.
문제에서 주어진 정보
static analysis와 dynamic analysis의 차이는?
Static은 program을 실행하지 않고, dynamic은 실제로 실행하면서 분석합니다.
수동/자동이라는 잘못된 축을 쓰지 않습니다.
최종적으로 구해야 하는 것
첫 문장에 정의 차이, 둘째 문장에 넓은 추론 대 실제 관찰 및 한계를 씁니다.
Static analysis는 program을 실행하지 않고 source 또는 binary의 구조와 가능한 control/data flow를 분석합니다. Dynamic analysis는 특정 입력으로 program을 실제 실행하며 나타난 memory·trace·behavior를 관찰합니다. Static은 넓은 경로를 볼 수 있지만 false positive가 있을 수 있고, dynamic은 실제 증거가 강하지만 실행하지 않은 path를 놓칩니다.
사용할 공식·판정 관계
첫 비교축을 실행 여부로 고정한다 → Static이 보는 것을 설명한다 → Dynamic이 보는 것을 설명한다 → 각 한계를 대칭적으로 쓴다 → 두 문장 비교 답안을 만든다
넓은 가능성 추론과 구체적 실행 관찰은 서로 대체 관계가 아니라 보완 관계입니다.
첫 비교축을 실행 여부로 고정한다
구체적으로 Static은 program을 실행하지 않고, dynamic은 실제로 실행하면서 분석합니다.
여기서 검산 수동/자동이라는 잘못된 축을 쓰지 않습니다.
다음 단계로 여기서 확인한 내용을 다음 ‘Static이 보는 것을 설명한다’ 단계의 출발점으로 사용합니다.
Static이 보는 것을 설명한다
구체적으로 Source/binary의 syntax, type, control flow, data flow와 가능한 경로를 추론합니다.
여기서 검산 실행 결과를 직접 관찰한다고 쓰지 않습니다.
다음 단계로 여기서 확인한 내용을 다음 ‘Dynamic이 보는 것을 설명한다’ 단계의 출발점으로 사용합니다.
Dynamic이 보는 것을 설명한다
구체적으로 특정 testcase 실행 중 memory, trace, system call, crash 같은 구체적 behavior를 관찰합니다.
여기서 검산 모든 possible path를 자동으로 본다고 하지 않습니다.
다음 단계로 여기서 확인한 내용을 다음 ‘각 한계를 대칭적으로 쓴다’ 단계의 출발점으로 사용합니다.
각 한계를 대칭적으로 쓴다
구체적으로 Static은 false positive 가능성이 있고 dynamic은 실행 coverage 밖의 bug를 놓칠 수 있습니다.
여기서 검산 둘 중 하나만 무조건 우수하다고 결론 내리지 않습니다.
다음 단계로 여기서 확인한 내용을 다음 ‘두 문장 비교 답안을 만든다’ 단계의 출발점으로 사용합니다.
두 문장 비교 답안을 만든다
구체적으로 첫 문장에 정의 차이, 둘째 문장에 넓은 추론 대 실제 관찰 및 한계를 씁니다.
여기서 검산 두 개념을 같은 기준 순서로 비교했는지 확인합니다.
다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.
정답과 해설
static analysis는 프로그램을 실행하지 않고 source/binary 구조와 가능한 data/control flow를 분석한다. dynamic analysis는 실제 실행 중 특정 입력에서 나타나는 behavior, memory, trace를 관찰한다.
시험 답안 골격
정답이 이렇게 되는 이유
Static analysis는 program을 실행하지 않고 source 또는 binary의 구조와 가능한 control/data flow를 분석합니다. Dynamic analysis는 특정 입력으로 program을 실제 실행하며 나타난 memory·trace·behavior를 관찰합니다. Static은 넓은 경로를 볼 수 있지만 false positive가 있을 수 있고, dynamic은 실제 증거가 강하지만 실행하지 않은 path를 놓칩니다.
초보자가 가장 자주 뒤집는 지점
잘못된 생각 Static은 사람이 코드를 읽는 것이고 dynamic은 자동 도구를 쓰는 것이다.
왜 틀렸나 자동화 여부는 정의의 축이 아닙니다. Static analyzer도 자동이고 dynamic debugging은 수동일 수 있습니다.
고쳐 말하면 Program 실행 여부와 관찰 범위를 기준으로 비교합니다.
한 문제만 더: 개념이 정말 연결됐는지 확인
질문 Sanitizer를 켜고 testcase를 실행하는 것은 static입니까 dynamic입니까?
정답 실행 중 memory behavior를 계측·관찰하므로 dynamic analysis입니다.
이 문제의 오답 함정
이 소문제를 점수로 바꾸는 6개의 작은 훈련
해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.
해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.
막힐 때만 첫 단서 열기
static은 자동차 설계도를 검사하고, dynamic은 실제로 주행시키며 센서 값을 보는 것이다.
static analysis와 dynamic analysis의 차이는?
정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.
작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.
답안 작성 후 채점 기준 열기
답안 슬롯 자가 점검 — 실제로 말하거나 쓴 항목만 체크하세요.
0/3 slots
조건 변형: 두 개념을 권한, oracle/관찰 정보, 금지 조건, 성공 조건의 네 행으로 다시 비교하세요. 이름을 가려도 어느 쪽이 더 강한 모델인지 판별할 수 있어야 합니다.
고칠 답안: static=수동, dynamic=자동으로 정의하지 않는다.
복구 힌트: static은 자동차 설계도를 검사하고, dynamic은 실제로 주행시키며 센서 값을 보는 것이다.
오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.
채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인
static analysis는 프로그램을 실행하지 않고 source/binary 구조와 가능한 data/control flow를 분석한다. dynamic analysis는 실제 실행 중 특정 입력에서 나타나는 behavior, memory, trace를 관찰한다.
4.3.5 forensic data collection에서 증거 연쇄의 무결성을 지키는 조치 두 가지를 쓰시오. 기존 71문항 학습 번호 71 · 4점 Forensics 절차
4.3.5 · 실제 시험 원문
한국어로 요구사항만 풀어 읽기
forensic data collection에서 증거 연쇄의 무결성을 지키는 조치 두 가지를 쓰시오.
TERMS FOR 4.3.5
이 소문제의 중요한 용어부터 이해하기
전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.
사건을 설명하거나 입증하는 데 사용할 수 있는 file, disk, log, memory 같은 디지털 자료입니다.
작은 예: 분석 편의를 위해 원본을 직접 수정하면 증거 신뢰성이 떨어질 수 있습니다.
저장장치의 할당·미할당 영역까지 bit 단위로 복제한 분석용 사본입니다.
작은 예: 원본 SSD는 봉인하고 image 사본에서 file recovery를 수행합니다.
증거 저장장치에 쓰기 명령이 전달되지 않게 막는 장치나 방식입니다.
작은 예: 수집 computer가 자동으로 metadata를 쓰는 일을 방지합니다.
입력 데이터에서 고정 길이 digest를 계산하는 함수입니다. 수집 전후 hash가 같으면 그 사이 byte가 바뀌지 않았다는 강한 근거가 됩니다.
작은 예: 원본과 forensic image의 SHA-256을 기록하고 비교합니다.
증거를 누가 언제 수집·이동·보관·분석했는지 이어서 기록하는 인계 이력입니다.
작은 예: 봉인 번호, 시간, 담당자, 전달받은 사람을 매 이동마다 기록합니다.
이 소문제만을 위한 0부터 시작하는 미니 강의
아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.
1 · 먼저 알아야 할 개념
Digital evidence는 조사 행위만으로 access time이나 metadata가 바뀔 수 있습니다. 따라서 원본을 그대로 보존하면서 분석 가능한 복제본을 만들고, 이후에도 같은 data인지 검증해야 합니다.
Write blocker는 원본 저장매체로 쓰기 명령이 전달되는 것을 막습니다. Forensic image는 보이는 파일만 복사하는 것이 아니라 가능하면 sector를 bit 단위로 획득해 삭제 영역과 filesystem metadata도 포함합니다.
Cryptographic hash는 원본과 image의 bit열이 같은지 비교하는 지문 역할을 합니다. Chain of custody는 evidence ID, handler, timestamp, action, location, seal state를 인계 때마다 기록하여 누가 언제 무엇을 했는지 이어 줍니다. Hash는 변경 탐지 근거이지 담당자와 절차의 적법성을 혼자 증명하지 않습니다.
SSD에는 중요한 한계가 있습니다. Host write blocker는 운영체제·분석 도구가 보내는 write command는 막지만, 전원이 켜진 SSD controller 내부의 garbage collection, TRIM 후 정리, wear leveling 같은 상태 변화까지 막지는 못합니다. 따라서 장치 종류를 기록하고 전원 상태·획득 순서·도구·한계를 문서화하며 가능한 한 신속히 적절한 절차로 획득해야 합니다.
2 · 일상 장면으로 먼저 잡기
범죄 현장의 유리 조각을 맨손으로 만지지 않고 봉인해 번호를 붙이며, 정밀 복제품을 만들어 검사하고, 담당자가 바뀔 때마다 시간·서명·봉인 상태를 기록합니다.
비유의 경계 Digital hash가 일치해도 수집 전 변조·보관 이력·법적 절차는 별도 기록이 필요합니다. 특히 SSD의 controller 내부 동작은 host write blocker의 통제 밖일 수 있습니다.
Evidence ID·장소·수집자·초기 상태
Write blocker로 원본 write 방지
Bitwise acquisition·tool/version 기록
Original/image/working copy hash 비교
모든 인계의 담당자·시각·봉인 상태
Controller 내부 GC·wear leveling은 별도 한계
Hash만 있어도 절차 신뢰가 약해짐
막기 → 복제 → 비교 → 추적의 어느 연결도 다른 연결을 완전히 대신하지 못합니다.
SSD E-017의 현장 수집부터 분석까지
주어진 것과 목표 수사관 Mina가 사건 PC의 SSD를 수집해 분석가 Leon에게 넘깁니다.
SSD에 evidence ID E-017을 붙이고 장소·시각·초기 상태를 기록합니다.
왜? 이후 모든 기록이 같은 물건을 가리키게 하기 위해서입니다.
중간 결과 증거의 식별과 시작 상태가 고정됩니다.
장치 종류와 전원 상태를 기록하고 write blocker를 통해 SSD를 연결합니다.
왜? 분석 도구의 host write를 막되 SSD controller 내부 변화 가능성도 숨기지 않기 위해서입니다.
중간 결과 Host write 위험은 줄고, garbage collection·wear leveling 한계는 acquisition 기록에 남습니다.
Bitwise forensic image를 만들고 tool/version/time을 기록합니다.
왜? 원본 대신 재현 가능한 복제본에서 분석하기 위해서입니다.
중간 결과 삭제·미할당 영역을 포함한 image가 생성됩니다.
원본과 image의 hash를 계산·비교합니다.
왜? 획득 결과가 원본 bit열과 같은지 탐지하기 위해서입니다.
중간 결과
H(original)=H(image)와 실제 값을 기록합니다.원본을 봉인하고 working copy에서 분석합니다.
왜? 원본을 반복 접근하지 않고 분석 중 변경을 격리하기 위해서입니다.
중간 결과 원본 보존과 분석 가능성을 동시에 얻습니다.
Mina에서 Leon으로 인계 기록을 추가합니다.
왜? 보관의 빈 시간을 없애기 위해서입니다.
중간 결과 handler, timestamp, purpose, location, seal state가 custody log에 남습니다.
예제 결론 변경 방지, 동일성 검증, 인계 추적은 서로 다른 역할이며 함께 있어야 강한 증거 연쇄가 됩니다.
실제 시험으로 옮기기 문제는 두 조치를 요구하므로 ‘write blocker로 원본 보호’와 ‘image 후 hash 비교 및 custody 기록’처럼 조치와 목적을 짝지어 두 개를 명확히 씁니다.
이번 문제는 이 단계로 풀어야 했습니다
먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.
먼저 문제를 식과 조건으로 정리하기
계산을 시작하기 전에 주어진 것과 구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.
강사가 문제의 요구사항을 쉬운 말로 바꾸면
시험 문장이 요구하는 것: forensic data collection에서 증거 연쇄의 무결성을 지키는 조치 두 가지를 쓰시오.
이 문제의 풀이 전략: 이 소문제에서는 문제의 수량과 목표를 표시한다 → 첫 조치로 원본 변경을 방지한다 → 둘째 조치로 획득 동일성을 검증한다 → 증거 연쇄 기록을 완성한다 → 두 채점 문장으로 압축한다 → Hash의 한계를 검산한다 순서로 진행합니다. 마지막에는 ‘Hash는 technical integrity, custody log는 procedural traceability를 뒷받침한다고 역할을 나눕니다.’라는 교정 기준으로 답을 다시 확인합니다.
문제에서 주어진 정보
forensic data collection에서 증거 연쇄의 무결성을 지키는 조치 두 가지를 쓰시오.
두 가지 Maßnahmen를 요구하며 목표는 파일 내용뿐 아니라 Beweiskette의 Integrität를 지키는 것입니다.
서로 같은 역할의 표현 두 개를 중복 답하지 않습니다.
최종적으로 구해야 하는 것
Hash 일치는 bit열 동일성 근거이지만 누가 언제 다뤘는지나 절차의 적법성을 단독으로 증명하지 않습니다.
첫째, 원본 매체를 write blocker로 보호하고 bitwise forensic image를 만들어 원본을 직접 분석하지 않습니다. 둘째, 원본과 image의 cryptographic hash를 계산·비교·기록하고, evidence ID·handler·timestamp·seal state를 모든 인계마다 chain of custody에 남깁니다. 이 조치들은 각각 host write 방지, 동일성 검증, 보관 과정 추적을 담당합니다. SSD에서는 controller 내부 garbage collection·wear leveling을 host write blocker가 막지 못할 수 있으므로 장치·전원 상태·획득 시각·절차와 이 한계도 문서화해야 합니다.
사용할 공식·판정 관계
문제의 수량과 목표를 표시한다 → 첫 조치로 원본 변경을 방지한다 → 둘째 조치로 획득 동일성을 검증한다 → 증거 연쇄 기록을 완성한다 → 두 채점 문장으로 압축한다 → Hash의 한계를 검산한다
막기 → 복제 → 비교 → 추적의 어느 연결도 다른 연결을 완전히 대신하지 못합니다.
문제의 수량과 목표를 표시한다
구체적으로 두 가지 Maßnahmen를 요구하며 목표는 파일 내용뿐 아니라 Beweiskette의 Integrität를 지키는 것입니다.
여기서 검산 서로 같은 역할의 표현 두 개를 중복 답하지 않습니다.
다음 단계로 여기서 확인한 내용을 다음 ‘첫 조치로 원본 변경을 방지한다’ 단계의 출발점으로 사용합니다.
첫 조치로 원본 변경을 방지한다
구체적으로 원본 매체를 write blocker 또는 동등한 read-only 절차로 보호하고 직접 분석하지 않는다고 씁니다.
여기서 검산 Write blocker가 host write를 막지만 SSD controller 내부 GC·wear leveling까지 정지시키지는 못한다는 한계를 구분합니다.
다음 단계로 여기서 확인한 내용을 다음 ‘둘째 조치로 획득 동일성을 검증한다’ 단계의 출발점으로 사용합니다.
둘째 조치로 획득 동일성을 검증한다
구체적으로 Bitwise forensic image를 만들고 원본과 image의 cryptographic hash를 계산·비교·기록합니다.
여기서 검산 Hash 대상과 비교 관계
H(original)=H(image)가 분명한지 봅니다.다음 단계로 여기서 확인한 내용을 다음 ‘증거 연쇄 기록을 완성한다’ 단계의 출발점으로 사용합니다.
증거 연쇄 기록을 완성한다
구체적으로 Evidence ID와 함께 모든 handler, timestamp, action, purpose, location, seal state를 chain of custody에 남깁니다.
여기서 검산 ‘잘 기록한다’는 추상어 대신 실제 필드를 적습니다.
다음 단계로 여기서 확인한 내용을 다음 ‘두 채점 문장으로 압축한다’ 단계의 출발점으로 사용합니다.
두 채점 문장으로 압축한다
구체적으로 1) Write blocker로 원본을 보호하고 bitwise image를 만든다. 2) 원본/image hash를 비교하고 모든 인계를 custody log에 기록한다.
여기서 검산 요구한 두 조치와 각각의 목적이 한눈에 보이는지 확인합니다.
다음 단계로 여기서 확인한 내용을 다음 ‘Hash의 한계를 검산한다’ 단계의 출발점으로 사용합니다.
Hash의 한계를 검산한다
구체적으로 Hash 일치는 bit열 동일성 근거이지만 누가 언제 다뤘는지나 절차의 적법성을 단독으로 증명하지 않습니다.
여기서 검산 Hash 하나로 법적 무결성이 완성된다고 과장하지 않습니다.
다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.
정답과 해설
write blocker로 원본 변경을 막고, forensic image를 만든 뒤 cryptographic hash로 동일성을 확인하며, evidence id, handler, timestamp, seal state를 포함한 chain of custody와 보고서에 전 과정을 문서화한다.
시험 답안 골격
정답이 이렇게 되는 이유
첫째, 원본 매체를 write blocker로 보호하고 bitwise forensic image를 만들어 원본을 직접 분석하지 않습니다. 둘째, 원본과 image의 cryptographic hash를 계산·비교·기록하고, evidence ID·handler·timestamp·seal state를 모든 인계마다 chain of custody에 남깁니다. 이 조치들은 각각 host write 방지, 동일성 검증, 보관 과정 추적을 담당합니다. SSD에서는 controller 내부 garbage collection·wear leveling을 host write blocker가 막지 못할 수 있으므로 장치·전원 상태·획득 시각·절차와 이 한계도 문서화해야 합니다.
초보자가 가장 자주 뒤집는 지점
잘못된 생각 Hash를 한 번 계산했으므로 chain of custody는 필요 없다.
왜 틀렸나 Hash는 두 bit열의 동일성만 보여 주며 누가 어떤 매체를 언제 인수·접근했는지 설명하지 못합니다.
고쳐 말하면 Hash는 technical integrity, custody log는 procedural traceability를 뒷받침한다고 역할을 나눕니다.
한 문제만 더: 개념이 정말 연결됐는지 확인
질문 일반 파일 복사가 forensic image보다 부족한 이유 두 가지와, SSD에서 write blocker가 보장하지 못하는 한 가지는?
정답 파일 복사는 삭제·미할당 영역과 일부 filesystem metadata를 놓칠 수 있고 원본의 bitwise 상태를 재현·검증하기 어렵습니다. SSD에서는 write blocker가 host command는 막아도 controller 내부 garbage collection·wear leveling까지 막는다고 보장할 수 없습니다.
이 문제의 오답 함정
이 소문제를 점수로 바꾸는 6개의 작은 훈련
해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.
해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.
막힐 때만 첫 단서 열기
hash 값을 계산했다고 끝이 아니다. 원본을 어떻게 보호했고, 누가 언제 다뤘는지까지 답안에 붙여야 한다.
forensic data collection에서 증거 연쇄의 무결성을 지키는 조치 두 가지를 쓰시오.
정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.
작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.
답안 작성 후 채점 기준 열기
답안 슬롯 자가 점검 — 실제로 말하거나 쓴 항목만 체크하세요.
0/6 slots
조건 변형: 원본과 image의 hash가 다르거나 custody 기록 한 줄이 비었다고 가정하세요. 무엇을 즉시 중단·기록·재검증해야 하는지 절차 순서로 답하세요.
고칠 답안: hash만 쓰고 forensic image, write blocker, chain of custody를 빼먹기
복구 힌트: hash 값을 계산했다고 끝이 아니다. 원본을 어떻게 보호했고, 누가 언제 다뤘는지까지 답안에 붙여야 한다.
오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.
채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인
write blocker로 원본 변경을 막고, forensic image를 만든 뒤 cryptographic hash로 동일성을 확인하며, evidence id, handler, timestamp, seal state를 포함한 chain of custody와 보고서에 전 과정을 문서화한다.