블로그 이미지
안녕하세요~ iolate(isho) 의 블로그 입니다~! iolate

카테고리

분류 전체보기 (163)
Server, Cloud (7)
끄적끄적 (6)
Linux, Ubuntu (23)
개발질 (45)
Mac (18)
iOS (23)
IoT (15)
NAS (1)
Web (5)
Network (3)
Review (10)
기타 (7)
비공개글 (0)
Total613,162
Today147
Yesterday175

'트윅'에 해당되는 글 2건

  1. 2013.03.02 [번역] MobileSubstrate의 위험들
  2. 2013.03.02 트윅 제작을 쉽게 하는 툴들 (5)

글 자체를 통째로 번역해보는 건 처음이네..ㅋㅋ

시디아 지역화 파일 정도 번역같은건 해봤지만.....


오역, 이상한 번역투, 이해 잘못한거, 번역 못한거, 빼먹은 거 등 수정 해주시면 감사합니다~


원문 : http://iphonedevwiki.net/index.php/MobileSubstrate_Pitfalls


#: 번역 주

확장기능(extension) 은 MobileSubstrate Extensions. 즉 트윅을 뜻하는 거임

주황색 : 번역 안됨 혹은 정확한 의미를 모르겠음


===========================================================


일반적인 MobileSubstrate 의 실수들을 막기 위해서 아래 가이드 라인을 따를 것.


1. SpringBoard 를 후킹할 경우 constructor 에서 UIDevice 를 사용하지 말 것

# constructor 는 theos 의 %ctor 나 +(void)load 와 같은걸 의미하는 듯. SpringBoard 가 완전히 로드된 후에는 사용해도 된다.


2. ivar 에 접근할 때는 적절한 property 들을 통해 사용


3. 본래 작업이 동작하지 않게 하는것이 필요하지 않다면 항상 본래 작업을 호출할 것. 또한 원래 작업은 그 메소드 내부에서만 호출해야 함.

# 쉽게 말하자면 꼭 필요한게 아니라면 %orig 를 빼먹지 말고, %orig 는 후킹한 메서드 안에서만 쓰란 얘기


4. MobileLoader 필터를 항상 포함할 것

SpringBoard 를 후킹한다면 com.apple.springboard 를, 모든 UIKit 앱들을 후킹한다면 com.apple.UIKit 필터를 사용하면 됨


5. SpringBoard 안에서 UIAlertView 사용을 피하고 SBAlertItem 을 재정의 해서 쓸 것. system이 경우에 따라 alert 을 무시해도 상관없다면 UIAlertView 를 사용해도 무방.


6. 공개된 SDK 에 기술된 API 들을 쓸 것. Private API 는 Apple이 Public 이전에 테스트 목적으로 넣어둔 경우가 많으며 이 후 버젼에 같거나 비슷한 Api 가 Public 으로 공개된다.


7. Preferences 프레임워크는 iOS 버젼 3.1 과 3.2 사이에 크게 변했다. 간단한 설정엔 PreferenceLoader 와 preferences plist 를 사용하고, 아니라면 PSViewController와 UITableView 를 함께 써라. (PSListController 또한 간단한 설정에 쓰면 좋고 OS 버젼에 따른 큰 차이가 없다. PSViewController 는 훨씬 강력하지만, 3.1->3.2 로 넘어오면서 많은 메서드들이 없어졌다.)

# 나의 경우엔 UIViewController 에 -(void)setRootController:(id)controller, -(void)setParentController:(id)controller, -(void)setSpecifier:(PSSpecifier *)spec, -(PSSpecifier *)specifier, -(void)lazyLoadBundle:(id)bundle 등을 대충 정의해준 뒤 쓴다.


8. 해상도나 기기 방향에 대해 별문제 없도록 autoresizingMask 나 layoutSubviews 를 적절히 써줄 것.


9. OS 나 Cydia 파일을 변경하지 말 것. 런타임 중에 변경되도록 할 것.

# WinterBoard 가 이미지 파일을 런타임으로 변경하는걸 생각하면 이해가 쉬움. 즉 후킹하란 소리


10. 쓸데 없는 작업들은 피할 것. 확장기능의 메서드 들은 타이트한 loop 속에서 실행 된며 디스크 파일 접근이나 property 를 호출하는 것 같은 작업은 많은 일을 하는 것을 고려할 것. 작업이 느려질 수 있음.

# 하지만 경험상 별 상관없음. ctor 나 load 등 최초 실행중에 삽질만 안하면 거의 문제 안남


11. UIImage 를 포함한 UI~~ 메서드들은 반드시 main thread 에서 실행되어야 한다. 백그라운드에서 이미지를 불러와야 한다면 CGImageSource 와 그 계열 함수들을 사용.


12. main thread 를 붙잡고 있지 말 것. 어떤 작업이든 오랜 시간이 걸리는 작업(인터넷 연결을 포함하여)을 main thread 에 두는 것은 좋지 않다.


13. NSBundle 을 통하여 리소스를 사용할 것. 이것은 WinterBoard 가 theme를 적용시킬 수 있게 해준다.

# 하지만 난 NSBundle 을 한번도 쓴 적이 없지 ㅋ


14. 적절한 의존성을 Debian control 파일 안에 포함할 것. 시디아가 자동으로 설치해 줄 것이며, OS 버젼과 같은 문제가 있을 경우 이를 사용자에게 알려준다.


15. 확장기능이 다른 확장기능이 사용할 수 있는 API 를 포함한다면, 이를 기술할 것.

찾기 쉽게 패키지 안에 헤더파일을 포함해 놔도 좋다.


16. 확장기능이 지역화될 수 있도록 할 것. 일반적인 .lproj 파일을 사용하면 된다. 텍스트를 포함한 이미지 사용은 지양.


17. package 가 .DS_Store / ._* / thumbs.db 같은 파일들을 포함하지 않도록 할 것

# 포함될 경우, 필요 없는 파일이기도 하고 저 파일들이 포함된 또 다른 패키지들이 있을 경우 설치가 안될 수가 있다. make package 가 아니라 직접 dpkg 할 경우 곧잘 포함되서 좀 짜증남;;ㅋㅋ


18. 클래스의 ivar 구조를 추정하지 말 것. 펌웨어 버젼에 따라 달라질 수 있다.

# 말그대로 구조. 구조를 토대로 메모리 주소로 값들을 사용하지 말란 거지 변수이름을 토대로 ivar 을 얻어오는 것과는 다른 얘기인 듯.


19. substrate.h, CaptainHook, Logos 와 같은 인정받은 후킹 메서드들을 사용할 것. 직접 만든것 보다 더 좋으며 당장 사용할 수 있는 자세한 정보들이 많다.


20. low-level 그래픽 하드웨어에 접근할 일이 있다면, 1세대 기기들은 통일된 메모리 모델을 가지고 있지 않음에 주의. (VRam 과 규칙적인 RAM 은 분리되어 있다.)

# 뭔소린지 모르겠지만 우린 1세대 기기와는 상관없으니 무시.


21. iOS의 Memory-Warning 시스템에 참여할 것. 확장기능이 많은 메모리를 사용한다면, 가능한 모든 것들을 해제할 것.


22. 큰 dataset 을 사용할 경우 mmap 을 사용. 커널이 필요에 따라 스왑할 것이다. (하지만 큰 작성은 피할 것, 가상메모리 보다 나은게 없어질 것이다.)

# 뭔소린지 모르겠다..


23. MobileSubstrate의 Safe Mode 를 방해하지 말 것


24. 확장기능이 홈화면의 아이콘을 다룬다면, IconSupport 를 사용함으로써 다른 확장기능의 수정이나 safe-mode layout 을 건드리지 말 것.


25. 가능한 최신의 펌웨어를 지원할 것 - "3.0.1, 3.1 이후 지원" 말고 "3.0 부터 지원" 이렇게 하란 뜻. 필요하다면 버젼을 감지해서 다르게 작동하도록 만들 것.


26. 사용자의 개인정보를 존중할 것.

IMEI, 전화번호, 연락처, 메일은 명백히 개인정보이다.

MAC 주소, Bluetooth MAC 주소, UDID 같은 것이 유저를 식별하기 위한 정보로 사용될 수 있다.


27. 숨겨야 할 것이 있다면, Strip symols 할 것. Objective-C 는 자세한 것까지 보여주니 일반적인 C 나 C++ 을 사용할 것

# 사실 그래도 다 보임. inline 으로 쓰고, ldflags 에 -Xlinker -unexported_symbol -Xlinker "*" 을 넣으면 그나마 덜 보인다고 함.


28. 많은 Private Framework 의 헤더들은 Mac 용 Public Framework 로 공개되어 있으니 그거 쓰면 됨. 혹은 다른 사람들이(kennytm 등) 추출해 놓은 header 들을 사용.


29. 사용하는 Framework 만 링크할 것. 필요없는 프레임워크의 링크는 실행 속도를 저하시킬 수 있음. (앱이 실행된 이후 런타임에서 라이브러리를 로드하기 위해서는 dlopen/dlsym 을 사용)

iOS3.1 이후에는 dyld shared object cache 덕분에 크게 상관 없음. 그래도 필요없으면 뺄 것.


30. Class 이름이나 Category 이름 앞에 Prefix 를 붙여 사용할 것. Objective-C 는 Namespacing capabilities 를 사용하지 않는다. (예를 들어 같은 이름의 클래스가 확장기능과 그 확장기능이 후킹한 앱에서 사용된다면 둘중 하나는 제대로 작동하지 않을 수 있음.)

# 이거 중요함. 이거 때문에 뜬금없이 앱이 오작동하는 일이 많다. UIKit 이나 Foundation 에 카테고리로 메서드를 추가할때도 특히 유의. 예를 들자면(실제 경험) UIView 에 viewController 라는 메서드를 새로 정의해놨는데 이게 앱에서도 똑같은 이름으로 정의해놨지만 앱쪽은 코드가 조금 달랐는지 앱이 제대로 작동 안했었음. 중복될 만한 클래스 명이나 메서드명 앞에는 A_ 같은 식으로 prefix 를 넣어주자. 수정해주기 귀찮으면 define 으로 처리해도 됨.


31. 설정 파일은 /var/mobile/Library/Preferences/ 안에 넣어둘 것. iTunes와 iCloud 가 이것을 백업한다.


32. sandbox 제한을 피해서 데이터를 저장하기 위해서는 필요에 따라 /var/mobile/Library/AddressBook/ 이나 /var/mobile/Library/Keyboard/ 를 사용.

# 샌드박스를 깨주는 라이브러리(혹은 트윅)도 있는 것으로 앎. 필요하다면 알아서 검색~


33. 잠자기에서 폰을 깨우거나 잠자기에 들어가는 것을 방해하지 말 것. 확장기능이 주기적으로 해야할 일이 있다면 Mail 앱의 동기화 부분을 후킹하여 사용. (스케쥴/알람 기능을 가지는 확장기능 들은 이 경고를 무시해도 된다.)


34. 배터리를 위해서 사용자가 예상할 수 없는 CPU, GPU, 디스크 작업은 피할 것


35. NSLog, CFLog, fprintf(stderr, ...) 등을 남용하지 말 것. 이것은 느리고 동기적(?, synchronous)이다.


36. 확장기능이 아이콘을 보여준다면, 29*29와 59*60의 사이즈를 둘다 포함할 것 (more for iPad.)


37. 다른 확장기능이 같은 메서드를 후킹할 것을 염두에 둘 것. 그들은 이 가이드라인을 읽지 않고 미친 짓을 할 수도 있다.


38. Prefer hooking methods over hooking functions--new jailbreaks don't always have kernel patches (although this is not as much of a concern, as jailbreakers understand the need for W^X) and MobileSubstrate may not support newer ARM instructions.

# 뭔소린지 잘 모르겠지만 low-level 의 함수들은 가급적 후킹하지 말란 소리 같음..


39. Public API를 후킹할 경우 return 값의 클래스를 바꾸지 말 것. 일부 AppStore 앱들은 객체의 클래스를 확인하지 않고 문제를 일으킨다.


40. XML 보다 더 빠른 binary plist 를 선호할 것. (OpenSTEP 스타일의 plist 또한 빠르지만 deprecated 된 것으로 보임.)

# binary plist 는 어떻게 만드는건지 모르겠다. 그냥 NSDIctionary 에 있는대로 써도 됨


41. Cocoa 메모리 관리 가이드 라인에 따라 모든 후킹에서 한줄한줄 정확하게 메모리 관리를 할 것.


42. MSHookMessage 대신 MSHookMessageEx 를 사용할 것.

MSHookMessage allows you to specify an optional prefix which gets added to the original method, polluting the class.

Posted by iolate

나같으면 @deVbug0 님의 도움을 아~주 많이 받았지만

도움을 못받는 사람도 있을거고 안받을려는 사람도 있을거고.....


뭐 여튼 트윅제작에 대해 대충 써본다. (사실 나도 잘 모른다)


0. Tweak?

트윅을 시디아스토어에 올라온 모든 앱을 통칭하는 정도로 쓰는 사람들이 있는데 그건 아니다.


Tweak 의 사전적 의미는 뒤틀다, 수정하다 정도가 된다.

이 의미에서 알 수 있듯이 Tweak 은 이미 있는걸 수정하는 앱이다.


대표적으론 SBSettings 와 Activator 같은 것들.

이미 있는 SpringBoard(잠금화면, 홈화면 등을 주관하는 앱이 SpringBoard 이다.)를 수정하여

SBSettings 를 보이게 하고, 특정 동작에 대해 다른 작업을 할 수 있게 하는 것이다.


이를 위해서 다른 앱을 후킹해야 하는데 이 작업을 saurik 이 MobileSubstrate 란 앱으로 잘 해결해 놨다.

이부분에서 잘은 모르겠지만 앱 실행시 트윅용으로 제작된 동적라이브러리를 MobileSubstrate 가 강제로 load 시키는 듯?

탈옥툴의 성능(?)이나 MobileSubstrate 의 한계 등으로 후킹이 안되는 것들도 있다던데 이부분은 여전히 이해가 안간다..


여튼 iOS 내에선 저런게 있고, 개발시에는 substrate.h 의 함수들이 있지만 CaptainHook 나 logos(theos 에서 사용가능한 언어)로 쉽게 후킹가능하게 만들어져 있다. theos 의 경우 후킹하기가 매우 쉬움!



1. THEOS

본래는 크로스컴파일러로 시작한 것 같은데 어차피 컴파일러 등 맥이 필요한게 사실이고

사실상 맥에서만 돌아간다.(삽질을 많이 하면 리눅스기반에서도 돌릴 수는 있는 듯)

나의 경우 처음엔 템플릿을 내려받아 xcode 에서 mobilesubstrate base (즉 트윅) 를 개발했었는데

여러가지로 불편한 점도 많고 강력한 logos 언어를 사용할 수 없어서 theos 로 돌아왔음.


또한 초기에 PreferenceBundle 을 제작하고 싶어도 어떻게 할 줄을 몰라서 생ㅈㄹ을 했었는데

그냥 theos 로 만드는 거였음...ㅠㅠ


여튼 그래서 대부분의 트윅이 theos 로 컴파일 된다고 보면 된다.

사실 이 theos 는 ios 에서도 설치, 사용할 수 있는데 ios sdk3 까지 밖에 지원하지 않는다.

다른건 상관없는데 새로 등장한 코딩기법(예를 들면 블럭코딩 등)을 사용할 수 없고 이에 따른 제약들이 있다..


맥용 설치 / 사용법은 아래 주소.. 참고로 쨋든 xcode 의 설치가 필요함.

devbug 님 이 쓰신게 한글이니 걍 저거 보고 하면 된다 ㅋ

http://devbug.me/629

http://brandontreb.com/beginning-jailbroken-ios-development-getting-the-tools/



2. Cycript

나도 뒤늦게 알았다..

그리고 매우 신기하다!!

(시디아에서 설치하거나 apt-get install cycript 로 설치할 수 있다.)


이미 실행중인 프로세스에 붙어서 메서드 들을 실행할 수 있다

테스트 같은거 할때 매우 편리!!

좀더 이해할 수 있게 말하자면.. 

터미널에서 SpringBoard 에 연결해서 아이폰에 SpringBoard 가 돌아가는 상태로 바로 AlertView 를 띄우거나, 메서드 값을 확인하거나, 후킹을 하거나(이건 좀 복잡하드라) 등등이 가능하다!!


디버거 같은거일텐데 내가 디버거를 안써봐서 잘 모름;;ㅠㅠ


자바스크립트를 obj-c 로 바꿔준다고 자바스크립트가 기본이라는데 변수 선언을 var 로 하는거 말고는 딱히 왜 자바스크립트 인지 모르겠다.

여튼 좋음. 좋다! 걍 한번 써봐라 트윅제작을 한다면 계속 끼고 살게 될것임!



3. logify.pl

써보진 않았고, @typ0s2ud10 님이 트윗에 쓰셔서 알게 된거..

$THEOS/bin/ 에 있다.

헤더 파일을 input 으로 집어 넣으면 이 헤더에 선언된 메서드들을 모조리 후킹해서 호출될때 로그를 찍고 실행되게 만들어 준다.



4. symbolicate

앱이 작동하다 에러로 뻗어버릴때 에러로그는 두가지 방식으로 나온다(난 두개밖에 못봤다)

1. 어떤 메소드가 왜 문제였는지 시스템 로그에 뜸

2. 크래쉬 로그


어떨때 시스템 로그에 보여주고 어떨때 크래쉬 로그인지 잘은 모르겠지만 여튼 대충 저렇다.

첫번째의 경우 문제를 잡아내기 그나마 편리하지만 크래쉬 로그는 사실상 도움이 안된다..(아주 간혹 될때도 있음)

내가 못하는건진 모르겠지만 일반적인 앱이 사용하는 symbolicate 방식으론 이상한 결과만 나오더라.


여튼 그때 쓸 수 있는 ashikase 작품. 시디아에 라이브러리로 있다. https://github.com/ashikase/symbolicate

사실 이 역시 제대로 써보지도 않았고 작동법도 모른다.

tsProtectore 리포트 하기를 누르면 가장 최근의 크래쉬 로그를 symbolicate 로 보내는데 이걸 내 메일로 받아보니 쓸만 하겠더라.


메모리 주소를 메서드 명으로 다 바꿔주는 건 물론, 후킹을 했을 경우도 어떤 트윅이(dylib 파일명이 나옴) 어떤 메서드를 후킹했는지 알 수 있다. 또한 한 메서드를 두개의 트윅이 후킹했다면 각각이 어떤 메서드를 후킹한건지도 나온다.(물론 크래쉬 나기 이전 몇스텝 이내의 작업결과에 한해서.)


요즘엔 개발을 안해서 쓸일이 없지만 하게 된다면, 혹은 버그리포팅을 받을때 유용하게 쓸수 있을듯.

혹은 경우에 따라서 일부로 크래쉬를 내서 후킹할 메서드를 찾는 것도 도움이 될 것 같다;;




이제 나름 상당히 안다 싶었는데 여전히 모르는거, 못하는게 산더미 같이 많은 것 같다..ㅠㅠ

그리고 c 쪽이나 디버깅 같은걸 전무하다 싶을 정도로 모르니...ㅠㅠ

Posted by iolate

최근에 달린 댓글

최근에 받은 트랙백

글 보관함