1. SRE Attack Mitigation
- 악의적인 목적으로 수행되는 SRE Attack으로부터 SW를 보호해야함
- 말그대로 본질적으로 SRE Attack을 '막는 것'이 아닌 '완화'
① Anti-disassembly tech (정적method) : code를 지저분하게 (쓸데없는 부분이라던가)
② Anti-debugging tech (동적method) : debugger 실행 시 혼란을 주도록
③ Tamper-resistance : 변경 여부 확인하도록
④ code obfuscation : garbage code를 통해 복잡하도록
1) Anti-disassembly
: "정적인 분해"를 최대한 헷갈리게
- object code를 암호화
- self-modifying code
e.g. junk code를 통해 복잡하게 (disassemble은 junk여부 알 수 없으므로 모든 disassemble code를 분석하여야함)
2) Anti-debugger
- "동적이 분해"를 최대한 헷갈리게
e.g. 디버그는 pre-fetch를 지원x// cpu는 원래 pre-fetching을 수행하지만
=> 디버깅으로 무언가 찾아내는 것을 감지할 수 있음
"1 overwrites 4"
- 위와 같을 때 inst1이 inst2,inst3,inst4를 pre-fetch한다고 가정, debugger를 실행하면 pre-fetch하지 않게됨.
- 이러한 상태에서 inst1이 inst4의 메모리 영역을 overwrite하게되면
=> program(디버거를 사용하지 않음,cpu)은 pre-fetch하였으므로 정상 작동
<=> debugger를 사용한 경우 inst4에 overwrite된 "junk"가 존재하여 공격자로 하여금 읽고 분석하는 것을 헷갈리게 함.
3) Tamper-resistance
: patching을 힘들게
해시를 통해 변경 발생을 확인 => 패치 여부 확인
4) Code Obfuscation (코드 난독화)
: <=> Good source in s/w engineering for intentional purpose
코드 분석에 많은 시간을 소요하게함
e.g. Authentication SW의 경우 인증 여부(1bit)가 공격의 핵심
=> bit를 1(true)참으로 하는 것이 공격의 핵심
=> 보안을하려면 이 1 bit를 최대한 잘 숨겨야함
다른 1)~3)과 같이 사용됨
2. Software Cloning
: 배포할 때, 동일한 복사본으로 해야함
이러한 Software Cloning의 과정에서도 보안상 취약점이 존재
그렇다면 한 곳에서 뚫리면 다른 곳에서도 모두 뚫림 (BOBE) = WORST CASE !!
- How to prevent?
1) 변형(변경) S/W
- malware 콘셉과 유사하게
"모든 instance가 기능적으로 동일/내부적으로 상이"
=> 1개 뚫린다고 나머지가 뚫리는 것은 아니다.
=> N번을 뚫어야할 수도 = BEST CASE for us
