Skip to content
KitploitKITPLOIT
उपकरणब्लॉग
जमा करें
उपकरणब्लॉग
जमा करें

हैकिंग, पेनटेस्ट और साइबर सुरक्षा उपकरण आपके सुरक्षा शस्त्रागार के लिए!

Kitploit हैकिंग, साइबर सुरक्षा और पेंटेस्टिंग टूल्स की एक निर्देशिका है। कमजोरियों को खोजने, सिस्टम का विश्लेषण करने, परीक्षण को स्वचालित करने और अपनी सुरक्षा को मजबूत करने के लिए नवीनतम प्रोजेक्ट अपडेट खोजें।

··फ़ीड·संपर्क·गोपनीयता·© 2026 Kitploit

टूल निर्देशिका

श्रेणियाँ

सभी श्रेणियाँ देखें
Loading categories
उपकरण/GitHubGitHub/rootup/git-clean-filter
फ़िशिंग उपकरणस्थायित्व तंत्रआईडीएस/आईपीएस से बचनाकमांड एंड कंट्रोलसामाजिक इंजीनियरिंगरेड टीमिंग
GitHubrootup/git-clean-filter

git-clean-filter

यह git के clean filter का दुरुपयोग करके IDEs और Sublime के विरुद्ध एक proof-of-work है।

रिपॉजिटरी देखें
32 महीने पहलेअभी तक समीक्षित नहीं

सबसे लोकप्रिय

सभी देखें →

हमारे समुदाय द्वारा सबसे अधिक उपयोग किए जाने वाले उपकरण खोजें।

सभी उपकरण खोजें

हमारे उपकरणों का संग्रह ब्राउज़ करें

सभी उपकरण देखें →
साझा करें

यह एक प्रलेखित (ज्ञात) समस्या है, लेकिन मैंने इसे अपने शोध के दौरान पाया और यह RT/PT के लिए काफी उपयोगी है।

सारांश: .git/config में filter.<name>.clean निर्देश एक स्क्रिप्ट की ओर इशारा करता है और .gitattributes उस फ़िल्टर को एक ट्रैक की गई फ़ाइल से बाँधता है। जब भी git उस फ़ाइल का वास्तविक git diff प्रस्तुत करता है, वह पहले वर्कट्री सामग्री को clean कमांड से गुज़ारता है, इसलिए git आँख बंद करके वहाँ निर्दिष्ट किसी भी पथ को लॉन्च कर देता है।

अब यहाँ यह दिलचस्प हो जाता है। हमारे एडिटर जैसे ही आप किसी बदली हुई फ़ाइल पर क्लिक करते हैं, अपने SCM (सोर्स कंट्रोल मैनेजमेंट) पैनल और गटर एनोटेशन को भरने के लिए git diff स्वचालित रूप से चलाते हैं। केवल फ़ोल्डर खोलना पर्याप्त नहीं है, लेकिन बदलाव देखना पर्याप्त है, और जब आप किसी रेपो में पहुँचते हैं तो यह करना काफी स्वाभाविक बात है।

यह core.fsmonitor जैसा ही विचार है, बस एक अलग निर्देश पर, और यह fsmonitor नहीं है, इसलिए जो कोई भी उस पर नज़र रखता है वह इसे नहीं देख पाएगा। यह ट्रेडक्राफ्ट RT अभियानों और assume-breach परिदृश्यों में किसी भी C2 या हमारे XRayC2 के साथ फिट बैठती है, ताकि एक ऐसा कॉलबैक मिल सके जो पारंपरिक नेटवर्क सुरक्षा से बच जाए। (बेशक, अंतिम उपयोगकर्ता को धोखा देने के लिए फ़िशिंग ईमेल आवश्यक हैं, लेकिन एक IDE में फ़ोल्डर खोलना और किसी फ़ाइल पर क्लिक करना एक उचित ऑपरेशन लगता है।)

प्रूफ ऑफ वर्क। git clone .git/config को आगे नहीं ले जाएगा, इसलिए फ़ोल्डर को .git/ को बरकरार रखते हुए भेजें। .git/config के अंतर्गत कॉन्फ़िग:

root@kitploit:~
[filter "poc"]
    clean  = ./icons/clean.sh
    smudge = cat

.gitattributes:

root@kitploit:~
sample.txt filter=poc

sample.txt committed है, लेकिन वर्किंग ट्री में संशोधित करके भेजा गया है। जिस क्षण git इसे diff करता है, clean फ़िल्टर सक्रिय हो जाता है। clean.sh कैलकुलेटर खोलता है और सामग्री को अपरिवर्तित पास करता है ताकि वर्किंग ट्री कभी दूषित न हो:

root@kitploit:~
#!/bin/sh
pgrep -x Calculator >/dev/null 2>&1 || open -a Calculator 2>/dev/null
exec cat

अपने एडिटर में फ़ोल्डर खोलें, उसका बदलाव देखने के लिए sample.txt पर क्लिक करें, और एक कैलकुलेटर खुल जाता है। (इसे फिर से चलाने के लिए कैलकुलेटर बंद करें।) यह POC macOS विशिष्ट है, इसे अपने वातावरण के लिए संशोधित करें।

Cursor (git CLI) और Sublime Text (libgit2) पर परीक्षण किया गया।

clean फ़िल्टर केवल पूर्ण git diff पर चलता है, न कि git status पर, इसलिए यह तब सक्रिय होता है जब एडिटर बदलाव प्रस्तुत करता है, न कि केवल फ़ोल्डर खोलने पर। दिलचस्प बात यह है कि Sublime इसे libgit2 के माध्यम से इन-प्रोसेस ट्रिगर करता है, पेलोड का पैरेंट स्वयं sublime_text होता है और श्रृंखला में कोई git बाइनरी नहीं होती, इसलिए यह केवल उन टूल्स तक सीमित नहीं है जो git को बाहरी प्रक्रिया के रूप में चलाते हैं।

https://github.com/user-attachments/assets/31ea495f-1ed8-44f8-bef3-8c6366a0eece

fsmonitor की तरह यह भी एडिटर के "इस फ़ोल्डर पर भरोसा करें?" प्रॉम्प्ट द्वारा नियंत्रित होता है। अधिकांश डेवलपर्स ~/Downloads और समान शीर्ष-स्तरीय फ़ोल्डरों को भरोसेमंद रखते हैं, और Cursor वर्कस्पेस ट्रस्ट को डिफ़ॉल्ट रूप से बंद रखता है, इसलिए PoC चुपचाप चलता है। यदि कोई रेपो उन भरोसेमंद पथों के बाहर रहता है तो IDE .git/config पढ़ने से पहले "इस प्रकाशक पर भरोसा करें?" पूछेगा।

Git दस्तावेज़: core.fsmonitor और filter.* https://git-scm.com/docs/gitattributes पर।

टूल डाउनलोड करें