نگاهی بر جیلبریک از گذشته تا امروز ( قسمت چهارم )

سلام به شما دوستان اپل اپسی عزیز, در ادامه‌ی قسمت سوم مقاله‌ی نگاهی بر جیلبریک از گذشته تا امروز به بررسی باینری ابزار TaiG میپردازیم.

در جلسه قبل موفق شدیم که فایل dmg یا همان DDI دستکاری شده را که دارای dylib های مورد نظر ماست را ماونت کنیم.

input

اگر فایل libmis.dylib را با jtool باز کنیم با خروجی های زیر رو به رو میشویم:

mahyarrezghi@Mahyars-Mac (~/Documents/iOS/JB/TaiG) % jtool -l /Volumes/DeveloperLib/libmis.dylib

Fat binary, big-endian, 3 architectures: armv7, armv7s, armv8
Specify one of these architectures with -arch switch, or export the ARCH environment variable

# دقیقا همان فایل هایی که در جیلبرک evasi0n استفاده شده بود!

mahyarrezghi@Mahyars-Mac (~/Documents/iOS/JB/Pangu) % ARCH=armv7 jtool -S /Volumes/DeveloperLib/libmis.dylib

I _MISValidateSignature (indirect for _CFEqual)
I _kMISValidationInfoEntitlements (indirect for _kCFUserNotificationTokenKey)
I _kMISValidationInfoSignerCertificate (indirect for _kCFUserNotificationTokenKey)
I _kMISValidationInfoSigningID (indirect for _kCFUserNotificationTokenKey)
I _kMISValidationInfoValidatedByProfile (indirect for _kCFUserNotificationTokenKey)
I _kMISValidationOptionAllowAdHocSigning (indirect for _kCFUserNotificationTokenKey)
I _kMISValidationOptionExpectedHash (indirect for _kCFUserNotificationTimeoutKey)
I _kMISValidationOptionLogResourceErrors (indirect for _kCFUserNotificationTokenKey)
I _kMISValidationOptionUniversalFileOffset (indirect for _kCFUserNotificationTokenKey)
I _kMISValidationOptionValidateSignatureOnly (indirect for _kCFUserNotificationTokenKey) U _CFEqual
U _kCFUserNotificationTimeoutKey
U _kCFUserNotificationTokenKey
U dyld_stub_binder

mahyarrezghi@Mahyars-Mac (~/Documents/iOS/JB/TaiG) % ARCH=armv7 jtool -l /Volumes/DeveloperLib/libmis.dylib

LC 00: LC_SEGMENT Mem: 0x00000000-0x00001000 __TEXT
Mem: 0x00001000-0x00001000 __TEXT.__text (Normal)
LC 01: LC_SEGMENT Mem: 0x00001000-0x00002000 __LINKEDIT LC 02: LC_ID_DYLIB /usr/lib/libmis.dylib
..
LC 15: LC_CODE_SIGNATURE Offset: 38576, Size: 752 (0x96b0-0x99a0) LC 16: LC_SEGMENT Mem: 0xfffff000-0x1ffff000 __DATA

mahyarrezghi@Mahyars-Mac (~/Documents/iOS/JB/TaiG) % ARCH=armv8 jtool -l /Volumes/DeveloperLib/libmis.dylib

LC 00: LC_SEGMENT_64 Mem: 0x000000000-0x4000 __TEXT
Mem: 0x000004000-0x000004000 __TEXT.__text (Normal)
LC 01: LC_SEGMENT_64 LC 02: LC_ID_DYLIB
..
LC 16: LC_SEGMENT_64
Mem: 0x000004000-0x8000 __LINKEDIT /usr/lib/libmis.dylib
Mem: 0xffffffffffffc000-0x1fffc000 __DATA

فایل جایگزین libmis که توسط TaiG نوشته شده چندان هم کامل نیست به همین دلیل ممکن است گاهی در زمانی که نتواند کد ها را تایید کند, کرش کند.

{“app_name”:”amfid”,”app_version”:””,”os_version”:”iPhone OS 8.1.2 (12B440)”, “slice_uuid”:”b99c5334-10f8-3014-865b-b0977d6f1a45″,”share_with_app_devs”:false, “build_version”:””,”is_first_party”:true,”bug_type”:”109″,”name”:”amfid”}

Incident Identifier: 59E17AA8-469A-4395-AC6B-53C1F2B9657B CrashReporter Key: a72d111b6b52f7c1ae1360e923e7c0da675b9261

Hardware Model: iPhone7,2

Process:
Path: Identifier: Version:
Code Type: Parent Process:
Date/Time: Launch Time: OS Version: Report Version:
ARM-64 (Native) launchd [1]
0400- 08:13:39.385 2015-05-21 0400- 08:13:21.101 2015-05-21
iOS 8.1.2 (12B440) 105
amfid [22] /usr/libexec/amfid
amfid ???

Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x00000001200fd088 Triggered by Thread: 2
Dyld Error Message:
Symbol not found: _MISCopyInstalledProvisioningProfiles Referenced from: /usr/libexec/amfid
Expected in: /usr/lib/libmis.dylib
Dyld Version: 353.6

خوب بخش سخت ماجرا تمام شده و تنها یک بخش دیگر باقی مانده است, آن هم پروسه ای است که به untether معروف شده و در واقع در هر بار ری استارت کردن سیستم تمامی این کار ها را به صورت اتوماتیک انجام میدهد! /taig/taig نام این فایل دوست داشتنی است که در انتهای پروسه اجرا شده و دستگاه را ری استارت میکند. (قبل از ری استارت شدن دستگاه کار هایی مانند مانت کردن روت, و انتقال فایل های کش شده به یک محل دائمی و اضافه کردن /DeveloperPatch که شامل AFC2 است و به ما اجازه میدهد تا به پوشه / که بالاترین سطح است دسترسی پیدا کنیم.)

تا اینجا برنامه TaiG عدد ۴۰% را نشان میدهد و با پیغام زیبای Success از ما پذیرایی میکند و سپس پیغام injecting jailbreak program را به ما نشان میدهد. حالا فایل taig/taig/ میتواند اجرا شود. میتوانید این فایل را از لینک زیر دانلود کنید:

دانلود باینری TaiG از وبسایت شخصی بنده

جالب ترین بخش کار بررسی فایل taig است:

mahyarrezghi@Mahyars-Mac (~/Documents/iOS/JB/TaiG) % file taig
/Volumes/VMware Shared Folders/iOS/JB/taig/taig: Mach-O universal binary with 2 architectures
/Volumes/VMware Shared Folders/iOS/JB/taig/taig (for architecture armv7): Mach-O executable arm
/Volumes/VMware Shared Folders/iOS/JB/taig/taig (for architecture arm64): Mach-O 64-bit executable

چیزی که با نگاه کردن به خروجی های بالا معلوم میشود این است که فایل taig به صورت universal نوشته شده است و هم روی دستگاه های ۳۲بیتی و هم ۶۴بیتی (آیفون 5S و آیپد ایر به بعد) کار میکند.

من در این مقاله فایل taig را تحت معماری ۶۴بیتی بررسی میکنم, اما معماری ۳۲ بیتی هم تا حد زیادی به همین شکل است.

اگر به یاد داشته باشید موقعی که این جیلبرک عرضه شد بسیار از هکر های قدیمی تر به مردم اعلام کردند که فعلا از این جیلبرک استفاده نکنند تا صحت کار آن مشخص شود و مبادا به بد افزاری آلوده باشد. پس قطعا آن ها هم تمامی این مراحل را طی کردن تا به این فایل برسند زیرا این فایل مهم ترین فایل این جیلبرک است. اما چگونه فهمیدند که این فایل آلوده نیست؟

شما با نگاه کردن به عکس مربوط به بررسی فایل با نرم افزار jtool و لیست فایل های مورد نیاز و آبجکت های فراخوانی شده به راحتی میتوانید تایید کنید که هیچگونه فایل یا کد مخربی در این جیلبرک استفاده نشده است.

  • خروجی که با کادر قرمز مشخص کردم به ما نشان میدهد که این فایل به هیچ عنوان کد گذاری نشده و ما میتوانیم تمام محتویات آن را ببینیم که همین امر نیز میتواند دلیلی بر آلوده نبودن این فایل باشد.
  • قسمتی که که با کادر سبز مشخص کردم به صورت پیشفرض در Xcode وجود دارد, پس قرار دادن بدون تغییر قطعا یک اشتباه در برنامه نویسی بوده است.

برای اجرای این فایل یک سری پیش نیاز ها فراخوانی میشود که در بین دو کادر قرار دارند, که میتوانید در زیر کار هر یک از آن ها را مشاهده کنید:

libsystem.B: بدون این فایل هیچ برنامه یا فایلی نمیتواند پیش نیاز های خود را فراخوانی کند, میتوان کار این فایل را مانند Kernel32+NtDll+MSVCRT در ویندوز و همچنین libc.so در لینوکس در نظر گرفت.

libc++: نشان میدهد که در این برنامه از ++c هم استفاده شده است.

libobjc و Foudation/CoreFoundation: نشان دهنده ی استفاده شدن از Objective C است.

IOKit: مهر تاییدی بر این موضوع است که عملیات پچ کردن کرنل توسط این فایل انجام میشود.

libafc.dylib: در بررسی این فایل من نتوانستم اطلاعات دقیقی از استفاده این پیش نیاز در اینجا به دست بیاورم!

Screen Shot 1394-08-07 at 21.34.26

موقعی که در مکینتاش این فایل را بررسی میکردم مشاهده کردم که طبق اعلام مکینتاش این فایل ساین نشده است و عملا اجرا شدنش در iDeviceیک معجزه است! اما معجزا ای درکار نیست و با با یک دستور ساده توسط jtool میتوانیم به راز این عمل پی ببریم:

mahyarrezghi@Mahyars-Mac (~/Documents/iOS/JB/TaiG) % JCOLOR=1 jtool -arch armv8 –sig -v –ent taig
Blob at offset: 112416 (1104 bytes) is an embedded signature of 1089 bytes, and 3 blobs
Blob 0: Type: 0 @36: Code Directory (709 bytes) Version: 20001
Flags: none (0x0)
Identifier: taig
CDHash: 09059af87d64372658826d73e419d42383e2cd75
# of Hashes: 28 code + 5 special
Hashes @149 size: 20 Type: SHA-1
Entitlementsblob: 3b3feeeb6676cb7bcd61e03436a8a39742feb44c(OK)
Application Specific: Not Bound
Resource Directory: Not Bound
Requirements blob: 3a75f6db058529148e14dd7ea1b4729cc09ec973 (OK)
Bound Info.plist: Not Bound
Slot 0 (File page @0x0000): b00b96b29f6a86c3bf2538d5b94c5d5a9ee0429e (OK)
Slot 1 (File page @0x1000): 1ceaf73df40e531df3bfb26b4fb7cd95fb7bff1d (OK)
# تمامی اسلات ها دارای هش سالم بودند به همین دلیل برای خلاصه شدن کد آنها را حذف کردم
Slot 27 (File page @0x1b000): bf05426e9a67734564f1e8bcd752885fd6182b05 (OK)
Blob 1: Type: 2 @745: Empty requirement set
Blob 2: Type: 5 @757: Entitlements (332 bytes)

<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE plist PUBLIC “-//Apple//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList-1.0.dtd”> <plist version=”1.0″>
<dict>
<key>platform-application</key> <true/> <key>get-task-allow</key> <true/> <key>task_for_pid-allow</key>
<true/> </dict>
</plist>
#
# Normally, there’d be a (potentially empty) CMS (RFC3852) signature blob here. This confuses codesign
Superblob ends @36

  • تمامی هش ها سالم میباشند
  • فایل با شناسه taig ساین شده است
  • امضاء فایل به شکل ad hoc نیست (این نوع امضا ها برای فایل ها نوشته شده توسط اپل استفاده میشوند و همچنین در Xcode هم برای ساین کردن برنامه ها به صورت ad hoc وجود دارد)
  • این فایل شامل entitlement است که حتی قابلیت دیباگ کردن هم در آن فعال است

<key>get-task-allow</key> <true/>

مهمترین دلیل اینکه این فایل حتما باید ساین شده باشد این است که ابتدا جلوی اجرا شدن پیش از موعد فایل توسط AMFI.kext گرفته شود و دوم اینکه entitlement هایی که در بالا ذکر شد در حافظه کرنل ذخیره میشود و سیستم عامل دیگر راهی برای تغییر دادن آنها ندارد در نتیجه میتوانیم همیشه از نعمت استفاده از کد های ساین نشده استفاده کنیم.

platform-application: من به این مشخصه لقب قاتل سندباکس را میدهم, چراکه در حالت عادی جلوی هر کدی که خارج از سندباکس اجرا شود, توسط amfid گرفته میشود, اما با این مشخصه ما به amfid اعلام میکنیم که این فایل یکی از برنامه های سیستم عامل هست در نتیجه مشکلی برای اجرا شدن ندارد.

get-task-allow و task_for_pid_allow: این دو دستور بخشی از دستور های اصلی اپل برای دیباگ کردن برنامه ها هستند که به ما اجازه بارگذاری هر پروسه ای توسط یوزر روت را میدهند.

در واقع در زمانی که این فایل میخواهد اجرا شود چیز هایی که اتفاق می افتد به این شکل است:

۱. برنامه اجرا میشود

۲. AMFI.kext پروسه را نمی بندد زیرا فایل مورد نظر ساین شده است!

۳. وقتی که AMFI.kext میبیند امضاء برنامه از نوع Ad Hoc نیست و با نام خاصی ثبت شده است نتیجه میگیرد که این یکی از برنامه های ثبت شده در App Store است پس از amfid با استفاده از دستور معروف HOST_AMFID_PORT میخواهد که یکبار دیگر فایل را چک کند

۴. اگر amfid هنوز اجرا نشده باشد, launchd آنرا اجرا میکند و دستور را انتقال میدهد.

۵. amfid-imwit فایل libmis.dylib را اجرا میکند, اگر به خاطر داشته باشید این فایل در مرحله قبل توسط فایل مورد نظر ما جایگزین شده بود! پس دستور سالم بود امضای فایل را میدهد

۶. AMFI.kext هم با کمال میل اجازه میدهد که فایل ما با سطح دسترسی روت اجرا شود.

بار اولی که این فایل میخواهد اجرا شود به صورت taig –s اجرا میشود و این وقتی است که پیغام injecting the jailbreak program را روی برنامه مشاهده میکنید.

هشدار خیلی خیلی مهم: به هیچ عنوان این دستور را به صورت دستی و پس از جیلبرک اجرا نکنید! طبق تجربه شخصی taig آنقدر هوشمند نیست که بفهمد یکبار روی دستگاه نصب شده و نباید دوباره اجرا شود, اینکار باعث میشود تا این فایل دوباره ساخته شود ولی به صورت خالی! در تنیجه دستگاه دچار بوت لوپ میشود و حتی سرویس ssh هم اجرا نمیشود تا به داد شما برسد. و مجبور به ریستور به آخرین نسخه میشوید که جیلبرکی هم هنوز برای آن موجود نیست.

پروسه نصب شدن شامل کپی شدن فولدر taig/ که شامل دو فایل taig و lockdown_patch.dmg میشود.

Mahyars-iPhone:~ root# ls -lR /DeveloperPatch

/DeveloperPatch:
total 0
drwxrwxrwx 4 mobile staff 136 Oct 12 20:55 Library drwxrwxrwx 4 mobile staff 136 Oct 21 00:19 bin

/DeveloperPatch/Library:
total 0
drwxrwxrwx 4 mobile staff 136 Nov 27 2013 Lockdown

/DeveloperPatch/Library/Lockdown:
total 0
drwxrwxrwx 4 mobile staff 136 Oct 21 19:54 ServiceAgents

/DeveloperPatch/Library/Lockdown/ServiceAgents:
total 4
-rwxrwxrwx 1 mobile staff 179 Oct 21 19:54 com.apple.afc2.plist

/DeveloperPatch/bin:
total 28
-rwxrwxrwx 1 mobile staff 24928 Oct 12 23:36 afcd2

afcd2 نسخه غیر محدود سرویس afc است که در مرحله ی اول تمام این اعمال را برای ما ممکن کرد. محتویات فایل com.apple.afc2.plist:

<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE plist PUBLIC “-//Apple//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList-1.0.dtd”> <plist version=”1.0″>
<dict>

<key>AllowUnauthenticatedServices</key> <true/>
<key>Label</key> <string>com.apple.afc2</string> <key>ProgramArguments</key>

<array>
<string>/DeveloperPatch/bin/afcd2</string> <string>–lockdown</string> <string>-d</string>
<string>/</string>

</array> </dict>

برای اینکه مطمئن شویم که فایل ما در هر بار بوت شدن دستگاه اجرا میشود فایل com.taig.untether.plist در launchd ایجاد میکنیم:

<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE plist PUBLIC “-//Apple//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList-1.0.dtd”> <plist version=”1.0″>
<dict>

<key>Label</key> <string>com.taig.untether</string> <key>LaunchOnlyOnce</key> <true/> <key>POSIXSpawnType</key> <string>Interactive</string> <key>ProgramArguments</key> <array>

<string>/taig/taig</string>

23

</array> <key>RunAtLoad</key> <true/> <key>UserName</key> <string>root</string>

</dict> </plist>

خوب کار جیلبرک با موفقیت به اتمام رسید! اینجاست که دستور ری استارت شدن به دستگاه داده میشود و پس از روشن شدن مجدد شما یک iDevice با جیلبرک untether خواهید داشت.

در بخش بعد خواهید خواند

در بخش های بعدی به بررسی ابزار های دیگری خواهیم پرداخت و همچنین سعی میکنم تا بیشتر وارد بحث مهندسی معکوس فایل های سیستم عامل iOS بشوم.

اگر این مطلب براتون مفید بود لطفا به اشتراک بگذارید تا دیگر دوستانتان هم استفاده کنند؛ درضمن نظرات و سوال های خودتان هم درمورد جیلبریک و هم درمورد اطلاعاتی که در این باره میخواهید بدانید را در قسمت نظرات مطرح کنید.