Raining_93

요즘 투자가 재밌어 보여서 이것저것 알아보다가, 자동 매매 시스템이라는 걸 알게 됐다.

"어? 자동으로 사고팔아준다고?

이거 완전 돈 버는 기계 아냐?"

그렇게 호기심이 폭발하면서 나도 "직접 만들어 봐야지!" 하고 계획을 세웠다.

하지만 막상 만들려고 보니, 가장 먼저 해결해야 할 문제가 떠올랐다.

바로 가격을 실시간으로 받아와야 뭐든 할 수 있겠다 싶었다.

그래서 국내 1위 거래소인 업비트에 접속해보았다.

역시 국내 거래량 1위 거래소 업비트(Upbit)에서 API를 제공하지 않을 리 없었다.

그래서 공식 홈페이지를 찾아봤더니...

2025년 2월 26일 기준으로 공식 사이트에서 표로 깔끔하게 정리한 내용을 보자면 다음과 같다.

공식 문서를 읽어보니 API는 크게 두 가지 종류로 나뉜다.

QUOTATION API – 시세 데이터를 조회할 때 사용하는 API

EXCHANGE API – 매수/매도를 할 때 사용하는 API

이걸 보고 난 "아, 거래하는 건 큰 문제가 없겠네?"라고 생각했다.

하지만...

자동 매매에는 치명적인 단점이 존재했다.

개인적으로 사람마다 다르겠지만,

API 문서를 읽어보면서, 이건 좀 불편한데? 싶은 점이 두 가지나 있었다.

1. 계정 필수 + IP 등록 제한

API를 사용하려면 반드시 업비트 계정이 있어야 하고, 

미리 등록한 IP에서만 요청 가능했다.

집에서만 돌릴 거면 문제없지만, 

밖에서도 실행할 수 있는 앱을 만들고 싶었던 나에겐 큰 걸림돌이었다.

2. 실시간 가격 조회 속도 제한

소켓(Socket)으로 가격을 받아올 수 있지만, 초당 5회, 분당 100회라는 제한이 있다.

코인 가격은 순식간에 변하는데, 

이 속도로는 수십 개의 종목을 실시간으로 모니터링하기 어려웠다.

그렇다고 서버를 둘 수 도 없고..

이건 모바일 자동 매매 프로그램을 만들 때 가장 큰 단점이었다.

"이거 어떻게든 해결해야겠는데?" 하는 마음으로 분석을 시작했다.

그리고 결국

2025년 2월 26일 기준, 160개의 코인을 거의 실시간으로 보여주는 데모 애플리케이션을 개발했다.

먼저 리플을 홈페이지와 직접 개발한 데모 애플리케이션과 비교했을때의 모습이다.

사실 화면에서는 보이지 않지만, 해당 애플리케이션의 빽단에서는 거의 실시간으로 데이터를 받을 수 있다.

하지만 UI로 표현 하는 방법과 코드 로직에 따라 조금은 시간차가 존재하였다.

다음은 비트코인의 호가창이다.

이것도 마찬가지로 애플리케이션의 빽단에서는 거의 실시간으로 데이터를 받을 수 있지만

UI로 표현 하는 방법에서 코드 로직이 조금 개선이 필요할것 같았다.

이것을 활용해서 자동 매매 프로그램을 제작해볼 예정이다.

모바일 애플리케이션을 분석하려면 가장 먼저 USB Debugging 설정을 활성화해야 한다.

이유는 여러 가지가 있겠지만, 가장 핵심적인 이유는 Frida와 같은 필수 도구를 사용하기 위함이다.

Frida는 앱의 내부 동작을 분석하고 디컴파일된 코드에 접근할 수 있도록 해주는 강력한 도구인데

문제는 간혹 애플리케이션이 USB Debugging 감지 로직을 통해 이를 탐지하고

앱 실행을 중단하는 경우가 존재한다.

다행히도 대부분의 USB Debugging 감지 로직은 Frida를 이용해 우회할 수 있다.

Java 또는 Native 레벨에서 동작하는 탐지 코드를 찾아내고,

그 메소드나 함수에 후킹(hooking)을 걸어 감지 로직을 우회할 수 있다.

하지만 여기서 다음과 같은 문제가 발생할 수 있다.

앱의 Java 코드나 Native 코드가 암호화되어 있다면???

코드가 암호화된 상태에서는 감지 로직이 어디에 숨겨져 있는지 찾아내기가 매우 어렵다.

암호화된 상태의 코드를 분석하려면,

실행 중인 앱에서 복호화된 상태의 원본 파일(예: Dex 파일이나 .so 파일)을

덤프(dump) 해야 한다.

이를 통해 암호화된 코드를 확인할 수 있으며 높은 확률로 탐지 로직도 찾을수 있다.

그런데 여기서 또 하나의 문제가 발생한다.

USB Debugging 탐지 로직이 앱을 종료시켜 버리면??

Frida를 이용해 복호화된 파일을 덤프할 기회조차 주어지지 않는다.

아래의 그림을 보자.

아래의 사진처럼 Frida로 Dex 혹은 so 파일을 덤프를 하려고 USB Debugging을 설정해주고

연결하면 아래의 사진처럼 USB Debugging 탐지 로직에 탐지되어 앱이 종료된다.

이런 상황을 대비하고자.

기존에는 Frida를 이용해 USB Debugging 감지를 우회하는 방법이 일반적이었지만,

이번엔 Frida로 USB Debugging을 우회하지 않고도 문제를 해결할 수 있는 새로운 환경을 구성해 보았다.

아래의 그림이 Frida를 이용하지 않고 USB Debugging을 우회하지 않고

USB Debugging을 탐지 로직을 우회한 모습이다.

이 방법을 통해, USB Debugging 감지 로직에 걸리지 않으면서도

Frida로 원본 Dex 파일 및 so 파일을 성공적으로 덤프할 수 있었다.

모의해킹을 진행하다 보면, 예상치 못한 도전에 부딪히는 순간들이 있다.

그중에서도 흔히 발생하는 일이 바로 취약점이 발견된 화면을 캡처하려다 실패하는 상황이다.

보고서를 작성하기 위해 "여기 보세요! 이게 바로 취약점입니다"라며 캡처 사진을

보고서에 첨부하려고 캡처 버튼을 누르는 순간,

화면에 뜨는 건 "이 앱에서는 캡처가 허용되지 않습니다"라는 냉랭한 문구.

화면이 짤막하게 깜빡일 뿐, 저장된 건 아무것도 없다.

캡처가 되더라도 검은색 화면만 캡처가 된다.

이런 문제는 특히 금융권 애플리케이션에서 자주 발견된다.

왜일까? 이유는 간단하다.

바로 보안 때문이다.

예를 들어, 은행 앱에서 사용자의 계좌정보나 금융 데이터를 화면 캡처로 저장할 수 있다면,

이는 악성 코드나 정보 탈취 프로그램에 의해 민감한 데이터가 쉽게 유출될 가능성이 있다.

그래서 화면 캡처를 차단해 둔다.

또 한 가지 재미있는 예로는, 저작권 보호를 위한 캡처 차단 사례를 들 수 있다.

네이버 웹툰과 카카오 웹툰이 대표적인 사례이다.

조금 주제를 벗어난 이야기를 하자면,

무료로 열람할 수 있는 웹툰의 경우에는 공격자나 악의적으로 저작권을 위반하려는

해커가 굳이 캡처를 할 필요가 없다.

왜냐하면, 어차피 누구나 볼 수 있는 공개된 회차이기 때문이다.

아래는 카카오 웹툰, 네이버 웹툰의 무료 회차에 대한 화면 캡처가 우회된 모습이다.

하지만 궁금한 마음에 유료로 열람하는 회차에서도 캡처가 가능한지 확인해보았다.

결과는 무료 회차든, 유료 회차든 모두 캡처가 가능했다.

다만, 네이버 웹툰에는 툰레이더라는 캡처 추적 시스템이 존재한다.

이 시스템은 네이버 웹툰 작품이 불법적으로 캡처되거나 유출될 경우,

이를 실시간으로 탐지해 담당자가 즉각 확인할 수 있도록 만들어진 솔루션이다.

물론 카카오 웹툰도 추척 시스템이 존재할것이다.

이 때문에, 확인은 단순히 테스트 목적으로만 진행했으며, 추가적인 캡처는 진행하지 않았다.

다시 본론으로 돌아와,

만약 위의 화면 캡처 방지 문제를 우회하지 못해,

화면을 다른 휴대폰으로 직접 사진을 찍어 보고서에 첨부해야 하는 상황이 발생한다.

이런 방식은 마치 "아날로그"로 돌아간 듯한 느낌을 주며,

결과적으로 보고서의 퀄리티가 개인적으로 한층 떨어져 보인다고 생각한다.

그래서 개인적으로 보고서에 화면을 첨부할 일이 생기면

Frida를 활용해 화면 캡처 방지를 우회한 뒤, 고화질로 캡처한 이미지를 보고서에 첨부한다.

이렇게 하면 보고서가 훨씬 더 전문적이고 완성도 높게 보인다고 생각이 되기 때문이다.

물론, 애플리케이션 중에는 설정 메뉴에서 화면 캡처를 허용하는 옵션을 제공하는 경우도 있다.

하지만 이러한 기능이 없는 애플리케이션도 여전히 많다.

이런 경우에는 위에서 언급한것처럼 Frida로 화면 캡처 제한을 우회해야만 캡처가 가능해진다.

문제는, Frida를 매번 실행해야하고 스크립트를 작성하는 과정

또, Frida를 탐지하고 있으면 이를 우회하는것이 상당히 번거롭다.

그래서 이러한 반복적인 작업을 항상 캡처 방지를 우회할 수 있는 환경을 구성했다.

이렇게 금융권 애플리케이션, 국내 대표적인 웹툰 애플리케이션인 네이버, 카카오 웹툰에서

Frida를 사용하지 않고도 화면 캡쳐 및 화면 녹화가 되는것을 확인하였다.

모바일 모의해킹에 처음 흥미를 느꼈던 순간을 떠올려 보면,

본격적으로 분석을 시작했던 대상이 바로 NSHC사의 libdxbase.so와

Liapp이라는 모바일 보안 솔루션이였다.

당시 이 솔루션을 우회하는 데 정말 많은 시간이 들었던 것으로 기억한다.

어떻게 접근을 해야하는지도 몰랐고, 어디서부터 분석을 시작해야하는지 참 막막했던 기억이 있다.

많은 시도를 반복하며, 하나씩 문제를 해결하는 과정에서 자연스럽게

모바일 보안 솔루션에 대한 기술을 익히게 되었다.

최근에는 1차 테스트용으로 개발이 완료된 환경에서

NSHC사의 모바일 보안 솔루션(libdxbase.so)을 탑재한

SK 주파수3이라는 애플리케이션을 실행해보았다.

테스트 결과는 성공적이었다.

현재 대부분은 Magisk를 사용해서 루팅하기 때문에 Magisk로 루팅된 환경에서 실행해보았다.

Magisk를 사용하여 루팅된 환경에서 실행 시 루팅된 환경이 탐지됬다는 알림창을 볼 수 있다.

하지만 1차 개발이 완료된 환경에서는

아래의 그림에서 보는것처럼 루팅된 환경에서도 아무 문제 없이 정상적으로 동작하는 것을 확인할 수 있다.

또한, 원래 Frida를 사용하면 아래와 같이 바로 종료가 된다.

하지만 아래와 같이 Spwan으로 Frida를 실행한 후

1초마다 Frida Bypass........라는 문자열을 출력해보았다.

5분이 넘게 Frida가 종료되지 않는것으로 보아 Frida 탐지가 되지 않고 잘 실행되고 있다는것을 

확인할 수 있다.

그냥 휴대폰 번호 하나 알고 있을 뿐인데, 그 사람의 이름과 집 주소까지 바로 알 수 있다면?

영화에서나 볼 법한 일이 현실에서 벌어진다면 어떤 기분일까.

생각만 해도 끔찍하다.

이름이랑 집 주소가 알려진다고 해서 큰 문제가 되지 않을 것 같다고 생각할 수도 있다. 

하지만 조금만 더 생각해 보면 이런 정보들이 심각한 문제를 초래할 수 있다.

첫째, 피싱 공격. 공격자는 이름과 주소를 이용해 더욱 신뢰성 있는 피싱 메시지를 만들어낼 수 있다.

둘째, 사생활 침해. 이름과 집 주소를 통해 개인의 사적 정보가 조사될 수 있고, 특정 시간에 부재 중일 때를 노려 물리적 침입이나 스토킹으로 이어질 위험이 있다.

셋째, 스미싱 및 스팸. 주소와 이름 정보는 스미싱(SMS 피싱) 공격에 사용되거나, 정교한 스팸 메시지를 보내 신뢰감을 높이는 방식으로 악용될 수 있다.

넷째, 개인화된 공격. 범죄자는 이름과 주소 정보를 바탕으로 더욱 정교한 공격을 계획할 수 있다. 

특정 지역이나 직업에 맞춘 사기 행각을 벌이거나, 실제 범죄로 이어질 수 있는 시도를 할 가능성도 존재한다.

이처럼 영화 속 이야기가 현실이 된 세상에 우리는 살고 있다. 

그만큼 현재 사회는 너무나도 발전해 있고, 동시에 위험도 커지고 있다.

해당 취약점은 3년 전에 발견되었으며, 제보까지 했던 것으로 기억한다.

하지만 지금까지도 조치가 되지 않은 것 같다.

발견했던 취약점을 직접 공개할 수는 없지만, 짧게나마 영상을 만들어 봤다.

휴대폰 번호와 이름과 주소는 모두 모자이크 처리를 했다.

단지 휴대폰 번호 하나만 알아도 이렇게 위험한 세상이 되어버렸다.

이처럼 개인정보 유출의 위협은 우리가 생각하는 것보다 훨씬 더 현실적이고 위험하다. 

개인의 정보를 보호하는 데 있어 더 강력한 법적 조치와 경각심이 필요한 때인것 같다.

대부분은 오랜만에 고향에 내려가거나 고향에서 올라올 때 기차 혹은 고속버스를 이용할 것이다.

고속버스는 경험상 1주일 정도 남았을 때 예매해도 충분히 표가 존재하지만,

SRT나 KTX 같은 경우는 적어도 3주 전 혹은 한 달 전에는 예매를 해야지 겨우 표를 구할 수 있다.

표를 구하지 못했거나 갑자기 고향이나 타지에 가기 위해서 SRT이나 KTX 표를 구하기 위해서

PC로 접속, 혹은 모바일로 접속을 하면 당연하게도 아래와 같이 대기열을 볼 수 있을 것이다.

그리고 이건 개인적인 생각인데 모바일에서 새로고침을 하면 처음 1번, 2번까지는 빠르게 새로고침이 되는데

3, 4번째부터는 체감이 될 정도로 늦게 새로고침이 되는 기분이었다.

혹은 새로고침이 되더라도 위와 같이 대기열이 존재하는 창이 발생되고 난 후 다시 새로고침이 되었다.

앞의 티켓팅 포스팅과 마찬가지로 대기열이 존재하여 혹시나어떤 문제들이 있는지 찾아보았다.

역시나 아래와 같은 기사들이 많이 나와있었다.

그래서 SRT 매크로는 어떻게 동작하고 있는지 찾아보았는데, 대부분 웹 PC 환경에서 매크로를 사용하였다.

혹은 표를 자동으로 티켓팅해주는 모바일 애플리케이션도 존재하는 것을 확인하였다.

하지만, 이건 정말 위험할 수 있다.

해당 애플리케이션에서는 아이디와 비번을 입력한 후 해당 계정에서 매크로를 실행시키기 때문에

해당 애플리케이션을 개발한 개발자가 악의적인 목적을 가지고

계정을 탈취하는코드가 존재한다면???

일반 사용자들은 분석을 할 수 없기 때문에 혹시나 이 글을 보시는 분이 있다면 되도록이면

그런 프로그램은 사용하는 것을 추천하지 않는다.

아무튼, 이번에는 티켓팅 사이트가 아닌 SRT 예매하는 과정을 분석해 보았다.

해당 매크로를 실행하면 아래와 같이 아이디와 패스워드를 입력하는 입력창이 나온다.

어차피 직접 개발한 프로그램이기 때문에 악성코드 및 바이러스는 걱정할 필요가 없다.

로그인을 하면 아래와 같이 출발지와 도착지, 시간 등의 정보를 입력할 수 있게 만들었다.

그리고 간편 조회를 누르면 아래와 같이 조회할 수 있지만 시간을 클릭해서 다음 날로 조회를 해보았다.

다음날로 조회하면 모바일에서 조회한 것과 같은 것을 볼 수 있다.

그 후 원하는 시간 대역을 클릭한 후 새로 고침 시간을 설정, 좌석 등급을 선택한 후 시작을 클릭하면

매크로가 시작된다.

이때 당연하게도 대기열을 우회하기 때문에 남들보다 빠르게 구할 수 있다.

그런 후 만약 내가 원하는 시간대에 표를 예약한다면

해당 단말기 즉, 자신의 휴대폰으로 다음과 같은 알람이 오게 만들었다.

이렇게 SRT 매크로도 직접 만들어 보았다.

크게 어려운 건 없었는데, 진짜 매크로 프로젝트를 하면서 느낀 건 매크로는 큰 문제인 것 같다.

물론 판매를 하지 않고 자기가 딱 사용할 만큼만 티켓을 빠르게 구하는 건 큰 문제가 없다고 생각한다.

하지만 진짜 다른 사람에게는 피해는 안 줬으면 좋겠다.