우리은행 + Eversafe == NULL

이하 포스팅은 Eversafe의 동적 모듈이 작동하지 않는 상태에서 분석한 글 입니다. 자세한 상황은 글 말미를 확인하시기 바랍니다.
(2017-08-10 08:57AM KST 추가)


 

이번 포스팅은 얼마전에 페이스북에서 불평을 토로했던 글의 확장판이다. 해당 글과 이번 글은 개인적인 생각임을 알린다.

글의 흥미를 위해 학생 시절 국어시간에 배운 5단 구성을 통해 이번 주제를 알아보도록 하자.

발단

사건의 발단은 생각보다 간단하다. 지인이 대화방에 올린 기사 링크를 보고 ‘이건 무슨 신종 사기지?’ 라는 생각이 들었다. 보안 필드에서, 아니, 어느 필드에서든 수학적인 증명을 통해 보이지 않는다면 100% 라는 수치는 사실상 숫자놀이에 불과하고 거짓이라는것은 기정사실이다. 하지만 특히 보안에서는 100%와 아닌것은 매우 큰 의미적 차이를 나타내기 때문에 정말 조심해서 사용하지 않으면 안되는 표현 중 하나이다. 또 보안에서 금기시 되는 단어 중 하나는 “절대” 인데, 이 기사는 무려 두 가지를 다 사용함으로써 어그로를 끄는데 성공했다.

그래도 일단 뭔지 알기도 전부터 욕부터 하면 나쁜사람이라고 배웠으니, “benefit of the doubt“을 줘보기로 하고 해당 솔루션 제작사 웹사이트를 방문했다.

무려 “세계 최초” 다이내믹 시큐리티 테크놀로지!

나는 원래 기술력이나 솔루션에 대해서 소위 “뻥카” 치는걸 별로 안좋아하는데, 그 이유는 해당 기술이나 연구에 대한 지식이 충분하지 않은 사람들이 들었을때 너무나 쉽게 현혹될 수 있기 때문이다 — 그리고 이 부분은 실제로 해당 기술/연구를 제대로 하는 사람들에게 불이익을 준다. 그냥 친구들끼리 장난으로 자랑하는것의 일환이라면 큰 상관이 없지만, 이게 국가에서 지원하는 펀드 프로그램이라던가 투자자가 투자하는 회사라면 사기가 된다. 물론, 마케팅에서는 “절대” “100%” 등과 같은 자극적인 표현을 사용했지만웹사이트 자체에는 그런 말이 없으므로 사기보다는 과대포장이라고 표현하는게 맞을 수 있겠다. (투자자 앞 발표에서는 어떻게 피치했는지는 알 수 없지만, 이런 심심한 기술로 투자를 꽤나 받은걸로 봐서는 영업을 하는 사람이 말을 정말 잘하나보다. 부럽다.)

다시 본론으로 돌아와서, Everspin이라는 이 회사에서 제공하는 보안 솔루션은 크게 4가지 종류가 있다. 그 중에서 우리가 오늘 살펴볼 녀석은 첫번째로 소개된 Eversafe이다. 어플리케이션을 공급할 때 보통은 컴파일 된 코드들과 리소스 등을 정적으로 패키징해서 배포를 하기 때문에 공격자가 보안 모듈 등을 분석하기가 쉽고 그에 따라 우회 또는 2차 공격을 진행할 수 있다는 데에서 착안한 컨셉이다. “다이내믹” “사용 후 폐기” “일정 시간마다 변경” 등의 말들로 열심히 꾸며보고 있지만, 사실 이 컨셉은 이미 예전부터 알려져 있던 Moving Target Defense (MTD)의 일종이다. 이 회사보다 몇 년은 더 일찍 관련 솔루션을 개발해온 업체들이 꽤나 있지만, 굳이 나열하진 않겠다. 구글 검색해보면 금방 나온다. (심지어 필자는 2013년 즈음 작업한 binary re-writing을 통한 런타임/동적 프로그램 보호 기법에 대한 특허도 가지고 있다.)

MTD는 다양한 레이어에서 시도할 수 있는데, 네트워크 단에서 적용하여 네트워크의 topology 또는 IP/MAC 주소 등을 수시로 변경하여 공격자가 항상 같은 패턴이나 타겟을 공격하기 어렵게 만들 수 있고, 바이너리/프로그램 단에서 적용하여 basic block re-ordering, runtime control flow mixing, instruction replacement 등 기존의 기능을 유지하되 여기저기 랜덤 요소를 주어 공격자가 이전에 노렸던 정적 타겟을 공격하기 어렵게 만드는 (cost를 높이는) 보안 기법이다.

자, 이제 세계 최초 타이틀은 아니라는걸 친절하게 설명해주었으니 실제로 어떻게 구현을 했는지, 정말 보안적으로 의미가 있는지를 확인해보자!

 

전개

일단 Eversafe를 분석하기 위해서는 적용된 앱을 찾아야 했다. 다행히도 어렵지 않게 찾을 수 있었는데, 위의 기사를 보면 다음과 같이 설명한다.

에버세이프는 사용자 정보를 보호해야 할 필요성이 있는 모든 서비스에 활용할 수 있다. […] 현재 우리은행이 에버세이프를 보안 앱으로 사용하고 있으며 연내 은행 3곳이 추가로 에버세이프를 사용할 예정이라고 한다. […] 에버스핀은 앞으로 공공 부분 솔루션 공급을 시작으로 금융권으로 공급을 확대할 계획이다.

오호라. 우리은행이 사용하나보다. 난 우리은행 고객은 아니지만 테스트용 안드로이드 폰은 가진 사람이다 (후후). 우리은행의 “원터치개인” 앱을 다운로드 받고 추출해서 열어봤다.

  
오. 정말로 Eversafe가 들어가 있다! 하지만 뭔가 보안 모듈 치고는 규모가 엄청 작다. 이럴때 다음으로 봐야할 곳은 native library 들이다. 역시 리버싱을 조금 귀찮게 하기 위하여 JNI를 사용한 전형적인 모습이다. 그래도 괜찮다, 우리에겐 IDA Pro가 있기 때문이다.

큰 구조를 파악하기 위해서 우선 apk안에 있는 kr.co.everspin.eversafe 패키지 클래스들을 살펴보기로 하자.

Eversafe

이 클래스는 거의 그냥 wrapper로 봐도 무방한데, 보다시피 constructor에서 몇 가지 멤버 변수들을 셋업해준 후 loadLibrary를 통해서 JNI 컴포넌트인 libeversafe.so를 로딩한다.

또한, 나중에 EversafeHelper 객체가 초기화될 때 호출되는 freeze 메소드에서는 eversafeJni 멤버 변수를 libeversafe.so JNI 모듈에서 expose하고 있는 loadJni 함수를 호출한 결과값으로 저장한다. 알아두어야 할 것은 이제 자바에서 이 eversafeJni 객체를 통해서 native library에서 declare한 메소드들을 호출 할 수 있다는 점이다. register, launch, relaunch, setSharedData, getSharedData, option 등과 같은 메소드인데, 우리 입장에서는 그다지 흥미로운 메소드들은 아니다.

     

EversafeHelper

Eversafe 클래스보다 훨씬 코드가 많고 흥미로운 기능들이 구현되어 있는 부분을 가진 EversafeHelper 클래스다. 현재 Eversafe의 상태나 intent 등을 통해 받은 메세지들을 처리해주는 코드가 들어있다. 후반에 다시 이야기 하겠지만, Eversafe에서 “안티바이러스” 역할을 하는 부분도 있기 때문에 기기 내에 위협 요소가 발견되면 해당 정보를 저장하는 코드 또한 포함되어 있다. 이 역시 그냥 앱의 정상 행동을 위한 코드들이 대부분이므로 우리의 관심사와는 크게 상관이 없다.

여기서 우리가 짚고 넘어가야할 부분은 EversafeHelper의 초기화 코드인 initialize 메소드다. 보다시피 위에서 언급한 Eversafe 객체의 freeze 메소드를 호출하고, 몇 가지 멤버 변수들을 셋업해준다. 그 중 하나는 registrationCodebaseUrl인데, 웹사이트에 설명된 대로라면 서버에서 일정 시간마다 어떤 새로운 모듈을 받아오거나 할 것이므로 이 두 변수는 중요해보이니 기억해두도록 하자.

이를 확인하기 위해 간단한 스크립트를 만들어서 앱 내에서의 완성된 baseUrl에 어떤 값이 들어가 있는지, 그리고 앱에서 이것저것 클릭했을 때 어떤 URL 등을 참조하는지를 확인해보았다.

보다시피 baseURL은 https://appsec.wooribank.com:4443/eversafe/6d7d2a5a-d288-e9fa-b6fe-94185e611030 이고, 어느 시점에서 /auth 경로를 요청하는것을 볼 수 있다. 자 그럼 여기서 UUID처럼 생긴 저 헥스 값들은 무엇일까? 위의 코드를 살펴보면 쉽게 알 수 있는데, 바로 registrationCode다. 이 코드는 RegistrationCode라는 클래스 객체를 통해 생성된다. 그렇다면 이 클래스의 생성자는 어떻게 생겼을까.

위의 스크린샷에는 살짝 짤렸지만, registration code가 생성되는 규칙은 다음과 같다. 인자로 들어온 고유값 (organization id?)을 이용하며, “<고유값>,<패키지 versionName>(<패키지 versionCode>)”으로 만들어진 스트링을 MD5 해쉬한 헥스 값을, 8자리-4자리-4자리-4자리-12자리로 나눈다.

우리은행 앱의 MainActivity에서 초기화를 하며 Eversafe 객체들도 초기화를 하는데, 여기를 살펴보면 EverSafeHelperinitialize 메소드를 호출할 때 들어오는 인자, 즉 RegistrationCode 생성자에 들어가는 고유값을 알 수 있게 된다. 여기서 사용되는 값은 “718E31DA0ED73B0B” 이다.

결과적으로 MD5 해쉬되는 스트링은 “718E31DA0ED73B0B,1.4.8(148)”이 되고, 이 문자열의 MD5 값은 “6d7d2a5ad288e9fab6fe94185e611030″이다. 위의 스크린샷 URL에서 보았던 “6d7d2a5a-d288-e9fa-b6fe-94185e611030″와 매칭한다는 것을 알 수 있다. 이걸 통해서 특정 패키지 버전이나 기관에 맞는 모듈을 다운받아서 실행하는가 보다 (라고 생각했지만, 나중에 더 큰 충격과 공포를 맛보게 된다).

libeversafe.so를 더 살펴보면 위와 같이 특정 jar파일을 DexClassLoader 클래스의 loadClass를 사용해서 동적으로 로드한다는 것을 알 수 있다. 이정도로 파악을 하고, 실제 기기에서 해당 파일들을 찾아보기로 하자. 아래의 “%s/.eversafe-%s”라는 스트링이 파일 시스템 내에 hidden directory로 존재한다는 힌트를 주고 있다.

 

위기

우선, 아직 살펴보지 않은 용량이 1.14MB로 다른것들에 비해 꽤나 큰 native library인 libeversafe-loader.so를 살펴보려고 했지만, 다음과 같은 에러를 볼 수 있었다.

보통 ELF 헤더가 corrupt되었을 때 뜨는 에러인데, 그래서 의아한 채로 헥스 에디터로 열어서 확인해 보았다.

보다시피 처음 16바이트 정도의 헤더만 빼고는 뭔가 랜덤해 보이는 데이터들이 가득 차있다. 바이트 별 히스토그램을 추출해봐도 전반적으로 골고루 분포된 것을 발견할 수 있는데, 이런 경우는 보통 압축이 되어있거나 암호화가 되어있을 때다. 그렇다. 용량도 큰 것이 조금 중요해 보인다 싶었던 libeversafe-loader.so 녀석은 암호화가 되어있었다. 위 스크린샷에서는 안보이지만 NULL-byte가 많이 포함된 부분에서는 동일한 “패턴”이 있었는데, 이런 경우는 ECB모드로 암호화를 했을 확률이 크다.

일단 그럼 넘어가기로 하고… 실제 기기에서 단서를 찾아보자!

예상했던대로 우리은행 앱의 데이터 캐시 디렉토리에 .eversafe-{ANDROID_ID} 디렉토리가 존재한다. 하지만 안을 들여다봤지만 아무것도 찾을 수 없었다고 한다 ㅠㅠ

또 시스템에서 얻을 수 있는 단서로는 현재 실행되고 있는 앱의 메모리 맵이 있는데, 특히 loadLibraryDexClassLoader 등으로 동적 로딩이 된 녀석들을 발견할 수 있다.

보다시피 우리가 좀전에 확인했던 디렉토리에 존재했던 파일들을 로드해둔 흔적이 보인다. 각 파일 이름 옆에 (deleted) 라고 뜬 것이 마치 놀리는것 같다. 이대로 끝인건가!

 

절정

당연히 아니다. 후후. 우리가 누구인가. 한 번 물으면 끝을 봐야하는 끈기있는 해커니까 더 분석해보도록 한다.

우선 클라우드에서 그때그때 필요한 모듈 (위 스크린샷에서의 UUID로 된 파일과 dex 파일)들을 받아온다는 가정하에 Man-in-the-Middle (MitM; 중간자 공격)을 시도했다.

어라? 우리가 앞서 봤듯이 https://appsec.wooribank.com:4443/eversafe/6d7d2a5a-d288-e9fa-b6fe-94185e611030/auth에 리퀘스트를 보내긴 하지만, 서버는 503 에러를 보내올 뿐이다..  열심히 내 폰의 정보를 던져주었는데도 서비스를 하지 않는다니!! 아주 건방진 서버다. 그리고 이후에도 계속된 /auth 리퀘스트의 실패만 나타날 뿐 모듈을 다운받거나 하는 정황을 포착할 수 없었다.

혼란에 빠진 나는 다시 코드를 읽기로 마음을 먹었고, 오래 걸리지 않아 동적 로딩된 파일이 어떻게 마법처럼 파일시스템에 생겼다가 사라지는지 알아냈다.

내가 혼란에 빠진 이유는 “클라우드에서 매번 다른 모듈을 받아오겠지”라는 아주 정상적이지만(?) 잘못된 가정을 세우고 있었기 때문이다. 적어도 우리은행 앱에 적용된 Eversafe는 서버와 전혀 교류없이 자체적으로 해당 파일들을 “만들어”낸다. (네?)

코드가 아름다운 이유는, 코드는 절대 거짓말을 하지 않기 때문이다. 이전에 읽다가 간과한 부분이었던 위의 코드를 보자.

이 코드와 앞서 봤던 메모리 맵에 나온 파일명들을 보면 무슨일이 있었는지 유추가 가능해진다. 어떤 jar파일의 경로를 만들어내고 있는데, 그 인자로 gettimeofday의 결과값이 사용된다. 정확히는 tv_sectv_usec의 값을 헥스로 표기한 값이 합쳐진 문자열을 파일명으로 사용하는데, 앞서 본 파일명을 예제로 들어보면 5987096917940 에서 tv_sec에 해당하는 0x59870969는 UTC로 2017년 8월 6일 12시 19분 53초를 나타내고 tv_usec에 해당하는 0x17940은  96575 마이크로 초를 나타낸다. 지금 글을 쓰는게 8월 7일이니까 대충 맞아 떨어진다. 즉, 파일이 생성된 시간으로 jar 파일명을 만든다는 것이다.

그러면 더 중요한 질문은.. 여기서 만들어지는 jar 파일은 어디에서 내용을 가져오는가 이다. 답은 역시 이 바이너리안에 있었다.

위의 코드는 .data 섹션에 embed 되어있는 jar 파일 내용을 읽어와서 방금 만든 파일 경로에 쓴 다음, DexClassLoader를 이용하여 로딩하고 (이 과정에서 메모리 맵에서 본 것 처럼 하위폴더와 dex파일이 생성된다), 해당 파일들을 파일시스템에서 지워버린다 (unlink). 즉, 이 말은 해당 jar파일은 매번 static 하다는 말이다 — 파일명만 달라질뿐…

자, 새로운 파일을 GET 했으니 들뜬 마음으로 열어보자!

네? 이게 전부라구요?

뭔가.. 또 많이 없어보인다. 이전에 보이지 않던 antivirus 관련 클래스들이 조금 추가 되었지만, 사실상 로직은 안들어있는것 같다. 눈에 띄는것은 HttpClient 클래스와 Crypto 클래스다. 하지만 따로 HTTP 통신은 딱히 하지 않는다는것을 이전 실험을 통해 알았으므로,  HttpClient는 그다지 흥미롭지 않으나 Crypto는 필시 libeversafe-loader.so의 복호화를 하는데 사용될 것이다!

위는 새롭게 추출한 jar 파일의 Eversafe 클래스의 loadJni 메소드다. 하는일은 매우 단순한데,  lib/ 디렉토리에 있는 libeversafe-loader.so 파일을 열고,  cache/.eversafe-{ANDROID_ID}/{PID}/{RANDOM_UUID} 파일 경로를 만들어낸 후, 암호화되어 있는 loader.so를 랜덤 UUID 파일에 복호화한다. 복호화가 끝난 후에는 System.load를 통하여 해당 라이브러리를 동적 로드한다. 마지막으로, 해당 파일 및 관련된 디렉토리를 삭제한다.

복호화 코드는 더더욱 간단하다. DES 알고리즘을 사용하며, 앞서 우리가 예측했던대로 ECB모드를 통해 암/복호화 하고 패딩은 PKCS5을 사용한다. DES는 symmetric 암호 알고리즘이기 때문에 고정키를 사용한다. 위에서 보는바와 같이 “0E329232EA6D0D73″가 암호키다. 다만, 파일 그자체를 통째로 복호화하면 안되고, 앞에 있는 fake ELF헤더인 16바이트를 제거해준 후 복호화 하면 된다.

위와 같은 간단한 스크립트로 복호화가 가능하다.

이제 모든 미스테리(?)가 풀렸다. 정리해보면 Eversafe의 전체적인 동적 로딩 플로우는 다음과 같다.

우리은행 앱 시작 => libeversafe.so 로드 => library에 임베드 된 jar 파일 생성 및 로드 => libeversafe-loader.so 복호화 및 로드

 

마지막으로 얻은 아이템인 “복호화 된 libeversafe-loader.so”는 사실상 libeversafe.so의 상위집합 개념으로 볼 수 있다. 대신, OpenSSL library 등이 static link 되어있는 등 규모는 앞서 말한대로 훨씬 크다. 실제로 네트워크 주소 스크랩핑이라던가 루팅된 폰 감지 기능 등이 구현되어 있다.

모든 루팅 “공격”에 100% 방어했다!!!

 

결말

이번 분석 결과는 개인적으로는 매우 실망적이었다. 뭔가 동적으로 로딩되고 보안모듈도 매번 새롭게 컴파일 되거나 하는 fancy한 기술이 사용될 줄 알았는데 그런 기술은 단 어디에도 찾아볼 수 없었다. 실제로 안드로이드 앱에 물려서 문제를 일으키지 않고 “기생하며 작동하는”걸 하기 위한 코드가 70% 정도 되는거 같고, 에러 처리라던가 로깅하는 코드가 20% 정도.. 나머지 실제로 보안에 1이라도 관련이 있는 부분은 정말 5%도 안된다는 생각이다.

웹사이트나 기사에서 언급했던 5-10분 주기마다 바뀐다는 말도 (내가 실험을 어떻게 잘못한건지도 모르겠지만) 3시간 이상 침착하게 기다렸음에도 불구하고 전혀 바뀌지 않고 그대로였다.

Eversafe의 “antivirus”에서 하는 백신 기능을 우회하는것은 솔직히 helloworld 프로그램을 작성하는거보다 쉽고 (실제로 악성행위를 하는 프로그램을 Eversafe가 체크하지 않는 경로 등에 두었더니 전혀 문제없이 돌아갔다), 기사에서 말하는 몇 천번의 테스트를 도대체 어떤걸 상대로 어떤 공격을 한건지 감도 안온다 — 너무 기능이 없어서;;

페이스북 원글의 댓글에서도 언급했지만, 여기서 당사자들이 말하는 “N번 테스트에서 100% 통과”라는 말은 정확히 어떻게 테스트 했냐에 따라서 의미가 있을 수도 또는 아예 0일 수도 있다. 학계 논문을 쓸 때 하는 실험에서 많이들 (반고의적으로) 실수하는 부분이기도 한데, 현재 모델과는 호환되지 않는 방향으로 바꾸었다면 테스팅 기법이나 접근도 달라져야하는 것이 당연지사지만 방어 모델은 바꾸었음에도 공격/위협 모델은 전혀 손대지 않고 “더이상 공격이 통하지 않으므로 완전히 안전하다” 라는 식의 주장을 하는 사람들이 있다.

시스템 해킹을 하는 사람들에게 좀더 직관적으로 이 문제를 설명하면, 마치 “ASLR을 적용했더니 메모리 코럽션 익스플로잇으로부터 100% 안전해졌습니다!” 라고 하는것과 마찬가지라는 거다. 그래서 해당 방어기법의 등장으로 메모리 코럽션 익스플로잇이 불가능해졌을까? 아니다. 그에 따라 공격자도 “진화”를 했고, 이건 그나마 챌린징하기라도 하지.. 우리가 좀전까지 함께 본 이 솔루션은 껍데기만 있을 뿐 하는게 없는 CS 전공 학부생 2학년 안드로이드 프로젝트에 버금가는 결과물이다.  (..너무 심했나) 초반에 말했듯이 수시로 동적으로 타겟을 바꾸어 공격이 어렵게 하는 것은 좋은 아이디어다. 다만, 이 컨셉을 사용하고 구현한것이 “세계 최초”는 절대 아니고 지금 Eversafe의 구현체가 실제로 보안에 도움이 되는건 더더욱 아니니 그렇게 과장하지는 않았으면 한다.

 

이쯤 되면, 우리은행이나 정부기관이 얼마를 주고 이 원더풀한 솔루션을 사용하는지 궁금해진다. 이 솔루션을 평가하고 심사한 (그리고 투자까지 이르게 한) 심사위원들은 뭘 평가한건지도 궁금하고. 내가 모르는 사연들이 많겠지만, 보안 스타트업을 하는 1인으로서 소위 “약장수” 느낌이 나는 제품들을 곱게 포장해서 사람들을 현혹하고 이 시장을 흩트리는 사건을 그냥 보고 넘어가기에는 너무 자극적인 단어들을 써가며 마케팅을 했다.

 

어쩌면 그게 보안 회사로서 쉽게 투자 받는 지름길이려나. 생각이 많아지는 밤이다. (라고 간지나게 쓰고 자야겠지만, 이제 본업 밀린것좀 해야지.. #스타트업라이프)

 

====================================== (2017/08/08 14:23 PM KST)

본문에서 언급된 “우리은행”은 이번 분석의 초점이었던 Eversafe 솔루션을 앱에 적용했다는 것 말고는 연관된 것이 없습니다. 이번 글은 우리은행 앱 자체에 대한 보안 문제나 취약점을 다루고 있지 않으며, 단지 해당 솔루션이 적용되었다는 소개가 기사내용에 있어 선택되었습니다. 모쪼록 이번 분석내용과는 관련이 없는 우리은행에게 불필요한 비난이나 우려는 없길 바랍니다. 원본에서 이 사항에 대해서 확실히 짚고 넘어가지 못한 점에 대해 사과드립니다.

====================================== (2017/08/08 14:10 PM KST)

본 글을 링크한 제 페이스북 포스팅에 에버스핀 사의 입장이 담겨 현재까지의 대화를 스크랩합니다. 실시간으로 확인하실 분들은 링크를 타고 보시면 됩니다. 제가 분석한 타겟은 글쓴 시점 최신 버전에 대한 분석이었으나, 은행사의 사정으로 인해 다이나믹 요소가 꺼져있다는 설명입니다. 더 자세한 설명은 오해를 일으킬 수 있으니, 원문을 게재합니다.

 

You may also like...

11 Responses

  1. asiagaming says:

    저도 기사를 읽고 의아해하고 있었는데 잘 읽었습니다!

  2. 기부 says:

    잘봤습니다. 엄청난 분석이네요

  3. blackcon says:

    상품 홍보를 하더라도 “사실”을 바탕으로 포장하면 좋을텐데, 이건 뭐..ㅎㅎ
    무튼 분석글 재밌게 읽고갑니다 :D

  4. HaHwul says:

    재미있게 봤습니다. 감사합니다 :)

  5. OTK says:

    잘 봤습니다. 감사합니다. ^^

  6. wow says:

    https://www.youtube.com/watch?v=ih_ar6haDLA
    이미 홍보영상에서부터 100%라는 말을 남용하고있었는데 기자탓 ㅋㅋ…

  7. Floyd son says:

    대응이 재미있습니다. 실제로 중요한건 다이나믹이냐 스태틱이냐가 아닌데 그걸로 몰고 가는 모습이 재미있네요.
    다이나믹이었다면 이런 상황이 오지 않았겠지만 금융권의 서비스 안정성 때문에 다이나믹 서비스를 할수 없다면 그건 실패한 서비스라고
    생각됩니다.
    Brain님 덕분에 많이 배우고 갑니다. 감사합니다.

  8. wonseok says:

    안녕하세요 ^^ 기사 정말 잘 읽었습니다.. 혹시 기사에 나와있는 mitm 도구의 이름은 힌트를 주실 수 있을까요?? 감사합니다!

  9. ys says:

    역시 대단하시네요. 많이 배우고 갑니다.
    – 화이트 해킹이라는 업무는 더 나은 발전을 위해 꼭 필요하다고 생각합니다.

  10. aSiagaming says:

    동적으로 가져오는 것까지 분석하신 분 계시던데, 분석글을 보고나니 100% 안전한 dynamic security solution을 습득할 수 있더라구용 ㅎㅎ

Leave a Reply

Your email address will not be published. Required fields are marked *