RASP — यह क्या है, कार्य सिद्धांत और रीयल-टाइम सुरक्षा

RASP क्या है?

Runtime Application Self-Protection (RASP) एक सुरक्षा तकनीक है जो बिल्ड समय पर या रनटाइम एजेंट के माध्यम से एप्लिकेशन में एकीकृत होती है। RASP निष्पादन के दौरान एप्लिकेशन के व्यवहार का विश्लेषण करता है और संदर्भ के आधार पर हमलों को ब्लॉक करने का निर्णय लेता है: कॉल कहाँ से आया, कौन सा डेटा पास किया जा रहा है, स्टैक की स्थिति क्या है। सिग्नेचर-आधारित सिस्टम के विपरीत, RASP ज्ञात हमले के पैटर्न नहीं खोजता — यह असामान्य व्यवहार का पता लगाता है जो अपेक्षित कोड निष्पादन परिदृश्य से भटकता है।

RASP अवधारणा को Gartner द्वारा 2011 में औपचारिक रूप दिया गया था, और पहला वाणिज्यिक कार्यान्वयन 2014–2015 में सामने आया। मोबाइल प्लेटफ़ॉर्म के लिए, 2017 में RASP का सक्रिय रूप से उपयोग शुरू हुआ, जब बाज़ार ने पारंपरिक अस्पष्टीकरण (obfuscation) की अपर्याप्तता को महसूस किया। MarketsandMarkets (2025) की रिपोर्ट के अनुसार, RASP समाधानों का बाज़ार 2.8 बिलियन USD है जो 24.5% की वार्षिक वृद्धि दर से बढ़ रहा है। भुगतान डेटा संसाधित करने वाले एप्लिकेशन के लिए OWASP Mobile Top 10 और PCI DSS 4.0 मानकों द्वारा RASP कार्यान्वयन की अनुशंसा की जाती है।

RASP दो स्तरों पर काम करता है: इंटरसेप्शन और असेसमेंट। इंटरसेप्शन — बिल्ड समय पर या गतिशील इंस्ट्रूमेंटेशन के माध्यम से रनटाइम पर कोड में एम्बेडेड हुक के माध्यम से सिस्टम और लाइब्रेरी कॉल को इंटरसेप्ट करना। असेसमेंट — कॉल संदर्भ का विश्लेषण: इनपुट पैरामीटर, कॉल स्टैक, सैंडबॉक्स स्थिति, डीबगर की उपस्थिति की जाँच। निर्णय डेवलपर द्वारा निर्धारित सुरक्षा नीति के आधार पर लिया जाता है। नीति सख्त (ब्लॉक), नरम (लॉग) या अनुकूली (खतरे के स्तर के अनुसार व्यवहार बदलना) हो सकती है।

RASP कैसे काम करता है: आर्किटेक्चर और तंत्र

RASP एजेंट आर्किटेक्चर में तीन घटक होते हैं: इंस्ट्रूमेंटेशन लेयर, विश्लेषक और नीति। इंस्ट्रूमेंटेशन लेयर सिस्टम कॉल और फ्रेमवर्क कॉल को इंटरसेप्ट करती है। विश्लेषक अपेक्षित पैटर्न के विरुद्ध संदर्भ की जाँच करता है। नीति प्रतिक्रिया निर्धारित करती है।

कोड इंस्ट्रूमेंटेशन

मोबाइल एप्लिकेशन के लिए कम्पाइल-टाइम इंस्ट्रूमेंटेशन का उपयोग किया जाता है: बिल्ड समय पर बाइटकोड या नेटिव कोड में संशोधन किया जाता है — प्रत्येक खतरनाक कॉल से पहले एक जाँच डाली जाती है। RASP एजेंट कंपाइलर एंट्री पॉइंट FileOutputStream.write(), Runtime.exec(), Class.forName() और android.app.Activity.onStart() को संशोधित करता है। Android के लिए, Gradle plugin के माध्यम से DEX बाइटकोड ट्रांसफ़ॉर्मेशन का उपयोग किया जाता है; iOS के लिए, पोस्ट-लिंक स्क्रिप्ट के माध्यम से Mach-O बाइनरी संशोधन।

संदर्भ विश्लेषण

कॉल को इंटरसेप्ट करते समय, RASP विश्लेषण करता है: कॉलर क्लास और मेथड (कौन कॉल कर रहा है), स्टैक ट्रेस (कॉल श्रृंखला), आर्गुमेंट (पास किया जा रहा डेटा), रिटर्न वैल्यू (क्या वापस आ रहा है), टाइमस्टैम्प और थ्रेड आइडी। एक विसंगति तब दर्ज की जाती है, उदाहरण के लिए, जब 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 plugin के माध्यम से एम्बेड किया जाता है जो बिल्ड समय पर 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 को हटा या अक्षम कर देगा।