HACKCATML

비트코인 자동매매 시스템

hackcatml — Tue, 30 Sep 2025 21:23:03 +0900

최근에 육아를 하면서 느끼는 점은 "돈이 모이지 않는다"는 것입니다.

이래서는 미래가 그려지지 않습니다.

그래서 아기가 생기기 전까지가 돈을 모을 수 있는 골든타임이라고 많이들 하는 것 같습니다. 골든타임을 놓쳐버렸...흑

월급외에 부수입을 한푼이라도 더 만들긴 해야 하는데...방법이 마땅히 떠오르지 않더군요.

투잡을 뛰자니 몸이 예전같지 않고, 불법 해킹을 할 수도 없고...

그나마 간간히 재미를 보던 비트코인이 떠올랐습니다.

매월 부수입을 만들어야 하니 무작정 비트코인 사고 3, 4년 존버하는 방식은 안되겠고, 단타로 접근해야 겠더군요.

현물 단타는 시드를 크게 집어넣어야 유의미한 수익을 얻을 수 있습니다.

그에 반해 선물 단타는 레버리지를 사용하기 때문에, 적은 시드로도 유의미한 수익을 얻을 수 있죠. 단, 청산이라는 위험이 있어서 단타 잘못치다가 자산이 삭제되는 일이 비일비재합니다.

현물 단타에 큰 시드를 넣고 운영하기에는 압박감이 심하고, 본업에 집중도 안될것 같아서 선물 단타로 방향을 정했습니다.

선물에서 돈을 따는 법을 우리 모두는 알고 있습니다.

자신만의 로직에 따른 "기계적 매매"...그런데 저 포함 99% 휴먼은 이 감정 통제가 안되어서 선물의 끝인 청산을 보게 됩니다.

"감정 통제는 코드가 해주면 되잖아?" 나의 손가락 개입을 최소화해주는 매매 로직을 짠다면 승산이 있겠다 생각이 들더군요.

그래서 자동매매를 알아보기 시작했는데, 트레이딩뷰라는 좋은 툴이 있더군요.

파인스크립트라는 전용 스크립트를 사용해서 정교한 매매 로직을 작성하는 것이 가능합니다.

그리하여 5월달부터 비트코인 자동매매 개발을 시작했는데,

트레이딩뷰 매매로직 + 웹훅 서버 프론트 + 시그널 처리 웹훅 서버 + DB 연동 으로 구성하였습니다. (Bitget 전용)

매매로직에서 시그널이 발동되면 웹훅 서버에서 시그널을 받아서 Bitget 에 주문을 넣는 것입니다.

핵심은 매매로직인데, 순환매 + 엘리엇파동 + 피보나치 + 개인 경험 짬뽕해서 로직을 작성했습니다.

매매로직 이름은 고양이 쥐잡듯이 저점 잡으라고 쥐캣(G-Cat) 이라고 명명...

아무튼 20.06.01 ~ 25.06.01 5년 백테스팅 돌려보니 수익률 4688% 나오네요.

흠...과거에 비트코인이 워낙 폭등을 했었으니 좋게 나오나 봅니다. 앞으로도 이렇게 나오면 좋겠네요.

5월 달부터 개발과 동시에 테스트를 진행하였는데, 말이 테스트지 시드가 작았을뿐 실매매를 진행하였습니다.

1 ~ 5 번째 매매까지는 시드 1000달러, 5 ~ 10 번째 매매까지는 시드 5000달러로 진행하고 전부 익절하였습니다.

아래 그림은 9번째, 10번째 테스트 매매. 1차 진입한 상태에서 바로 차트가 방향을 틀어서 1차 익절(녹색선), 2차 익절(파란선) 을 할 수 있었습니다.

3차 익절은 빨간선을 건드리면 되는데, 3차선 안 닿을것 같으면 그냥 수동으로 개입해서 익절하고 "Long Close Manual" 이라고 표시합니다.

현재는 적은 시드로 돌리는 10번의 테스트는 끝났고, 시드를 상향 조정(만달러 단위)해서 돌리고 있습니다.

흠 이게 되는건가 싶지만...완벽한 것은 없겠지요.

선물시장은 정말 위험하기 때문에 조심해서 운영해보려고 합니다. (내가 만들었고 5년 백테스팅 기간동안 청산 한번 없었지만 시장 자체가 확률 싸움이니 내가 만든 로직을 100% 믿을 수 없는 아이러니...)

원래는 10번 테스트 매매 끝나면 Bitget 에 카피 트레이딩(다른 투자자들이 쥐캣의 매수 매도를 그대로 카피해서 투자하는 것)을 오픈하려고 했는데, 최근에 시그널이 안울리는 오류도 있고 해서 아직은 위험하다 판단이 되어서 당분간은 혼자서 계속 돌려보려구요.

코인 및 재테크 관심 있으신 분들은 텔방 들어오셔서 보안쟁이가 자본주의 세상에서 살아남기 위해 발버둥치는거 구경하십쇼.

https://t.me/+VvTCsJa0fIhiYzc1

Magisk v27.0+ 달라진 점 (Zygote Injection 방식)

hackcatml — Tue, 3 Sep 2024 10:04:17 +0900

Magisk v27.0 이후로 많은 부분이 업데이트 되었지만 주목할 만한 것은, Zygisk의 Zygote Injection 방식이 달라진 것입니다.

이전 버전에서는 LD_PRELOAD 방식을 이용하여 Injection 하였습니다. 이 방식은 linker 에 침투 흔적을 남겨서 zygisk 활성화 여부를 탐지 할 수 있었습니다.

v27.0 에서는 Zygote Injection 으로 native bridge 방식이 도입되었습니다.

Zygisk 가 없던 시절 Riru (https://github.com/RikkaApps/Riru?tab=readme-ov-file) 가 해당 방식으로 Zygote Injection 을 구현하였는데, Zygisk 도 해당 방식을 차용한 것으로 보입니다.

Native bridge 방식이 어떤 흔적을 남기는지 간략히 확인해보겠습니다.

Magisk 에서 Zygisk 기능을 활성화하고 재부팅을 해보면 "Unsupported native bridge API..." 로그를 볼 수 있습니다.

해당 로그는 안드로이드 소스코드의 native_bridge.cc 에서 찾을 수 있습니다.

출처: https://cs.android.com/android/platform/superproject/+/android14-qpr3-release:art/libnativebridge/native_bridge.cc;drc=1aa5d121d7eb21a96f42cfd396e56bf2acdca162;l=231

소스 코드를 보면 해당 로그를 찍고, callbacks = nullptr; 로 설정합니다.

그 결과 CloseNativeBridge(true); 가 호출됩니다.

bool LoadNativeBridge(const char* nb_library_filename,
                      const NativeBridgeRuntimeCallbacks* runtime_cbs) {
  // We expect only one place that calls LoadNativeBridge: Runtime::Init. At that point we are not
  // multi-threaded, so we do not need locking here.

  if (state != NativeBridgeState::kNotSetup) {
    // Setup has been called before. Ignore this call.
    if (nb_library_filename != nullptr) {  // Avoids some log-spam for dalvikvm.
      ALOGW("Called LoadNativeBridge for an already set up native bridge. State is %s.",
            GetNativeBridgeStateString(state));
    }
    // Note: counts as an error, even though the bridge may be functional.
    had_error = true;
    return false;
  }

  if (nb_library_filename == nullptr || *nb_library_filename == 0) {
    CloseNativeBridge(false);
    return false;
  } else {
    if (!NativeBridgeNameAcceptable(nb_library_filename)) {
      CloseNativeBridge(true);
    } else {
      // Try to open the library. We assume this library is provided by the
      // platform rather than the ART APEX itself, so use the system namespace
      // to avoid requiring a static linker config link to it from the
      // com_android_art namespace.
      void* handle = OpenSystemLibrary(nb_library_filename, RTLD_LAZY);

      if (handle != nullptr) {
        callbacks = reinterpret_cast<NativeBridgeCallbacks*>(dlsym(handle,
                                                                   kNativeBridgeInterfaceSymbol));
        if (callbacks != nullptr) {
          if (isCompatibleWith(NAMESPACE_VERSION)) {
            // Store the handle for later.
            native_bridge_handle = handle;
          } else {
            ALOGW("Unsupported native bridge API in %s (is version %d not compatible with %d)",
                  nb_library_filename, callbacks->version, NAMESPACE_VERSION);
            callbacks = nullptr;
            dlclose(handle);
          }
        } else {
          dlclose(handle);
          ALOGW("Unsupported native bridge API in %s: %s not found",
                nb_library_filename, kNativeBridgeInterfaceSymbol);
        }
      } else {
        ALOGW("Failed to load native bridge implementation: %s", dlerror());
      }

      // Two failure conditions: could not find library (dlopen failed), or could not find native
      // bridge interface (dlsym failed). Both are an error and close the native bridge.
      if (callbacks == nullptr) {
        CloseNativeBridge(true);
      } else {
        runtime_callbacks = runtime_cbs;
        state = NativeBridgeState::kOpened;
      }
    }
    return state == NativeBridgeState::kOpened;
  }
}

CloseNativeBridge 함수의 소스코드는 다음과 같은데, CloseNativeBridge(true); 호출 결과 had_error 값이 true 로 설정되는 것을 확인할 수 있습니다.

출처: https://cs.android.com/android/platform/superproject/+/android14-qpr3-release:art/libnativebridge/native_bridge.cc;drc=1aa5d121d7eb21a96f42cfd396e56bf2acdca162;l=225

static void CloseNativeBridge(bool with_error) {
  state = NativeBridgeState::kClosed;
  had_error |= with_error;
  ReleaseAppCodeCacheDir();
}

그렇다면 had_error 가 메모리의 어디에 위치해 있나가 궁금한데, 그것은 libnativebridge.so 파일을 IDA 로 까보면 알 수 있습니다. 음 소스코드와 IDA 를 비교해보니 had_error 변수가 byte_5288 에 있군요.

byte_5288 은 .bss segment 의 시작부분입니다.

이는 앱 프로세스에서도 확인 가능합니다. Zygisk 활성화 후 아무앱이나 실행시키고 Frida 로 libnativebridge.so 의 오프셋 0x5288 로 이동해봅니다. 0x1 이 설정되어 있습니다.

Zygisk 가 비활성화된 상태에서는 had_error 값이 false 이므로 앱 프로세스에서 확인하면 0x0 이 설정되어 있습니다.

헛?! 그렇다면 이것으로 Zygisk 를 탐지할 수 있는것인가!! 라는 생각이 들 수 있지만, 매지스크 개발자 topjohnwoo 도 알고 있겠죠. 아마 이정도 사소한 것은 모듈단에서 알아서 처리하라고 내비두지 않았을까 생각됩니다.

Shamiko (https://github.com/LSPosed/LSPosed.github.io/releases) 나 Zygisk-Assistant (https://github.com/snake-4/Zygisk-Assistant/releases) 모듈을 설치하면 해당 값을 0x0 으로 패치해줍니다. 따라서 유의미한 탐지 방식이 될 수는 없겠죠.

음 여기까지 봤을때 제 짧은 식견으로는 Zygisk 자체를 어떻게 탐지해야 할지 아이디어가 떠오르지 않더군요.

이미 뛰어난 해커, 솔루션 개발자들은 탐지하고 있겠죠?? 저도 더욱 분발해야 겠네요 :)

모바일 해킹, 보안 주제로 자유롭게 대화 나눠요

hackcatml — Mon, 2 Sep 2024 13:40:32 +0900

텔레그램 채널 및 대화방 개설하였습니다.

모바일 해킹, 보안, 리버싱 관심 있으신 분들은 들어오셔서 자유롭고 편하게 대화 나눠봐요 :)

채널: https://t.me/hackcatml1

대화방: https://t.me/hackcatmlchat

Android SO File Dump

hackcatml — Sat, 31 Aug 2024 23:11:08 +0900

악성코드 분석을 하다 보면 반복적으로 so 파일을 추출하고 있는 자신을 발견하게 됩니다.

apk를 까봤더니 그 안에 타겟 so 파일이 들어 있고 IDA에서 문제없이 열린다면 매우 땡큐입니다. 분석 난이도가 매우 낮은 경우로 흔하지 않습니다.

그렇지 않은 경우에도, frida 가 순조롭게 붙기만 하면 쉽게 타겟 so 파일을 획득할 수 있습니다.

그런데 조금 난이도가 있는 친구들은 frida 탐지 기능은 내비둔채, 앱의 솔루션을 무력화합니다.

이 경우 frida 탐지 기능을 우회하면 되지만, 여의치 않은 경우 native 모듈을 만들어 so 파일을 추출하게 됩니다.

아래 그림의 so 로딩 흐름을 보면, 최종적으로 linker 의 do_dlopen 을 호출하는 것을 알 수 있습니다.

출처: https://juejin.cn/post/6899061455610773511

do_dlopen 함수는 첫번째 인자로 so 파일 이름이 전달되고, so 파일이 로드되었다면 그 so 파일의 handle 을 반환하는 함수입니다.

출처: https://cs.android.com/android/platform/superproject/+/android14-qpr3-release:bionic/linker/linker.cpp;l=2112;bpv=1?q=do_dlopen&ss=android%2Fplatform%2Fsuperproject

그러니 do_dlopen 함수를 후킹하면 so 파일 로딩을 추적 및 덤프를 뜰 수 있습니다.

do_dlopen 함수의 심볼은 "__dl__Z9do_dlopenPKciPK17android_dlextinfoPKv" 입니다.

so 파일 로딩을 온전히 추적하기 위해서 후킹 타이밍은 빠르면 빠를 수록 좋겠죠.

모든 프로세스의 부모인 zygote 에 injection 하여 구현하는게 제일 좋습니다. zygote 가 fork 되면서 앱 프로세스가 시작이 되는데, 이 zygote 에 모듈을 인젝션 해놓으면, 앱의 시작과 동시에 모듈을 작동하게 할 수 있기 때문입니다.

magisk 의 기능인 zygisk 가 zygote injection 을 구현해놓았으며, 우리가 할 것은 zygisk 모듈을 만들기만 하면 됩니다.

음 zygisk 모듈을 만드는 것은 알겠고, 덤프 로직은 어떻게 구현해야 할까요?

so 파일의 base 주소와 size 정보를 알아내서 메모리에서 그만큼을 읽어들여 파일에 쓰면 되겠네요.

frida-gum (https://github.com/frida/frida-gum) 에서 제공하는 여러 유용한 api 들을 이용하면 수월하게 구현 가능합니다.

이를 종합해서, 여러 so 파일 로딩 case에 대응하여 덤프를 뜰 수 있는 툴을 제작하였습니다. 사용법은 깃헙 참고 바랍니다.

https://github.com/hackcatml/zygisk-memdump

GitHub - hackcatml/zygisk-memdump: A zygisk module that dumps so file from process memory

A zygisk module that dumps so file from process memory - hackcatml/zygisk-memdump

github.com

Frida Build & Debug Using Logs For Android

hackcatml — Sat, 31 Aug 2024 17:35:45 +0900

MacOS, frida v16.4.10 android-arm64 빌드 및 디버깅(log 찍기) 하기

◼︎ How to build

// clone

git clone --recurse-submodules https://github.com/frida/frida.git

cd frida

// ndk 환경변수 설정

export ANDROID_NDK_ROOT=$HOME/Library/Android/sdk/ndk/25.0.8775105

// configure & make

mkdir android-arm64 && cd android-arm64
../configure --host=android-arm64

make

// build output

frida-server 위치: frida/android-arm64/subprojects/frida-core/server/frida-server
frida-gadget 위치: frida/android-arm64/subprojects/frida-core/lib/gadget/frida-gadget.so
frida-inject 위치: frida/android-arm64/subprojects/frida-core/inject/frida-inject

◼︎ How to debug using logs

관심 있는 구간에 g_info 집어 넣고 빌드

adb logcat -s "Frida"

Proxy Android Flutter Apps

hackcatml — Sun, 19 May 2024 17:48:35 +0900

◼︎ 개요

Flutter 앱은 Flutter 프레임워크(https://flutter.dev/)를 사용해 개발된 앱으로, Flutter 프레임워크는 Dart 언어(https://dart.dev)를 사용합니다.
다양한 앱들이 Flutter 로 개발됩니다. Google Ads, BMW, 네이버 블로그, 네이버 지식인, 삼쩜삼, Demaecan, Nubank 등이 있죠.
Flutter 는 빠르게 네이티브 성능의 앱을, 그것도 멀티플랫폼으로 개발할 수 있습니다.
개발자들에게는 Flutter 가 좋은 옵션이 되겠네요.

음...하지만, 보안인에게는 Flutter 앱이 꽤나 골치가 아픕니다.
분석을 하려고 하는데 심볼은 전부 날라가 있고, 일반적인 방식으로 네트워크 프록시도 안잡히기 때문이죠.

본 글에서는 안드로이드 Flutter 앱의 http 패킷을 BurpSuite 으로 잡기 위해 수행한 분석에 대해서 다뤄보고자 합니다.

성격 급하신 분들을 위해, 제가 작성한 frida script 공유합니다.

https://github.com/hackcatml/frida-flutterproxy

GitHub - hackcatml/frida-flutterproxy: Burp proxy android flutter apps

Burp proxy android flutter apps. Contribute to hackcatml/frida-flutterproxy development by creating an account on GitHub.

github.com

◼︎ BurpSuite 으로 http 패킷 보내기

내 컴퓨터에서 돌아가고 있는 Burp 에 http 패킷을 보내야 프록시를 잡을 수 있습니다.

그런데, Flutter 의 경우 Flutter 엔진 내부에서 네트워크를 담당하고 있어서 아래 그림처럼 단말기에서 프록시를 설정하여도 패킷이 Burp 로 날라가지 않습니다.

Flutter 엔진에서 "Socket_CreateConnect" 라는 함수가 서버와의 연결을 담당합니다. (출처: https://blog.weghos.com/flutter/engine/third_party/dart/runtime/bin/socket.cc.html)

음...IDA 에서 해당 함수를 찾아봐야 겠군요.

안드로이드에서 Flutter 엔진 파일은 libflutter.so 입니다.

"Socket_CreateConnect" 문자열을 검색해서 클릭, 클릭 따라 들어가면 쉽게 해당 함수의 주소를 찾아낼 수 있습니다.

해당 함수 sub_6FD704 의 pseudo code 의 생김새를 보아하니, 두번째 함수 sub_70371c 가 "SocketAddress::GetSockAddr" 함수 이겠군요.

sub_70371c 의 두번째 인자는 sockaddr 구조체입니다.

아하! sub_70371C 를 후킹하면 sockaddr 구조체 주소를 얻을 수 있겠군요. sockaddr 구조체에는 IP 및 PORT 정보가 담겨져 있기 때문에, 이를 조작해서 Burp 로 패킷을 보낼 수 있겠습니다.

음 좀더 살펴보니 "Socket_CreateConnect" 함수는 내부적으로 socket 함수를 사용하고 있습니다.

아하! sockaddr 구조체 조작 시점을 socket 함수 사용 시점으로 하면 되겠네요. socket 함수 사용 시점이 네트워크 통신을 위한 socket 생성 시점이니, 이때 Burp IP 와 PORT 로 조작한 sockaddr 구조체를 준비해 놓으면 되겠습니다.

그런데 문제는 Flutter 앱이 업데이트 되거나 다른 Flutter 앱을 마주치면 매번 IDA로 디컴파일해서 "SocketAddress::GetSockAddr" 함수 주소를 찾아내고 후킹을 해서 sockaddr 구조체 주소를 얻어야 하는 건가 싶습니다.

그래서 여러 Flutter 앱들을 디컴파일해서 살펴봤는데요, 모두 "Socket_CreateConnect" 함수의 두번째 BL 인스트럭션이 가리키는 주소가 "SocketAddress::GetSockAddr" 함수 주소였습니다.

여러 Flutter 앱들에서 동일 패턴이 발견되었으니, 이는 frida script 로 충분히 구현 할 수 있습니다. 다음과 같은 흐름이 되겠죠.

libflutter.so 메모리에서 "Socket_CreateConnect" 문자열을 메모리 스캔 -->

"Socket_CreateConnect" 문자열이 저장된 주소를 참조하는 곳을 메모리 스캔 -->

(발견된 주소 - 0x10) 이 "Socket_CreateConnect" 함수 주소임 -->

"Socket_CreateConnect" 함수 주소에서 두 번째 BL 지시어가 가리키는 곳이 "SocketAddress::GetSockAddr" 함수 주소임 -->

"SocketAddress::GetSockAddr" 함수를 후킹해서 sockaddr 구조체 주소를 얻을 수 있음 -->

socket 함수를 후킹해서 socket 함수 사용 시점에 sockaddr 구조체의 정보를 Burp IP 와 PORT 로 변조

자 여기까지 frida 로 구현하고 앱을 실행해보면, Burp로 패킷이 날라가기는 하지만 패킷이 잡히지는 않습니다.

Burp 에서 "Remote host terminated the handshake" 에러가 발생합니다.

◼︎Verify cert chain 우회

위 에러의 원인을 찾아보니, Flutter 엔진의 경우 자체적으로 boringssl 을 사용해서 인증서 검증을 하고 있습니다.

그러다 보니 Burp 인증서가 검증을 통과하지 못해서 에러가 발생한 것이지요.

Flutter 엔진에서 인증서 검증을 담당하는 함수는 "ssl_crypto_x509_session_verify_cert_chain" 입니다. (출처: https://blog.weghos.com/flutter/engine/third_party/boringssl/src/ssl/ssl_x509.cc.html)

음 함수 내부에 "ssl_client" 라는 문자열이 보이네요. IDA 에서 해당 문자열을 검색하면 verify_cert_chain 함수를 쉽게 찾을 수 있겠습니다.

여러 Flutter 앱들을 살펴보았는데, 모두 "ssl_client" 문자열이 노출되었으며 이를 통해 "ssl_crypto_x509_session_verify_cert_chain" 함수 주소를 찾아낼 수 있었습니다.

따라서 이것도 충분히 frida script 로 구현 가능합니다. 이런 흐름이 되겠죠

libflutter.so 메모리에서 "ssl_client" 문자열을 메모리 스캔 -->

"ssl_client" 문자열이 저장된 주소를 참조하는 곳을 메모리 스캔 -->

발견된 주소가 속해 있는 함수가 "ssl_crypto_x509_session_verify_cert_chain" 임 -->

"ssl_crypto_x509_session_verify_cert_chain" 함수 후킹해서 return 값 변조

◼︎결과

"BurpSuite 으로 http 패킷 보내기" 에서의 분석결과와 "Verify cert chain 우회" 에서의 분석결과를 종합해서 frida script 를 작성하였습니다. 사용방법은 Github 주소 참고 바랍니다. https://github.com/hackcatml/frida-flutterproxy

테스트한 모든 앱들에서 정상적으로 프록시를 잡을 수 있었습니다.

◼︎참고

https://github.com/Impact-I/reFlutter (reFlutter)

https://blog.nviso.eu/2020/05/20/intercepting-flutter-traffic-on-android-x64/

https://swarm.ptsecurity.com/fork-bomb-for-flutter/

kfd exploit 활용

hackcatml — Fri, 9 Feb 2024 22:04:52 +0900

felix-pb 에 의해 공개된 kfd 는 kernel file descriptor 의 약자로 애플 단말기의 유저단에서 커널 영역의 메모리를 읽고, 쓰는 것을 목표로 하는 프로젝트입니다.

깃헙에 들어가보면 write up 도 자세히 적어놨는데, 제 레벨로는 읽어도 이해가 안되더군요...

https://github.com/felix-pb/kfd

GitHub - felix-pb/kfd: kfd, short for kernel file descriptor, is a project to read and write kernel memory on Apple devices.

kfd, short for kernel file descriptor, is a project to read and write kernel memory on Apple devices. - GitHub - felix-pb/kfd: kfd, short for kernel file descriptor, is a project to read and write ...

github.com

그래도 어떻게 커널과 친해질 수 있을까 고민하던중에 kfund 프로젝트를 발견하였습니다.

원래 kfd 를 사용하려면 단말기의 고유한 offset 들을 직접 찾아내고 소스코드에 적어줘야 하는데, kfund 에서는 dynamic 하게 offset 들을 찾아줍니다. 유용한 api도 많이 제공하고 있습니다.

https://github.com/wh1te4ever/kfund

GitHub - wh1te4ever/kfund: kfund, short for my fun with kfd exploit.

kfund, short for my fun with kfd exploit. Contribute to wh1te4ever/kfund development by creating an account on GitHub.

github.com

Jailbreak community 에서 활동하시는 분들 보면 자동으로 엄지척이 올라갑니다.

메모리를 자주 들여다보면 뉴비인 저도 커널과 친숙해지지 않을까 싶어서, kfund 에 frida-gadet 을 삽입하여 kernel memory 를 들여다볼수 있는 툴을 제작하였습니다.

https://github.com/hackcatml/kfd-explorer

GitHub - hackcatml/kfd-explorer: iOS kernel memory explorer

iOS kernel memory explorer. Contribute to hackcatml/kfd-explorer development by creating an account on GitHub.

github.com

kfund 프로젝트에는 "/System/Library/Audio/UISounds/photoShutter.caf" 파일을 숨겨서 아이폰 카메라를 무음으로 만드는 예시가 있는데요. 이것을 한번 따라 해보려고 합니다.

iPhone11, iOS 16.1.1 에서 테스트하였습니다.

"/System/Library/Audio/UISounds/photoShutter.caf" 파일의 vnode 를 구합니다.

vnode는 커널 메모리 영역에 있는 object 로써, 유닉스 파일 인터페이스(open, read, write, close, readdir, etc.)와 소통하는 역할을 한다고 합니다. (https://man.openbsd.org/vnode.9)

해당 vnode 주소로 이동해보면 iocount, usecount, flag 필드가 보입니다. Offsets 탭에서 해당 필드들이 vnode 로부터 얼만큼 떨어져 있는지 확인할 수 있습니다.

vnode 플래그에는 VISSHADOW (0x008000) 라는 값이 있습니다. https://github.com/apple-oss-distributions/xnu/blob/xnu-8792.41.9/bsd/sys/vnode_internal.h#L297

현재 설정되어 있는 플래그 (0x84800) 와 VISSHADOW 플래그 (0x8000) 를 OR 연산한 값을 덮어씌우면 파일에 접근할 수 없게 됩니다.

(0x84800 | 0x8000) --> 0x8c800

kfund 에서는 flag 값을 덮어씌우기 전에 usecount 및 iocount 값을 1씩 증가시킵니다.

usecount 및 iocount 변화 없이 flag만 설정하면 처음에는 카메라가 무음이었다가 몇분 지나면 다시 카메라 음이 살아나더군요.

어쨌든 따라해보겠습니다.

iocount 및 usecount 1씩 증가한 값 kwrite

VISSHADOW 와 OR 연산한 새로운 flag (0x8c800) kwrite

이렇게 설정하면 단말기 재부팅하기 전까지 아이폰 카메라 셔터음이 나지 않습니다.

버sucker 키우기

hackcatml — Sat, 27 Jan 2024 19:13:36 +0900

최근에 새로 출시된 중국산 게임이 모바일 매출순위에서 리니지를 제꼈다고 게임 유튜버 및 온라인 뉴스에서 시끌벅적했습니다.

글을 올리는 시점에도 매출순위 2등을 하고 있군요.

그래서 도대체 어떤 게임이길래 궁금해서 플레이해봤는데요.

딱 봐도 전형적인 유저들 돈 단기간에 뽑아먹고 튈 형태의 게임처럼 보였습니다.

보안을 하는 입장에서 이런 생각이 들더군요.

"이 정도 퀄리티의 간단한 게임이면 변조앱 사이트서 무료로 변조앱 뿌려서 누구나 다 현질없이 게임하고, 어뷰징하고 개판나서 망할텐데 어떻게 매출순위가 이렇게 높지?"

그래서 궁금해서 까봤더니 아이쿠~ 유니티가 아니고 cocos 게임입니다.

유니티였으면 출시하자마자 게임 변조앱 사이트들에 어뷰징앱이 올라왔을 겁니다.

cocos, lua 같은 언어로 제작된 게임은 마이너여서 그런지 모드앱이 안보이더군요. 흠, 개발사 입장에서는 일단은 모드앱 걱정은 줄일 수 있겠네요.

좀 더 구조를 살펴보니 script 기반의 게임이더군요...아...

이렇게 되면 배포되고 있는 모드앱만 없을 뿐이지, 잼민이들도 script 수정해서 어뷰징하고 있을 가능성이 높습니다.

다음은 게임내 사용되는 어느 변수에 대한 로그를 찍어본 것입니다. 변수에 대한 로그를 찍을수 있으면 뭐다? 조작도 가능하겠죠

음...나름 캐릭터는 귀엽더군요. 출퇴근시간에 무과금으로 즐기기에 적합한 게임인것 같습니다.

Roothide Bootstrap

hackcatml — Sun, 7 Jan 2024 18:39:07 +0900

Dopamine 이후로 arm64e 단말기(iPhone X 이후 기종)에 대한 탈옥툴이 나오고 있지 않은 가운데,

탈옥툴은 아니지만 앱에서 tweak이 작동하게끔 하는 Bootstrap 이라는 툴이 RootHide 에 의해 공개되었습니다. (https://github.com/RootHide/Bootstrap)

GitHub - RootHide/Bootstrap: A full featured bootstrap for ios14.0~17.0 (A8~A17,M1+M2)

A full featured bootstrap for ios14.0~17.0 (A8~A17,M1+M2) - GitHub - RootHide/Bootstrap: A full featured bootstrap for ios14.0~17.0 (A8~A17,M1+M2)

github.com

탈옥툴은 아니지만, 탈옥의 주요 목적이 tweak injection 이므로 탈옥단말기와 비슷한 환경을 갖출 수 있습니다.

보안을 하는 입장에서는 tweak 을 통해 앱 동작을 조사할 수 있으므로 좋은 소식이 아닐 수 없습니다.

Bootstrap 은 TrollStore 설치 가능한 단말기에서 tweak 이 작동하도록 해줍니다. (TrollStore 설치 가능 단말기: https://ios.cfw.guide/installing-trollstore/)

Bootstrap.tipa 파일을 TrollStore로 설치해줍니다. (직접 빌드하거나, https://github.com/Baw-Appie/RootHideBootstrap/releases/tag/release 에서 빌드된 .tipa 파일을 다운로드 받을 수 있습니다)

그리고 우선 sileo 에서 ellekit 을 설치해줘야합니다.
그 후, AppEnabler 에서 앱별로 트윅 활성화를 해줄수 있습니다.

카카오페이앱에 트윅 활성화를 해봤습니다.

트윅 활성화를 하면 앱을 rebuild 하게 되는데요, 다음과 같은 현상이 발생하게 됩니다.

원본앱이 .backup 에 백업되고, 변조앱이 .app 에 위치하게 됩니다.

패치된 바이너리를 살펴볼 경우 .prelib 가 LC_LOAD_DYLIB 에 인젝션되어 있습니다.

따라서, 솔루션이 강하게 적용된 앱의 경우에는 무결성 탐지를 우회해줘야 합니다. 보통 탈옥탐지 우회보다 까다롭습니다.

카카오페이앱은 역시 무결성 탐지를 하고 있군요.

트윅은 roothide 용으로 빌드해줘야 합니다. (https://github.com/RootHide/Developer)

테스트결과 C function, address 후킹 정상적으로 작동하였으며, frida 도 정상 작동하였습니다.

Frida-portal 사용법

hackcatml — Fri, 1 Dec 2023 23:33:32 +0900

주로 단말기에서 frida-server 구동하고 attach 를 하였습니다.

attach 방향이 Device <----- Local 입니다.

문득 Reverse TCP 처럼 방향이 Device ----> Local 은 될 수 없는 것일까? 라는 생각이 들었습니다만,

이미 frida-portal 이라고 frida 15.0 버전에 도입되었더군요...허허

(https://frida.re/news/2021/07/18/frida-15-0-released/,

https://frida.re/docs/gadget/#connect)

아무튼 사용법은 다음과 같습니다.

로컬에서 frida-portal 파이썬 코드 작성해서 구동시켜줍니다. (출처: https://github.com/frida/frida-python/blob/bbdcdfaca821276361399775bd81599710ec0625/examples/portal_server.py)

cluster_params 는 gadget 이 attach 시도할 내 컴퓨터의 ip address 입니다. 192.168.0.76:27052 로 설정하였구요.

control_params 는 gadget 이 내 컴퓨터에 attach 되었을때, 이를 컨트롤 할 수 있게끔 노출되는 인터페이스입니다. 127.0.0.1:27042 로 설정하였습니다.

# -*- coding: utf-8 -*-
import json

import frida
from frida_tools.application import Reactor

ENABLE_CONTROL_INTERFACE = True


def on_message(message, data):
    message = json.loads(message)
    if message is not None and 'payload' in message and message['payload'] is not None:
        print(message['payload'])


class Application:
    def __init__(self):
        self._reactor = Reactor(run_until_return=self._process_input)

        cluster_params = frida.EndpointParameters(address="192.168.0.76",
                                                  port=27052)

        if ENABLE_CONTROL_INTERFACE:
            control_params = frida.EndpointParameters(address="::1",
                                                      port=27042)
        else:
            control_params = None

        service = frida.PortalService(cluster_params, control_params)
        self._service = service
        self._device = service.device

        service.on('node-connected', lambda *args: self._reactor.schedule(lambda: self._on_node_connected(*args)))
        service.on('node-joined', lambda *args: self._reactor.schedule(lambda: self._on_node_joined(*args)))
        service.on('node-left', lambda *args: self._reactor.schedule(lambda: self._on_node_left(*args)))
        service.on('node-disconnected', lambda *args: self._reactor.schedule(lambda: self._on_node_disconnected(*args)))
        service.on('controller-connected', lambda *args: self._reactor.schedule(lambda: self._on_controller_connected(*args)))
        service.on('controller-disconnected', lambda *args: self._reactor.schedule(lambda: self._on_controller_disconnected(*args)))

    def run(self):
        self._reactor.schedule(self._start)
        self._reactor.run()

    def _start(self):
        self._service.start()
        self._device.enable_spawn_gating()

    def _stop(self):
        self._service.stop()

    def _process_input(self, reactor):
        while True:
            try:
                command = input("Enter command: ").strip()
            except KeyboardInterrupt:
                self._reactor.cancel_io()
                return

            if len(command) == 0:
                print("Processes:", self._device.enumerate_processes())
                pid = self._device.enumerate_processes()[0].pid
                session = self._device.attach(pid)
                self._device.resume(pid)
                self.script = session.create_script('''
                    send("hello world");
                ''')
                self.script.on('message', on_message)
                self.script.load()
                continue

            if command == "stop":
                self._reactor.schedule(self._stop)
                break

    def _on_node_connected(self, connection_id, remote_address):
        print("on_node_connected()", connection_id, remote_address)

    def _on_node_joined(self, connection_id, application):
        print("on_node_joined()", connection_id, application)
        print("\ttags:", self._service.enumerate_tags(connection_id))

    def _on_node_left(self, connection_id, application):
        print("on_node_left()", connection_id, application)

    def _on_node_disconnected(self, connection_id, remote_address):
        print("on_node_disconnected()", connection_id, remote_address)

    def _on_controller_connected(self, connection_id, remote_address):
        print("on_controller_connected()", connection_id, remote_address)

    def _on_controller_disconnected(self, connection_id, remote_address):
        print("on_controller_disconnected()", connection_id, remote_address)


if __name__ == '__main__':
    app = Application()
    app.run()

그 다음 frida-gadget 을 앱에 인젝션 시켜줍니다. 여러가지 방법이 있습니다만, 기본적으로 https://hackcatml.tistory.com/58 참고해서 인젝션 할 수 있겠죠.

config 파일을 위치시켜줘야 하는데, frida-gadget 과 동일 디렉터리에 확장자가 .config.so 라는 이름으로 위치시켜주면 됩니다.

lib
└── arm64-v8a
    ├── libgadget.config.so
    ├── libgadget.so

config 내용은 다음과 같습니다.

{
  "interaction": {
    "type": "connect",
    "address": "192.168.0.76",
    "port": 27052
  }
}

그다음 앱을 실행시켜주면, node 가 connect, join 했다는 알림이 뜹니다. Gadget 이 내 컴퓨터에 attach 한 것이지요.

엔터 입력하면, script 가 실행되어 "hello world"가 출력됩니다.

물론, frida -H 명령어로 control interface 에 frida 를 붙여줄수도 있습니다.