가. 어플리케이션 패칭이란?
- 애플리케이션 패칭(Application Patching)은 애플리케이션의 바이너리 파일이 영구적으로 변경되는 것을 말하며 애플리케이션 위·변조라고도 부른다.
- 바이너리 파일에는 앱 실행 및 동작에 필요한 모든 데이터들이 들어가 있으므로 바이너리 파일을 수정하여 로그인 메소드, 탈옥 탐지 메소드 등을 우회할 수 있다.
* 바이너리(Binary) 파일이란 실행 가능한 형식의 데이터 파일을 말하며, 쉽게 윈도우즈의 exe 파일이라 생각하면 된다.
나. 대응방안
- 애플리케이션 바이너리 파일의 해시 값을 검증(코드 무결성 검증)하여 앱이 위·변조되었는지 체크 한다.
다. DVIA-v2 앱을 통한 실습
1. 분석 대상 앱 실행
- 어플리케이션 패칭 실습을 위해 DVIA-v2 앱을 실행한다.
※ DVIA-v2 어플이 설치되어있지 않은 사람은 아래의 글을 참고하여 앱을 설치하길 바란다.
2022.07.01 - [Mobile App 취약점 진단/iOS App 진단] - [iOS App 진단] 04강 - 진단 대상 설치
- 메인메뉴 좌측 상단 메뉴 클릭 → Application Patching 클릭 → START CHALLENGE 클릭 → Check For Jailbreak 클릭
- 현재 탈옥된 기기를 사용하고 있다는 "Device is Jailbroken" 메시지가 출력된다.
- 본글에서는 탈옥된 기기를 사용하더라도 위 메시지가 출력되지 않도록 바이너리 파일을 변조할 것이다(탈옥탐지 우회).
2. 바이너리 파일 추출
- 바이너리 파일을 변조하기위해서는 앱내부에 존재하는 바이너리 파일을 추출해내야 한다.
- 3uTools Files에서 Applications(User) 클릭 또는 탐색창에 /var/Containers/Bundle/Application 입력한다.
- 분석 대상 앱 이름과 동일한 폴더를 더블클릭한다.
- Size 클릭하여 파일을 크기순으로 정렬한다.
- 폴더를 제외하고 크기가 제일 큰 파일이 바이너리 파일이다.
- 바이너리 파일을 우클릭한뒤 Export 버튼을 눌러 PC로 추출한다.
3. ASLR 적용여부 확인
- 바이너리 파일을 분석하기 위해서는 ASLR이 적용되어 있지는 확인하여야 한다.
* ASLR(Address Space Layout Randomization, 주소 공간 배열 무작위화) : 메모리 손상 취약점 공격을 방지하기 위한 기술로, 프로그램이 실행될 때마다 메모리주소가 랜덤으로 변경된다.
- 아래의 글을 참고하여 앱에 ASLR이 적용되어 있는지 확인한다.
2023.10.03 - [Mobile App 취약점 진단/iOS App 진단] - 바이너리 ASLR 적용유무 확인방법 - otool
- 확인결과 DVIA-v2 바이너리 파일에는 ASLR이 적용되어 있는 것을 알 수 있다.
4. 바이너리 파일 분석
- 아래의 과정을 따라하여 추출한 바이너리 파일을 기드라(Ghidra)를 통해 분석한다.
※ 기드라가 설치되어 있지 않은 사람은 아래의 글을 참고하여 설치하길 바란다.
2022.06.28 - [Mobile App 취약점 진단/iOS App 진단] - [iOS App 진단] 03강 - 진단 도구 설치
- File 클릭 → New Project 클릭 → Non-Shared Project 선택 → Next 클릭
- Project Directory 경로지정 → Project Name 입력 → Finish 클릭 → File 클릭 → Import File 클릭
* Project Directory : 프로젝트 저장 경로.
* Project Name : 프로젝트 이름.
- 위에서 추출한 바이너리 파일 선택 → Select File To Import 버튼 클릭
- 설정내용을 아무것도 건드리지 않고 OK 버튼 클릭
- 추가된 바이너리 파일(DVIA-v2)을 더블클릭 → Yes 버튼 클릭
- 설정내용을 아무것도 건드리지 않고 Analyze 버튼 클릭 → 분석이 종료될때까지 대기(우측 하단에 진행률이 표시됨).
※ 분석이 종료되면 알림창이 발생한다. 분석이 완료되지 않으면 결과가 달라질 수 있으므로 완료될 때까지 기다린다.
- Search 클릭 → For Strings 클릭
- Check For Jailbreak 클릭 시 발생했던 오류문구를 Filter에 입력 → 검색결과 중에서 분석하고자 하는 행(아이템)을 더블클릭
- 검색창을 최소화하거나 닫으면 메인창의 커서가 위에서 더블클릭한 문구가 위치한 곳으로 이동되어 있다.
- 음영표시된 칸의 우측 "XREF[1]: __T07DVIA_v213DVIAUtilitiesC9sho..."을 더블클릭한다.
- 더블클릭 시 음영표시된 칸을 선택 → Window 클릭 → Function Graph 클릭
- 노란색으로 표시되면서 확대/축소를 반복하는 곳을 마우스 휠을 이용하여 확대한다.
- 내용을 분석해 보면 레지스터 w0의 값이 0x0일 때와 아닐 때의 결과가 달라진다는 것을 알 수 있다.
* 1001cc17c : 문구를 보았을때 탈옥되지 않은 기기일때 실행되는 로직인걸 알 수 있음.
* 1001cbdd4 : 문구를 보았을때 탈옥된 기기를 사용할때 실행되는 로직인걸 알 수 있음.
* tbz(Test bit and Branch if Zero) : 테스트 비트의 값을 0과 비교하여 결과에 따라 다른 오프셋의 레이블로 분기함.
5. 바이너리 파일 변조
- 현재 로직을 분석해 보면 w0 레지스터 값이 0x0일때 1001cc17c 오프셋(offset)으로 이동되도록 되어져 있다는 것을 알 수 있다.
- 1001cc17c 오프셋은 탈옥이 탐지되지 않았을 때의 로직이므로, 'Check For Jailbreak' 클릭 시 w0 값으로 0x0이외의 값이 입력되어 탈옥이 탐지되었을 때의 로직이 실행되었다고 추측할 수 있다.
- #0x0을 'Check For Jailbreak' 클릭 시 w0에 입력되는 값으로 수정하여 탈옥탐지 기능을 우회해 보겠다.
* 'Check For Jailbreak' 클릭 시 w0에 입력되는 값이 0x1이라고 가정하고 #0x0을 #0x1로 수정하였을 경우 조건문이 반대가 되므로, w0의 값이 0x0일때 탈옥이 탐지되었을때의 오프셋(1001cbdd4)으로 연결되고 0x1일때 탈옥이 탐지되지 않았을때의 오프셋(1001cc17c)으로 연결된다.
//이해하기 쉽게 변경하고자 하는 내용을 C언어로 작성하면 아래와 같다.
//변경 전(AS-IS)
if (w0 == 0) {
탈옥이 탐지되지 않았을 때의 로직 실행
}
else {
탈옥이 탐지되었을 때의 로직 실행
}
//변경 후(TO-BE)
if (w0 == 1) {
탈옥이 탐지되지 않았을 때의 로직 실행
}
else {
탈옥이 탐지되었을 때의 로직 실행
}
- 분기점이 되는 곳의 오프셋을 알기 위해 아래와 같이 적색박스로 되어 있는 곳을 클릭한다(더블클릭 X).
- Function Graph 창을 최소화하거나 닫으면 메인창의 커서가 위에서 클릭한 분기점의 위치로 변경되어 있을 것이다.
- 음영표시된 칸의 오프셋을 기억하도록 한다.
* 분기점의 오프셋 : 1001cbdd0
- 레지스터 w0의 값을 변조하기 위해서는 탈옥된 기기에 프리다 서버, PC에 프리다 클라이언트가 설치되어 있어야한다.
- 아래의 글을 참고하여 프리다(Frida) 서버와 클라이언트를 설치하도록 한다.
2022.06.28 - [Mobile App 취약점 진단/iOS App 진단] - [iOS App 진단] 03강 - 진단 도구 설치
- PC의 프리다 클라이언트를 이용하여 탈옥탐지 기능을 우회하고자 하는 앱의 이름을 알아낸다.
- 명령어 : frida-ps -Ua
* 앱의 이름 : DVIA-v2
frida-ps -Ua
- 위에서 확인한 정보를 바탕으로 아래의 자바스크립트 코드를 PC에서 작성한다.
- 파일 명 : hagsig_patching.js
* 메모장에 아래의 코드를 입력한 뒤 확장자명을 .js로 저장하면 자바스크립트 파일이 만들어진다.
//DVIA-v2 바이너리가 실행되어 메모리에 올라갔을때 할당된 주소를 realbase_address에 저장
var realbase_address = Module.findBaseAddress('DVIA-v2')
//realbase_address에 저장된 주소를 화면에 출력
console.log('realbase address : ' + realbase_address)
//realbase_address에 위에서 확인한 분기점의 오프셋을 더함
//분기점 메모리 주소가 jailbreak_address에 저장됨
var jailbreak_address = realbase_address.add('0x1cbdd0')
//jailbreak_address에 저장된 주소를 화면에 출력
console.log('jailbreak address : ' + jailbreak_address)
//jailbreak_address에서 호출되는 값을 가로채기 위해 준비
Interceptor.attach(jailbreak_address, {
//호출되는 레지스터 값을 받아옴
onEnter: function(args){
//받아온 레지스터 값을 JSON 형태로 화면에 출력
console.log(JSON.stringify(this.context))
}
})
※ 위 코드를 좀 더 자세히 공부하고 싶다면 아래의 게시글을 참고하여 프리다 문법을 공부하도록 하자.
2023.10.03 - [Mobile App 취약점 진단/iOS App 진단] - 프리다(Frida) 문법 정리
※ 오프셋(offset)이란?
- 오프셋은 상대 주소, 즉 기준이 되는 주소로부터 얼마나 떨어져 있는지를 나타내는 값을 말한다.
- DVIA-v2 바이너리 실행 시 부여되는 realbase_address에서 분기점의 오프셋을 더하면 분기점의 실제 메모리주소가 나온다.
* realbase_address + 분기점 offset = jailbreak_address
- PC의 프리다 클라이언트를 이용하여 작성한 코드를 실행한다.
- 명령어 : frida -U -l [코드경로] [앱이름]
frida -U -l hagsig_patching.js DVIA-v2
- ASLR이 적용되어져 있으므로, realbase address와 jailbreak address는 실행할때마다 값이 달라진다.
- 위 화면에서 'Check For Jailbreak'을 클릭하면 아래와 같이 많은 데이터가 출력되는 것을 확인할 수 있다.
- 레지스터 x0의 값으로 0x1이 입력되어 탈옥된 기기라는 "Device is Jailbroken"메시지가 출력되는 것을 확인할 수 있다.
* 레지스터 x0은 위에서 본 레지스터 w0이다.
- 위 과정을 통해 w0 레지스터에 0x1 값이 입력되고 있어, 앱 실행 시 탈옥이 탐지되었을때의 오프셋(1001cbdd4)이 실행된다는 것을 알게되었다.
- 이제 레지스터 w0의 값이 0x1일때 탈옥이 탐지되지 않았을때의 오프셋(1001cc17c)으로 연결되고 0x0일때 탈옥이 탐지되었을때의 오프셋(1001cbdd4)으로 연결되도록 조건문을 수정할 것이다.
- 분기점 우클릭 → Path Intrcution 클릭
- 레지스터 w0의 값을 0x1으로 수정한 뒤에 엔터를 누른다.
* 기존(AS-IS) : 0x0
* 변경(TO-BE) : 0x1
- File 클릭 → Export Program 클릭
- Format을 Binary로 변경 → OK 버튼 클릭
- 저장된 바이너리파일의 확장자를 삭제 → 3uTools를 통해 앱의 바이너리 파일 교체(덮어쓰기)
* 기존(AS-IS) : DVIA-v2.bin
* 변경(TO-BE) : DVIA-v2
-앱을 재실행 한 뒤 다시 시도해 보면 "Device is Not Jailbroken"이라는 문구와 함께 탈옥탐지 기능을 우회한 것을 확인 할 수 있다.
'Mobile App 취약점 진단 · 모의해킹 > iOS App 취약점 진단 · 모의해킹' 카테고리의 다른 글
[iOS App 진단] 11강 - 애플리케이션 패칭(앱 위·변조) 실습 4 (0) | 2023.09.10 |
---|---|
[iOS App 진단] 11강 - 애플리케이션 패칭(앱 위·변조) 실습 3 (0) | 2023.09.10 |
[iOS App 진단] 11강 - 애플리케이션 패칭(앱 위·변조) 실습 1 (0) | 2023.06.22 |
페어플레이 DRM 복호화 방법 - Clutch (0) | 2023.02.26 |
페어플레이 DRM 복호화 방법 - Frida-iOS-Dump (0) | 2023.02.26 |