باورهای اشتباه متداول در خصوص امنیت پلتفرم های موبایل

با وجود تهدیدات و آسیب‌پذیری‌های متنوع در حوزه امنیت اپلیکیشن‌های موبایل، بسیاری از برنامه‌نویسان و توسعه‌دهندگان برنامه‌های موبایلی و صاحبان کسب‌وکار حوزه اپلیکیشن‌ها، بر این باورند که برنامه‌های موبایلی آن‌ها پس از تولید دارای یک سطح امنیتی مورد قبول می‌باشد که از سوی ارائه‌دهنده پلتفرم (اندروید یا iOS) تضمین شده است. آن‌ها عموماً تصور می‌کنند که امکان دست‌کاری یا به‌اصطلاح Tampering اپلیکیشن ایشان وجود ندارد و یا این احتمال با توجه به تمهیدات امنیتی درنظر گرفته شده از سوی گوگل و اپل، خیلی کم است. بسیاری از این افراد غالباً از خریدهای درون برنامه‌ای یا تبلیغات برای کسب درآمد از کسب‌وکار خود استفاده می‌کنند. در این شرایط هرگونه امکان دست‌کاری یا تغییر اپلیکیشن که منجر به دور زدن مکانیسم‌های امنیتی بکار گرفته‌شده در درون برنامه شود، می‌تواند موجب ضررهای جبران‌ناپذیری گردد و مجموعه‌ای از چالش‌ها را از ضررهای مالی برای توسعه‌دهندگان و کاربران گرفته تا تأثیر بر شهرت، برند و ایجاد مشکلات کسب‌وکاری، ایجاد کند.

حال سؤال اینجاست که کدام پلتفرم موبایلی امن‌تر است؟ تقریباً عمده توسعه‌دهندگان و برنامه نویسان موبایلی از آسیب‌پذیری اپلیکیشن های اندرویدی در برابر مهندسی معکوس (Reverse Engineering) مطلع هستند و می‌دانند که کد برنامه آن‌ها قابل برگشت و تغییر و احتمالاً انتشار مجدد توسط هکرها و مهاجمین است. اما احتمالاً شما هم شنیده‌اید که خیلی‌ها بر این باورند که پلتفرم Apple iOS از این نظر دارای امنیت بالاتری است. اما متأسفانه باید گفت که این تصور رایج کاملاً اشتباه است و به طور کلی، یک اپلیکیشن iOS به همان اندازه که اپلیکیشن های اندرویدی امکان دست‌کاری دارند، مستعد تحلیل هکرها و اعمال تغییرات سودجویانه هستند.

همان‌طور که گفته شد این تفکر رایج وجود دارد که اپلیکیشن های موبایل در محیط iOS از امنیت بیشتری نسبت به اندروید برخوردار هستند و این باور معمولاً شامل موارد زیر است:

1- مکانیسم رمزنگاری کدها توسط App Store برای عدم امکان مهندسی معکوس اپلیکیشن کفایت می کند.

2- کد اپلیکیشن های iOS  بر نمی‌گردد یا این کار بسیار مشکل است.

3- مکانیسم sign اپلیکیشن ها در Apple از دست‌کاری کد و انتشار مجدد اپلیکیشن تغییریافته جلوگیری می‌کند.

اما همان‌طور که اشاره شد متأسفانه هیچ‌یک از گزاره‌ها و باورهای فوق صحیح نیست و این موضوع خود یکی از عوامل اصلی عدم امن‌سازی مناسب اپلیکیشن ها به‌ویژه در بستر iOS توسط برنامه نویسان و صاحبان کسب‌وکار است.

برای تبیین بهتر و نشان دادن این تصورات غلط در مورد امنیت پلتفرم موبایل، در این مقاله قصد داریم تا با بهره‌گیری از این مقاله و همچنین استفاده از یک سناریوی حمله واقعی، آسیب‌پذیری دست‌کاری کد یا Tampering را پیاده‌سازی نماییم. در این راستا یک تکه برنامه تبلیغاتی را در یک اپلیکیشن موبایل که در هر دو پلتفرم اندروید و iOS موجود است را به اصلاح Patch کرده و مجدداً آن‌ها را repackage کرده و انتشار می‌دهیم. همچنین نشان خواهیم داد که چگونه می‌توان مکانیزمهای امنیتی پیاده‌سازی‌ شده بر روی خرید درون برنامه‌ای را تقریباً بدون صرف زمان زیاد و به آسانی دور زد.

دست‌کاری یک اپلیکیشن موبایل نمونه در هر دو پلتفرم

در این بخش نشان خواهیم داد که در هر دو سیستم‌عامل ، به‌راحتی می‌توان تبلیغات موجود در یک اپلیکیشن را غیرفعال کرد و یا خریدهای جعلی را با استفاده از روش‌های زیر انجام داد:

• برنامه را برای تجزیه و تحلیل و همچنین تشخیص و یافتن کدها و بخش‌های مهم کد، دانلود می‌کنیم
• کد دلخواه خود را به اپلیکیشن اضافه کرده، آن را repackage کرده و روی یک دستگاه موبایل اجرا می‌کنیم
• اعمال تغییر و دست‌کاری در منطق اپلیکیشن، درحالی‌که در اپلیکیشن در حال اجرا می‌باشد (بدون نیاز به repackage)

با استفاده از این تکنیک‌ها، هکر یا مهاجم می‌تواند کسب‌وکارها را در معرض ریسک‌های امنیتی اشاره شده در بالا قرار دهد.

برای نشان دادن محدودیت‌های مکانیسم‌های امنیتی موجود در پلتفرم‌ها، همان‌طور که در تصویر زیر مشاهده می‌شود یک اپلیکیشن رایگان با نام "چراغ قوه" را در هر دو سیستم‌عامل مورد بررسی قرار می‌دهیم. از این قبیل اپلیکیشن ها می‌توان برای روشن کردن چراغ قوه استفاده کرد و معمولاً یک گزینه خرید درون برنامه‌ای برای حذف تبلیغات دارند.

 سناریوی حمله پیاده‌سازی شده در ادامه که به عنوان یک POC قلمداد می‌گردد، شامل سه بخش می‌باشد: تجزیه و تحلیل اپلیکیشن ها ، Patch و غیرفعال سازی تبلیغات و همچنین دور زدن خریدهای درون برنامه‌ای به‌صورت پویا برای هر دو اپلیکیشن.

تجزیه و تحلیل اپلیکیشن

در ابتدا قصد داریم اپلیکیشن ها را مورد تجزیه و تحلیل قرار دهیم تا بدین‌وسیله نحوه و به طوری کلی منطق بارگذاری تبلیغات را در اپلیکیشن متوجه شویم. برای انجام این کار، ابتدا باید اپلیکیشن ها را در رایانه خود دانلود می‌کنیم.

برای iOS ، ما از ابزار frida-ios-dump برای دریافت اپلیکیشن از دستگاه موبایل استفاده می‌کنیم. برای Android ، می‌توانیم آن را از دستگاهی به همان شیوه بیرون بیاوریم یا از یکی از ابزارهای متعدد آنلاین مانند https://apps.evozi.com/apk-downloader، که در این پست وبلاگ مورداستفاده قرار گرفته، استفاده کنیم. بدین ترتیب یک فایل IPA برای iOS و یک فایل APK برای Android مربوط به اپلیکیشن مذکور را برای تحلیل به دست می‌آوریم.

مهاجمین برای تجزیه و تحلیل منطق موجود در اپلیکیشن ها، معمولاً از Disassembler ) ابزاری که کدهای ماشین را به متن قابل خواندن برای انسان ترجمه می‌کند) و یک دی‌کامپایلر DeCompiler (ابزاری که کد ماشین را به کد اصلی تبدیل کند) استفاده می‌کنند. در این خصوص برای iOS ، ما از Hopper به عنوان یک Disassembler و همچنین دی‌کامپایل استفاده می‌کنیم. برای اندروید نیز Smali و decompiler JD مورداستفاده قرار می‌گیرد.

iOS

ما اپلیکیشن را در Hopper باز می‌کنیم و نام تابع حاوی "ads" را جستجو می‌کنیم. خواهیم دید که کلاس ALAdService پیدا می‌گردد. جستجو در این کلاس ما را به theAppLovin که یک SDK است می‌رساند که توسط این اپلیکیشن برای بارگذاری تبلیغات استفاده می‌شود. با نگاهی اجمالی به اپلیکیشن دموی AppLovin درمیابیم که تعامل اصلی توسعه‌دهنده از طریق کلاس  ALSdk انجام می‌شود.

اندروید

پس از بدست آوردن APK موردنظر شروع به جستجوی کلمه “ad” می‌کنیم. همان‌طور که در تصویر زیر مشاهده می‌نمایید، تابعbilling.d.a (Context) یافت می‌شود. اگر این تابع را کامپایل کنیم ، چیزی شبیه به این به دست می‌آید:

برای بررسی اینکه آیا تبلیغات باید نمایش داده شوند یا خیر ، اپلیکیشن ‌این تابع را فراخوانی می‌کند که shared preference با نام BillingSp را حاوی متغیر بولین ad را برمی‌گرداند. این مقدار صفر و یک (بولین) برای تصمیم‌گیری در مورد نمایش یا عدم نمایش تبلیغات استفاده می‌شود.

 شاید با خود بگویید که برای برخی از اپلیکیشن ها، ممکن است هنگام جستجوی "ad" هیچ چیز بدرد بخوری پیدا نکنیم و یا SDK تبلیغاتی مانند مثال بالا ممکن است در دسترس عموم نباشد. در این موارد هم امکان تجزیه و تحلیل کد وجود دارد ولی به تمرکز و جستجوی بیشتری نیازمندیم. مثلاً ممکن است مهاجم شروع به بررسی نام همه توابع نماید تا ببیند آیا مورد قابل تأملی برجسته می‌شود یا خیر. از سوی دیگر روش‌های متعدد دیگری نیز برای تجزیه و تحلیل اپلیکیشن ها توسط هکرها مورداستفاده قرار می‌گیرد. روش‌هایی نظیر بهره‌گیری از Debugger، مشاهده رشته‌ها و کاربردهای آن‌ها در باینری ، تجزیه و تحلیل نمودار فراخوانی‌ها و سایر موارد.

حذف تبلیغات و Repackage اپلیکیشن

اکنون که نحوه لود شدن تبلیغات را متوجه شدیم، شروع به تغییر و دست‌کاری اپلیکیشن ها خواهیم کرد تا آن‌ها را غیرفعال کند. نکته اساسی در این مرحله این است که از آنجا که این کار باعث تغییر اپلیکیشن اصلی می‌گردد، ساین یا امضای کد پس از تغییر دیگر معتبر نخواهد بود. می‌دانیم که هر دو سیستم‌عامل فقط اپلیکیشن‌هایی با امضای معتبر را می‌پذیرند. اما این امکان وجود دارد که اپلیکیشن ها را Repackage کرده و اپلیکیشن‌های اصلاح‌شده را با گواهینامه‌های ایجادشده توسط خودمان امضا کنیم. به این ترتیب ما یک نسخه اصلاح‌شده از اپلیکیشن را با امضای معتبر از سوی سیستم‌عامل دریافت می‌کنیم که می‌تواند بر روی هر دستگاهی نصب شود.

اکثر ابزارهای رایج Disassembler دارای یک اسمبلر داخلی نیز هستند که فرآیند را به‌صورت معکوس انجام می‌دهد. این به ما امکان می‌دهد که بخش‌ها و مقادیر واقعی باینری را به موارد مدنظر خود تغییر داده و نسخه اصلاح‌شده اپلیکیشن را ایجاد نماییم. با این کار می‌توان منطق اپلیکیشن را مطابق میل خود تنظیم کرد.

iOS

در مرحله آنالیز کد متوجه شدیم که متدی با نام initializeSdkWithCompletionHandler برای راه‌اندازی SDK تبلیغات مورداستفاده قرار می‌گیرد. اگر بتوانیم این تابع را به نحوی تغییر دهیم که پس از اجرا، سریعاً از اجرای ادامه دستورات جلوگیری کرده و به‌اصطلاح exit/return/ret نماید، به‌راحتی می‌توانیم مطمئن باشیم که SDK مذکور اجرا نشده و قاعدتاً تبلیغات لود نخواهند شد.

سپس از zsign برای تغییر Bundle ID اپلیکیشن به یک Bundle ID  معتبر دیگر که خود در اختیار داریم، به منظور امضای مجدد یا به‌اصطلاح Resign اپلیکیشن وصله شده استفاده می‌کنیم. بدین ترتیب ما یک اپلیکیشن اصلاح‌شده با امضای کد معتبر خواهیم داشت که می‌تواند بر روی iPhone نصب گردد. وقتی اپلیکیشن اصلاح‌شده را اجرا می‌کنیم ، خواهیم دید که تبلیغات دیگر لود نمی‌شوند.

اندروید

همان‌طور که در مرحله تجزیه و تحلیل کد دریافتیم، متد billing.d.a(Context) جهت چک کردن این موضوع که آیا تبلیغات باید نمایش داده شوند یا خیر، مورداستفاده قرار می‌گیرد. در صورتیکه این تابع مقدار true را برگرداند، به این معنی است که کاربر پرداخت وجه انجام داده است و تبلیغات مخفی خواهند شد.

با نگاهی به getBooleanAPI متوجه می‌شویم درصورتیکه preference موجود نباشد، پارامتر دوم به عنوان مقدار پیش‌فرض برمی‌گردد. درواقع shared preference با نام BillingSp تنها زمانی که خرید انجام می‌شود، ایجاد می‌گردد. خوب از آنجایی که خریدی نیز انجام‌نشده، اپلیکیشن پارامتر پیش‌فرض را برمی‌گرداند.

در بایت کد مشاهده می‌شود که مقدار false به‌صورت پیش‌فرض در const/4 v0, 0x0 ذخیره‌شده است. این بدان معنا است که اگر ما این مقدار را به 0x1(true) تغییر دهیم، باوجود اینکه هیچ خریدی انجام‌نشده است، تبلیغات نمایش داده نخواهند شد.

تکنیک فوق تنها یکی از چندین روش قابل استفاده برای غیرفعال سازی تبلیغات در اپلیکیشن فوق می‌باشد. در روش دیگر می‌توانستیم به‌صورت دستی اقدام به ایجاد shared preference با نام BillingSp و اعمال مقدار مدنظر بولین نماییم.

در مرحله بعد با بهره‌گیری از ابزار Apktool جهت کامپایل مجدد و همچنین apksigner به منظور resign اپلیکیشن می‌توانیم کار خود را به پایان برسانیم. بدین ترتیب در بستر اندروید هم مانند iOS، این اپلیکیشن به‌راحتی دست‌کاری گردید و بدون تبلیغات قابل اجرا شد.

اکنون می‌توان از اپلیکیشن اصلاح‌شده بدون تبلیغات برای استفاده شخصی و یا حتی  انتشار مجدد آن استفاده کرد. در حمله مشابه دیگر می‌توان برای تعویض کلید API سرویس تبلیغات اقدام نمود ، بدین ترتیب فرد مهاجم می‌تواند درآمد تبلیغات حاصل از استفاده از اپلیکیشن دست‌کاری شده را نصیب خود کند.

همان‌طور که می‌دانید به طور کلی توزیع و انتشار مجدد اپلیکیشن‌های دست‌کاری شده برای مهاجمین و سودجویان در هر دو پلتفرم دشوار نیست. به عنوان مثال ، برای iOS ، می‌توان از اکانت های رایگان developer جهت resign  اپلیکیشن استفاده کرد. حتی گاهی اوقات ، کلیدهای خصوصی گواهی های امضای یک شرکت نشت می‌کند، که می‌تواند برای امضای هر اپلیکیشن iOS برای هر دستگاهی مورداستفاده قرار گیرد. ابزارهای زیادی وجود دارد که این فرآیند Repackaging را برای کاربران که عمده آن‌ها هکرها هستند بسیار آسان می‌کند. نکته بعدی پیدا کردن محیطی برای انتشار اپلیکیشن دست‌کاری شده است که این امر به خصوص در کشور ما با توجه به اجبار موجود برای کاربران برای دانلود اپلیکیشن ها از سایت‌های شخص ثالث (منظور از شخص ثالث سایت‌هایی هستند به غیر از Apple App Store) انتشار اپ های موبایلی، می‌تواند آسان‌تر هم باشد. از سوی دیگر در دستگاه‌های Jailbreak شده حتی امکان غیرفعال سازی کامل فرآیند کنترل امضاها و گواهینامه‌ها وجود دارد که این موضوع می‌تواند حتی مهاجم را از resign کردن اپلیکیشن بعد از دست‌کاری، بی‌نیاز نماید.

دور زدن خریدهای درون برنامه‌ای

همان‌طور که در قسمت قبل نشان دادیم ، تغییر یک اپلیکیشن و بسته‌بندی مجدد(Repackaging) آن کار سختی نیست. اکنون نشان خواهیم داد که خریدهای درون برنامه‌ای در هر دو پلتفرم معمولاً فقط با استفاده از یک یا چند کنترل شرطی تائید می‌شوند. این کدهای کنترلی تعیین می‌کند که آیا آن قابلیت یا ویژگی مستلزم هزینه در اپلیکیشن خریداری شده است یا خیر. با توجه به اینکه این کنترل‌ها را می‌توان در درون اپلیکیشن دور زد، مهاجمین و هکرها در صورت استفاده از این آسیب‌پذیری می‌توانند قابلیت‌های پولی را بدون پرداخت هزینه مورداستفاده قرار دهند.

برای این منظور می‌خواهیم با یک روش جدید که نیاز به بسته‌بندی مجدد(Repackaging) ندارد، اپلیکیشن را به‌صورت پویا در حال اجرا تغییر دهیم. این روش نوع دیگری از دست‌کاری اپلیکیشن با نام Dynamic Tampering نامیده می‌شود.

iOS

در iOS ، خریدهای درون برنامه‌ای از طریق کتابخانه StoreKit انجام می‌شود که در همه دستگاه‌ها گنجانده شده است. هر زمان که خرید درون برنامه‌ای درخواست شود ، StoreKit یک تراکنش SKPaymentTransaction  را برمی‌گرداند. با کمی بررسی در اسناد راهنمای این کتابخانه متوجه می‌شویم که هریک از آن‌ها دارای یک فیلد با عنوان transactionState هستند که نتیجه هر تراکنش StoreKit را در خود نگه می‌دارد.

حال باید مطمئن شویم که  در هر زمانی که وضعیت تراکنش توسط اپلیکیشن مورد پرسش قرار می‌گیرد، ما SKPaymentTransactionStatePurchasedstate را برگردانیم و نشان دهیم که خرید موفقیت‌آمیز بوده است.

برای این منظور از ابزار Frida جهت اتصال یا به‌اصطلاح Hook اپلیکیشن استفاده می‌نماییم. هدف فوق‌الذکر از طریق اسکریپت زیر در Frida محقق می‌گردد.

  بدین ترتیب ما با فشردن دکمهGO FLASH PRO  فرآیند خرید را در اپلیکیشن راه‌اندازی می‌کنیم و می‌بینیم که حتی اگر پنجره خرید نشان داده شود، این عملیات قبلاً در پس‌زمینه پذیرفته شده است. درواقع ما تمامی ویژگی‌های مستلزم هزینه اپلیکیشن را بدون اینکه هیچ پولی خرج کرده باشیم در دسترس داریم.

 اندروید

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

اپلیکیشن مورد بررسی ما از OpenIAB برای حفظ امنیت و مراقبت از تعامل با theInAppBillingService استفاده می‌کند. همچنین فرآیند تائید امضا از طریق API java.security.Signature.verify(byte[]) انجام می‌شود.

در اینجا ما از فریم ورک Xposed برای هوک کردن فرآیند منطقی پرداخت در اپلیکیشن استفاده می‌کنیم. با استفاده از این ابزار، ما می‌توانیم ماژول Xposed طراحی شده توسط خود را ایجاد کنیم که می‌تواند خریدهای درون برنامه‌ای را دور بزند. تکنیک بکار گرفته‌شده برای دور زدن توسط ماژول Xposed شامل دو مرحله زیر است:

این ماژول ابتدا ، تمامی فراخوانی‌ها و تماس‌های برقرارشده از سوی اپلیکیشن ما با theInAppBillingService را مورد شنود و رهگیری قرار می‌دهد. از این طریق مطمئن می‌شود که هیچ خرید واقعی انجام‌نشده و یک شیء خرید موفق بازگردانده می‌شود. با این حال ، ایجاد امضای معتبر برای این شی امکان‌پذیر نیست ، زیرا ما به گواهینامه‌های موردنیاز دسترسی نداریم. در عوض ، ما می‌توانیم یک امضای ساختگی نامعتبر را برگردانیم.

در مرحله دوم ، این ماژول همچنین عملکرد تائید امضا را هوک می‌کند تا همیشه در کنار امضای ساختگی که در مرحله قبل استفاده شده بود ، کار کند و یک تأییدیه ساختگی ایجاد کند.

به این ترتیب ، وقتی فرآیند خرید را راه‌اندازی می‌کنیم، داده‌های جعلی تراکنش بلافاصله بازگردانده می‌شود و اعتبار امضا به‌صورت موفقیت‌آمیز تائید خواهد شد.

برای این عملیات از ماژول Xposed زیر استفاده می‌شود:

تقریباً هر برنامه‌ای که از خریدهای درون برنامه‌ای استفاده می‌کند ، با استفاده از API های مشابه ارائه‌شده توسط پلت فرم، به شیوه‌ای مشابه توضیح داده شده در بالا عمل می‌کند. کاملاً واضح است که وقتی بفهمیم چگونه می‌توان خریدهای درون برنامه‌ای را در یک اپلیکیشن واحد دور زد ، به طور کلی می‌توان آن را به سایر اپلیکیشن ها نیز تسری داد.برای هر دو سیستم‌عامل، می‌توانیم ابزارهایی مانند LocalIAPStore (iOS) یا LuckyPatcher (Android) را بارگیری کنیم که یک رابط کاربری آسان برای دور زدن تقریباً همه خریدهای درون برنامه‌ای بدون نیاز به مهارت مهندسی معکوس را ارائه می‌دهد.

نسخه‌های تغییریافته از اپلیکیشن‌های محبوب و مورد اقبال همگان این روزها در بسیاری از سایت‌ها و فروشگاه‌های توزیع و انتشار اپلیکیشن‌های شخص ثالث موجود است. در این خصوص، پس از دانلود و استفاده یک کاربر از این اپلیکیشن های تغییریافته، خود کاربران نیز ممکن است به مرجعی برای انتشار این اپلیکیشن ها برای دیگران شوند.

توجه داشته باشید که تغییراتی که ما در مثال‌های بالا ارائه دادیم، عموماً بسیار ابتدایی و آموزشی بوده و ممکن است قابل استفاده در اپلیکیشن‌های دیگر نباشند. در عوض ، این تغییرات به عنوان یک مثال آموزشی عمل می‌کنند تا نشان دهند که دست‌کاری اپلیکیشن ها کار دشواری نیست. از طرفی متذکر این موضوع هستند که نتایج این حملات درعمل و به‌صورت کاربردی چگونه خواهد بود.

روش‌های امن سازی در برابر دست‌کاری کد یا Tampering

 اگر با دقت بیشتری آسیب‌پذیری‌های ذکرشده و روش‌های دور زدن کنترل‌های امنیتی را مورد بررسی قرار دهیم، احتمالاً به این نتیجه می‌رسیم که حملات ذکرشده در بالا به این دلیل رخ می‌دهند که به طور کلی، تجزیه و تحلیل اپلیکیشن ها و کشف منطق داخلی آن‌ها با صرف زمان و حتی مهارت نسبتاً کمی توسط هکرها و مهاجمین امکان‌پذیر است. بدین ترتیب با بهره‌گیری از اطلاعات جمع‌آوری‌شده حاصل از مرحله آنالیز، می‌توان تغییراتی را برای دور زدن کنترل‌های امنیتی بکار گرفته‌شده و یا منطق آن‌ها در اپلیکیشن اعمال نمود.

به طور کلی قبل از اعمال هرگونه کنترل امنیتی بهتر است با بهره گیری از روش های ارزیابی امنیتی و یا تست نفوذپذیری بر روی اپلیکیشن موبایل، اقدام به کشف آسیبپذیری ها نمود. اما به صورت خاص برای مقابله با این نوع آسیب‌پذیری‌ها و حملات ناشی از آن‌ها می‌بایست عملیات تجزیه و آنالیز اپلیکیشن را برای مهاجم و ابزارهای بکار گرفته‌شده توسط ایشان مشکل و دشوار نمود. با رمزنگاری و همچنین مبهم ساختن/درهم‌ریزی یا به‌اصطلاح obfuscation مناسب اطلاعات معنایی (مانند نام کلاس‌ها ، نام تابع و مقادیر رشته) و منطق (مانند جریان کنترل) اپلیکیشن، تحلیل ایستا (استاتیک) یک اپلیکیشن بسیار دشوارتر می‌شود.

برای دسته دوم تهدیدات دست‌کاری اپلیکیشن ها که از آن‌ها با عنوان تحلیل پویا (داینامیک) در زمان اجرای اپلیکیشن یاد می‌شود، می‌توان با افزودن مکانیسم‌های امنیتی در زمان اجرا (RASP) به اطمینان مناسبی از عملکرد امن اپلیکیشن دست یافت. این مکانیسم‌های امنیتی اطمینان حاصل می‌کنند که منطق اپلیکیشن یا کتابخانه (توسط ابزارهایی رایجی چون مانند Frida ، Cydia Substrate و Xposed) مورد اتصال و هوکینگ قرار نگرفته و اپلیکیشن در محیط نامعتبر یا ناامن نظیر شرایط Jailbreak و یا Root اجرا نمی‌شوند. بدین ترتیب می‌توانیم تا حد زیادی از عدم‌تغییر غیرمجاز، دست‌کاری، بسته‌بندی مجدد و انتشار اپلیکیشن جعلی اطمینان حاصل نماییم.

درواقع به‌کارگیری روش‌ها و مکانیسم‌های امنیتی هم در شرایط ایستا و هم در زمان اجرا به‌صورت توأمان، می‌تواند اپلیکیشن ما را به‌صورت مناسبی در برابر حملات دست‌کاری (Tampering) محافظت نماید. برای این منظور ابزارهای DexGuard برای اپلیکیشن های اندرویدی به عنوان نسخه تجاری ابزار رایگان و نام آشنای Proguard و همچنین iXGuard برای برنامه های iOS با ارائه ویژگی های امنیتی متنوع می توانند این هدف میسر نمایند.

جمع‌بندی

هرچند هر دو پلتفرم Android و iOS دارای ویژگی‌های امنیتی زیادی را ارائه می‌دهند ، اما متأسفانه اغلب این مکانیسم‌های امنیتی در لایه خود اپلیکیشن بسیار محدود و یا ضعیف هستند.

در این مقاله در ادامه مقالات ارائه شده در خصوص امنیت اپلیکیشن های موبایلی نشان دادیم که کرک کردن یا به‌صورت دقیق‌تر دست‌کاری اپلیکیشن های موبایلی در هر دو پلتفرم معروف کار چندان دشواری نیست. با انتشار این نسخه‌های دست‌کاری شده به عنوان اپلیکیشن های جعلی و یا ارائه ابزارهای کرک آسان برای استفاده، کاربران غیر فنی و کم‌تجربه  بدخواه نیز می‌توانند از نتایج این حملات استفاده کنند. از آنجا که یک اپلیکیشن اصلاح‌شده می‌تواند باعث از دست رفتن اعتبار و اعتبار یک کسب‌وکار شود ، این موضوع می‌تواند مشکلات و چالش‌های امنیتی متعددی را برای صاحبان کسب‌وکار و برنامه نویسان ایجاد نماید.

در پایان خاطرنشان می‌شود، افزودن مکانیسم‌های امنیتی مناسب، لایه‌ای و چندوجهی به اپلیکیشن، کلید بالا بردن امنیت اپلیکیشن موبایل به‌صورت یکپارچه در محیط ناامن کسب‌وکار محسوب می‌شود.