🧬 전자금융 보안 모의해킹 · 소스코드 난독화 적용
Target: 모바일/HTS 실행파일 (APK·IPA·EXE)
평가기준: 위험도 4 MOB/HTS-FIN 소스코드 난독화(020)
평가기준: 위험도 4 MOB/HTS-FIN 소스코드 난독화(020)
💡 쉽게 말하면
난독화는 설계도를 외계어로 바꿔 놓는 것입니다. 안 하면 누구나 앱을 뜯어 도면을 그대로 읽고 숨겨둔 열쇠(키)까지 주워 갑니다. 열쇠는 도면이 아니라 따로 금고에 둬야 합니다.
난독화는 설계도를 외계어로 바꿔 놓는 것입니다. 안 하면 누구나 앱을 뜯어 도면을 그대로 읽고 숨겨둔 열쇠(키)까지 주워 갑니다. 열쇠는 도면이 아니라 따로 금고에 둬야 합니다.
🔓 공격 시뮬레이션 (Red Team)
🛡️ 대응 방안 (Blue Team)
앱 디컴파일 분석🔒 Secured Channel
실행파일이 난독화 없이 배포되면 공격자가 디컴파일러(jadx, apktool)로 원본에 가까운 소스코드를 복원합니다. 하드코딩된 API 키·암호화 키·거래 로직이 그대로 노출됩니다.
⚡ 정적 역공학(디컴파일)
jadx / apktool 로 평문 로직·하드코딩 키 추출
jadx / apktool 로 평문 로직·하드코딩 키 추출
OFF
🖥️ 금융 시스템 처리 로그
[SYSTEM] Core Banking Channel ready.
[INFO] 거래 요청 대기 중...
⚖️ 컴플라이언스 위반 분석
공격 실행 후 분석 결과가 표시됩니다.
[심각] 전자금융 보안 기준 위반 감지
- 금융보안원 평가기준 [전자금융] 소스코드 난독화 적용(020) (위험도 4)
- 중요정보(키) 하드코딩 금지 위반
- 디컴파일 대응(난독화) 미적용
🛡️ 대응 코드/설정 실습
빌드 시 난독화(R8/ProGuard/DexGuard)를 적용하고, 키·시크릿은 코드에서 분리하여 안전저장소(KeyStore)나 서버에서 주입해야 합니다. 아래 코드를 보완하세요.
📚 금융보안원 평가기준 / 조치 가이드
1. 점검 항목
단말 보안 > 소스코드 난독화 적용2. 위험 분석
- 디컴파일(jadx/apktool)로 평문에 가까운 소스 복원
- 하드코딩된 키·로직 노출 → 위·변조, 키 탈취
3. 조치 방법
- R8/ProGuard/DexGuard 등 난독화 적용
- 키·시크릿 코드 분리(KeyStore/서버 발급)
🏗️ 현대 금융 IT 환경에서의 변형
R8 / ProGuard매핑 파일Flutter·RN
어디가 달라졌나
Android 는 R8 이 기본 축약·난독화기입니다. 그런데 크로스플랫폼 프레임워크가 늘면서 난독화 범위가 애매해졌습니다 — React Native 의 JS 번들과 Flutter 의 Dart 스냅샷은 R8 이 건드리지 않으므로, 자바 계층만 난독화하고 정작 비즈니스 로직은 평문인 경우가 많습니다.
현대 스택에서의 조치
- RN 은 Hermes 바이트코드 + 별도 JS 난독화, Flutter 는
--obfuscate --split-debug-info로 심볼을 분리합니다. - 매핑 파일(mapping.txt) 은 난독화 해제 열쇠입니다 — 소스 저장소가 아니라 접근 통제된 별도 저장소에 보관하고 빌드별로 버전 관리합니다.
- 난독화는 지연 수단이지 보호 수단이 아닙니다. 비밀값은 어차피 빼내집니다 — 서버에 두는 것이 원칙입니다.
# Flutter — 심볼을 빼서 따로 보관 $ flutter build apk --obfuscate --split-debug-info=build/symbols # 크래시 리포트 복원은 이 심볼로만 가능하므로 유실 주의
놓치기 쉬운 곳 — 난독화를 켜면 리플렉션·JSON 역직렬화가 조용히 깨집니다.
-keep 규칙을 넣다가 결국 핵심 클래스를 전부 예외 처리해 난독화가 무력해지는 일이 흔합니다.