teppi 님의 블로그

후킹으로 잡는 하드코딩 키

teppi — Wed, 14 Oct 2026 17:21:02 +0900

후킹으로 잡는 하드코딩 키

앱이 데이터를 암호화하는 그 순간, 키와 IV는 반드시 메모리를 통과한다. Android의 Cipher.init과 iOS의 CCCrypt 한 지점만 잡으면 된다.

Platform Android / iOS · Tool Frida · jadx · Target AES/CBC

모바일 앱 진단을 하다 보면 "이 앱은 통신 데이터를 암호화해서 보낸다"는 벽을 자주 만난다.

패킷을 떠봐야 전부 암호문이니 그다음이 막힌다. 그런데 암호화에는 반드시 키가 필요하고, 그 키는 어디선가 암호화 함수로 전달된다. 바로 그 전달 지점을 후킹하면, 앱이 아무리 암호문을 잘 숨겨도 키 자체를 손에 넣을 수 있다.

이 글은 어느 금융 앱을 진단하면서 Android와 iOS 양쪽에서 하드코딩된 AES 키와 고정 IV를 찾아낸 과정을 정리한 것이다.

핵심은 한 문장으로 요약된다.

암호화 함수에 키가 들어가는 순간을 가로챈다.

01 · 원리 — 왜 Cipher를 후킹하는가

Android에서 대칭·비대칭 암복호화는 거의 전부 javax.crypto.Cipher를 거친다.

AES든 RSA든, 어떤 라이브러리를 쓰든 최종적으로 이 클래스로 모인다. 그래서 여기 한 곳만 잡으면 앱이 무엇을 어떻게 암호화하는지 한눈에 관찰할 수 있다.

특히 주목할 메서드는 세 개다.

getInstance(transformation) — 어떤 알고리즘·모드·패딩을 쓰는지 알려준다. AES/ECB나 약한 패딩 같은 설계 취약점이 여기서 바로 드러난다.
init(opmode, key, ...) — 키와 IV가 들어오는 핵심 지점. 이 글의 주인공이다.
doFinal(input) — 입력 평문과 출력 암호문. 키 추출이 막혀도 평문/암호문은 여기서 관찰된다.

진단에서 노리는 건 init이다.

암호화 객체는 쓰기 직전 반드시 init으로 키를 주입받는다. 그 순간 전달된 Key 객체에서 getEncoded()로 raw 바이트를, 파라미터 스펙에서 IV를 꺼내면 된다.

02 · Android — Cipher.init 후킹

Frida로 Cipher.init의 모든 오버로드를 감싸고, 인자로 들어온 Key와 IV 스펙을 hex로 출력하도록 짰다.

init은 오버로드가 여러 개라 전부 걸어야 누락이 없다.

Java.perform(function () {
    var Cipher  = Java.use('javax.crypto.Cipher');
    var GCMSpec = Java.use('javax.crypto.spec.GCMParameterSpec');
    var IvSpec  = Java.use('javax.crypto.spec.IvParameterSpec');

    // Key 객체 → raw 바이트를 hex로
    function hex(bytes) {
        if (bytes === null) return '(null)';
        var s = '';
        for (var i = 0; i < bytes.length; i++)
            s += ('0' + (bytes[i] & 0xff).toString(16)).slice(-2);
        return s;
    }

    // 모든 init 오버로드를 감싼다
    Cipher.init.overloads.forEach(function (ov) {
        ov.implementation = function () {
            console.log('\n[Cipher.init] transform=' + this.getAlgorithm());
            for (var i = 1; i < arguments.length; i++) {
                var arg = arguments[i];
                if (arg === null) continue;

                // 1) Key
                try {
                    if (arg.getEncoded && arg.getAlgorithm) {
                        console.log('  key(hex)=' + hex(arg.getEncoded()));
                        continue;
                    }
                } catch (e) {}

                // 2) IV (CBC 등)
                try {
                    if (IvSpec.class.isInstance(arg))
                        console.log('  IV (hex)=' + hex(Java.cast(arg, IvSpec).getIV()));
                } catch (e) {}
            }
            var ret = ov.apply(this, arguments);

            // 스펙 없이 Cipher가 내부 생성한 IV까지 회수
            try {
                var auto = this.getIV();
                if (auto !== null) console.log('  IV(cipher.getIV())=' + hex(auto));
            } catch (e) {}
            return ret;
        };
    });
    console.log('[*] Cipher.init hook 설치 완료');
});

스크립트를 로드한 상태에서 앱의 인증번호 입력 기능을 수행했다.

입력 전에는 로그가 조용하다가, 입력하는 순간 후킹이 트리거되며 값이 쏟아졌다. 이 선후관계 자체가 "이 암호화가 인증 처리에 쓰인다"는 증거가 된다.

[Cipher.init] transform=AES/CBC/PKCS5Padding
  key(hex)=4558414d504c454b4559313233343536
  IV (hex)=4558414d504c45495631323334353637

[Cipher.init] transform=AES/CBC/PKCS5Padding
  key(hex)=4558414d504c454b4559313233343536
  IV (hex)=4558414d504c45495631323334353637

[Cipher.init] transform=RSA/ECB/PKCS1Padding
  key(hex)=(null)   <-- Keystore (non-exportable)

[Cipher.init] transform=AES/GCM/NoPadding
  key(hex)=(null)   <-- Keystore (non-exportable)
  IV(cipher.getIV())=aea87f75a29dd95ce23122d7

구조가 한눈에 보인다.

신규 데이터는 Keystore 기반 GCM으로 처리해 키가 (null)로 나온다(비추출, 양호). RSA도 마찬가지다.

그런데 CBC 경로만 키가 raw로 그대로 찍혔다. 그리고 그 값을 바이트로 읽는 순간, 결정적인 게 드러난다.

03 · 판별 — hex를 ASCII로 읽어본다

제대로 생성된 키는 SecureRandom이 뽑은 난수라서, 바이트 값이 0x00~0xFF 전 범위에 아무렇게나 흩어진다.

ASCII로 읽으면 깨진 문자와 제어문자가 뒤섞여 절대 단어가 되지 않는다. 그런데 이 키는 달랐다.

KEY  45 58 41 4d 50 4c 45 4b 45 59 31 32 33 34 35 36
     E  X  A  M  P  L  E  K  E  Y  1  2  3  4  5  6
  →  "EXAMPLEKEY123456"

IV   45 58 41 4d 50 4c 45 49 56 31 32 33 34 35 36 37
     E  X  A  M  P  L  E  I  V  1  2  3  4  5  6  7
  →  "EXAMPLEIV1234567"

16바이트가 전부 숫자·영대문자(0x30~0x5A) 범위에만 깔끔하게 들어가 있다. 우연일 확률은 사실상 0이다.

이런 패턴이 보이면, 개발자가 소스에 문자열 상수로 박아뒀다는 신호다. (예시 값으로 치환했으며, 실제 키는 위와 동일한 구조로 나왔다)

셸에서 한 줄로 바로 확인된다.

$ echo 4558414d504c454b4559313233343536 | xxd -r -p; echo
EXAMPLEKEY123456

바이트를 글자로 읽었더니 비밀번호처럼 생긴 문자열이 튀어나왔다.

이것이 하드코딩을 눈으로 바로 잡아내는 가장 빠른 신호다.

04 · 교차검증 — jadx로 소스를 확인한다

동적 분석으로 확보한 값이 진짜 소스에 박힌 상수인지, jadx로 디컴파일해 교차검증했다.

암호화 유틸리티 클래스에서 바이트 단위로 일치하는 배열 선언을 찾았다.

// com.example.bank.util.CryptoUtil

// Key → "EXAMPLEKEY123456"
c = new byte[]{69, 88, 65, 77, 80, 76, 69, 75, 69, 89, 49, 50, 51, 52, 53, 54};

// IV  → "EXAMPLEIV1234567"
d = new byte[]{69, 88, 65, 77, 80, 76, 69, 73, 86, 49, 50, 51, 52, 53, 54, 55};

69=0x45=E, 88=0x58=X… 후킹으로 뽑은 hex를 10진수로 적은 것뿐, 값은 동일하다.

눈여겨볼 건 문자열 리터럴이 아니라 바이트 배열로 풀어 썼다는 점이다. 문자열 검색을 피하려는 난독화 의도로 보인다.

하지만 배열도 ASCII로 읽으면 그대로 드러나니 우회가 되지 않는다. 오히려 "일부러 숨기려 한 정황"이라 지적 포인트가 하나 더 생긴다.

✅ 증거 체인 완성

동적(런타임 키·IV) → 정적(소스 선언 위치·클래스명) → 바이트 일치.
세 겹이 맞물리면 "런타임 우연"이라는 반박이 불가능해진다.

05 · iOS — 같은 기법, 다른 함수

iOS에서도 원리는 똑같다. 다만 iOS는 암호화 API가 한 군데로 모이지 않는다는 점이 다르다.

네이티브 AES는 대부분 CommonCrypto의 CCCrypt C 함수로 흘러간다. Android의 Cipher.init에 대응하는 자리가 바로 여기다.

차이는 후킹 방식이다. 자바 클래스가 아니라 C 함수라서 Interceptor.attach로 네이티브 함수를 가로챈다. 핵심은 이 함수의 인자 순서를 아는 것이다.

CCCrypt(op, alg, options, key, keyLength, iv, ...)
         a0  a1    a2     a3      a4      a5

4번째 인자(a[3])가 키가 담긴 메모리 주소, 6번째(a[5])가 IV 주소다.

이 함수가 호출되는 순간 그 주소에서 각각 keyLen바이트, 16바이트를 읽으면 된다.

(function () {
    var seen = {};   // 같은 key/IV 반복 출력 방지

    function hook(name) {
        var p = Module.findExportByName(null, name);
        if (!p) { console.log('[-] ' + name + ' 없음'); return; }

        Interceptor.attach(p, {
            onEnter: function (a) {
                try {
                    var keyLen = a[4].toInt32();
                    if (keyLen <= 0 || keyLen > 32) return;   // 비정상 길이 방어

                    // a[3] = key 포인터, a[5] = IV 포인터
                    var kb = a[3].readByteArray(keyLen);
                    if (!kb) return;
                    var keyHex = '', u = new Uint8Array(kb);
                    for (var i = 0; i < u.length; i++)
                        keyHex += ('0' + u[i].toString(16)).slice(-2);

                    var ivHex = '';
                    if (!a[5].isNull()) {
                        var v = new Uint8Array(a[5].readByteArray(16));
                        for (var j = 0; j < v.length; j++)
                            ivHex += ('0' + v[j].toString(16)).slice(-2);
                    }

                    var sig = name + keyHex + ivHex;
                    if (seen[sig]) return;   // 중복 스킵 → 로그 폭주 방지
                    seen[sig] = true;

                    console.log('\n[' + name + '] keyLen=' + keyLen);
                    console.log('  key(hex)=' + keyHex);
                    console.log('  IV (hex)=' + (ivHex || '(none)'));
                } catch (e) { console.log('[' + name + '] err: ' + e); }
            }
        });
        console.log('[+] ' + name + ' 후킹 완료');
    }

    hook('CCCrypt');          // 원샷 암호화
    hook('CCCryptorCreate');  // 스트리밍 암호화
})();

Android와 동일하게 인증번호를 입력하자, CCCrypt가 호출되며 값이 떨어졌다.

[+] CCCrypt 후킹 완료
[+] CCCryptorCreate 후킹 완료

[CCCrypt] keyLen=16
  key(hex)=4558414d504c454b4559313233343536
  IV (hex)=4558414d504c45495631323334353637

Android에서 본 값과 바이트 하나까지 동일하다.

양 플랫폼 빌드가 같은 하드코딩 키·IV를 공유한다는 뜻이고, 이는 플랫폼과 무관하게 CBC 암호문을 전부 복호화할 수 있다는 의미다.

한 가지 실전 포인트

처음엔 hexdump를 직접 쓰는 짧은 후킹을 썼는데, 유효하지 않은 메모리를 읽다가 세션이 멈추는 일이 있었다. 위처럼 readByteArray + 길이 체크 + try/catch + 중복 제거를 넣으면 안정적으로 찍힌다. 로그 폭주도 함께 막힌다.

06 · 정리 — 대응과 핵심

이 CBC 경로의 문제는 세 겹이다.

하드코딩 AES-128 키 — 앱 소지자 누구나 복호화 가능
고정 IV — CBC의 의미론적 안전성 상실, 평문 패턴 노출
바이트 배열 난독화 — 은폐 시도 정황

흥미로운 건 같은 앱의 Keystore 기반 GCM 경로는 제대로 짜여 있었다는 점이다. 레거시 CBC만 구멍으로 남은 전형적인 split 아키텍처였다.

항목	Android	iOS
후킹 지점	`javax.crypto.Cipher.init`	`CCCrypt` / `CCCryptorCreate`
방식	Java 메서드 implementation 교체	네이티브 함수 Interceptor.attach
키 위치	`Key.getEncoded()`	인자 `a[3]` 메모리
IV 위치	IvParameterSpec / `getIV()`	인자 `a[5]` 메모리

대응방안

하드코딩 키 제거 — 소스 상수 대신 Android Keystore / iOS Keychain·Secure Enclave 기반의 비추출 키를 사용하거나, 안전한 키 교환으로 관리한다.
고정 IV 제거 — 매 암호화마다 SecureRandom으로 IV를 새로 생성하고, 암호문 앞에 붙여 전달한다.
AEAD로 전환 — 무결성까지 보장하는 AES/GCM으로 통일한다. 같은 앱의 Keystore GCM 경로가 이미 좋은 선례다.

기억할 한 가지

암호화는 키를 숨길 수 없다.

암호화하는 순간 키는 반드시 함수로 전달되고, 그 함수는 메모리 위에 있다. Android면 Cipher.init, iOS면 CCCrypt — 그 한 지점에 덫을 놓고 기능을 트리거하면, 앱이 무엇을 숨기든 키는 드러난다.

그리고 뽑은 바이트를 ASCII로 한 번 읽어보는 것, 그 30초가 하드코딩을 잡는 가장 빠른 길이다.

#Frida #AES/CBC #HardcodedKey #CommonCrypto #jadx #MobilePentest

개인 학습 기록 · 패키지명·도메인·키 값은 전부 예시로 치환했으며, 기법 자체는 실제 진단에서 쓴 것과 동일하다.

Android 알람창 우회 코드 모음

teppi — Mon, 3 Aug 2026 17:47:44 +0900

Java.perform(function() {

var Reflect = Java.use('android.app.Dialog');

Reflect.dismiss.implementation = function(){

console.log('test');

this.hide()

};

});

Java.perform(function() {

var Activity = Java.use('android.app.Activity');

Activity.finish.overload().implementation = function(){

console.log('finish() blocked : ' + this.getClass().getName());

// 아무것도 안 하고 그냥 무시 -> 원래 finish() 호출 안 함

};

Activity.finish.overload('int').implementation = function(finishTask){

console.log('finish(int) blocked : ' + this.getClass().getName() + ' arg=' + finishTask);

// 마찬가지로 아무것도 안 하고 무시

};

var ActivityMoveBack = Java.use('android.app.Activity');

ActivityMoveBack.moveTaskToBack.overload('boolean').implementation = function(nonRoot){

console.log('moveTaskToBack() blocked : ' + this.getClass().getName());

return false; // 원래 boolean 리턴 -> 실행 안 됐다는 의미로 false

};

var SystemClass = Java.use('java.lang.System');

SystemClass.exit.implementation = function(code){

console.log('System.exit(' + code + ') blocked');

};

var Runtime = Java.use('java.lang.Runtime');

Runtime.exit.implementation = function(code){

console.log('Runtime.exit(' + code + ') blocked');

};

Runtime.halt.implementation = function(code){

console.log('Runtime.halt(' + code + ') blocked');

};

var Process = Java.use('android.os.Process');

Process.killProcess.implementation = function(pid){

console.log('Process.killProcess(' + pid + ') blocked');

};

Process.sendSignal.implementation = function(pid, signal){

console.log('Process.sendSignal(pid=' + pid + ', signal=' + signal + ') blocked');

};

Activity.finishAffinity.implementation = function(){

console.log('finishAffinity() blocked : ' + this.getClass().getName());

};

Activity.finishAndRemoveTask.implementation = function(){

console.log('finishAndRemoveTask() blocked : ' + this.getClass().getName());

};

});

2025년 4회차 정보보안기사 합격 후기 (공부 방법/ 소소한 꿀팁들)

teppi — Mon, 3 Aug 2026 17:45:29 +0900

짧게나마 제 공부 방법과 소소한 팁, 느낀 점에 대해서 남겨봅니다.
정보보안기사 기사를 준비하는 분들께 도움이 되었으면 좋겠습니다.

0. 지원동기

"너 쌍기사 있어?"

2023년에 보안 공부에 막 발을 들였을 때, 같이 공부하던 동료에게서 '쌍기사'라는 단어를 처음 들었습니다. 정보처리기사와 정보보안기사를 모두 가진 사람을 부르는 말이라는데, 그게 괜히 그렇게 멋지게 들렸습니다.

단순하게 "나도 저 타이틀 갖고 싶다!"라는 마음으로 시작했던 것 같습니다. 그렇게 시작된 도전은 2024년 6월 정보처리기사 합격으로 이어졌고, 기세를 몰아 2025년 신년 목표를 '정보보안기사 취득'으로 잡고 본격적인 레이스에 뛰어들게 되었습니다.

1. 자격증 설명

정보보안기사는 한국방송통신전파진흥원(KCA)에서 시행하는 국가기술자격증 시험이며 정보보안 시스템, 네트워크, 애플리케이션 등 IT 인프라 전반의 보안 상태를 진단하고 침해 사고에 대응 능력을 두루 평가합니다.

1-1. 시험 과목 및 검정 방법

시험은 1차 필기와 2차 실기로 나뉘어 진행됩니다.

필기 시험

객관식 4지 택일형으로 진행되며, 과목당 20문항(총 100문항, 150분)이 출제됩니다.

과목명	주요 학습 내용
1. 시스템 보안	OS(Linux, Windows) 보안, 계정 관리, 로그 분석, 취약점 점검
2. 네트워크 보안	OSI 7 Layer, TCP/IP 프로토콜 분석, 네트워크 공격(DoS, 스푸핑 등), 장비 보안
3. 어플리케이션 보안	웹 보안(OWASP Top 10), FTP/SMTP/DB 보안, 전자상거래 보안, 악성코드 분석
4. 정보보안 일반	암호학(대칭키/비대칭키, 해시함수), 접근통제 모델, 인증 기술
5. 정보보안 관리 및 법규	ISMS-P 인증 제도, 위험 관리, 정보통신망법, 개인정보 보호법 등

합격 기준: 100점 만점 기준 과목당 40점 이상(과락 기준), 전 과목 평균 60점 이상

실기 시험

필답형(주관식)으로 진행되며, 시험 시간은 180분입니다.

실기 시험은 총 18문제가 출제되지만, 실무형에서 1문제를 선택해 풀기 때문에 실제 수험생이 답안을 작성하는 문제는 총 17문제(100점 만점)입니다.

시험 유형	출제 문항	문항당 배점
1. 단답형	12문항	3점 x 12
2. 서술형	4문항	12점 x 4
3. 실무형	2문항 중 1문항 선택	16점 x 1
합계	17문항	100점

단답형: 용어, 명령어, 설정 파일 경로, 법률 조항 빈칸 채우기 등
서술형: 공격 원리 설명, 취약점 조치 방안, 로그 분석 결과 해석 등
실무형: 방화벽/Snort 룰(Rule) 설정, 리눅스 명령어 및 스크립트 작성 등

합격 기준: 100점 만점 기준 60점 이상.

1-2. 합격률 및 난이도 특징

필기는 평균 30% ~ 40% 합격률로 처음 공부를 시작하는 사람들에게는 어렵지만 시간을 두고 충분히 공부 후 문제 풀이를 진행했다면 어려움 없이 합격할 수 있습니다.

하지만 실기는 국가기술자격증 중에서도 악명 높은 난이도를 자랑합니다. 예전에는 0% ~ 10%의 평균 합격률이라는 극악의 난이도를 자랑했지만 한국방송통신전파진흥원(KCA) 이관된 이후에는 10% ~ 20% 대로 올라온 만큼 난이도가 예전에 비해 쉬워졌습니다.

하지만 가장 최근 2026년 1회차 실기 합격률이 다시 6%를 기록하는 등 여전히 타 자격증들의 비해서 매우 합격하기 어려운 자격증입니다.

2. 필기 준비 과정

소요 기간: 약 10일
공부 방법
- 알기사 정보보안기사 필기 1200제 문제편 1회독
- CBT 기준 최근 5년 기출문제 풀이
최종 결과
- 합격 / 총점 62점
- 과목별: 65 / 70 / 65 / 60 / 50

이론서를 정독하며 공부하고 싶었지만,
집중력 문제와 시간적인 여유가 부족하여 문제 위주의 학습 방식을 선택했습니다.

정보보안기사는 동일한 기출문제가 그대로 출제되는 경우가 거의 없기 때문에,
문제편의 해설을 꼼꼼히 읽으며 관련 이론을 최대한 함께 정리하려고 노력했습니다.

특히 5과목 법규 영역은 문장 표현의 미묘한 차이로 혼동을 주는 문제가 많아 많이 헷갈렸고,
실제 시험 결과에서도 법 과목 때문에 상당히 아슬아슬하게 합격했습니다.

개인적으로 느낀 점은,
필기 난이도가 결코 쉬운 편은 아니지만 1200제 문제를 2회독 정도 한다면 합격 가능성은 충분하다는 것입니다.

3. 실기 준비 과정

소요 기간: 약 3개월 반
공부 방법
- 알기사 정보보안기사 실기 강의 수강
- 알기사 실기 문제집 문제편 풀이
- 전자책(기출문제) 반복 학습
최종 결과
- 합격 / 67점

필기를 합격한 후 여유가 없어 5개월이 흐른 후 공부를 시작했으며, 알기사 실기 강의를 구매하였습니다.

알기사 실기 강의가 총 152강으로 구성되어 있어,

약 3개월 동안은 강의 수강에만 집중했습니다.

이후 남은 약 2주 동안은
실기 문제집과 구매한 전자책에 포함된 기출문제를 중심으로
집중적으로 풀고 암기하며 시험을 준비했습니다.

공부를 하며 느낀 점은,
요즘 정보보안기사는 기출문제와 그와 연관된 내용을 100% 이해하고 있다면
난이도가 다소 높게 출제되더라도 합격선 점수는 충분히 받을 수 있는 시험이라는 것입니다.

시험 후, 예상 점수는 67~79 점이었습니다.

제가 본 회차가 기출문제 비율이 높아 결과가 나오기 전에도 쉽게 합격을 예상할 수 있었습니다.
시험이 쉽게 나온만큼 채점의 기준이 높았는지 예상 점수에서 최저점을 받았습니다.

4. 실기 공부 방법 (개인적인 의견)

실기 준비를 하며 느낀 공부 방법에 대한 개인적인 생각을 정리해봅니다.
※ 지극히 개인적인 경험에 기반한 내용입니다.

① 강의를 활용한 학습

가장 정석적인 방법이라고 생각합니다.

저는 기출만으로는 불안해서, 모든 유형의 문제에 대응하고자 강의를 구매해 공부를 시작했습니다.

장점

기본 이론을 체계적으로 익힐 수 있음
실습을 함께 진행해 주어 이해에 큰 도움이 됨
기출문제뿐 아니라 다양한 문제 유형에 대비 가능
강의의 기간이 있기 때문에 강제로 공부하게 됨

단점

총 152강으로 분량이 매우 많음
강의 하나하나 놓치지 않으려다 보니 체력적으로 부담
시험 대비보다는 ‘보안 전반’을 다루는 느낌
비용 부담이 큼

시간적·금전적 여유가 있는 경우, 인터넷 강의를 활용해 기본 개념을 뼈대부터 탄탄히 다진 뒤,

기출문제를 꼼꼼하게 회독하는 방식을 추천합니다.

이론과 문제 풀이를 밸런스 있게 챙길 수 있어서 가장 안정적으로 합격권에 진입할 수 있는 정석적인 방법입니다.

② 책 중심 독학

책을 여러 번 정독하고 문제를 빠르게 반복하는 방식입니다.

장점

시험 위주 공부에 매우 적합
자주 출제되는 유형(snort, 위험관리 등)에 집중 가능
준비 시간이 짧은 경우 특히 추천
비용 부담이 적음

단점

정보보안기사는 신규 문제가 꾸준히 출제됨
기출 위주 학습은 새로운 유형 대응에 한계가 있을 수 있음

시간적·금전적 여유가 부족한 경우, 독학 교재(기본서)로 핵심 개념만 빠르게 훑어본 뒤,

곧바로 기출문제 풀이와 오답 노트에 집중하는 '선택과 집중' 전략을 추천합니다.

최근 시험 경향을 보면 기출문제만 제대로 파고들어도 충분히 합격 점수를 넘길 수 있도록 출제되고 있기 때문에,

이 방법 역시 승산이 매우 높습니다.

다만 무엇보다 중요한 것은,
정해진 정답 같은 공부 방법이 아니라 자신에게 가장 잘 맞는 학습 방식을 찾는 것이라고 생각합니다.
본인의 상황과 성향에 맞는 방법을 선택해 꾸준히 이어가는 것이
결국 합격으로 이어지는 가장 현실적인 전략이었습니다.

5. 시험 후기

정보보안기사를 취득했다고 해서 겉으로 보이는 변화가 생긴 것은 사실상 없습니다.

다만 합격 당일 느꼈던 성취감은 분명했고,

‘언젠가는 꼭 따야 한다’는 마음속 부담에서 벗어났다는 점이 가장 큰 보상이었다고 느꼈습니다.

또한 이론적인 부분이 많이 정리되면서
실무에서도 직·간접적으로 도움이 되고 있다는 점을 체감하고 있습니다.

2026년에는 결혼을 잘 준비하면서,
버그바운티 활동에 조금 더 집중해보고
여유가 된다면 CPPG 자격증에도 도전해볼 생각입니다.

정보보안기사를 준비하며 가장 중요하다고 느낀 것은
결국 꺾이지 않는 마음과 끈기였습니다.

6. 도움 자료들

필기:

1. 알기사 정보보안기사 필기 이론서 + 1200제

2. 정보보안기사 필기 기출문제 CBT https://www.comcbt.com/xe/ccw

실기:

1. 알기사 정보보안기사 실기 이론서 + 문제편

2. 지안에듀 알기사 정보보안기사 정일영 교수님 156강

3. 네이버 블로그 ‘온계절’ https://blog.naver.com/stereok2

4. 블로그 ‘온계절’ 님이 집필한 정보보안기사 전자책

5. 네이버 카페 ‘알기사’ https://cafe.naver.com/algisa

frida 버전 추천

teppi — Mon, 3 Aug 2026 17:45:03 +0900

frida 버전은 16.2.5 버전을 다운 받으시는 것을 추천드립니다.

frida-tools 는 13.7.0 버전을 다운 받으시는 것을 추천드립니다.

충돌 회피를 위하고 원활한 동작을 제공하는 버전입니다.

디스어셈블러 : 함수 앞 [+]와 [-] 기호의 의미와 루팅 우회 전략

teppi — Mon, 3 Aug 2026 17:43:41 +0900

루팅 우회를 하다 보면, IDA Pro나 Ghidra 같은 디스어셈블러의 함수 목록에서 +[ClassName MethodName] 또는 -[ClassName MethodName]과 같은 독특한 표기법을 자주 접하게 됩니다.

이 기호들은 단순한 GUI 아이콘이 아니라, 해당 함수가 어떤 타입의 메서드인지, 그리고 바이너리가 주로 Objective-C 기반임을 알려주는 중요한 단서입니다. 이 표기법을 정확히 이해하는 것은 성공적인 후킹(Hooking) 및 분기문 우회 전략을 수립하는 첫걸음입니다.

1. [+]와 [-] 기호, 그 근본적인 차이

이 기호들은 **객체 지향 프로그래밍(OOP)**의 핵심 개념인 **클래스 메서드(Class Method)**와 **인스턴스 메서드(Instance Method)**를 나타냅니다.

기호	Objective-C 용어	OOP 개념	설명
+	클래스 메서드 (Class Method)	정적(Static) 메서드	특정 객체(인스턴스)를 생성하지 않고 클래스 자체에 소속되어 호출되는 기능입니다. 환경 변수 확인, 공통 유틸리티 기능 등 전역적인 처리에 사용됩니다.
-	인스턴스 메서드 (Instance Method)	동적(Dynamic) 메서드	반드시 객체(인스턴스)를 생성해야만 호출할 수 있는 기능입니다. 특정 객체의 내부 상태를 조작하거나 확인하는 개별적인 업무 처리에 사용됩니다.

예시: +[SystemUtil isJailBroken]는 SystemUtil 클래스에 "전체 시스템 상태가 탈옥이니?"라고 묻는 것이고, -[AFSDKChecksum calculateV2Sa...]는 특정 AFSDKChecksum 객체에게 "너의 체크섬을 계산하라"고 지시하는 것입니다.

2. 분기문 우회(Hooking) 전략: 왜 [-]가 유리한가?

"분기문 우회는 - 메서드에 집중하는 것이 좋다"는 조언은 매우 실용적입니다. 이는 Objective-C 런타임의 Method Swizzling 기법과 보안 로직의 특성 때문입니다.

A. 후킹 기법의 용이성

Objective-C 바이너리 후킹의 표준 기법인 Method Swizzling은 **인스턴스 메서드(-)**에 대해 가장 간결하고 표준적으로 적용될 수 있습니다.

- 메서드: 인스턴스 메서드는 objc_getClass 함수로 클래스를 얻어낸 후, 해당 클래스의 Method 포인터를 class_getInstanceMethod 함수로 쉽게 찾아 재정의할 수 있습니다.
+ 메서드: 클래스 메서드 역시 후킹이 가능하지만, 때때로 호출 방식이 다르거나 컴파일러에 의해 인라인(Inline) 최적화되어 있어 인스턴스 메서드보다 다소 복잡한 접근이 필요할 수 있습니다.

B. 로직의 집중 지점

보안 라이브러리(예: 안티-디버깅)는 종종 특정 객체를 생성하여 그 객체의 상태를 이용해 보안 검증을 수행합니다.

예를 들어, 보안 라이브러리가 SecurityManager 객체를 만들고 -[SecurityManager isConfigurationSafe]와 같은 - 메서드를 통해 분기문을 발생시킵니다.
이때 해당 - 메서드를 후킹하여 무조건 $\text{True}$를 반환하게 만들면, 객체의 상태를 "안전함"으로 속여 분기문을 손쉽게 통과할 수 있습니다.

3. 우회 전략의 결론: 두 마리 토끼 잡기

실제 우회 작업에서는 +와 -를 모두 고려해야 합니다.

1순위 (+): 전역적인 탈옥/디버깅 확인 함수에 주목하세요. +[SystemUtil isJailBroken], +[Codeguard isJailBroken] 등은 앱 실행 초기에 호출되어 앱을 즉시 종료시키는 Kill Switch 역할을 할 가능성이 높습니다.
2순위 (-): 중요한 검증 로직 및 데이터 조작에 주목하세요. -[AFSDKChecksum calculate...]와 같이 체크섬이나 무결성 검증을 수행하는 - 메서드를 후킹하여 검증 로직이 요구하는 '정상 값'을 강제로 반환하게 만드는 것이 핵심 우회 작업이 됩니다.

[+]와 [-]는 단순한 구분이 아닌, 해당 함수의 책임 영역(Scope)을 나타내는 중요한 단서입니다. 이 정보를 활용하여 전략적으로 후킹 지점을 선택한다면, 리버스 엔지니어링 효율을 크게 높일 수 있을 것입니다.

Android vs iOS : Frida가 동작하는 방식이 다른 이유

teppi — Mon, 3 Aug 2026 17:42:32 +0900

Frida는 동적 분석을 위한 강력한 도구지만, 플랫폼에 따라 실행 방식이 조금 다릅니다. 특히 Android에서는 adb shell로 직접 frida-server를 실행해야 하지만, iOS(탈옥 환경)에서는 별도 실행 없이 바로 사용이 가능합니다.

1. Android : 직접 실행이 필요한 이유

Android는 리눅스 기반의 보안 모델을 따릅니다.

각 앱은 독립된 UID로 실행
기본적으로 앱 간 메모리 접근이 불가
시스템 수준 접근은 root 권한이 필요
때문에 다음과 같은 과정이 필요

adb shell        # 디바이스에 접속
./frida-server   # root 권한으로 실행

즉, Frida가 대상 프로세스를 후킹하려면 루트 권한으로 돌아가는 별도 백엔드 서버가 필요합니다.

2. iOS: frida-server 실행이 필요 없는 이유

iOS는 기본적으로 매우 폐쇄적인 OS이지만, 탈옥(jailbreak) 상태에서는 다음과 같이 동작합니다.

시스템 루트 권한 획득 (root)
AMFI, Sandbox, Code Signing 우회
시스템 데몬과 launchd 접근 가능

# Cydia / Sileo 등에서 설치
apt install frida

탈옥 디바이스에서 frida 설치 시 frida-server가 launchd에 등록되어 자동 실행됩니다.

즉, 별도로 frida-server를 실행하지 않아도, PC에서 바로 attach가 가능합니다.

Android vs iOS

항목	Android	iOS
기본 권한	일반 사용자	root
앱 간 접근	X 불가능	O 가능
frida-server 실행	수동 (adb shell로)	자동 (설치 시 등록됨)
루팅/탈옥 필요	필요	필요
설치 방식	binary push	.deb 패키지 설치

3줄 요약

Android는 보안이 강력한 구조여서 frida-server를 따로 실행해야 한다.
iOS는 시스템에 루트 접근이 가능하고 launchd로 자동 실행되므로 별도 실행이 필요 없다.
운영체제의 보안 정책과 권한 모델 차이에서 비롯된다.