← 메인으로

🧩 전자금융 보안 모의해킹 · 앱 위·변조 및 안티디버깅

Target: 모바일/HTS 실행파일
평가기준: 위험도 5 MOB/HTS-FIN 프로그램 무결성
💡 쉽게 말하면
앱을 뜯어고쳐 가짜로 재배포해도 검사가 없으면 그대로 실행됩니다. 위·변조 검사·난독화로 "정품 앱"임을 확인해야 합니다.
🔓 공격 시뮬레이션 (Red Team)
🛡️ 대응 방안 (Blue Team)
앱 무결성 점검🔒 Secured Channel
설치파일(APK/IPA)이나 실행 라이브러리가 위·변조 검증·난독화·안티디버깅 없이 배포되면, 디컴파일로 로직을 분석하거나 변조 후 재서명하여 악성코드를 삽입·재배포할 수 있습니다.
⚡ APK 변조 후 재서명
디컴파일→로직 패치→재서명 설치
OFF
🖥️ 금융 시스템 처리 로그
[SYSTEM] Core Banking Channel ready.
[INFO] 거래 요청 대기 중...
⚖️ 컴플라이언스 위반 분석
공격 실행 후 분석 결과가 표시됩니다.
[심각] 전자금융 보안 기준 위반 감지
  • 평가기준 [전자금융] 프로그램 무결성 검증(위험도 5)
  • 소스코드 난독화 미적용 / 디버깅 탐지 미적용
  • 무결성 검사 없는 코드 다운로드(보안기능)
🛡️ 대응 코드/설정 실습

앱은 서명·체크섬 기반 무결성 검증, 코드 난독화, 안티디버깅을 적용해야 합니다. 실행 시 무결성 검사를 보완하세요.

📚 금융보안원 평가기준 / 조치 가이드

1. 점검 항목

단말 보안 > 프로그램 무결성 검증·난독화·안티디버깅

2. 위험 분석

  • 변조 앱 재배포로 악성코드 유포
  • 디컴파일로 중요 로직·키 노출

3. 조치 방법

  • 설치파일 서명/체크섬 무결성 검증
  • 소스코드 난독화(R8/ProGuard 등)
  • 안티디버깅·메모리 보호 적용
🏗️ 현대 금융 IT 환경에서의 변형
Play IntegrityApp Attest서버 검증

어디가 달라졌나

앱이 스스로 위·변조를 탐지하던 방식은 공격자가 그 탐지 코드를 지우면 끝이었습니다. 현재 표준은 OS 가 보증하고 서버가 검증하는 구조입니다 — Android Play Integrity API, iOS App Attest / DeviceCheck.

현대 스택에서의 조치

  • 앱이 무결성 토큰을 받아 서버로 보내고, 서버가 구글·애플에 검증합니다. 판정 주체가 단말 밖으로 나가는 것이 핵심입니다.
  • 검증 대상: 패키지명·서명 인증서 해시·정품 설치 경로 여부(사이드로딩 탐지)·기기 무결성.
  • 실패 시 즉시 차단이 아니라 위험 점수로 다룹니다 — 오탐이 있어 정상 사용자를 막을 수 있습니다.
// 서버에서 검증 — 앱의 "괜찮다"는 말을 믿지 않는다
IntegrityTokenResponse r = playIntegrity.decode(token);
if (!r.appRecognitionVerdict().equals("PLAY_RECOGNIZED"))
    risk.add(40, "비정품 앱 또는 변조");
if (!r.deviceRecognitionVerdict().contains("MEETS_DEVICE_INTEGRITY"))
    risk.add(30, "기기 무결성 미충족");
놓치기 쉬운 곳 — 토큰을 앱에서 받아 그대로 서버에 넘기고 서버는 파싱만 하는 구현이 흔합니다. 반드시 구글/애플 API 로 원격 검증해야 하며, nonce 를 서버가 발급해 재사용도 막아야 합니다.