본문 바로가기
일기장 겸 뻘소리

오늘자 일기 및 메모

by 개발의 묘미(GaeMyo) 2022. 6. 1.
SMALL

자 우선 애플의 자체 보안이 정말 답없을 정도로 철저하다는 사실은 예상했었었어.

하지만 앞서 써둔 글 들에서도 그랬었다시피 애초에 그걸 뚫는게 목적인건 아니야.(오히려 피할 수 있다면 피해야지(우회))

내 목적은 1차적으로 아이폰 내에서 데이터를 받아와 처리하는 기능을 구현하는게 목적이야.

 

그래서 일단은 ios앱에 대한 약간의 개발과정을 훑어보았어.

 

그래서 일단은 최단시간으로 앱 하나를 빌드해봤어.

4시간?도 안 걸렸었던 것 같아.

물론 정말 세세하게 하나하나 다 훑어가면서 짜넣고 한 게 아니기 때문에 속에 든 건 딱히 본래의 기능과는 달라진 게 없어.

 

하지만 이 아주 짧은 과정으로써 추가적으로 얻게 된 정보들은 수없이 많아.

 

  1. ios개발자가 앱을 개발할 때 사용하는 xcode로 가상 에뮬환경이 아닌 실제로 갖고있는 아이폰에 직접 빌드해볼 수 있다.
  2. 그렇게 한 빌드와 실제 앱 사이엔 딱히 큰 차이점이 없다.                                                                                                               (이유는 실제 앱 배포를 위한 전처리과정으로의 디버깅목적 기능이기때문. (아마))
  3. 그렇다면 내가 원하는 기능을 직접 구현해서 내 기기에 빌드시킨다음 사용하는것 또한 실제 앱과 별 차이가 없다는 말임.
  4. 그럼 안드로이드에서의 챗봇이나 스크립트 러너기능을 가진 어플리케이션을 스위프트로 직접 구현하기만하고 빌드해서 사용하면 끝     (물론 기존의 안드 대부분의 챗봇관련앱들은 안드OS에 내장된 알림 답장 기능으로 출력을 구현한다 라는사실도 알고있고 아이폰은 그런 기능이 없다는것 또한 알고있음)
  5. 하지만 목표 실현을 위한 사전조사로 얻은 4번에 대한 부분은 전부다 믿지는 않음.

 

나는 아예 바보는 아니야.

위 리스트 항목의 4번에 대한 사실을 알게되자마자 그 당시 아이폰의 메신저앱들에 대한 종류별 알림 실험을 해봤어.

꾹 누르거나 스와이프할 시 답장기능이 분명히 존재했었어.

 

앗...그건 ios아이폰 자체에 내장된 노티피케이션(알림)에 종속된 기능이면 어쩌려고.. 아이폰자체를 뚫어야할텐데..

라고 생각할수도 있어.

확실히 그렇다면 저 말이 맞는 셈이긴 해.

하지만 난 그게 전부는 아니라고 생각해.

그 말대로라  할지라도 아이폰 자체 보안을 뚫어야만 할 이유는 없어.

그리고 저 방법이 가장 전체적인 해결법인 것도 맞아.

하지만 현실적인 당장의 상황과 조건을 감안해서 다시 생각해봐야 하는 거라고 봐.

(애초에 나는 저런식의 결론이 나오지도 않아. 1초~3초 남짓되는 시간동안 하는 생각만 해도 남들의 수 분 동안 할 생각의 결론은 내니까(물론 아직도 미련하고 경험이 부족해))

물론 그 방법밖에 없다면 시도하기야 하겠지만 그 전에 해볼 수 있는 방법들이 아직 수없이 많이 남아있어.

사람들은 포기가 너무 빨라.

이런 불가능해 보이는 문제마다 단 15초씩 만이라도 좋으니 약간씩 만이라도 좀 더 생각해 본다면 반짝이는 해결책이 나올 가능성도 있을텐데 말이야.

 

얘기로 돌아가야겠어.

아이폰 자체에 내장된 답장 기능일 경우엔  내가 원하는 출력의 경로로써 지정될 앱 자체를 디컴파일하면 돼.

좀 더 풀어서 기록해두자면 안드로이드의 경우 지금 내가 채택하여 사용하고 있는 챗봇의 출력 경로는 주로 카xx톡을 쓰고 있어.

가끔 페xxx 메신저 라거나 인xxxx 디엠에서 사용하기도 하지만 주로 사용하는건 결국 저 어플이야.

그럼 조금만 더 있는 그대로를 관찰하고 곰곰히 유추해 본다면 출력 기능을 담당하는건 아이폰 내부가 아닌(면밀히따지자면 맞을 것 같긴 하지만) 내가 원하는 출력의 경로로 지정될 어플리케이션인 셈인 것 같아.

그걸 뜯어보면 입력 창에 대한 스키마나 전송버튼에 대한 스키마도 있을 것이고 그 어플리케이션을 수정하여 내 앱과 상호작용시킨다던지,

내 어플리케이션 자체에 해당 앱의 필요한 기능들에 접근하는 기능들을 넣는다던지 이런 수없이 많은 방법들이 5초정도만 더 생각해봐도 머릿속을 스쳐지나가. 그리고 이런 생각이나 유추는 누구나 할 수 있는 부분이야.

 

여기서 이제 누군가는 앱을 수정하려면 아이폰 내부 앱에 접근할 수 있어야 하고 그게 가능하다 하더라도 수정을 하기 위해선 복제를 하여 수정 후 대체시킬 수 밖에 없는데 그렇게 하게되면 아예 서명이 깨져서 돌아가지 않는다 라고 주장할수도 있고 복제하는 즉시 아예 작동이 멈추는 앱들도 많다고 주장할수도 있어. 

하지만 그런 부분들은 나도 이미 알고있어.

그건 그거대로의 방법도 1초정도만 더 생각해보면 어떤 부분을 좀 더 알아보고 공부해야 해결이 될 것 같은지 줄줄이 나오잖아.

 

우선 내가 알기로는 ios에서는 써드 파티션의 모든 앱들에게 절대 모든 권한들을 주지 않는걸로 알고있어.

하지만 여기서 발상의 전환을 약간만 해보면 아이폰 내부에 접근할 수 있는 시스템 권한을 가진 앱 자체를 복제하면 될 수도 있지 않을까.

물론 위에 앞서 말한대로 그대로 복제하는 즉시 복제된 앱은 작동하지 않게 될 거라고 예상중이야.

하지만 그게 실패인건 아니야.

복제된 앱은 작동은 안하더라도 내부는 들여다 볼 수 있잖아.

그 내부에서 보이기 시작한 스키마들 이라거나 토큰들 또는 여타 여러 수많은 구조들에 대한 정보들을 참고하여 내가 만든 앱 내부에다가 짜 넣거나 파악된 구조를 기반으로 다시 새로운 결론을 고민해 보면 되지 않을까?

 

"에에~ 뭣도 모르고 뇌피셜 지리네...ios는 어플리케이션 설치 경로는 /var/mobile/Containers/Data/Application 인데 사파리나 브라우저로 다운로드한 파일이 위치하게 되는 경로는 /var/mobile/Containers/Shared/AppGroup/~~ 이런 식으로 모두 다른데 어차피 애플리케이션이 깔릴 경로에 위치하게 될 앱에다가 내장 스키마들을 넣는다고 해서 작동할 거라는 보장도 없잖아?"

 

맞아. 

그리고 거기다 추가로 좀 더 덧붙이자면 심지어 내장 프로그램이 아닌 앱스토어에서 다운받은 앱을 복제해서 폰에 넣는다고 해도 빌드한 기기와 업체명이 다를 경우 유효하지 않은 회사라고 오류가 나(해봄..ㅎㅎ)

하지만 그 모든것도 수정하고 고쳐버리면 해결되는 문제라고 생각해.

그리고 그건 이미 성공한 것 같아.

물론 많은 추가적인 기능들을 넣진 않았지만 복제해서 어떤 조건을 지켜 빌드해야 정상적인 앱으로 인식하고 작동하는지에 대해 필요한 정보들은 대부분 확보한 것 같아.

이번엔 똑같이 실험하되, 내가 원하는 기능들을 주고받을 수 있게 조금 더 수정하면 거의 다 온게 아닐까 싶어.

거기에 내 앱에는 ios에서 스크립트를 돌릴 수 있는 기능을 주고 내 앱과 수정한 앱의 상호작용만 가능하도록 연결시켜 주기만 하면 끝나는 문제라고 생각해.

 

앱 내부 경로와 구조, 데이터 등을 포함한 모든 아이폰 내부를 XXXX XXXX 가능했고,(이미)

불필요한 부분들까지 죽이고 변형시켜가며 뚫는 것 만이 해킹이 아닌 필요한 부분만을 정확히 짚어 뽑아내는게 어쩌면 최적의 해킹 방법이 아닐까 하고 생각하기도 하는 중이야.

물론 내 목적은 해킹이 아니지만 말이야.

일단은 여기까지 기록해두고 이어서 하러 가야겠어.

블로그 대부분의 글 들이 대부분 다 공개라서 혹시라도 무슨 이슈라도 생길 까 싶어 많은 부분을 못 적는게 너무 아쉬워.

반응형
SMALL