Online Analyzers 

Sandroid : http://sanddroid.xjtu.edu.cn/

 

Sandroid는 온라인을 이용한 안드로이드 APK 파일 분석을 해주는 사이트로 APK 파일 업로드 안에 정적 동적 분석 보고서를 리포트해 줍니다.


정적 분석 항목

· 권한 분석(Permission Analysis)

· 구성 요소 분석(Component Analysis)

· 악성 코드 탐지(Malware Detection)

· 카테고리별 분류(Classification Analysis)


동적 분석 항목

· 응용프로그램이 실행되는 동안 파일 작업, 네트워크 행동, 개인정보 노출 등의 동적 행동들을 모니터링하여 분석

 

1. Sandroid를 이용한 APK 파일 분석


분석할 안드로이드 APK 파일을 추출하여 Sandroid 웹 페이지(http://sanddroid.xjtu.edu.cn/)를 통해 해당 파일을 업로드 시도합니다. 분석 결과를 메일로 받기 위해서 메일 주소를 포함시킵니다.

[그림 1] 분석할 APK 파일 업로드

 


파일 업로드 완료 , 완료 메시지를 확인 가능하며 FileMD5 값을 확인할 있습니다.

[그림 2] 업로드 성공 확인

 


, 분석 결과 URL 포함한 메일을 수신할 있습니다.

[그림 3] 분석 결과 URL 확인

 


분석 결과를 통해 일반적인 정보의 확인과 정적 동석 분석 결과를 확인할 있습니다.

[그림 4] 일반적인 정보 정적, 동적 분석 결과 확인

 


정적 분석 항목 Activity Services 정보, 권한 분석(Permission Analysis) 등을 확인할 있습니다.

[그림 5] Activity Services 정보, 권한 분석 확인

 


권한 분석(Permission Analysis) 경우 APK 파일을 apktool 이용한 Decoding , AndroidManifest.xml 파일 상의 권한 확인 결과 동일함을 확인할 있습니다.

[그림 6] AndroidManifest.xml 권한 확인

 


사용중인 API 정보, 포함하고 있는 URL 정보 등을 확인할 있습니다.

[그림 7] API, URL 정보 확인



API 포함하는 URL 경우 dex2jar 이용한 .dex 파일의 .jar 파일로의 변환 jd-gui 이용한 .jar 파일의 .class 파일을 .java Decompile 결과 동일한 URL 찾을 있음을 확인할 있습니다.

[그림 8] Decompile URL 정보 확인

 

Sandroid에서 지원하는 분석 항목 모바일 어플리케이션 점검 기준이 되는 권한 분석을 통한 불필요한 권한 부여 여부, 중요 정보 노출과 관련해 특정 문자열 검증 부분을 지원해 줌 확인 가능합니다. 또한, Activity, Services, 사용중인 API 정보를 통해 해당 APK 파일 분석에 있어 유용한 정보를 가져올 있습니다.

 


2. Online Analyzers 사이트


·  AMAT (http://dunkelheit.com.br/amat/analysis/index_en.php)

·  Anadroid (http://pegasus.cs.utah.edu:8080/) - static analysis

·  AndroTotal (http://andrototal.org/) - AV scanning

·  Comdroid (http://www.comdroid.org/)

·  CopperDroid (http://copperdroid.isg.rhul.ac.uk/copperdroid)

·  Dexter (https://dexter.bluebox.com/) - static analysis

·  Mobile-Sandbox23 (http://mobile-sandbox.com)

·  Stowaway http://www.android-permissions.org/

·  App360scan http://www.app360scan.com/

 


3. 참고 자료


·  http://ashishb.net/security/android-security-related-tools/

저작자 표시 비영리 변경 금지
신고

TeamCr@k 전원이 지난 주말

2013.1차 M.T project '관악산' 나들이를 다녀왔습니다.

 

신림 휴먼시아아파트 -> 안양유원지 약 6km정도의 산행이었습니다.

군시절 40km FM 군장 코스에 비하면 가벼운 런닝코스 일뿐이지만,

오랫만에 하는 운동으로 인해 지난 일요일은 

팀원 모두 근육통에 시달렸다는 잔혹한 이야기가 .......... 

(참고로 저는 인제 원통에서 군생활 했습니다. 부대 뒷산(625m)도 가볍게 뛰어다니던 ....그런 리즈 시절이...)

 

아직 2013.2차 M.T project 의 장소는 미정입니다.

좋은 곳 알고 계신분은 연락바랍니다.

 

사진 설명: 이번 산행의 유일한 깔딱 코스 돌파 후 상무님께서 등산코스에 대한 브리핑 중입니다.

 

 

사진 설명: 너무 즐거워 주먹을 불끈 쥐고 휴식을 취하는 박대리~

 

 

사진 설명: 이번 산행을 제일 즐겁게 다녀온 '간헐적 단식' 현기입니다. 지치지도 않는지 깔딱 코스도  가볍게 통과~

 

 

 사진 설명: 휴식중인 정대근 팀장입니다. 팔의 각도로 보아 많이 지쳐 있는 것을 확인할 수 있습니다.

 

 

사진설명 : 안양유원지 밥집에서 밥시켜 놓고 찍은 사진입니다. 사진 촬영 후 닭볶음탕과 묵 그리고 막걸리 아주 맛있게 먹었습니다.

 

 

이것으로 2013.1차 M.T project 관악산 나들이 프로젝트 리뷰를 종료하며, 

 

함께한 대장님과 TeamCr@k 팀원 모두 고하셨습니다.

 

 

 

 

 

 

저작자 표시 비영리 변경 금지
신고

국내 PHP 기반인 많은 사용자를 보유하고 있는 익스프레스엔진(XE)에서 LFI 취약점이 발표되었습니다.

해당 취약점은 일반 사용자 권한으로 서버에 명령어를 실행하여 웹쉘을 업로드 할 수 있어 아래주소에서 패치하시길 바랍니다.

http://www.xpressengine.com/blog/textyle/21937678

 

 

 

<그림1. KISA 보안 업데이트 권고>

 

 

패치 소스 관련해서 아래 경로에서 확인할 수 있습니다.

https://code.google.com/p/xe-core/source/detail?r=13127

 

<그림2. 변경된 소스코드 확인>

 

 

다음은 LFI 취약점이 발생하는 코드 일부 입니다.

create_function 에서 취약점이 발생합니다.

 

<그림3. LFI 취약점 발생 코드>

 

 

패치된 1.7.3.3 버전에서는 create_function 함수를 사용하지 않습니다.

<그림4. 취약점 패치된 코드>

 

패치된 소스를 분석하고 발생한 취약점을 이용하여 exploit code를 작성 하였습니다.

  

<그림5. exploit code 실행 화면>

 

웹쉘을 공격자 서버에서 업로드합니다.

 

<그림6. 웹쉘 업로드 확인>

 

업로드된 경로를 접속하게 되면 웹쉘페이지로 접속할 수 있습니다.

 

<그림7. 웹쉘 실행 확인>

 

 

exploit code와 상세 공격 내역은 문제가 될 요지가 있어 공개하지 않겠습니다.

XE를 사용하는 유저는 해당 취약점을 패치하길 권고합니다.

감사합니다.

 

ps. thanks to indra, maz3

 

 

저작자 표시 비영리 변경 금지
신고

Android Device를 이용한 동적 디버깅

스마트폰 2013.04.26 04:23 Posted by TEAMCR@K

본 문서는 Android APK 파일을 Device에서 동적 디버깅 방법에 대해 작성 하였습니다.

안드로이드 기반 동적 디버깅 환경 구축(emulator): http://teamcrak.tistory.com/342

 

테스트 환경은 아래와 같습니다.

  • OS: Window 7
  • Java version: jdk6
  • APKTools: 1.4.1
  • NetBeans IDE: 7.3
  • APK Sign tool
  • Galaxy S2

APKTool 1.4.1 버전 사용 이슈

APK Tool 1.4.1 이상 버전부터 디버그모드(-d) 일 때 java파일이 생성되지 않아 동적 디버깅을 할 수 없다고 합니다.

http://i5on9i.blogspot.kr/2012/10/smali-apk-debugger.html

 

우선 APKTool 1.4.1 다운로드 합니다.

APKTool 1.4.1: https://android-apktool.googlecode.com/files/apktool1.4.1.tar.bz2

기존 APKTool을 사용하고 있었다면 다음경로의 파일을 삭제해야 에러가 발생하지 않습니다.

C:\Users\<USER_NAME>\apktool\framework\1.apk

다운로드 후 디버깅옵션으로 smali code를 생성합니다.

apktool.bat d –d <file>.apk

[그림1] APKTool 을 이용한 smali code 생성

 

AndroidManifest.xml 파일에서 아래 항목을 추가해줍니다.

Android:debuggable="true" //디버깅 허용

-------------------------------------------------------------------------------------------------------

<intent -filter="-filter">

<action android:name="android.intent.action.MAIN">

// 테스크의 첫 액티비티로 액티비티를 시작한다.

<category android:name="android.intent.category.LAUNCHER">

//액티비티가 어플리케이션의 런처에 표시되고 테스크의 첫 액티비티가 될 수 있다.

</intent>

 

[그림2] AndroidManifest.xml 패치

 

추가 및 패치하기 전 DDMS 화면을 보면 attach 할 수 있는 프로세스가 없습니다.

[그림3] attach 프로세스 유무 확인

 

다시 apktool로 패키징 후 코드사인 합니다.

[그림4] 패치후 리패키징

 

패치 된 APK 설치 전 디바이스에서 환경설정 > 개발자 옵션 > USB디버깅 체크해줍니다.

[그림5] USB 디버깅 모드

 

어플리케이션 설치 후 연결된 디바이스에서 attach 할 수 있는 프로세스를 확인할 수 있습니다.

[그림6] 접근 가능한 프로세스 확인

 

NetBeans 7.3 버전들 다운로드 후 설치합니다.

NetBeans Download: https://netbeans.org/downloads/

NetBeans 설정은 다음과 같이 진행합니다.

[그림7] 새 프로젝트 작성

 

[그림8] 프로젝트 위치 지정

 

APKTool 1.4.1 로 디코딩 한 smali 경로를 설정해 줍니다.

[그림9] smali code 위치 설정

 

[그림10] API Level에 맞춰 라이브러리를 설정

 

[그림11] API Level에 맞춰 라이브러리 추가

 

[그림12] 테스트로 작성된 어플리케이션 실행

 

Debug > Attach Debugger 를 선택합니다.

[그림13] Attach Debugger

 

[그림14] 호스트, 포트 입력

 

Attach 에 성공하면 형광색 아이콘이 생겨 디바이스에서 디버깅을 시작할 수 있습니다.

[그림15] 디버깅 시작

 

지금까지 디버깅 환경 설정을 살펴보았습니다.

이제부터 실제로 디버깅을 시작하기 위해 어플리케이션 실행 시부터 디버깅 할 수 있는 방법에 대해 알아보겠습니다.

디버깅을 어플리케이션이 시작과 동시에 하기 위해서 smali code에서 onCreate 메소드 호출 시 'invoke-static {}, Landroid/os/Debug;->waitForDebugger()V' 를 삽입해 줍니다.

[그림16] 디버깅 대기를 위한 코드패치

 

코드 패치 + 리패키징 + 코드사인 후 어플리케이션을 설치합니다.

어플리케이션을 실행하게 되면 DDMS 에서 붉은색 아이콘이 생성되며 attach 전까지 대기하게 됩니다.

[그림17] 디버깅 대기

 

[그림18] 디버깅 전 화면

 

NETBeans에서 attach 하기 전 ctrl+shift+F8 단축키를 눌러 bp를 설정합니다.

[그림19] break point 설정

 

Attach 시 debugging wait 에서 벗어나 호출된 함수에서 break point 가 걸리게 됩니다.

[그림20] break point 지점 확인

 

[그림21] 라인별로 smali code, java code를 보며 디버깅을 시작

 

[그림22] 어플리케이션 시작

 

버튼 이벤트 발생 시 break point를 설정하여 디버깅 할 수 있습니다.

Ctrl+shift+F8 단축키를 이용하여 break point 지점을 설정합니다.

[그림23] 버튼 이벤트 메소드 확인

 

[그림24] 버튼 이벤트 동작

 

[그림25] 동작 지점 확인

 

[그림26] 디버깅 메뉴를 이용하여 분석

 

이상으로 디바이스에서 APK 동적 디버깅 환경을 살펴 보았습니다.

 

마지막으로 APK 동적 디버깅 순서 정리하면 아래와 같습니다.

  1. APKTool을 이용한 디코딩 (Apktool d –d <file>.apk)
  2. Device 설정(USB디버깅 모드) 및AndroidManifest.xml 수정
  3. MainActivity에 debugging wait 함수 추가
  4. 어플리케이션 리패키징 및 코드사인 후 설치
  5. NETBeans설정 후 호출되는 Method break point 설정
  6. Attach Debug 후 디버깅을 시작

 

 

참고자료

http://d-kovalenko.blogspot.kr/2012/08/breakpoints-in-smali-code.html

http://d-kovalenko.blogspot.kr/2012/08/debugging-smali-code-with-apk-tool-and.html

http://dztall.blogspot.kr/2011/01/blog-post.html

http://i5on9i.blogspot.kr/2012/10/smali-apk-debugger.html

http://code.google.com/p/android-apktool/issues/detail?id=339

 

신고

Creating hashes on the Apple OS X

CR@K 이야기 2013.04.25 18:05 Posted by TEAMCR@K

저희 TeamCR@K 사무실 한 곳에서 조용하게 자리잡고 있는 식구 하나가 있습니다.


이름하야 Mac Pro...



Apple | iPhone 5 | Normal program | Spot | 1/20sec | F/2.4 | 4.1mm | ISO-80 | Flash did not fire | 2013:01:17 15:18:05


한동안 너무 바빠 신경 써 주지 못했던 OS X에게 새로운 역할을 줘 보았습니다.

기존 레인보우 테이블에 해시를 생성하던 일을 OS X에서 해 보려고 하는데요.

해시 생성 코드는 리눅스 기반으로 만들고 테스트 했던지라 BSD 유틸 기반인 OS X에서도 잘 동작하리라 생각합니다.


OS X에서 포팅을 준비하면서 테스트코드 하나를 컴파일 해 봤습니다.


#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>


int main(void)

{

        char buf[1024];


        bzero(buf, sizeof(buf));

        strcpy(buf, "test!\n");

        fprintf(stdout, "%s", buf);

        return 0;

}


컴파일 시도 결과 다음과 같은 메세지를 출력하는군요.



보통 리눅스 시스템에서 사용하는 C컴파일러 명령으로는 gcc가 있는데 유닉스 환경과 호환성을 위해 cc 명령으로 심볼릭 링크를 생성해 놓습니다.

OS X 콘솔 터미널에서 컴파일 테스트를 하던 도중 무의식적으로 cc 명령을 사용했는데 gcc 명령과는 다른 Warning 구문을 출력해 주네요.

cc 명령을 사용한 결과에서 함수 원형이 선언되어 있지 않아 출력되는 경고 구문에 대해서는 일반 gcc 결과와 다를게 없었습니다.

그러나 잘 살펴보면 다음 두 가지에 변화가 있다는 것 을 알 수 있습니다.


1. 소스코드 내에서 함수 원형이 선언되어 있지 않은 함수에 대해 기본 시스템 헤더파일들 중 같은 이름으로 선언된 함수의 원형을 출력


2. note 태그를 사용하여 참조된 기본 시스템 헤더파일 정보를 출력


cc 명령의 결과 형태가 XCode IDE에 활용되는지는 아직 잘 모르겠습니다.

그러나 기본 gcc 경고구문보다는 진일보 된 경고구문이 아닐까 생각해봅니다.


cc 명령 결과 형태에 깜짝놀라 이야기가 잠시 딴 곳으로 샜습니다만..

여차저차해서 컴파일을 마무리 했습니다.


만들어져 있던 레인보우 테이블에서 일반 평문에 비해 해시 데이터가 많이 부족하기 때문에 지금 실행하는 프로그램에서 평문 데이터 저장을 잠시 미루도록 했습니다.



fork()를 사용하여 프로세스 별로 해시 데이터를 생성하도록 했는데 전체적으로 시스템에도 크게 지장을 주지 않는 범위내에서 실행되고 있는 것 같습니다.


오늘부터 OS X는 사무실 한 곳에서 묵묵히 그리고 쉼 없이.. 해시 데이터를 생성하게 되겠네요..

저작자 표시 비영리 변경 금지
신고


 

티스토리 툴바