안드로이드 스튜디오(Android Studio)를 이용한 동적디버깅

1. 디버깅할 APP을 apktool로 디컴파일

2. 디컴파일한 폴더의 AndroidManifest.xml를 열고 <application> 태그 내에 android:debuggable="true" 옵션 추가 후 저장
ex) <application android:icon="@drawable/app_icon" android:debuggable="true" ...
** 일반적으로 앱스토어에서 다운받은 앱은 android:debuggalbe 속성이 존재하지 않거나 false로 처리되어있다.  
→ true인 경우, 앱스토어에 올릴 수 없음


3. 재컴파일 후 디바이스에 설치

4. 디버거 연결 대기 ON  :: 디바이스에서 설정 > 개발자 옵션 > USB 디버깅 ON > 디버깅할 앱 선택 > debuggable 옵션을 준 앱 선택 



6. 안드로이드 스튜디오에 설치한 뒤 재시작 :: File > Settings > Plugins > Install plugin from disk...


7. 안드로이드 스튜디오 실행 시 Open an existing Android Studio project를 클릭하여 디버깅할 앱의 smali 폴더를 지정하여 실행
* android studio를 켰을 때 좌측에 파일들이 보이지 않을 경우 상단의 Android라고 되어 있는 부분을 클릭하여 Project로 선택

8. Run > Edit Configurations > + > Remote 선택하여 나온 탭에서 Settings의 Port를 8700으로 변경 후 저장


9. [Help - Find Action] 클릭 후 monitor 검색 및 실행
* 만약 안켜질 경우 [SDK 설치 폴더 - tools - monitor.bat] 실행
ex) C:\Users\KJY\AppData\Local\Android\Sdk\tools 


10. 진단폰에서 디버깅할 APP 실행 시 디버거 대기 창이 뜨고 이 때 monitor에서 빨간색 디버깅모양이 뜨면 정상

11. 안드로이드 스튜디오 내에서 브레이크 포인트를 건 뒤 Shift+F9를 눌러 디버깅 



JEB2를 이용한 동적디버깅

    1. 위의 1~4과정 진행 혹은 dirtyC0w를 이용하여 디버깅 가능상태 만들기

    2. 디버깅할 앱의 패키지와 액티비티명 확인

    3. 현재 실행중인 애플리케이션 중에서 디버깅 플래그 값을 확일할 수 있게끔 명령어 실행

        adb shell am start -D -n [패키지 이름/액티비티]
                 
    -D : 디버깅 가능하도록 플래그 추가
                 -n : 네이티브 힙메모리 덤프



    4. JEB2에서 디버깅 시작 :: Debugger > Start (혹은 벌레모양 아이콘 클릭)


    5. 디버거에 디버깅할 앱 Attach
    ** 하단의 Suspend all threads 체크한다


    6. 필요한 곳에 break point를 설정하여 디버깅 진행 (Ctrl+b)


    아주 간단한 정규 표현식에 대해 정리한다...
    훨씬 더 많은 방법이 있지만 가장 보편적으로 쓰이는 것만!
    더 필요한게 있을 경우 추가할 예정임..

    \d
    숫자(0-9)
    .
    모든 char (숫자, 글자, 공백, 특수문자 등)
    \. , \?
    . (마침표),  ? (물음표)
    [abc]
    a,b,c
    [^abc]
    a,b,c 제외
    [A-C]
    A~C까지의 글자 검색
    \w
    알파벳 대소문자, 숫자(0-9), 공백 = [A-Za-z0-9_]
    a{3}
    aaa -> a 3번 반복
    a{1,3}
    a가 1번이상 3번 이하 반복
    \d*
    0개 이상의 숫자 (0 or more)
    \d+
    1개 이상의 숫자 (1 or more)
    ?
    선택적 포함
    \s
    빈칸( ), 탭(\t), 줄바꿈(\r), LF(\n)
    ^Mission$
    문장의 시작(^)과 끝($) 
    ()
    그룹 묶을때 -> 묶인 순서대로 그룹 형성
    |
    OR
    \D
    non-digits
    \S
    non-whitespace
    \W
    non-alphanumeric


    참고 URL


    DirtyC0w(더티카우) 취약점 (CVE-2016-5195)

    1. 개요
             1) DirtyC0w (더티카우) 취약점이란?
                : 2016년 10월 CVE-2016-5195 취약점
                : 루트 권한으로도 변경할 수 없었던 default.prop 파일을 익스플로잇을 통해 수정 가능하도록 하는 취약점
                : 디바이스를 재시작하는 경우, default.prop이 초기 설정으로 돌아가기 때문에 다시 수정해주어야함.

    1. 필요성
            1) 안드로이드 apk 파일 동적 디버깅 시, Manifest.xml 파일에 android:debuggable="true"라는 옵션이 있어야 디버깅이 가능하다.
                무결성 검증을 하는 앱의 경우, Manifest.xml 파일만 변경해도 무결성 탐지가 일어나므로 무결성 우회를 하지 않는 이상 디버깅이 불가능하다.
                따라서, 더티카우 취약점을 이용해 default.prop 파일 변경

            2) 매번 Manifest.xml파일을 변경하기 귀찮으므로 수월하게 default.prop 파일 변경


    1. 방법
            ** <안드로이드 애플리케이션 리버스 엔지니어링 - 남대현, 류재형 저>책에 나와 있는대로 시도해 보았지만 
    계속 에러가 나서 익스플로잇 코드로는 실행해보지 못함..ㅠㅠ
                 → 안드로이드 애플리케이션의 기본적인 점검 방법부터 약간의 후킹 방법까지 잘 나와있는 책이므로 추천

             그래서 인터넷 검색 도중 앱으로 쉽게 default.prop을 바꿀 수 있는 방법을 찾아냈당!! (그러면 결론적으로 dirtyC0w 익스플로잇을 한것과 동일해짐)



           

             1)  플레이스토어에서 Root Explorer를 다운받는다.
                 ** 유료 앱이므로 http://ko.apkhere.com/app/com.speedsoftware.rootexplorer 에서 apk를 다운받아 디바이스로 옮기는 것을 추천
                 ** 비슷하게 생긴 Explorer 앱이랑은 다른 기능을 가지고 있으므로 다운 시 유의! 



           2) 앱을 실행시킨 후 default.prop 파일의 ro.debuggable 속성 정보 확인

            → ro.debuggable의 속성값이 1이 되면 디버깅이 가능해짐
            → 처음에는 해당 파일의 권한이 644가 아니라 444로 설정되어있던것 것으로 기억하므로 3)번 과정을 수행해야 파일 수정이 가능할 것이다...
            


           3) 파일 권한 바꾸기 (최소 600)


           4) 이제 default.prop 파일 편집이 가능하다! 편집기로 텍스트를 열고 ro.debuggable=1로 변경하고 저장하면 끝!!!






    2020-01-30 수정

    해당 내용으로 인터넷 검색 도중 과거에 포스팅한 내용이 현재에는 실행이 불가능한 것을 알게되어 수정한다. 


    어느 중국인이 포스팅한 내용이다. 


    #0. mprop 파일 다운로드

    https://github.com/wpvsyou/mprop에 들어가 mprop 파일을 다운받는다. 


    이제 다운받은 mprop 파일을 디바이스에 삽입하고 실행 권한을 준뒤 실행시키면 익스플로잇 코드가 실행되면서 ro.debuggable이 0에서 1로 변경된다. 


    #1. 현재 설정값 확인

    일단 getprop ro.debuggable 명령어를 통해 현재 값을 확인한다.

       ※ 익스플로잇 전에는 설정값이 0임


    #2. mprop 파일 기기에 설치 후 권한 변경

    > adb push mprop /data/local/tmp     //mprop 파일 기기로 이동

    > adb shell    // adb 연결


    shell@b1:/$ su   // 루트 접근

    root@b1:/# chmod 777 /data/local/tmp/mprop     // mprop 권한 변경


    root@b1:/# cd /data/local/tmp              // 현재 위치 이동

    root@b1:/# ./mprop ro.debuggable 1     // mprop 실행


    mprop 실행 시 익스플로잇이 실행되면서 다음과 같은 결과를 출력하며 끝난다. 

    이 때, patched ~ 이부분이 뜨지 않는 경우 마지막 명령어를 다시한번 실행시켜준다.


    0001ffa0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

    0001ffb0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

    0001ffc0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

    0001ffd0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

    0001ffe0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

    0001fff0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

    patching it at:0xb6e81904[0xb6f388fc], value:[0x00000030 -> 0x00000031]

    patching it at:0xb6e81900[0xb6f388f8], value:[0x01000000 -> 0x01000000]

    patched, reread: [0xb6f388fc] => 0x00000031

    patched, reread: [0xb6f388f8] => 0x01000000


    #3. 변경된 설정값 확인

    이제 ro.debuggable 값이 1로 변경된 것을 확인할 수 있을 것이다!!

    하지만 이전에 설명한 root explorer로 default.prop 파일을 확인하면 값이 변하지 않았으므로 getprop ro.debuggable 명령어로 꼭 확인할것!!


    그리고 디바이스를 재실행하면 해당 값도 다시 0으로 초기화되므로 주의하자



    더 자세한 설명은 https://www.bodkin.ren/index.php/archives/533/ 참조.....(중국어임.....)


    안드로이드 취약점 점검 시 자주 사용하거나 알아두면 유용한 adb 명령어에 대해 정리할 예정이다!

    먼저 adb가 무엇인지부터 짚고 넘어가자.

    adb란?

    : Android Debug Bridge의 약자로서 명령줄 도구
    : 앱 개발자가 데스크톱 컴퓨터를 사용해 연결된 Android 디바이스와 통신하거나 디바이스 애뮬레이터를 실행할 수 있도록 도와주는 도구
    : 안드로이드 취약점 점검 시에는 루트 권한으로 명령어를 사용하기 위해 루팅된 폰에서 많이 사용한다.


    adb 명령어

    아직 adb를 사용해 본적이 없다면 이전 포스팅에 설명한 설정과정부터 진행하고 와야한다.

    지난번 포스팅에서도 설명했던 명령어도 포함하여 설명한다.

    1. 연결된 device 목록 확인

          adb devices 

    1. 연결된 디바이스의 리모트 쉘 실행

    1)  adb shell 

    한개의 디바이스나 애뮬레이터가 연결되어 있으면 기본 명령어로 실행이 가능하지만 1개이상이면 실행이 불가능하다.
    (LG로 시작하는 기기는 usb 연결 단말기이고, 127.0.0.1은 녹스 실행한 가상 에뮬레이터이다. )

    따라서, 옵션 -d (usb 연결 단말기)나 -e (녹스 등의 가상에뮬레이터)를 사용해서 연결해야한다.

    2) adb -d shell → usb 단말기 연결


    3) adb -e shell → 가상 에뮬레이터 연결


    ** 이 때도, 둘 이상의 에뮬레이터가 연결되어 있으면 에러를 반환하므로 주의한다.

    1. adb 버전 확인

         adb version 
        

        



    1. 연결된 장치에 apk 파일을 설치하는 명령어 
         adb install [apk파일경로\파일명] 



      5.  로컬 컴퓨터에 존재하는 파일을 디바이스로 복사하는 명령어

         adb push [로컬파일 경로] [디바이스경로] 






      6. 디바이스에 존재하는 파일을 로컬 컴퓨터로 복사하는 명령어


          adb pull [디바이스 경로] [로컬컴퓨터 경로] 




    7. 디바이스에 존재하는 애플리케이션(apk)의 저장 경로 확인

          adb pm list packages -f | grep [패키지명] 


    녹스로 가상 디바이스 사용 시 adb devices에서 녹스를 인식하지 못한다.

    그래서 따로 명령어를 입력해야 연결가능!


    • NOX adb 연결

            adb connect 127.0.0.1:62001 

    • NOX adb 연결 확인

            adb devices 



    JADX

    : 이전 포스팅에서 설명한 jd-gui와 동일하게 java 디컴파일러
        ** 하지만 jd-gui 보다 디컴파일 결과가 좋고, dex2jar를 사용하지 않고도 디컴파일이 가능하여 더 많이 사용

    다운로드 경로: https://github.com/skylot/jadx

    1) jadx-gui.jar 파일 실행 


    2) 디컴파일하고자 하는 apk 파일을 가져오면 디컴파일 끝!


    JEB2

    : java 디컴파일러

    JEB는 상용화툴이라 앞서 설명한 두개의 디컴파일러보다 조금 더 기능도 많고 디컴파일 결과가 젤 좋다. 
    다음에 설명할 동적 디버깅 또한 지원하는 툴로 모바일 애플리케이션 분석 시 가장 많이 사용하는 디컴파일러이다.

    (해당 경로에서는 Free trial만 제공한다)

    1) jeb.exe 실행



    2) 디컴파일하고자 하는 apk 파일을 가져오기 후 Bytecode 선택 (smali 코드 추출)


    3) 커서를 해당 페이지에 놓고 q를 눌러 디컴파일 끝~!




    dex2jar

    : APK 파일은 안에 classes.dex라는 파일이 있는데 이 파일을 Android Dalvik이 인식할 수 있도록 class 파일을 바이트 코드로 변환하는 툴


    1) apk 파일의 압축을 푼다.



    2) 압축을 푼 classes.dex파일을 d2j-dex2jar.bat이 위치한 폴더로 이동시킨다.

    3) cmd를 열고 다음 명령어를 실행하여 dex파일을 jar파일로 변환한다.


    4) 해당 폴더 내 jar 파일이 위치하는 것 확인


    5) jar파일의 내용을 확인하려 하지만 깨져서 확인 불가ㅠㅠ



    이때 사용하는 것이 다음의 jd-gui 툴이다!


    JD-GUI

    : 자바 디컴파일러로 위에서 dex2jar로 추출해낸 jar파일을 디컴파일해 주는 툴

        ** 하지만 디컴파일이 완벽하게 100% 가능한 것이 아니므로 참고하장...ㅠㅠ

    다운로드 경로: http://jd.benow.ca/

    1) 다운받은 jd-gui.exe 실행


    2) 디컴파일할 jar 파일 가져오기



    APK-Manager Fix 7.4 (APK 디컴파일 / 컴파일 도구)

    : apk 파일을 디컴파일 및 재 컴파일 등을 할 수 있는 툴

    • 최신버전을 다운받을 수 있다면 최신 버전 추천
    • 압축파일을 다운로드 받으면 다음 그림과 같이 여러 폴더와 cmd 파일이 존재한다.
    • cmd 파일을 실행시키면 apktool을 간편하게 사용할 수 있다.


    • 자주 사용하는 기능 및 사용 방법
      • 9 : Decompile APK
      • 14 : Compile APK / Sign APK / Install APK (All in one step)

    ** 앱은 TeamSIK의 CTF 연습 문제인 app-easy-release.apk를 사용 

    1) 앱을 컴퓨터로 추출한다. (adb pull 또는 ASTRO 앱 사용)
                        - adb pull <apk 파일 위치 경로>
                        - 단말기에 설치된 앱 추출 시 ASTRO 앱 사용하면 편리함
                            → 앱 실행 > 앱 > 앱 오른쪽 상단의 메뉴 > 백업 
                            →  컴퓨터에 단말기 연결 후 backups > apps > 해당앱

                2) 추출한 앱(apk파일)을 "place-apk-here-for-modding" 폴더로 이동시킨다. 

                3) script.cmd를 실행시킨 후 22. Set current Project 입력


     4) 디컴파일하려는 앱(apk파일) 번호 입력


              5) 9. Decompile APK 입력하여 디컴파일

              6) Projects 폴더에서 디컴파일된 apk파일 확인

          


            7) 코드 수정 후  14. Compile apk / Sign apk / Install apk 를 입력하면 한번에 컴파일, 서명, 설치까지 가능하다. 
                ** 11. Compile APK로 컴파일 후, 12. Sign APK로 서명, 13. install APK로 단말기에 설치 각각 진행 가능\
                ** 서명까지 완료된 apk 파일은 "plcae-apk-here-for-modding" 폴더에 "signed[본래 파일명]"으로 저장된다.




    apktool.jar

    위의 방법이 훨씬 더 간단하므로 cmd툴을 이용하는 것을 추천하지만 apktool.jar 명령어에 대해서도 설명한다. 

    https://ibotpeaches.github.io/Apktool/에서 최신 버전의 apktool을 다운로드 받은 후 진행하자.


    1) 다운로드 받은 apktool.jar 파일이 위치한 경로에서 cmd를 실행시킨다.

           java -jar apktool.jar 
            


    2) 디컴파일
        
          java -jar apktool d [apk파일 경로] 



    3) 파일 수정 후 재 컴파일

         java -jar apktool b [디컴파일한 소스 폴더] -o [저장할 apk 명] 





    4) 단말기에 설치하기 전에 서명을 해줘야 제대로 동작한다. 이때 APK Easy Tool을 사용하면 편리하다.

        [select] 클릭 후, 재 컴파일한 apk파일 선택 > sign selected APK 








    안드로이드 APK 취약점 점검 환경 구성

    안드로이드 APK 취약점 점검을 하려면 일단 내 호스트 PC에 환경 설정을 해야한다. 

    1. 안드로이드폰을 루팅
                일단, 대부분의 취약점 점검이 루팅된 환경에서 진행되므로 안드로이드폰을 루팅해야한다. 

                - 루팅 방법에 대해서는 가지고 있는 핸드폰의 안드로이드 버전 및 비트(32/64bit)를 확인 후에 진행하도록 한다. 
                - 검색하면 루팅툴들이 많이 존재하므로 각 핸드폰에 맞는 툴을 이용하는 것을 추천
                - 나는 KingRoot라는 앱을 이용해서 루팅을 진행했는데 여전히 많이 사용하고 있는 툴인것 같다. 
          • 루팅 확인 :  플레이 스토어에 검색하면 여러 툴이 나오므로 다운로드 후 사용 

    1. 단말기 제조사 드라이브 설치
                단말기를 컴퓨터에 제대로 연결하기 위해 각 제조사의 통합 드라이버를 설치한다.
                ex) LG USB 통합 드라이버, SAMSUNG 통합 드라이버 등...

      3. Android SDK 설치
                이클립스, 안드로이드 스튜디오 등 여러 SDK 툴이 존재하지만 안드로이드 스튜디오 설치시 추후에 필요한 
                개별 실행파일, adb 등이 같이 설치되므로 안드로이드 스튜디오를 추천
                
                - 자세한 설치 과정은 설명하지 않는다.

    1. adb 환경변수 설정
                단말기를 PC에 연결하기 위해서 SDK의 adb라는 프로그램이 사용된다.

                1) 안드로이드 SDK 설치  경로에 platform-tools폴더 내 adb.exe파일이 있는 것을 확인 후 해당 경로 복사
                    ex) C:\Users\Users\AppData\Local\Android\Sdk\platform-tools
                2) 위의 경로를 환경변수의 Path에 저장
                3) cmd 창 열고 "adb" 명령어 실행 시 정상 실행 확인

      5.  단말기 개발자 옵션 및 디버깅모드 켜기
                해당 설정을 하지 않으면 adb shell로 PC에 연결이 불가능하다.

                - 환경설정 > 개발자 옵션 켜기 > USB 디버깅 체크
                    ** 개발자 옵션이 없는 경우, 디바이스 정보 > 소프트웨어 정보 > 빌드 번호를 7번 터치하면 생성됨

                



                
           6. 단말기와 PC 연결 및 확인
               이제 USB 케이블을 이용하여 단말기와 PC를 연결한다.
               
                - USB 케이블이 정상적으로 연결되면 "USB 디버깅을 허용할까요?" 라는 경고창이 뜨는데 [확인]을 클릭한다.
                - 이제 cmd창을 켜서 adb 명령어를 실행한다.
                


                ** adb devices :  연결된 device 목록 확인
                ** adb shell : 연결된 디바이스의 리모트 쉘 실행
                ** adb 명령어에 대해서는 추후 포스팅할 예정임.




    참고 URL

    1.1. XML이란? 

    - Extensible Markup Language의 약자
    - 다목적 마크업 언어로 인터넷에 연결된 시스템끼리 데이터를 쉽게 주고 받을 수 있게 하기 위해 사용
    - 데이터를 저장하고 전달하는 목적으로 사용 (데이터를 보여주는 목적 X
    - 태그가 미리 정의되어 있지않고, 사용자가 직접 정의 가능
    - 종료 태그가 반드시 포함되어야함 → 생략 시 에러
    - 태그 사용 시 대소문자, 띄어쓰기 구별
    - 속성값은 반드시 따옴표로 구별

    1.2. XPath란? 

    - XML Path Language의 약자
    - XML 문서의 특정 요소나 속성에 접근하기 위한 경로를 지정하는 언어
    - XML 문서를 탐색하기 위해 경로 표현식(path expression) 사용
    - 절대경로(/로 시작하며 루트 노드부터 탐색)와 상대경로(기준으로 지정되는 노드부터 탐색)로 나타냄


    2. XPATH(XML Path Language) Injection

    2.1. XPATH Injection이란?  

    - SQL Injection과 비슷하지만 서버에 XPATH 쿼리를 조작하여 요청 후 로그인 우회 및 데이터 추출 등이 가능한 취약점
    - form 필드나 URL 파라미터에 인젝션 시도
    - XML 기반의 인증 시스템이 구현된 경우, 인증 우회가 가능

    2.2. 공격방법 

    다음의 users.xml을 기반으로 로그인 처리가 된다고 가정하자. 
    [users.xml]
    <?xml version="1.0" encoding="UTF-8"?>
    <users>
        <user>
            <username>admin</username>
            <password>admin123</password>
            <role>admin</role>
        </user>
        <user>
                    <username>testest</username>
                    <password>testest123</password>
                    <role>guest</role>
            </user>
    </users>

    정상적으로 admin으로 로그인할 경우, XPath 쿼리는 다음과 같으며,  role에 들어있는 값을 반환한다.

    string(//user[username/text()='admin' and password/text()='admin123']/role/text())

    이 때, 사용자 입력값을 적절하게 필터링하지 않는 경우, SQL Injection과 동일하게  username과 password 입력창에 ' or '1'='1을 입력하면 Xpath Injection이 가능하다. 
    공격 시 완성되는 쿼리문은 다음과 같다.

    string(//user[username/text()='' or '1'='1' and password/text()='' or '1'='1']/role/text())

    위의 쿼리는 결과값이 항상 참이므로 로그인 우회가 가능하다. 


    2.3. 대응 방안 

    - SQL Injection과 동일하게 방어 (싱글쿼터('), 더블쿼터(") 등의 특수 문자 필터링)


    3. XXE(XML External Entities) Injection

    3.1. XXE Injection이란?  

    - Server-side Request Forgery(SSRF)의 일종
    - XML의 DTD (Document Type Definition)를 조작하여 가능 
                         ** DTD : 문서의 구조 및 해당 문서에서 사용할 수 있는 적법한 요소와 속성을 정의
                                       XML 문서 하나에 오직 1개의 DTD만 존재 가능
    - XML 문서의 외부참조 기능을 이용하여 서버의 중요정보 파일을 가져오거나, 오픈포트 등을 확인하는 공격


    3.2. 공격방법

        3.2.1. 환경 구성

    [xxe.php]
    <html>
    <body>
    <meta charset='utf-8'/>
    <php?
        $xml=$_POST['xml'];
        if($xml){
            $doc = simplexml_load_string($xml);
        }
    ?>
        <form method="post">
            <textarea name="xml" rows="12" cols="100">
    <?
        echo $xml;
    ?>
        </textarea>
            <input type="submit">
        </form>
    <?
        echo $doc;
    ?>
    </body>
    </html>

        3.2.2. DTD 변경 시도




        3.2.3 SYSTEM 함수 이용한 로컬파일 읽기
    • SYSTEM 함수 - 외부 문서를 불러올 수 있는 기능 제공
             



    3.3. XXE Injection의 한계 

    - DTD 선언이 가능해야 함
    - 불러오는 외부 리소스가 DTD 문법에 어긋나지 않아야 함
    - Binary 파일 불러오기 불가 
    - 파일 불러오기의 경우, 서버 구동 사용자((예) apache, nobody 등)가 해당 파일에 대한 읽기(r)권한이 있어야 불러오기가 가능함

    3.4. 대응 방안 

    - 근본적인 해경방안으로는 entity 기능을 비활성화
    - 안전한 함수 사용(PHP 기준)::
    -> libxml_use_internal_errors(true) : XML 파싱 도중 오류가 발생했을 경우, 오류 메시지 출력을 하지 않게 막아주는 함수
    -> libxml_disable_entity_loader(true) : 외부 리소스를 불러오지 못하게 하는 함수



    + Recent posts