• 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 में सार्वजनिक हैं

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.