- AI-आधारित malware detection की संभावना को परखने के लिए, कई open source server binaries में कृत्रिम रूप से बैकडोर डाले गए और AI agents तथा Ghidra से detection experiments किए गए
- Claude Opus 4.6 जैसे नवीनतम models ने कुछ सरल बैकडोर खोज निकाले, लेकिन detection rate 49% और false positive rate 28% रही, जो वास्तविक उपयोग के लिए अनुपयुक्त स्तर है
- प्रयोग में lighttpd, dnsmasq, Dropbear, Sozu जैसे C·Rust आधारित projects का उपयोग हुआ, और AI ने source code के बिना केवल reverse engineering tools से analysis किया
- कुछ models ने स्पष्ट malicious calls (
execl("/bin/sh", ...)) को सामान्य functionality समझ लिया, या असंबंधित code पर ध्यान केंद्रित किया, जिससे निर्णय क्षमता की कमी दिखी
- शोधकर्ताओं ने माना कि AI अभी पूर्ण security tool नहीं है, लेकिन यह इतना विकसित हो चुका है कि गैर-विशेषज्ञ भी शुरुआती security checks कर सकें
शोध पृष्ठभूमि
- हाल के Shai Hulud 2.0 supply chain attack और Notepad++ binary hijacking incident जैसी घटनाओं ने अविश्वसनीय executable files के जोखिम को उभारा है
- हमलावर वैध software में malicious code डालकर credential theft या remote command execution करते हैं
- firmware और hardware devices में भी छिपे हुए communication modules या backdoor accounts मिलने के मामले सामने आए हैं
- इन खतरों के जवाब में यह परखा गया कि क्या AI binary स्तर पर malicious behavior पहचान सकता है
बाइनरी विश्लेषण का अवलोकन
- सामान्य programming में source code पर काम किया जाता है, लेकिन malware analysis में machine-level binaries को समझना पड़ता है
- compilation प्रक्रिया में function names, variable names जैसी high-level जानकारी गायब हो जाती है, और optimization के कारण code structure विकृत हो जाता है
- analysis में
machine code → assembly → pseudo C code में बदलने वाली reverse engineering प्रक्रिया से गुजरना पड़ता है
- open source tools: Ghidra, Radare2
- commercial tools: IDA Pro, Binary Ninja
- ये tools code का अर्थ पुनर्निर्मित करते हैं, लेकिन परिणाम
FUN_00130550, bVar49 जैसे अर्थहीन identifiers से भरे होते हैं
BinaryAudit benchmark की संरचना
- कई open source servers (lighttpd, dnsmasq, Dropbear, Sozu) में test backdoors डाले गए
- उदाहरण: HTTP header के जरिए command चलाना, या DHCP option के जरिए shell command चलाना
- AI को source code के बिना केवल compiled executables दिए गए, और उसने Ghidra·Radare2·binutils आदि से analysis किया
- लक्ष्य था बैकडोर की मौजूदगी और उससे जुड़े function के start address की पहचान करना
- कुछ tasks ऐसे बनाए गए थे जिनमें कई binaries में से केवल यह पहचानना था कि कौन-सा infected है
detection की सफल मिसालें
- lighttpd server में डाले गए
X-Forwarded-Debug header-आधारित बैकडोर को Claude Opus 4.5 ने 5 मिनट में detect कर लिया
- उसने
popen() call खोजा और Radare2 से reverse engineering करके command execution logic की पुष्टि की
X-Request-Trace response header के जरिए परिणाम लौटाने की संरचना भी पहचान ली
- model ने
nm, strings, grep, r2 commands को मिलाकर स्वचालित analysis workflow चलाया
detection failure के मामले
- dnsmasq के DHCP processing code में डाले गए
/bin/sh execution backdoor को Claude Opus 4.6 ने सामान्य functionality समझकर गलत आकलन किया
- उसने
execl("/bin/sh", "sh", "-c", ...) call देखा, लेकिन उसे DHCP script execution समझ लिया
- वास्तव में वह ऐसा vulnerable code था जो client packet की सामग्री को ज्यों-का-त्यों execute करता था
- model ने सही location ढूंढ लेने के बाद भी जोखिम से इनकार किया और दूसरे function पर चला गया, जिससे detection छूट गया
AI की सीमाएँ और false positives की समस्या
- औसत false positive rate 28% रही, यानी साफ binaries में भी बैकडोर होने की गलत रिपोर्ट कई बार की गई
- उदाहरण: Gemini 3 Pro ने सामान्य command-line option parsing code को “command execution backdoor” समझ लिया
- security community में भी AI-generated reports की गिरती गुणवत्ता को समस्या माना जा रहा है
- curl project ने कहा कि AI-generated bug reports में से अधिकांश अर्थहीन हैं
- व्यावहारिक security tool के रूप में उपयोग के लिए 0.001% से कम false positive rate चाहिए
open source tools की सीमाएँ
- Ghidra और Radare2, C code analysis में उपयोगी हैं, लेकिन Rust·Go binaries में इनका प्रदर्शन गिरता है
- उदाहरण: Go-आधारित Caddy server (50MB) को Ghidra में load होने में 40 मिनट लगे, और परिणाम भी सटीक नहीं थे
- IDA Pro ने 5 मिनट के भीतर load होकर अधिक सटीक code दिया
- प्रयोग में tool quality के अंतर को हटाने के लिए C-आधारित binaries पर ज़्यादा ध्यान दिया गया
परिणाम और आगे की दिशा
- Claude Opus 4.6: 49%, Gemini 3 Pro: 44%, Claude Opus 4.5: 37% detection rate दर्ज की गई
- बड़े binaries या सामान्य behavior की नकल करने वाले backdoors के सामने ये models कमजोर रहे
- फिर भी AI अब Ghidra को सीधे संचालित कर reverse engineering करने के स्तर तक पहुँच चुका है
- गैर-विशेषज्ञ भी संदिग्ध executable files की शुरुआती जांच कर सकते हैं
- आगे commercial tool integration और local model-आधारित security analysis को विकास की दिशा बताया गया है
- पूरा benchmark और उसके परिणाम GitHub के QuesmaOrg/BinaryAudit में सार्वजनिक हैं
1 टिप्पणियां
Hacker News की राय
उन्होंने obfuscation नहीं किया था, यह मान भी लें, फिर भी import या symbols छिपाकर और strings को obfuscate कर देने पर detection success rate तुरंत 0 हो जाएगी
ऐसे मामलों में LLM जो detect करता है, वह बस malicious behavior से जुड़े भाषाई anomaly patterns होते हैं, इसलिए यह इतना प्रभावशाली नहीं है
उदाहरण के लिए Ghidra या Radare2 जैसे tooling को समझने वाले models अभी Opus 4.5, 4.6, Gemini 3 Pro, GLM 5 तक ही सीमित हैं
संबंधित benchmark यहाँ देखा जा सकता है
यह बस binaries के साथ काम करने में AI के लिए एक शुरुआती बिंदु है, और पूरी solution तक पहुँचने में अभी काफी समय है
असली software reverse engineering में कुछ देर तक बेवजह भटकने के बाद जब यह समझ आता है कि code obfuscated है, तब से CLAUDE.md जैसे दस्तावेज़ में परिणाम अपडेट करते हुए काम काफ़ी smoothly आगे बढ़ता है
उदाहरण के तौर पर dnsmasq-backdoor और dropbear-brokenauth patches देखे जा सकते हैं
हालाँकि मैंने nation-state स्तर के backdoor नहीं, बल्कि software crack स्तर की चीज़ें देखी थीं
उल्टा, complex logic ही LLM को ज़्यादा तोड़ती है, लेकिन अच्छे models उस complexity को खुद पहचानकर flag भी कर देते हैं
मैं अपना ghidra-cli project साझा कर रहा हूँ
मैंने Ghidra के साथ Altium file format के Delphi हिस्से को reverse किया था, और असर काफ़ी चौंकाने वाला था
models शुरुआत से पूरा parser नहीं लिख पाते, लेकिन LLM से पहले तो हम ऐसी कोशिश भी नहीं करते
security audit के लिए मैं इस पर निर्भर नहीं रहूँगा, लेकिन आधुनिक models file format reverse engineering के लिए काफ़ी उपयोगी हैं
उदाहरण के लिए diagram generation, attack surface mapping, code exploration जैसी चीज़ें उन्हें दे देता हूँ और मैं manual analysis पर ध्यान देता हूँ
LLM बोरिंग और दोहराए जाने वाले काम अपने ऊपर ले लेते हैं, इसलिए गति बढ़ जाती है। लेकिन बहुत ज़्यादा काम दे दिया जाए तो productivity trap में फँस सकते हैं
सही “skills” set वाले agents का combination लिया जाए तो निश्चित रूप से efficiency बढ़ती है
Ghidra की सबसे बड़ी limitation यह थी कि Go language analysis बहुत धीमा था
मैंने GhidrAssistMCP, analyzeHeadless, PyGhidra आदि इस्तेमाल किए हैं,
खासकर explicit SKILL.md वाला approach AI agents के साथ integration के लिहाज़ से बहुत अच्छा है
इस thread का मुख्य बिंदु methodology पर चर्चा है
“obfuscation जोड़ने पर success rate 0%” वाली बात सही है, लेकिन experiment का उद्देश्य यह देखना है कि AI एक skilled reverse engineer की तरह non-obfuscated binaries को संभाल सकता है या नहीं
यह internal audit या legacy code analysis जैसे ऐसे scenarios हैं जहाँ इसका वास्तव में उपयोग हो सकता है
असली अहम बात है threat model की परिभाषा। अगर attacker automated स्तर का है तो यह पहले ही काफ़ी उपयोगी है,
लेकिन अगर advanced attacker AI detection को ध्यान में रखकर काम कर रहा हो, तो यह test पर्याप्त नहीं है
व्यावहारिक validation यह देखना होगा कि हल्के obfuscation (imports छिपाना, string encoding) के स्तर पर performance कैसी रहती है
अगर मौसम बादलों से घिरा हो तो सेब नहीं तोड़ पाने वाले robot को क्या हम “skilled apple picker” कहेंगे? यही सवाल है
GPT का false positive rate 0% के साथ behavior स्थिर है, लेकिन detection rate लगभग 18% है
वहीं Claude Opus 4.6 का detection rate 46% तक जाता है, लेकिन false positive rate 22% है
अगर कई models को मिलाकर इस्तेमाल किया जाए, जहाँ एक validation procedure design करे और दूसरा असली exploit test चलाए, तो शायद और दिलचस्प नतीजे मिलें
लेकिन generative models आते ही जैसे सब भूल गए हों
मुख्य बात यह है कि “AI के लिए complete malware detection करना मुश्किल हो सकता है, लेकिन developers के लिए initial security audit करना बहुत आसान हो गया है”
reverse engineering का अनुभव न रखने वाले developers भी अब suspicious binaries का पहला विश्लेषण कर सकते हैं
यह सिर्फ security तक सीमित नहीं, बल्कि optimization, debugging, hardware reverse, architecture porting जैसे कई क्षेत्रों तक फैल सकता है
अंततः महत्वपूर्ण बात यह है कि AI को perfect analyzer नहीं, बल्कि hypothesis generation tool की तरह देखा जाए
benchmark के executable files सैकड़ों से लेकर हज़ारों functions से बने हैं, और backdoor उनमें सिर्फ कुछ lines का होता है
इसलिए network parser या input handling routines जैसी critical paths को रणनीतिक रूप से explore करना ज़रूरी है
ऐसी strategy को
.mdfile के रूप में LLM को देना भी एक तरीका हो सकता हैprompt का कोई सूक्ष्म शब्द भी नतीजा बदल सकता है
अंततः experiment design की complexity बहुत बढ़ जाती है, और परिणामों की robustness घट जाती है
अगर expert guidance जोड़ दी जाए तो यह शक्तिशाली performance amplification effect दे सकता है
इंसानी strategic thinking को AI से सच में follow करवाना अब भी कठिन है
benchmark का सीधा लिंक यहाँ है,
open source code GitHub repository में उपलब्ध है
Gemini का false positive rate सबसे ज़्यादा होना मेरे अनुभव से मेल खाता है
मैंने ChatGPT, Claude, Gemini तीनों इस्तेमाल किए हैं, और Gemini सबसे ज़्यादा positive bias दिखाता है
वह हमेशा सबसे आशावादी जवाब देता है
मैं ऐसी विशेषता को numbers में दिखाने वाला benchmark ढूँढ रहा था, और यह परिणाम उसके लिए आधार बन सकता है
मैं expert नहीं हूँ, लेकिन false positive समस्या कम करने के लिए क्या model को खुद backdoor चलाकर verify नहीं करना चाहिए? ऐसा विचार आता है
इसलिए cross-model comparison कठिन हो जाता है, और उसकी जगह model से backdoor की location स्पष्ट बताने को कहा जाता है
अगर model को सीधे customize या fine-tune किया जाए, तो आपका सुझाया तरीका उपयोगी हो सकता है
best-performing model ने भी लगभग 50% ही detect किया, और यह बुरा नहीं है। शायद इंसान से बेहतर भी हो
लेकिन बाकी 50% क्यों छूट गया, यह जानने की जिज्ञासा है
Claude Opus 4.6 का backdoor ढूँढ लेने के बाद भी “कोई समस्या नहीं” निष्कर्ष देना दिलचस्प है
आखिरकार यह दिखाता है कि मानव judgement support के बिना AI के लिए पूर्ण समझ तक पहुँचना कठिन है