RASP — یہ کیا ہے، کام کرنے کا اصول اور حقیقی وقت میں تحفظ

RASP کیا ہے؟

Runtime Application Self-Protection (RASP) ایک حفاظتی ٹیکنالوجی ہے جو بلڈ ٹائم پر یا رن ٹائم ایجنٹ کے ذریعے ایپلیکیشن میں ضم ہوتی ہے۔ RASP عملدرآمد کے دوران ایپلیکیشن کے رویے کا تجزیہ کرتا ہے اور سیاق و سباق کی بنیاد پر حملوں کو روکنے کے فیصلے کرتا ہے: کال کہاں سے آئی، کون سا ڈیٹا منتقل کیا جا رہا ہے، اسٹیک کی حالت کیا ہے۔ دستخط پر مبنی نظاموں کے برعکس، RASP معروف حملہ پیٹرن تلاش نہیں کرتا — یہ غیر معمولی رویے کا پتہ لگاتا ہے جو متوقع کوڈ پر عملدرآمد کے منظر نامے سے ہٹتا ہے۔

RASP کا تصور 2011 میں Gartner نے رسمی شکل دی تھی، اور پہلا تجارتی نفاذ 2014–2015 میں سامنے آیا۔ موبائل پلیٹ فارمز کے لیے، RASP نے 2017 میں فعال طور پر استعمال ہونا شروع کیا، جب مارکیٹ نے روایتی ابہام (obfuscation) کی ناکافی کو محسوس کیا۔ MarketsandMarkets (2025) کی رپورٹ کے مطابق، RASP حل کی مارکیٹ 2.8 بلین USD ہے جس کی سالانہ شرح نمو 24.5% ہے۔ RASP کے نفاذ کی سفارش OWASP Mobile Top 10 اور PCI DSS 4.0 معیارات کے ذریعے ان ایپلیکیشنز کے لیے کی جاتی ہے جو ادائیگی کے ڈیٹا پر کارروائی کرتی ہیں۔

RASP دو سطحوں پر کام کرتا ہے: روکنا اور تشخیص۔ روکنا — بلڈ ٹائم پر یا متحرک انسٹرومینٹیشن کے ذریعے رن ٹائم پر کوڈ میں ایمبیڈڈ ہکس کے ذریعے سسٹم اور لائبریری کالز کو روکنا۔ تشخیص — کال کے سیاق و سباق کا تجزیہ: ان پٹ پیرامیٹرز، کال اسٹیک، سینڈ باکس کی حالت، ڈیبگر کی موجودگی کی جانچ۔ فیصلہ ڈویلپر کی طرف سے مقرر کردہ حفاظتی پالیسی کی بنیاد پر کیا جاتا ہے۔ پالیسی سخت (بلاک)، نرم (لاگ) یا انکولی (خطرے کی سطح کے مطابق رویہ تبدیل کرنا) ہو سکتی ہے۔

RASP کیسے کام کرتا ہے: فن تعمیر اور میکانزم

RASP ایجنٹ کے فن تعمیر میں تین اجزاء ہوتے ہیں: انسٹرومینٹیشن پرت، تجزیہ کار اور پالیسی۔ انسٹرومینٹیشن پرت سسٹم کالز اور فریم ورک کالز کو روکتی ہے۔ تجزیہ کار متوقع نمونوں کے خلاف سیاق و سباق کی جانچ کرتا ہے۔ پالیسی ردعمل کا تعین کرتی ہے۔

کوڈ انسٹرومینٹیشن

موبائل ایپلیکیشنز کے لیے کمپائل ٹائم انسٹرومینٹیشن استعمال کیا جاتا ہے: بلڈ ٹائم پر بائٹ کوڈ یا مقامی کوڈ میں ترمیم کی جاتی ہے — ہر خطرناک کال سے پہلے ایک جانچ ڈالی جاتی ہے۔ RASP ایجنٹ کمپائلر انٹری پوائنٹس FileOutputStream.write()، Runtime.exec()، Class.forName() اور android.app.Activity.onStart() میں ترمیم کرتا ہے۔ Android کے لیے، Gradle پلگ ان کے ذریعے DEX بائٹ کوڈ کی تبدیلی استعمال ہوتی ہے؛ iOS کے لیے، پوسٹ لنک اسکرپٹ کے ذریعے Mach-O بائنری میں ترمیم کی جاتی ہے۔

سیاق و سباق کا تجزیہ

کال کو روکتے وقت، RASP تجزیہ کرتا ہے: کالر کلاس اور طریقہ (کون کال کر رہا ہے)، اسٹیک ٹریس (کال کا سلسلہ)، دلائل (منتقل کردہ ڈیٹا)، واپسی کی قدر (کیا واپس آ رہا ہے)، ٹائم اسٹیمپ اور تھریڈ ID۔ ایک بے ضابطگی ریکارڈ کی جاتی ہے جب، مثال کے طور پر، Runtime.exec() کو UI تھریڈ سے اور ایپلیکیشن کوڈ سے نہیں، بلکہ JNI کے ذریعے غیر معیاری راستے پر لوڈ کردہ لائبریری سے کال کیا جاتا ہے۔ یا جب FileOutputStream.write() کو ایسا ڈیٹا ملتا ہے جس میں متوقع PNG ہیڈر کے بجائے قابل عمل بائٹ کوڈ ہوتا ہے۔

ردعمل کی پالیسیاں

RASP تین قسم کے ردعمل کی حمایت کرتا ہے: Block — حملے کا پتہ چلنے پر ایپلیکیشن کو ہنگامی طور پر بند کرنا، Log — ایپلیکیشن کو روکے بغیر لاگ جمع کرنے والے سرور پر واقعے کی تفصیلات بھیجنا، Deceive — واپسی کی قدر کو جعلی سے تبدیل کرنا تاکہ حملہ آور کو غلط ڈیٹا ملے۔ Log اور Deceive کا امتزاج پتہ لگانے کی حقیقت کو ظاہر کیے بغیر حملہ آور کے بارے میں معلومات اکٹھی کرنے کی اجازت دیتا ہے۔

// مثال: Runtime.exec() کال کی RASP جانچ
public class RASPAgent {
    public static Object onExecCalled(String command,
            StackTraceElement[] stack) {

        // کالر کی جانچ ہو رہی ہے
        String caller = stack[1].getClassName();

        // اگر کال ہمارے پیکیج سے نہیں ہے — مشکوک
        if (!caller.startsWith("com.example.app")) {
            SecurityPolicy.reportIncident(
                "UNEXPECTED_EXEC", command, stack
            );
            return SecurityPolicy.getAction().execute(command);
        }

        // بلیک لسٹ کے خلاف کمانڈ کی جانچ
        String[] blocked = {"su", "frida", "ptrace", "/data/local"};
        for (String pattern : blocked) {
            if (command.contains(pattern)) {
                SecurityPolicy.reportIncident(
                    "BLOCKED_CMD", command, stack
                );
                return new Process(); // deceiving: خالی عمل
            }
        }

        return null; // عملدرآمد کی اجازت دیں
    }
}

RASP بمقابلہ WAF اور دیگر حفاظتی آلات

RASP کا اکثر Web Application Firewall (WAF) سے موازنہ کیا جاتا ہے، لیکن بنیادی فرق پوزیشننگ میں ہے۔ WAF نیٹ ورک کے دائرے پر واقع ہوتا ہے اور صرف HTTP درخواستوں کا تجزیہ کرتا ہے۔ RASP ایپلیکیشن کے اندر کام کرتا ہے اور پروسیسنگ منطق کو دیکھتا ہے۔

ابہام (ProGuard, DexGuard) کے برعکس جو کوڈ کو ناقابل مطالعہ بناتا ہے، RASP استحصال کے دوران فعال طور پر حملوں کا پتہ لگاتا ہے۔ ابہام غیر فعال تحفظ ہے: اگر حملہ آور ریورس انجینئرنگ پر کافی وقت صرف کرے تو کوڈ پڑھ لیا جائے گا۔ RASP فعال ہے: یہ دیکھتا ہے کہ حملہ آور ایپلیکیشن کو ڈیبگ کرنے کی کوشش کر رہا ہے اور کوڈ کی ایک بھی سطر پڑھے جانے سے پہلے ردعمل ظاہر کرتا ہے۔ ابہام + RASP کا امتزاج کثیر سطحی تحفظ فراہم کرتا ہے، جہاں ابہام تجزیہ کو سست کرتا ہے اور RASP انسٹرومینٹیشن مرحلے پر حملے کو روکتا ہے۔

موبائل ایپلیکیشنز میں RASP

موبائل RASP حل Android اور iOS کی خصوصیات کے مطابق ڈھالے گئے ہیں۔ سرور سائڈ Java ایپلیکیشنز کے برعکس، موبائل RASP ایجنٹ محدود میموری اور بیٹری کے حالات میں کام کرتے ہیں، جس کے لیے ہلکی انسٹرومینٹیشن کی ضرورت ہوتی ہے۔

Android پر RASP

Android پر، RASP ایجنٹ Gradle پلگ ان کے ذریعے ایمبیڈ کیا جاتا ہے جو بلڈ ٹائم پر DEX بائٹ کوڈ میں ترمیم کرتا ہے۔ ایجنٹ 50 سے زیادہ سسٹم کالز کو روکتا ہے، جن میں شامل ہیں: Runtime.exec() (su یا Frida کے نفاذ کا پتہ لگانے کے لیے)، Class.forName() (مشتبہ کلاسز کی لوڈنگ کی شناخت کے لیے)، System.loadLibrary() (غیر معیاری راستوں سے مقامی لائبریریوں کی لوڈنگ کو کنٹرول کرنے کے لیے)۔ مزید برآں، یہ /proc/self/maps میں لائبریریوں frida-agent، frida-helper، libinject اور substrate کی موجودگی کی جانچ کرتا ہے۔

iOS پر RASP

iOS پر، RASP Mach-O بائنری کے پوسٹ پروسیسنگ کے ذریعے نافذ کیا جاتا ہے۔ Apple کی بائنری تبدیلی کے سخت تقاضوں کی وجہ سے iOS زیادہ پیچیدہ ہے۔ ایجنٹ fork()، dlopen()، ptrace() فنکشن کالز کو روکتا ہے اور لوڈ کردہ لائبریریوں میں CydiaSubstrate.dylib کی موجودگی کی جانچ کرتا ہے۔ iOS کے لیے RASP App Store بلڈز میں کوڈ میں ترمیم نہیں کر سکتا — صرف Enterprise تقسیم کے لیے۔ App Store کے لیے، Swift Macro یا Objective-C method swizzling کے ذریعے کمپائل ٹائم انسٹرومینٹیشن کی سفارش کی جاتی ہے۔

تجزیہ کے آلات کا پتہ لگانا

موبائل RASP پتہ لگاتا ہے: Frida (/proc/self/maps اور /data/local/tmp/frida* کی جانچ کے ذریعے)، Xposed Framework (ClassLoader میں de.robv.android.xposed.XposedBridge کی جانچ کے ذریعے)، JDWP ڈیبگر (Debug.isDebuggerConnected() کے ذریعے)، ایمولیٹرز (Build.FINGERPRINT، Build.HARDWARE، Build.MODEL کی جانچ کے ذریعے) اور AndroidManifest میں debuggable پرچم۔ NowSecure Mobile Threat Report (2025) کے مطابق، RASP ایجنٹ 89–97% انسٹرومینٹڈ Frida سیشنز کا پتہ لگاتا ہے۔

RASP ایجنٹ کا عملی نفاذ

موبائل ایپلیکیشن میں RASP کو ضم کرنے کے لیے انسٹرومینٹیشن کو ترتیب دینا، پالیسیوں کی وضاحت کرنا اور واقعے کے لاگز جمع کرنے کے لیے SIEM سسٹم کے ساتھ انضمام ضروری ہے۔

نفاذ کا انتخاب: کمپائل ٹائم بمقابلہ رن ٹائم

کمپائل ٹائم انسٹرومینٹیشن — بلڈ ٹائم پر بائٹ کوڈ میں ترمیم، رن ٹائم کارکردگی کو متاثر نہیں کرتی۔ رن ٹائم انسٹرومینٹیشن (سرور پر Java Agent یا کلائنٹ پر Frida کے ذریعے) زیادہ لچکدار ہے لیکن 5–10% اوور ہیڈ کا اضافہ کرتی ہے۔ موبائل ایپلیکیشنز کے لیے، کمپائل ٹائم طریقہ کار کی سفارش کی جاتی ہے کیونکہ اسے مسلسل نیٹ ورک کنیکشن کی ضرورت نہیں ہوتی اور تجزیہ کے لیے بیٹری خرچ نہیں ہوتی۔

موجودہ لائبریریوں کے ساتھ انضمام

RASP ایجنٹ کو مقبول SDK کے ساتھ صحیح طریقے سے کام کرنا چاہیے۔ Firebase Crashlytics، Google Analytics اور Appsee کو بلاک نہیں کیا جانا چاہیے۔ معروف لائبریریوں کے لیے وائٹ لسٹ ترتیب دینا لازمی ہے۔ ایجنٹ کی ترتیب میں مستثنیات متعین کی جاتی ہیں: اگر کال com.google.firebase کلاس سے آتی ہے — جانچ چھوڑ دی جاتی ہے۔ وائٹ لسٹ ہر SDK ریلیز کے ساتھ اپ ڈیٹ ہوتی ہے۔

واقعہ ہینڈلنگ کی مثال

جب RASP ایجنٹ کے ذریعے Frida کا پتہ چلتا ہے، تو درج ذیل ہوتا ہے: سیاق و سباق کا مجموعہ (اسٹیک ٹریس، OS ورژن، وقت)، خفیہ کردہ شکل میں لاگنگ سرور کو ڈیٹا بھیجنا، پالیسی پر عملدرآمد (کریش، صرف لاگ یا deceive)، اجتماعی حملے کی شناخت کے لیے کاؤنٹر میں اضافہ۔ مختلف آلات کا ڈیٹا سرور پر جمع کیا جاتا ہے تاکہ حملے کے نمونوں کی شناخت کی جا سکے۔

class RASPManager {
    fun analyzeAndReact() {
        val threats = detectThreats()
        if (threats.isNotEmpty()) {
            val report = ThreatReport().apply {
                threats = threats
                timestamp = System.currentTimeMillis()
                deviceId = DeviceInfo.getHashedId()
                stackTrace = Thread
                    .currentThread()
                    .stackTrace
                    .take(10)
                    .toList()
            }

            val policy = SecurityPolicy.getPolicy(threats.maxBy { it.severity })

            when (policy) {
                Policy.BLOCK   -> throw SecurityException("Protection triggered")
                Policy.LOG     -> ServerLogger.sendReport(report)
                Policy.DECEIVE -> DeceptionLayer.activate(report)
            }
        }
    }
}

حدود اور غلط مثبت نتائج

RASP کوئی چاندی کی گولی نہیں ہے۔ ٹیکنالوجی کی حدود ہیں جنہیں تحفظ ڈیزائن کرتے وقت مدنظر رکھنا چاہیے۔

کارکردگی

ہر روکی گئی کال سیاق و سباق کی جانچ کا اضافہ کرتی ہے۔ جارحانہ ترتیب (تمام IO اور exec کالز کو روکنا) کے ساتھ، کارکردگی 5–15% تک گر سکتی ہے۔ موبائل ایپلیکیشنز کے لیے اسٹارٹ اپ وقت اہم ہے: RASP ابتدائیہ اسٹارٹ اپ پر 200–500 ms کا اضافہ کرتا ہے۔ ہدفی انسٹرومینٹیشن کی سفارش کی جاتی ہے — تمام ممکنہ فنکشنز نہیں، صرف اہم فنکشنز۔ جانچ کے دوران RASP ایجنٹ کے ساتھ پروفائلنگ لازمی ہے۔

غلط مثبت نتائج

RASP جائز رویے کو بلاک کر سکتا ہے: Firebase Crashlytics نیٹ ورک کال کے ذریعے ایرر اسٹیک بھیجتا ہے، اسے ڈیٹا کے اخراج سے غلطی سے تعبیر کیا جا سکتا ہے؛ Google Play Integrity API ڈیوائس کی سالمیت کی جانچ کرتا ہے، اسے مشتبہ کال کے طور پر شناخت کیا جا سکتا ہے۔ غلط مثبت نتائج کو کم کرنے کے لیے، 7–14 دنوں کا سیکھنے کا موڈ (learning mode) ضروری ہے، جس کے دوران RASP صرف لاگ کرتا ہے لیکن بلاک نہیں کرتا۔

RASP کو نظرانداز کرنا

اگر حملہ آور کرنل سطح تک رسائی حاصل کر لے (کرنل استحصال کے ذریعے)، RASP اپنی جانچوں پر بھی بھروسہ نہیں کر سکتا — ایجنٹ یوزر اسپیس میں کام کرتا ہے اور صرف وہی دیکھتا ہے جو کرنل اسے دیکھنے کی اجازت دیتا ہے۔ کرنل سطح پر نظرانداز کو روکنے کے لیے، سرور سائڈ تصدیق کے ساتھ Secure Boot Chain جانچ استعمال کی جاتی ہے۔ مزید برآں، RASP ایجنٹ خود بھی مبہم اور ڈیبگنگ سے محفوظ ہونا چاہیے — ورنہ حملہ آور حملہ شروع کرنے سے پہلے RASP کو ہٹا یا غیر فعال کر دے گا۔