decalage2/collisionsHash collisions and their exploitations
TL;DR इन दो छवियों का MD5 टकराव प्राप्त करना अब(*) तुच्छ और तुरंत है।
⟷
<a href=http://gunshowcomic.com/648>
आग से मत खेलो, MD5 पर भरोसा मत करो।
(*) किसी भी दो फ़ाइलों का टकराव पैदा करना कई वर्षों से संभव है, लेकिन हर बार इसमें कई घंटे लगते हैं, बिना किसी शॉर्टकट के।
यह पृष्ठ फ़ाइल प्रारूपों और पूर्व-गणना किए गए टकराव उपसर्गों के लिए विशिष्ट तरकीबें प्रदान करता है ताकि टकराव को तुरंत बनाया जा सके।
git clone. स्क्रिप्ट चलाएँ। हो गया।
Ange Albertini और Marc Stevens द्वारा।
लक्ष्य मौजूदा हमलों का व्यापक रूप से पता लगाना है - और रास्ते में यह दिखाना है कि MD5 कितना कमज़ोर है (किसी भी JPG, PNG, PDF, MP4, PE... का तुरंत टकराव) - और सामान्य फ़ाइल प्रारूपों का विस्तार से पता लगाना है ताकि यह निर्धारित किया जा सके कि वर्तमान या भविष्य के हमलों से उनका दोहन कैसे किया जा सकता है।
वास्तव में, एक ही फ़ाइल प्रारूप तरकीब का उपयोग कई हैशों पर किया जा सकता है (वही JPG तरकीबें MD5, malicious SHA-1 और SHA1 के लिए उपयोग की गई थीं), जब तक टकराव समान बाइट पैटर्न का पालन करते हैं।
ज्ञात हमलों की वर्तमान स्थिति - दिसंबर 2018 तक -:
(*) crypt के साथ उदाहरण - धन्यवाद Sven!```
import crypt crypt.crypt("5dUD&66", "br") 'brokenOz4KxMc' crypt.crypt("O!>',%$", "br") 'brokenOz4KxMc'
# हमले
MD5 और SHA1 64 बाइट्स के ब्लॉकों के साथ काम करते हैं।
यदि दो सामग्रियों A और B का हैश समान है, तो दोनों में समान सामग्री C जोड़ने पर हैश समान बना रहेगा।``` text
hash(A) = hash(B) -> hash(A + C) = hash(B + C)
Collisions एक ब्लॉक सीमा पर कुछ गणना किए गए कोलिज़न ब्लॉक डालकर काम करते हैं जो फ़ाइल में पहले जो कुछ आया था उस पर निर्भर करते हैं। ये कोलिज़न ब्लॉक कुछ मामूली अंतरों के साथ बहुत यादृच्छिक दिखते हैं (जो प्रत्येक हमले के लिए एक विशिष्ट पैटर्न का अनुसरण करते हैं) और वे छोटे अंतर उत्पन्न करेंगे जबकि अंततः इन ब्लॉकों के बाद हैश का मान समान हो जाता है।
इन अंतरों का दुरुपयोग विशिष्ट गुणों वाली मान्य फ़ाइलें तैयार करने के लिए किया जाता है।
फ़ाइल प्रारूप भी ऊपर-से-नीचे काम करते हैं, और उनमें से अधिकांश बाइट-स्तरीय चंक्स द्वारा काम करते हैं।
कुछ 'कमेंट' चंक्स को फ़ाइल चंक्स को ब्लॉक सीमाओं के साथ संरेखित करने के लिए डाला जा सकता है, विशिष्ट संरचनाओं को कोलिज़न ब्लॉक अंतरों के साथ संरेखित करने के लिए, बाकी कोलिज़न ब्लॉक यादृच्छिकता को फ़ाइल पार्सर्स से छिपाने के लिए, और अन्यथा मान्य सामग्री को पार्सर से छिपाने के लिए (ताकि वह दूसरी सामग्री देख सके)।
ये 'कमेंट' चंक्स अक्सर आधिकारिक रूप से वास्तविक कमेंट नहीं होते: वे केवल डेटा कंटेनर के रूप में उपयोग किए जाते हैं जिन्हें पार्सर अनदेखा कर देता है (उदाहरण के लिए, लोअरकेस से शुरू होने वाले ID वाले PNG चंक्स सहायक (ancillary) होते हैं, महत्वपूर्ण (critical) नहीं)।
अधिकांश समय, कोलिज़न ब्लॉक में अंतर का उपयोग किसी कमेंट चंक की लंबाई को संशोधित करने के लिए किया जाता है,
जो आमतौर पर इस चंक के डेटा से ठीक पहले घोषित किया जाता है:
इस चंक के छोटे और लंबे संस्करण के बीच के अंतर में,
एक और कमेंट चंक घोषित किया जाता है ताकि वह एक फ़ाइल की सामग्री A को पार कर सके।
इस फ़ाइल सामग्री A के बाद, बस एक और फ़ाइल सामग्री B जोड़ दें।
चूँकि फ़ाइल प्रारूप आमतौर पर एक टर्मिनेटर परिभाषित करते हैं जो पार्सर्स को उसके बाद रुकने पर मजबूर कर देता है,
A पार्सिंग समाप्त कर देगा, जिससे जोड़ा गया कंटेंट B अनदेखा कर दिया जाएगा।
तो आमतौर पर कम से कम दो कमेंट की आवश्यकता होती है - अक्सर तीन:
फ़ाइल प्रारूपों के ये सामान्य गुण इसे संभव बनाते हैं - इन्हें आमतौर पर कमजोरियों के रूप में नहीं देखा जाता, लेकिन इन्हें पहचाना या सामान्यीकृत (normalized) किया जा सकता है:
| उपसर्ग | = | उपसर्ग |
|---|---|---|
| कोलिज़न A | ≠ | कोलिज़न B |
| सफ़िक्स | = | सफ़िक्स |
दोनों फ़ाइलें लगभग समान हैं (उनकी सामग्री में केवल कुछ बिट्स के अंतर हैं)
शोषण:
दो सामग्रियों को एक साथ बंडल करें, फिर या तो:
इस संरचना वाली दो फ़ाइलें:
या तो A या B प्रदर्शित होगा।
अंतिम संस्करण 2009 में।
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. X. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. X. .X ..
.. .. .. .. .. .. .. .. .. .. .. X. .. .. .. ..
अंतर ब्लॉकों के आरंभ/अंत के पास नहीं होते, इसलिए शोषण करना बहुत कठिन है क्योंकि आप किसी भी निकटवर्ती बाइट को नियंत्रित नहीं करते। एक संभावित समाधान आसपास के बाइट्स को ब्रूट-फोर्स करना है - देखें PoCGTFO 14:10।
उदाहरण:
खाली उपसर्ग के साथ:``` MD5: fe6c446ee3a831ee010f33ac9c1b602c SHA256: c5dd2ef7c74cd2e80a0fd16f1dd6955c626b59def888be734219d48da6b9dbdd
00: 37 75 C1 F1-C4 A7 5A E7-9C E0 DE 7A-5B 10 80 26 7u┴±─ºZτ£α▐z[►Ç&
10: 02 AB D9 39-C9 6C 5F 02-12 C2 7F DA-CD 0D A3 B0 ☻½┘9╔l_☻↕┬⌂┌═♪ú░
20: 8C ED FA F3-E1 A3 FD B4-EF 09 E7 FB-B1 C3 99 1D îφ·≤ßú²┤∩○τ√▒├Ö↔
30: CD 91 C8 45-E6 6E FD 3D-C7 BB 61 52-3E F4 E0 38 ═æ╚Eµn²=╟╗aR>⌠α8
40: 49 11 85 69-EB CC 17 9C-93 4F 40 EB-33 02 AD 20 I◄àiδ╠↨£ôO@δ3☻¡
50: A4 09 2D FB-15 FA 20 1D-D1 DB 17 CD-DD 29 59 1E ñ○-√§· ↔╤█↨═▌)Y▲ ................
60: 39 89 9E F6-79 46 9F E6-8B 85 C5 EF-DE 42 4F 46 9ë₧÷yFƒµïà┼∩▐BOF ...X............
70: C2 78 75 9D-8B 65 F4 50-EA 21 C5 59-18 62 FF 7B ┬xu¥ïe⌠PΩ!┼Y↑b { .............XX.
...........X....
................
00: 37 75 C1 F1-C4 A7 5A E7-9C E0 DE 7A-5B 10 80 26 7u┴±─ºZτ£α▐z[►Ç& ...X............
10: 02 AB D9 B9-C9 6C 5F 02-12 C2 7F DA-CD 0D A3 B0 ☻½┘╣╔l_☻↕┬⌂┌═♪ú░ .............XX.
20: 8C ED FA F3-E1 A3 FD B4-EF 09 E7 FB-B1 43 9A 1D îφ·≤ßú²┤∩○τ√▒CÜ↔ ...........X....
30: CD 91 C8 45-E6 6E FD 3D-C7 BB 61 D2-3E F4 E0 38 ═æ╚Eµn²=╟╗a╥>⌠α8
40: 49 11 85 69-EB CC 17 9C-93 4F 40 EB-33 02 AD 20 I◄àiδ╠↨£ôO@δ3☻¡ /
50: A4 09 2D 7B-15 FA 20 1D-D1 DB 17 CD-DD 29 59 1E ñ○-{§· ↔╤█↨═▌)Y▲
60: 39 89 9E F6-79 46 9F E6-8B 85 C5 EF-DE C2 4E 46 9ë₧÷yFƒµïà┼∩▐┬NF
70: C2 78 75 9D-8B 65 F4 50-EA 21 C5 D9-18 62 FF 7B ┬xu¥ïe⌠PΩ!┼┘↑b {
MD5: fe6c446ee3a831ee010f33ac9c1b602c SHA256: e27cf3073c704d0665da42d597d4d20131013204eecb6372a5bd60aeddd5d670
अन्य उदाहरण, समान उपसर्ग के साथ: [1](https://github.com/decalage2/collisions/blob/HEAD/examples/fastcoll1.bin) ⟷ [2](https://github.com/decalage2/collisions/blob/HEAD/examples/fastcoll2.bin)
**प्रकार**: एक [एकल-ब्लॉक MD5 संघट्टन](https://marc-stevens.nl/research/md5-1block-collision/) है, लेकिन इसकी गणना में पाँच सप्ताह लगते हैं।
यहाँ एक [रिकॉर्डिंग](https://github.com/decalage2/collisions/blob/HEAD/examples/fastcoll.svg) है जिसमें बिना किसी उपसर्ग के FastColl गणना दिखाई गई है,
और [एक और](https://github.com/decalage2/collisions/blob/HEAD/examples/fastcoll-prefix.svg) जिसमें एक उपसर्ग के साथ।
### [UniColl](https://github.com/decalage2/collisions/blob/HEAD/unicoll.md) (MD5)
[2012](https://www.cwi.nl/system/files/PhD-Thesis-Marc-Stevens-Attacks-on-Hash-Functions-and-Applications.pdf#page=199) में प्रलेखित, [2017](https://github.com/cr-marcstevens/hashclash/blob/95c2619a8078990056beb7aaa59104021714ee3c/scripts/poc_no.sh) में कार्यान्वित
[UniColl](https://github.com/cr-marcstevens/hashclash#create-you-own-identical-prefix-collision) आपको संघट्टन ब्लॉक्स में पहले अंतर से पहले और बाद के कुछ बाइट्स नियंत्रित करने देता है,
जो इसे कुछ नियंत्रणीय अंतरों के साथ एक समान-उपसर्ग संघट्टन बनाता है, लगभग एक चयनित-उपसर्ग संघट्टन जैसा।
यह बहुत सुविधाजनक है, और इससे भी बेहतर, अंतर बहुत अनुमानित हो सकता है:
`m2+= 2^8` के मामले में (जिसे HashClash [poc_no.sh](https://github.com/cr-marcstevens/hashclash/blob/master/scripts/poc_no.sh#L30) स्क्रिप्ट में `N=1` / `m2 9` भी कहा जाता है),
अंतर 9वें बाइट पर +1 होता है, जो इसे बहुत शोषणीय बनाता है,
क्योंकि आप संघट्टन के बारे में अपने दिमाग में भी सोच सकते हैं:
उस वाक्य का 9वां अक्षर अगले अक्षर से बदल दिया जाएगा: `0` को `1` से, `a` को `b` से बदला जाएगा..
- समय: कुछ मिनट (आप जितने बाइट्स को नियंत्रित करना चाहते हैं उस पर निर्भर करता है )
- स्थान: दो ब्लॉक
- अंतर: ```
.. .. .. .. DD .. .. .. ..
.. .. .. .. +1 .. .. .. ..
N=1 और collision blocks में 20 बाइट्स सेट टेक्स्ट वाले उदाहरण:```
00: 55 6E 69 43-6F 6C 6C 20-31 20 70 72-65 66 69 78 UniColl 1 prefix
10: 20 32 30 62-F5 48 34 B9-3B 1C 01 9F-C8 6B E6 44 20b⌡H4╣;∟☺ƒ╚kµD
20: FE F6 31 3A-63 DB 99 3E-77 4D C7 5A-6E B0 A6 88 ■÷1:c█Ö>wM╟Zn░ªê
30: 04 05 FB 39-33 21 64 BF-0D A4 FE E2-A6 9D 83 36 ♦♣√93!d┐♪ñ■Γª¥â6
40: 4B 14 D7 F2-47 53 84 BA-12 2D 4F BB-83 78 6C 70 K¶╫≥GSä║↕-O╗âxlp
50: C6 EB 21 F2-F6 59 9A 85-14 73 04 DD-57 5F 40 3C ╞δ!≥÷YÜà¶s♦▌W_@< .........X......
60: E1 3F B0 DB-E8 B4 AA B0-D5 56 22 AF-B9 04 26 FC ß?░█Φ┤¬░╒V"»╣♦&ⁿ ................
70: 9F D2 0C 00-86 C8 ED DE-85 7F 03 7B-05 28 D7 0F ƒ╥♀ å╚φ▐à⌂♥{♣(╫☼ ................
................
.........X......
00: 55 6E 69 43-6F 6C 6C 20-31 21 70 72-65 66 69 78 UniColl 1!prefix ................
10: 20 32 30 62-F5 48 34 B9-3B 1C 01 9F-C8 6B E6 44 20b⌡H4╣;∟☺ƒ╚kµD ................
20: FE F6 31 3A-63 DB 99 3E-77 4D C7 5A-6E B0 A6 88 ■÷1:c█Ö>wM╟Zn░ªê ................
30: 04 05 FB 39-33 21 64 BF-0D A4 FE E2-A6 9D 83 36 ♦♣√93!d┐♪ñ■Γª¥â6
40: 4B 14 D7 F2-47 53 84 BA-12 2C 4F BB-83 78 6C 70 K¶╫≥GSä║↕,O╗âxlp /
50: C6 EB 21 F2-F6 59 9A 85-14 73 04 DD-57 5F 40 3C ╞δ!≥÷YÜà¶s♦▌W_@<
60: E1 3F B0 DB-E8 B4 AA B0-D5 56 22 AF-B9 04 26 FC ß?░█Φ┤¬░╒V"»╣♦&ⁿ
70: 9F D2 0C 00-86 C8 ED DE-85 7F 03 7B-05 28 D7 0F ƒ╥♀ å╚φ▐à⌂♥{♣(╫☼
UniColl के पास एक सच्चे chosen-prefix collision की तुलना में कम नियंत्रण होता है, लेकिन यह बहुत तेज़ है, खासकर जब इसमें केवल दो ब्लॉक लगते हैं।
यहाँ एक UniColl गणना का [रिकॉर्डिंग](https://github.com/decalage2/collisions/blob/HEAD/examples/unicoll.svg) है।
### [Shattered](http://shattered.io) (SHA1)
[2013](https://marc-stevens.nl/research/papers/EC13-S.pdf) में प्रलेखित, [2017](http://shattered.io) में परिकलित।
- समय: 6500 years.CPU and 110 year.GPU
- स्थान: दो ब्लॉक
- अंतर: ```
.. .. .. DD ?? ?? ?? ??
or
?? ?? ?? DD .. .. .. ..
The difference between collision blocks of each side is this Xor mask:``` 0C 00 00 02 C0 00 00 10 B4 00 00 1C 3C 00 00 04 BC 00 00 1A 20 00 00 10 24 00 00 1C EC 00 00 14 0C 00 00 02 C0 00 00 10 B4 00 00 1C 2C 00 00 04 BC 00 00 18 B0 00 00 10 00 00 00 0C B8 00 00 10
उदाहरण: [PoC||GTFO 0x18](https://github.com/angea/pocorgtfo#0x18) गणना किए गए SHA1 उपसर्गों का उपयोग कर रहा है,
छवि को सीधे PDFLaTeX स्रोत से पुनः उपयोग करते हुए ([लेख 18:10](https://archive.org/stream/pocorgtfo18#page/n62/mode/1up) देखें),
लेकिन HTML पेज में JavaScript के माध्यम से उपसर्गों के मान की जाँच भी कर रहा है (फ़ाइल पॉलीग्लॉट है, ZIP HTML और PDF)।
## चयनित-उपसर्ग टकराव
वे किसी भी सामग्री को टकराने की अनुमति देते हैं।
| 𝓐 | ≠ | 𝔅 |
| :----: |:-:| :----: |
| टकराव *A* | ≠ | टकराव *B* |
1. दो मनमाने उपसर्ग लें
2. सबसे छोटे को सबसे लंबे जितना लंबा करने के लिए पैड करें। दोनों को अगले ब्लॉक तक पैड किया जाता है - 12 बाइट घटाकर
- ये 12 बाइट यादृच्छिक डेटा बर्थडे खोज को यादृच्छिक बनाने के लिए दोनों ओर जोड़े जाएंगे
3. X निकट-टकराव ब्लॉक की गणना करके जोड़े जाएंगे।
जितने कम ब्लॉक, उतनी लंबी गणना।
उदा.: एक ब्लॉक के लिए [400 kHours](https://www.win.tue.nl/hashclash/SingleBlock/)। [HashClash](https://github.com/cr-marcstevens/hashclash) के साथ नौ ब्लॉकों के लिए 72 घंटे.कोर।
चयनित-उपसर्ग टकराव सर्वशक्तिमान होते हैं, लेकिन सिर्फ एक जोड़ी फाइलों के लिए उनमें लंबा समय लग सकता है।
### [HashClash](https://github.com/cr-marcstevens/hashclash) (MD5)
अंतिम संस्करण [2009](https://www.win.tue.nl/hashclash/ChosenPrefixCollisions/) में।
उदाहरण: चलिए `yes` और `no` को टकराते हैं। इसमें 24 कोर पर तीन घंटे लगे।```
'yes' prefix:
000: 79 65 73 0A-3D 62 84 11-01 75 D3 4D-EB 80 93 DE yes◙=bä◄☺u╙MδÇô▐ - Prefix, padding
010: 31 C1 D9 30-45 FB BE 1E-71 F0 0A 63-75 A8 30 AA 1┴┘0E√╛▲q≡◙cu¿0¬
020: 98 17 CA E3-A2 6B 8E 3D-44 A9 8F F2-0E 67 96 48 ÿ↨╩πókÄ=D⌐Å≥♫gûH
030: 97 25 A6 FB-00 00 00 00-49 08 09 33-F0 62 C4 E8 ù%ª√ I◘○3≡b─Φ
040: D5 F1 54 CD-CA A1 42 90-7F 9D 3D 9A-67 C4 1B 0F ╒±T═╩íBÉ⌂¥=Üg─←☼ - Collision blocks start
050: 04 9F 19 E8-92 C3 AA 19-43 31 1A DB-DA 96 01 54 ♦ƒ↓ΦÆ├¬↓C1→█┌û☺T
060: 85 B5 9A 88-D8 A5 0E FB-CD 66 9A DA-4F 20 8A AA à╡Üê╪Ñ♫√═fÜ┌O è¬
070: BA E3 9C F0-78 31 8F D1-14 5F 3E B9-0F 9F 3E 19 ║π£≡x1Å╤¶_>╣☼ƒ>↓
080: 09 9C BB A9-45 89 BA A8-03 E6 C0 31-A0 54 D6 26 ○£╗⌐Eë║¿♥µ└1áT╓&
090: 3F 80 4C 06-0F C7 D9 19-09 D3 DA 14-FD CB 39 84 ?ÇL♠☼╟┘↓○╙┌¶²╦9ä
0A0: 1F 0D 77 5F-55 AA 7A 07-4C 24 8B 13-0A 54 A2 BC ▼♪w_U¬z•L$ï‼◙Tó╝
0B0: C5 12 7D 4F-E0 5E F2 23-C5 07 61 E4-80 91 B2 13 ┼↕}Oα^≥#┼•aΣÇæ▓‼
0C0: E7 79 07 2A-CF 1B 66 39-8C F0 8E 7E-75 25 22 1D τy•*╧←f9î≡Ä~u%"↔
0D0: A7 3B 49 4A-32 A4 3A 07-61 26 64 EA-6B 83 A2 8D º;IJ2ñ:•a&dΩkâóì
0E0: BE A3 FF BE-4E 71 AE 18-E2 D0 86 4F-20 00 30 26 ╛ú ╛Nq«↑Γ╨åO 0&
0F0: 0A 71 DE 1F-40 B4 F4 8F-9C 50 5C 78-DD CD 72 89 ◙q▐▼@┤⌠Å£P\x▌═rë
100: BA D1 BF F9-96 80 E3 06-96 F3 B9 7C-77 2D EB 25 ║╤┐∙ûÇπ♠û≤╣|w-δ%
110: 1E 56 70 D7-14 1F 55 4D-EC 11 58 59-92 45 E1 33 ▲Vp╫¶▼UM∞◄XYÆEß3
120: 3E 0E A1 6E-FF D9 90 AD-F6 A0 AD 0E-C6 D6 88 12 >♫ín ┘É¡÷á¡♫╞╓ê↕
130: B8 74 F2 9E-DD 53 F7 88-19 73 85 39-AA 9B E0 8D ╕t≥₧▌S≈ê↓sà9¬¢αì
\
140: 82 BF 9C 5E-58 42 1E 3B-94 CF 5B 54-73 5F A8 4A é┐£^XB▲;ö╧[Ts_¿J
150: FD 5B 64 CF-59 D1 96 74-14 B3 0C AF-11 1C F9 47 ²[d╧Y╤ût¶│♀»◄∟∙G ................
160: C5 7A 2C F7-D5 24 F5 EB-BE 54 3E 12-B0 24 67 3F ┼z,≈╒$⌡δ╛T>↕░$g? ................
170: 01 DD 95 76-8D 0D 58 FB-50 23 70 3A-BD ED BE AC ☺▌òvì♪X√P#p:╜φ╛¼ ...............X
................
180: B8 32 DB AE-E8 DC 3A 83-7A C8 D5 0F-08 90 1D 99 ╕2█«Φ▄:âz╚╒☼◘É↔Ö
190: 2D 7D 17 34-4E A8 21 98-61 1A 65 DA-FC 9B A4 BA -}↨4N¿!ÿa→e┌ⁿ¢ñ║ ................
1A0: E1 42 2B 86-0C 94 2A F6-D6 A4 81 B5-2B 0B E9 37 ßB+å♀ö*÷╓ñü╡+♂Θ7 ................
1B0: 44 D2 E4 23-14 7C 16 B8-84 90 8B E0-A1 A7 BD 27 D╥Σ#¶|▬╕äÉïαíº╜' ..............X.
................
1C0: C7 7E E6 17-1A 93 C5 EE-59 70 91 26-4E 9D C7 7C ╟~µ↨→ô┼εYpæ&N¥╟|
1D0: 1D 3D AB F1-B4 F4 F1 D9-86 48 75 77-6E FE 98 84 ↔=½±┤⌠±┘åHuwn■ÿä ................
1E0: EF 3C 1C C7-16 5A 1F 83-60 EC 5C FE-CA 17 0C 74 ∩<∟╟▬Z▼â`∞\■╩↨♀t ................
1F0: EB 8E 9D F6-90 A3 CD 08-65 D5 5A 4C-2E C6 BE 54 δÄ¥÷Éú═◘e╒ZL.╞╛T ...............X
................
'no' prefix: ................
000: 6E 6F 0A E5-5F D0 83 01-9B 4D 55 06-61 AB 88 11 no◙σ_╨â☺¢MU♠a½ê◄ ................
010: 8A FA 4D 34-B3 75 59 46-56 97 EF 6C-4A 07 90 CC è·M4│uYFVù∩lJ•É╠ ............X...
020: FE 19 D7 CF-6F 92 03 9C-91 AA A5 DA-56 92 C1 04 ■↓╫╧oÆ♥£æ¬Ñ┌VÆ┴♦ ................
030: E6 4C 08 A3-00 00 00 00-8D B6 4E 47-FF AF 7A 3C µL◘ú ì╢NG »z<
................
040: D5 F1 54 CD-CA A1 42 90-7F 9D 3D 9A-67 C4 1B 0F ╒±T═╩íBÉ⌂¥=Üg─←☼ ................
050: 04 9F 19 E8-92 C3 AA 19-43 31 1A DB-DA 96 01 54 ♦ƒ↓ΦÆ├¬↓C1→█┌û☺T ............X...
060: 85 B5 9A 88-D8 A5 0E FB-CD 66 9A DA-4F 20 8A A9 à╡Üê╪Ñ♫√═fÜ┌O è⌐ ................
070: BA E3 9C F0-78 31 8F D1-14 5F 3E B9-0F 9F 3E 19 ║π£≡x1Å╤¶_>╣☼ƒ>↓
................
080: 09 9C BB A9-45 89 BA A8-03 E6 C0 31-A0 54 D6 26 ○£╗⌐Eë║¿♥µ└1áT╓& ................
090: 3F 80 4C 06-0F C7 D9 19-09 D3 DA 14-FD CB 39 84 ?ÇL♠☼╟┘↓○╙┌¶²╦9ä .............X..
0A0: 1F 0D 77 5F-55 AA 7A 07-4C 24 8B 13-0A 54 B2 BC ▼♪w_U¬z•L$ï‼◙T▓╝ ................
0B0: C5 12 7D 4F-E0 5E F2 23-C5 07 61 E4-80 91 B2 13 ┼↕}Oα^≥#┼•aΣÇæ▓‼
................
0C0: E7 79 07 2A-CF 1B 66 39-8C F0 8E 7E-75 25 22 1D τy•*╧←f9î≡Ä~u%"↔ ................
0D0: A7 3B 49 4A-32 A4 3A 07-61 26 64 EA-6B 83 A2 8D º;IJ2ñ:•a&dΩkâóì ...............X
0E0: BE A3 FF BE-4E 71 AE 18-E2 D0 86 4F-20 00 30 22 ╛ú ╛Nq«↑Γ╨åO 0" ................
0F0: 0A 71 DE 1F-40 B4 F4 8F-9C 50 5C 78-DD CD 72 89 ◙q▐▼@┤⌠Å£P\x▌═rë
/
100: BA D1 BF F9-96 80 E3 06-96 F3 B9 7C-77 2D EB 25 ║╤┐∙ûÇπ♠û≤╣|w-δ%
110: 1E 56 70 D7-14 1F 55 4D-EC 11 58 59-92 45 E1 33 ▲Vp╫¶▼UM∞◄XYÆEß3
120: 3E 0E A1 6E-FF D9 90 AD-F6 A0 AD 0E-CA D6 88 12 >♫ín ┘É¡÷á¡♫╩╓ê↕
130: B8 74 F2 9E-DD 53 F7 88-19 73 85 39-AA 9B E0 8D ╕t≥₧▌S≈ê↓sà9¬¢αì
140: 82 BF 9C 5E-58 42 1E 3B-94 CF 5B 54-73 5F A8 4A é┐£^XB▲;ö╧[Ts_¿J
150: FD 5B 64 CF-59 D1 96 74-14 B3 0C AF-11 1C F9 47 ²[d╧Y╤ût¶│♀»◄∟∙G
160: C5 7A 2C F7-D5 24 F5 EB-BE 54 3E 12-70 24 67 3F ┼z,≈╒$⌡δ╛T>↕p$g?
170: 01 DD 95 76-8D 0D 58 FB-50 23 70 3A-BD ED BE AC ☺▌òvì♪X√P#p:╜φ╛¼
180: B8 32 DB AE-E8 DC 3A 83-7A C8 D5 0F-08 90 1D 99 ╕2█«Φ▄:âz╚╒☼◘É↔Ö
190: 2D 7D 17 34-4E A8 21 98-61 1A 65 DA-FC 9B A4 BA -}↨4N¿!ÿa→e┌ⁿ¢ñ║
1A0: E1 42 2B 86-0C 94 2A F6-D6 A4 81 B5-2B 2B E9 37 ßB+å♀ö*÷╓ñü╡++Θ7
1B0: 44 D2 E4 23-14 7C 16 B8-84 90 8B E0-A1 A7 BD 27 D╥Σ#¶|▬╕äÉïαíº╜'
1C0: C7 7E E6 17-1A 93 C5 EE-59 70 91 26-4E 9D C7 7C ╟~µ↨→ô┼εYpæ&N¥╟|
1D0: 1D 3D AB F1-B4 F4 F1 D9-86 48 75 77-6E FE 98 84 ↔=½±┤⌠±┘åHuwn■ÿä
1E0: EF 3C 1C C7-16 5A 1F 83-60 EC 5C FE-CA 17 0C 54 ∩<∟╟▬Z▼â`∞\■╩↨♀T
1F0: EB 8E 9D F6-90 A3 CD 08-65 D5 5A 4C-2E C6 BE 54 δÄ¥÷Éú═◘e╒ZL.╞╛T
यहाँ पूरे ऑपरेशन का लॉग है।
Shambles एक अत्यंत महंगा chosen-prefix collision है जो 9 ब्लॉकों का उपयोग करता है।
प्रत्येक ब्लॉक में Shattered के समान xor पैटर्न होता है:``` 0C 00 00 02 C0 00 00 10 B4 00 00 1C 3C 00 00 04 BC 00 00 1A 20 00 00 10 24 00 00 1C EC 00 00 14 0C 00 00 02 C0 00 00 10 B4 00 00 1C 2C 00 00 04 BC 00 00 18 B0 00 00 10 00 00 00 0C B8 00 00 10
## हमलों का सारांश
हैश | नाम | दिनांक | अवधि | उपसर्ग प्रकार | अंतर के निकट नियंत्रण
---- | --------- | ---- | -------- | ----------- | -----------------
MD5 | FastColl | 2009 | 2s | समान | कोई नहीं
| UniColl | 2012 | 7-40min | समान | 4-10 bytes
| HashClash | 2009 | 72h | चयनित | n/a
| | | | |
SHA1 | Shattered | 2013 | 6500yr | समान | उपसर्ग और प्रत्यय
| Shambles | 2020 | ? | चयनित | n/a
# शोषण
समान उपसर्ग टकराव को आमतौर पर (बहुत) सीमित माना जाता है, लेकिन चयनित-उपसर्ग समय लेने वाला होता है।
एक और दृष्टिकोण पुन: प्रयोग योग्य उपसर्गों को तैयार करना है - या तो UniColl जैसे समान-उपसर्ग हमले के माध्यम से, या कुछ सीमाओं को दूर करने के लिए चयनित-उपसर्ग द्वारा - लेकिन उस उपसर्ग जोड़ी को दो पेलोड के साथ संयोजन में पुन: उपयोग करना, जैसे कि एक क्लासिक समान-उपसर्ग हमला हो।
एक बार उपसर्ग जोड़ी की गणना हो जाने पर, यह दो सामग्रियों को टकराना तात्क्षणिक बना देता है:
यह केवल फ़ाइल डेटा को (विशिष्ट फ़ाइल प्रारूपों के अनुसार) इस प्रकार समायोजित करने की बात है कि वह फ़ाइल प्रारूपों की विशिष्टताओं और पूर्व-गणना किए गए उपसर्ग की आवश्यकताओं में फिट बैठे।
## मानक रणनीति
एक ही फ़ाइल प्रकार की दो मान्य फ़ाइलों के क्लासिक टकराव।
### JPG
सैद्धांतिक सीमाएँ और समाधान:
- सिद्धांततः *Application* सेगमेंट *Start of Image* मार्कर के ठीक बाद होना चाहिए।
व्यवहार में यह आवश्यक नहीं है, इसलिए हमारा टकराव जेनेरिक हो सकता है: एकमात्र सीमा सबसे छोटी छवि का आकार है।
- एक टिप्पणी की लंबाई दो बाइट्स में संग्रहीत होती है, इसलिए इसमें संग्रहीत की जा सकने वाली मात्रा 65536 बाइट्स तक सीमित है (लगभग 400x400 फोटो के आकार के बराबर)।
- किसी पूर्ण JPG फ़ाइल को कूदकर पार करने के बजाय, उस फ़ाइल को उसके सेगमेंटों में विभाजित किया जा सकता है, और सेगमेंटों के बीच जंप ट्रैम्पोलिन जोड़े जा सकते हैं।
*प्रत्येक छवि सेगमेंट पर टिप्पणियाँ*
*टिप्पणियों के ट्रैम्पोलिन कैसे काम करते हैं*
- जबकि JPG संरचना का अधिकांश भाग ऐसे सेगमेंटों से बना होता है जो सभी आकार में 65536 बाइट्स तक सीमित होते हैं,
वास्तविक संपीड़ित डेटा *Entropy Coded Segment* में संग्रहीत होता है, जो अपनी सीमाओं का पालन नहीं करता:
इसका आकार पहले से अज्ञात होता है और उस सीमा से आगे बढ़ता जाता है।
यह छवि के आकार के साथ बढ़ता है, जिससे बेसलाइन (गैर-प्रगतिशील) छवि में फ़ाइल का अधिकांश आकार बनता है।
पूरी छवि को 64kb चंक्स में फिट करने के लिए, आसान तरीका यह है कि पहले छवि को प्रगतिशील रूप में सहेजने का प्रयास किया जाए (जो कोई भी सॉफ़्टवेयर कर सकता है, और ECS को आमतौर पर अधिकतम छह स्कैनों में विभाजित करता है)। अधिक उन्नत तरीका *JPEGTran* का उपयोग उसके 'विज़ार्ड' `--scans` कमांड लाइन पैरामीटर के साथ करना और कस्टम स्कैन परिभाषित करना है।
स्कैन सेगमेंटों के अलावा कोई अन्य प्रतिबंध नहीं है,
इसलिए दो मनमाने JPGs के बीच MD5 टकराव *तात्क्षणिक* है, और इसे किसी चयनित-उपसर्ग टकराव की आवश्यकता नहीं है, केवल UniColl की आवश्यकता है।
[स्क्रिप्ट](https://github.com/decalage2/collisions/blob/HEAD/scripts/jpg.py) के साथ:```
21:07:35.65>jpg.py Ange.jpg Marc.jpg
21:07:35.75>
उदाहरण:
⟷
2 MD5-टकराने वाली JPGs
यहाँ JPEGTran स्कैन परिभाषा का एक उदाहरण है जो 1944x2508 RGB इमेज को 20 स्कैन वाली 100% JPG में बदल देता है, जिनमें सभी 64kb में समा जाते हैं।``` // : -, , ;
// 0=luma 0: 0-0, 0, 0; 0: 1-1, 0, 0; 0: 2-6, 0, 0; 0: 7-10, 0, 0; 0: 11-13, 0, 0; 0: 14-20, 0, 0; 0: 21-26, 0, 0; 0: 27-32, 0, 0; 0: 33-40, 0, 0; 0: 41-48, 0, 0; 0: 49-54, 0, 0; 0: 55-63, 0, 0;
// 1=blueness 1: 0-0, 0, 0; 1: 1-16, 0, 0; 1: 17-32, 0, 0; 1: 33-63, 0, 0;
// 2=redness 2: 0-0, 0, 0; 2: 1-16, 0, 0; 2: 17-32, 0, 0; 2: 33-63, 0, 0;
परिणाम:
*20 स्कैन वाली 100% JPG के रूप में एक 1944x2508 RGB छवि*
### PNG
सैद्धांतिक सीमाएँ और कार्य-उपाय:
- PNG अपने chunks के अंत में CRC32 का उपयोग करता है, लेकिन व्यवहार में उन्हें अनदेखा किया जाता है। वे सही हो सकते हैं लेकिन यह आवश्यक नहीं है।
- छवि का मेटा डेटा (आयाम, कलर स्पेस...) `IHDR` chunk में संग्रहीत होता है,
जो सिद्धांत रूप में सिग्नेचर के ठीक बाद होना चाहिए (अर्थात, किसी भी संभावित टिप्पणी से पहले),
इसलिए इसका मतलब होगा कि हम केवल समान मेटा डेटा वाली छवियों के टकराव (collisions) की पूर्व-गणना कर सकते हैं।
हालाँकि, वह chunk वास्तव में एक कमेंट ब्लॉक के बाद हो सकता है (अधिकांश रीडर्स में, Apple के रीडर्स को छोड़कर), इसलिए हम टकराव डेटा को हेडर से पहले रख सकते हैं,
जो एक ही पूर्व-गणना के साथ PNG के किसी भी जोड़े को टकराने (collide) में सक्षम बनाता है।
चूँकि एक PNG chunk की लंबाई चार बाइट्स पर होती है, किसी भी फ़ाइल की संरचना को संशोधित करने की आवश्यकता नहीं है: हम एक ही बार में पूरी छवि को छोड़ सकते हैं।
हम जितने चाहें उतने छोड़े गए chunks डाल सकते हैं, इसलिए हम संरेखण (alignment) के लिए एक जोड़ सकते हैं, फिर एक ऐसा जिसकी लंबाई UniColl द्वारा बदल दी जाएगी। इसलिए लंबाई `00` `75` और `01` `75` होगी।
इसलिए दो मनमानी PNG छवियों का MD5 टकराव *तात्कालिक* है, बिना किसी पूर्वापेक्षा (कोई गणना नहीं, केवल कुछ मामूली फ़ाइल परिवर्तन), और इसे किसी chosen-prefix collision की आवश्यकता नहीं है, बस UniColl की।
[स्क्रिप्ट](https://github.com/decalage2/collisions/blob/HEAD/scripts/png.py) के साथ:```
19:27:04.79>png.py nintendo.png sega.png
19:27:04.87>
उदाहरण:
⟷
अलग-अलग गुणों वाली 2 MD5-टकराव वाली PNGs
यहाँ पूरी प्रक्रिया की एक रिकॉर्डिंग है।
अधिकांश रीडर ऐसी PNG फ़ाइलों को बिना किसी समस्या के स्वीकार कर लेते हैं जो IHDR न होने वाले चंक से शुरू होती हैं।
हालाँकि, कुछ (जैसे Safari और Preview - कोई और?) इसे बर्दाश्त नहीं करते। ऐसे मामले में, इमेज हेडर और उसके गुण (आयाम, कलर स्पेस) किसी भी टकराव ब्लॉक से पहले होने चाहिए।
ऐसे मामले में, दोनों टकराव वाली फ़ाइलों के गुण समान होने चाहिए। फिर से, UniColl ही पर्याप्त है, और निश्चित रूप से गणना की गई प्रीफ़िक्स जोड़ी का पुनः उपयोग समान गुणों वाली किसी भी अन्य फ़ाइल जोड़ी के लिए किया जा सकता है।
यहाँ ऐसी फ़ाइलों की किसी भी जोड़ी को टकराने के लिए एक स्क्रिप्ट है, जो आवश्यकता पड़ने पर प्रीफ़िक्स जोड़ी की गणना करने के लिए UniColl लॉन्च करती है।
उदाहरण:
⟷
⟷
अधिकतम संगतता के लिए समान गुणों वाली MD5-टकराव वाली PNGs की 2 जोड़ियाँ
यहाँ पूरी प्रक्रिया की एक रिकॉर्डिंग है, जब UniColl लॉन्च किया जाता है,
और दूसरी रिकॉर्डिंग तब, जब प्रीफ़िक्स की गणना पहले ही की जा चुकी हो।
GIF पेचीदा है:
हालाँकि, टिप्पणी चंक एक विशिष्ट संरचना का अनुसरण करते हैं: यह <length:1> <data:length> की एक श्रृंखला है जब तक कि एक null लंबाई परिभाषित न हो जाए।
इसलिए यह किसी भी गैर-शून्य बाइट को एक वैध 'आगे कूदने' का अवसर बनाता है, जो इसे FastColl के साथ उपयोग के लिए उपयुक्त बनाता है,
जैसा कि PoC||GTFO 14:11 में दिखाया गया है।
तो कम से कम, भले ही हमारे पास एक सामान्य प्रीफ़िक्स न हो, हम समान मेटाडेटा (आयाम, पैलेट) वाली GIF की किसी भी जोड़ी को टकरा सकते हैं और हमें इसका प्रीफ़िक्स गणना करने के लिए FastColl के केवल एक सेकंड की आवश्यकता होती है।
अब समस्या यह है कि हम PNG की तरह पूरी इमेज के ऊपर या JPG की तरह किसी बड़ी संरचना के ऊपर कूद नहीं सकते।
एक संभावित समाधान संपीड़ित डेटा को समायोजित करना है या इमेज को छोटे-छोटे क्षेत्रों में विभाजित करना है, जैसा कि GIF hashquine के मामले में है, लेकिन यह इष्टतम नहीं है।
एक और विचार जो सामान्य रूप से काम करता है वह यह है कि इमेज डेटा भी इसी length data अनुक्रम संरचना का उपयोग करके संग्रहीत किया जाता है:
इसलिए यदि हम बिना एनीमेशन वाली दो GIF लेते हैं, तो हमें केवल यह करना होता है:
मामूली सेटअप (केवल कुछ सौ बाइट्स के ओवरहेड) के साथ, हम किसी भी GIF इमेज के ऊपर स्लेज कर सकते हैं और 256 बाइट्स की सीमा को दरकिनार कर सकते हैं। यह विचार Marc द्वारा सुझाया गया था, और यह शानदार है!
तो अंत में, तत्काल MD5 टकराव के लिए वर्तमान GIF सीमाएँ हैं:
gifsicle --use-colormap webस्थिर GIF इमेज को सामान्य करने का एक आसान शॉर्टकट उन्हें एक ही इमेज के एनीमेशन फ्रेम बनाना है, फिर हम एक स्क्रिप्ट का उपयोग करके FastColl ब्लॉक का पुनः उपयोग या गणना कर सकते हैं ताकि एक फ़ाइल जोड़ी बनाई जा सके जो उनमें से प्रत्येक को दिखाती है।
उदाहरण:
⟷
2 MD5-टकराव वाली GIFs - चित्र KidMoGraph द्वारा
यहाँ पूरी प्रक्रिया की एक रिकॉर्डिंग है।
GZIP विनिर्देश v4.3: RFC 1952 (1996)।
1F 8B की जाँच की जाएगी। यदि हस्ताक्षर मेल नहीं खाता है, तो पार्सिंग रुक जाएगी, जिसका उपयोग दो पेलोड के बीच पार्सिंग को जबरन रोकने के लिए किया जा सकता है, लेकिन इससे कुछ चेतावनियाँ उत्पन्न होंगी जो समस्याएँ पैदा कर सकती हैं। एक अन्य रणनीति फ़ाइल के अंत में एक अतिरिक्त खाली member जोड़ना है, और दोनों पेलोड की पार्सिंग को वहीं समाप्त करना है - member पर या उसके body पर।filename और file comment null-समाप्त होते हैं जबकि Extra field size16-परिभाषित होता है, इसलिए दुरुपयोग योग्य है। यह एक या अधिक subfield(s) से बना होता है, जिसमें एक ID और अपनी स्वयं की sublength होती है, लेकिन subfields को लागू नहीं किया जाता है - बहुत कम आधिकारिक रूप से परिभाषित हैं।इसलिए एक extra field वाला खाली gzip member एक आदर्श परजीवी मेज़बान है।
यदि शीर्ष फ़ाइल extra field में फिट होने के लिए बहुत बड़ी है, तो इसकी असंपीड़ित स्ट्रीम को छोटी फ़ाइलों में विभाजित किया जा सकता है जब तक कि वे सभी extra fields में फिट न हो जाएँ।
एक member के हेडर के बाद उसका संपीड़ित body, उसका CRC32 और उसका असंपीड़ित आकार (लागू नहीं) आते हैं। इसलिए null CRC32 और आकार वाला एक खाली डेटा body एक सामान्य postwrap बनाता है, जिसे विभिन्न member हेडर के बीच भी साझा किया जा सकता है।
विभिन्न कार्यान्वयन सभी members के योग के बजाय अंतिम member के असंपीड़ित आकार पर भरोसा करते हैं। इसलिए हमारी टकराव वाली फ़ाइलें दिखाएँगी कि वे null-आकार की हैं, क्योंकि ये फ़ाइलें एक खाली member के साथ समाप्त होती हैं जिसे trampoline के रूप में उपयोग किया जाता है।
यहाँ दो GZip फ़ाइलों के तत्काल MD5 टकराव उत्पन्न करने के लिए एक स्क्रिप्ट है। यदि इनपुट फ़ाइलें बड़ी हैं तो इसमें अधिकांश समय डेटा को डीकंप्रेस और पुनः कंप्रेस करने में लगता है - टकराव प्रीफ़िक्स पहले से गणना किए गए हैं। डीकंप्रेस किए बिना members को विभाजित करना संभव नहीं है क्योंकि असंपीड़ित CRC32 की गणना करने की आवश्यकता होती है।
एक .tar.gz केवल एक tar संग्रह का gzip संग्रह है। यह gzipped tar के साथ ठीक काम करेगा, tar के विपरीत।
उदाहरण: collision1.tar.gz (Pacome) ⟷ collision2.tar.gz (Reg)
Portable Executable की एक विशिष्ट संरचना होती है:
तो रणनीति यह है:
DOS/Collisions/Header1/Header2 संरचना के बाद एक-दूसरे के बगल में रखा जा सकता है। आपको बस दो सेक्शन तालिकाओं के ऑफसेट में डेल्टा लागू करने की आवश्यकता है।इसका अर्थ है कि PE executables की किसी भी जोड़ी को तुरंत टकराना संभव है। भले ही वे विभिन्न subsystems या architecture का उपयोग करते हों।
जबकि executables के टकराव आमतौर पर किसी भी loader के माध्यम से सरल होते हैं, यहाँ इस प्रकार का दोहन पारदर्शी है: कोड समान है और समान पते पर लोड होता है।
उदाहरण: tweakPNG.exe (GUI) ⟷ fastcoll.exe (CLI)
यहाँ Windows Executables के तत्काल MD5 टकराव उत्पन्न करने के लिए एक स्क्रिप्ट है।
इस प्रारूप का कंटेनर Length Type Value चंकों का एक अनुक्रम है जिन्हें Atoms कहा जाता है।
लंबाई 32-बिट बिग-एंडियन होती है और यह स्वयं, type और value को कवर करती है, इसलिए न्यूनतम सामान्य लंबाई 8 है
(type एक 4 ASCII वर्णों की स्ट्रिंग है)।
यदि लंबाई null है, तो atom फ़ाइल का शेष भाग ले लेता है - जैसे JP2 फ़ाइलों में jp2c atoms।
यदि यह 1 है, तो Type के बाद 64-बिट लंबाई आती है, जो atom को Type Length Value में बदल देती है, जिससे यह Shattered जैसे अन्य टकरावों के साथ संगत हो जाता है।
कुछ atoms अन्य atoms को समाहित करते हैं: ऐसे मामलों में, उन्हें boxes कहा जाता है। इसीलिए इस अन्यथा अनाम संरचना को "atom/box" कहा जाता है।
MP4 में उपयोग किया जाने वाला यह "atom/box" प्रारूप वास्तव में Apple Quicktime का व्युत्पन्न है, और कई अन्य प्रारूपों (JP2, HEIF, F4V) द्वारा उपयोग किया जाता है।
पहला atom type आमतौर पर ftyp होता है, जो वास्तविक फ़ाइल प्रारूप में अंतर करने में सक्षम बनाता है।
प्रारूप काफी उदार है:
बस free atoms को श्रृंखलित करें, UniColl के साथ किसी एक की लंबाई का दुरुपयोग करें, फिर पहले पेलोड के ऊपर कूदें।
MP4 फ़ाइलों के लिए, केवल एक चीज़ जोड़नी है वह है stco (Sample Table - Chunk Offsets) या co64 (64-बिट समकक्ष) तालिकाओं को समायोजित करना, क्योंकि वे mdat मूवी डेटा की ओर इशारा करने वाले absolute(!) ऑफसेट हैं - और वे वास्तव में लागू होते हैं!
यह एक स्क्रिप्ट देता है जो किसी भी वीडियो को तुरंत टकराता है - और जैसा कि उल्लेख किया गया है, यह MP4 के अलावा अन्य प्रारूपों पर भी काम कर सकता है।
उदाहरण (KidMoGraph के वीडियो):
32b लंबाई (मानक) collision1.mp4 ⟷ collision2.mp4
⟷
64b लंबाई collisionl1.mp4 ⟷ collisionl2.mp4
⟷
ध्यान दें कि कुछ व्यूअर (OS X, Safari, FireFox) ऐसी फ़ाइल की अनुमति नहीं देते जो ftyp न होने वाले Atom से शुरू होती है।
ऐसे मामले में, प्रीफ़िक्स को इसे कवर करना होता है, और यह इतना सामान्य नहीं होता, लेकिन इसके अलावा यह वही रणनीति है - केवल एकल फ़ाइल प्रकार तक सीमित।
JPEG2000 फ़ाइलें आमतौर पर MP4 की तरह Atom/Box संरचना से शुरू होती हैं,
फिर अंतिम atom jp2c आमतौर पर फ़ाइल के अंत तक होता है (null लंबाई),
फिर इस बिंदु से यह JFIF संरचना का अनुसरण करता है, जैसे JPEG (एक सेगमेंट मार्कर के रूप में FF 4F से शुरू)।
शुद्ध-JFIF रूप भी सहन किया जाता है, ऐसी स्थिति में टकराव JPEG जैसा होता है: Shattered-संगत, लेकिन टिप्पणियाँ 64Kb तक सीमित होती हैं।
दूसरी ओर, यदि आप Atom/Box के साथ JPEG2000 फ़ाइलों में हेरफेर करते हैं, तो आपके पास यह सीमा नहीं होती।
जैसा कि पहले उल्लेख किया गया है, यदि आप इस संरचना को टकराने की कोशिश कर रहे हैं और
यदि अधिक प्रतिबंध हैं - उदाहरण के लिए free atom से शुरू करना कुछ प्रारूपों द्वारा सहन नहीं किया जाता -
तो आप इस प्रारूप के लिए विशिष्ट एक अन्य UniColl प्रीफ़िक्स जोड़ी की गणना कर सकते हैं:
JPEG2000 सामान्य ftyp से पहले एक 'jP ' atom को लागू करता प्रतीत होता है,
लेकिन इसके अलावा, यही एकमात्र प्रतिबंध है: कुछ भी स्थानांतरित करने की आवश्यकता नहीं है।
तो परिणामी स्क्रिप्ट और भी सरल है!
उदाहरण: collision1.jp2 ⟷ collision2.jp2
Shattered के बारे में
Shattered का दोहन कोई PDF तरकीब नहीं थी, बल्कि PDF में एक JPG तरकीब थी।
इसने केवल एक PDF को एक JPG-संपीड़ित वस्तु समाहित करने में सक्षम बनाया जिसमें दो अलग-अलग सामग्रियाँ हो सकती थीं। दोनों PDFs को अन्यथा पूरी तरह समान होना आवश्यक था।
ध्यान दें कि दस्तावेज़ पूरी तरह सामान्य हो सकते हैं, और बस टकराव वाली JPG को क्लिप करके इसे अलग-अलग स्थानों पर प्रदर्शित कर सकते हैं, जैसे बहु-पृष्ठ दस्तावेज़।
उदाहरण: Shattered पेपर, संशोधित ⟷ Shattered पेपर, मूल
दो स्थानों पर टकराव वाली JPG का उपयोग करता हुआ Shattered पेपर
MD5 के साथ PDF टकराव
MD5 (और अन्य टकराव पैटर्न) के साथ, हम दस्तावेज़ स्तर पर PDF टकराव कर सकते हैं, दोनों में से किसी भी फ़ाइल पर कोई प्रतिबंध नहीं!
PDF की संरचना अन्य फ़ाइल प्रारूपों से बहुत अलग होती है। यह एक ट्री परिभाषित करने के लिए ऑब्जेक्ट संख्याओं और संदर्भों का उपयोग करता है। पूरा दस्तावेज़ Root तत्व पर निर्भर करता है।
यह (वैध) PDF``` text %PDF-1. 1 0 obj<</Pages 2 0 R>>endobj 2 0 obj<</Kids[3 0 R]/Count 1>>endobj 3 0 obj<</Parent 2 0 R>>endobj trailer <</Root 1 0 R>>
के समतुल्य है:``` text
%PDF-1.
11 0 obj<</Pages 12 0 R>>endobj
12 0 obj<</Kids[13 0 R]/Count 1>>endobj
13 0 obj<</Parent 12 0 R>>endobj
trailer <</Root 11 0 R>>
ट्रिक्स:
XREF तालिका में संख्याओं को छोड़ने का एक आधिकारिक तरीका भी मौजूद है।तो एक ही फ़ाइल में दो दस्तावेज़ ट्री संग्रहीत करना ठीक है। हमें केवल यह सुनिश्चित करना होगा कि रूट ऑब्जेक्ट दोनों दस्तावेज़ों में से किसी एक रूट ऑब्जेक्ट को संदर्भित करे।
इसलिए हमें बस दो दस्तावेज़ लेने हैं,
ऑब्जेक्ट्स और संदर्भों को पुनः क्रमांकित (renumber) करना है ताकि कोई ओवरलैप न हो,
एक ऐसा टकराव (collision) तैयार करना है ताकि रूट ऑब्जेक्ट के रूप में संदर्भित तत्व संख्या को समान हैश मान बनाए रखते हुए बदला जा सके,
जो N=1 के साथ UniColl के लिए एकदम उपयुक्त है, और तदनुसार XREF तालिका को समायोजित करें।
इस तरह, हम किसी भी PDF जोड़ी को सुरक्षित रूप से टकरा सकते हैं, चाहे पृष्ठ संख्याएँ, आयाम, चित्र... कुछ भी हों।
टिप्पणियाँ
PDF विदेशी डेटा को दो तरीकों से संग्रहीत कर सकता है:
\r और \n) वर्ण निषिद्ध हैं।
इसका उपयोग किसी शब्दकोश ऑब्जेक्ट के अंदर किया जा सकता है, उदाहरण के लिए UniColl के माध्यम से किसी ऑब्जेक्ट संदर्भ को संशोधित करने के लिए।
इसलिए यह एक मान्य PDF ऑब्जेक्ट है, भले ही इसमें बाइनरी टकराव ब्लॉक हों - जब तक आपको कोई न्यूलाइन वर्ण न मिले, तब तक पुनः प्रयास करें: ```
1 0 obj
<< /Type /Catalog /MD5_is /REALLY_dead_now__ /Pages 2 0 R
%¥┬•σe╕█╙X₧_~π▌╒εX∟■φe♦%τ8╞■[...]p╛╬ûFZ»‼v◘Åp↑╝%▓% ▼σφj╔◄dZ▀c²aU≤╨╩[├└─yNΓ5╔+▀╪yδ☻ß⌐░¼à(☺z₧
endobj
टकराता पाठ
पहला मामला UniColl की सुंदरता को उजागर करना संभव बनाता है, एक ऐसा टकराव जहाँ अंतर अनुमानित होते हैं, ताकि आप टकराते डेटा पर कविता लिख सकें - धन्यवाद Jurph!
दस्तावेज़ की संरचना को संशोधित करने और पार्सर्स को धोखा देने के बजाय, हम सीधे collision blocks का उपयोग करके सीधे पाठ उत्पन्न करेंगे, वैकल्पिक पठन के साथ!``` V V Now he hash MD5, Now he hath MD5, No enemy cares! No enemy dares! Only he gave Only he have the shards. the shares. Can’t be owned & Can’t be pwned & his true gold, his true hold, like One Frail, like One Grail, sound as fold. sound as gold. ^ ^
उदाहरण: [poeMD5 A](https://github.com/decalage2/collisions/blob/HEAD/examples/poeMD5_A.pdf) ⟷ [poeMD5 B](https://github.com/decalage2/collisions/blob/HEAD/examples/poeMD5_B.pdf)
*एक सच्ची क्रिप्टोग्राफ़िक कलात्मक रचना :)*
(नोट: मैंने Adobe संगतता के साथ गड़बड़ कर दी, लेकिन यह मेरी गलती है, UniColl की नहीं)
**टकराने वाली दस्तावेज़ संरचना**
चाहे आप UniColl को इनलाइन कमेंट के रूप में उपयोग करें या डमी स्ट्रीम ऑब्जेक्ट में chosen-prefix के रूप में, रणनीति समान है:
ऑब्जेक्ट नंबरों को इधर-उधर फेरबदल करें, फिर Root ऑब्जेक्ट को अलग-अलग ऑब्जेक्ट्स की ओर इंगित करें, इसलिए Shattered के विपरीत, इसका अर्थ है दस्तावेज़ स्तर पर PDF के किसी भी मनमाने जोड़े का तात्क्षणिक टकराव।
एक उपयोगी ट्रिक यह है कि [`mutool clean`](https://mupdf.com/docs/manual-mutool-clean.html) का आउटपुट विश्वसनीय रूप से अनुमानित होता है,
इसलिए इसका उपयोग इनपुट के रूप में PDFs को सामान्य (normalize) करने और अपनी मर्ज की गई PDF को ठीक करने के लिए किया जा सकता है, जबकि फ़ाइल के महत्वपूर्ण हिस्से अपरिवर्तित रहते हैं।
MuTool नकली कुंजी/मानों को नहीं हटाता - जब तक कि कहा न जाए, और उन्हें उसी क्रम में रखता है,
इसलिए `/MD5_is /REALLY_dead_now__` जैसी नकली डिक्शनरी प्रविष्टियाँ किसी अन्य प्रकार की टिप्पणियों की आवश्यकता के बिना चीजों को अनुमानित रूप से संरेखित करने के लिए एकदम सही हैं।
हालाँकि यह डिक्शनरी में टिप्पणियाँ नहीं रखेगा (इसलिए इनलाइन-कमेंट ट्रिक नहीं)
बिना किसी परेशानी के ऑब्जेक्ट-फेरबदल ऑपरेशन करने का एक आसान तरीका दोनों PDF फ़ाइलों को मर्ज करना है
`mutool merge` के माध्यम से, फिर `/Pages` ऑब्जेक्ट को दो भागों में विभाजित करें।
इस ऑब्जेक्ट के लिए जगह बनाने हेतु, दोनों दस्तावेज़ों के सामने बस एक डमी PDF मर्ज करें।
वैकल्पिक रूप से, डैंगलिंग ऐरे का एक नकली संदर्भ बनाएँ
ताकि गार्बेज कलेक्शन पेजों के दूसरे सेट को हटा न सके।
**उदाहरण**:
इस [स्क्रिप्ट](https://github.com/decalage2/collisions/blob/HEAD/scripts/pdf.py) से,
Spectre और Meltdown जैसे दो सार्वजनिक PDF पेपरों को टकराने में [एक सेकंड से भी कम](https://github.com/decalage2/collisions/blob/HEAD/examples/pdf.log) समय लगता है:
उदाहरण: [spectre.pdf](https://github.com/decalage2/collisions/blob/HEAD/examples/collision1.pdf) ⟷ [meltdown.pdf](https://github.com/decalage2/collisions/blob/HEAD/examples/collision2.pdf)
संभावित विस्तार: UniColl ब्लॉकों को श्रृंखलाबद्ध करें ताकि मूल स्रोत फ़ाइलों में मौजूद विभिन्न [गैर-महत्वपूर्ण ऑब्जेक्ट](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdfs/PDF32000_2008.pdf#page=81) के जोड़े भी बने रहें,
जिन्हें Root ऑब्जेक्ट में संदर्भित किया जा सकता है - जैसे `Outlines`, `Names`, `AcroForm` और Additional Actions (`AA`)।
**PDFLaTeX में**
पिछली तकनीकें केवल एक जोड़ी PDF फ़ाइलों के साथ काम करती हैं,
लेकिन इसे सीधे TeX स्रोतों से करना भी संभव है
[विशिष्ट PDFTeX ऑपरेटरों](http://texdoc.net/texmf-dist/doc/pdftex/manual/pdftex-a.pdf) के माध्यम से।
आप सीधे ऑब्जेक्ट परिभाषित कर सकते हैं - संरेखण के लिए डमी कुंजी और मानों सहित - और अपने TeX स्रोतों की बिल्कुल शुरुआत में इसे शामिल करके कुछ ऑब्जेक्ट स्लॉट आरक्षित करने के लिए खाली ऑब्जेक्ट परिभाषित कर सकते हैं:``` latex
% set PDF version low to prevent stream XREF
\pdfminorversion=3
\begingroup
% disable compression to keep alignments
\pdfcompresslevel=0\relax
\immediate
\pdfobj{<<
/Type /Catalog
% cool alignment padding
/MD5_is /REALLY_dead_now__
% the first reference number should be on offset 0x49,
% so the '2' object number will be changed to '3' by UniColl
/Pages 2 0 R
% now padding so that the collision blocks (ends at 0xC0) are covered
/0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF
% with an extra character to be replaced by a return char
/0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0
>>}
% the original catalog of the shifted doc
\immediate\pdfobj{<</Type/Pages/Count 1/Kids[8 0 R]>>}
% the original catalog of the host doc
\immediate\pdfobj{<</Type/Pages/Count 1/Kids[33 0 R]>>}
% now we need to reserve PDF Objects so that there is no overlap
\newcount\objcount
% the host size (+3 for spare object slots) - 1
% putting a higher margin will just work, and XREF can have huge gaps
\objcount=25
\loop
\message{\the\objcount}
\advance \objcount -1
\immediate\pdfobj{<<>>} % just an empty object
\ifnum \objcount>0
\repeat
\endgroup
Don't forget to normalize PDFLaTeX output - with mutool for example - if needed:
PDFLaTeX is hard to get reproducible builds across distributions - you may even want to hook the time on execution to get the exact hash if required.
आप उम्मीद कर सकते हैं कि JPG केवल छवियाँ हों, लेकिन PDF में और कुछ PDF रीडरों (गैर-ब्राउज़र, जैसे Evince और Adobe Reader) में, इसे किसी भी अन्य एम्बेडेड ऑब्जेक्ट की तरह पेज सामग्री के रूप में उपयोग किया जा सकता है, जो एक JPEG छवि में एम्बेडेड होता है।
JPEG डेटा को बिना हानि के संग्रहीत करने के लिए, इसे 100% ग्रेस्केल के रूप में संग्रहीत करें, फिर या तो एकल पंक्ति/स्तंभ की तस्वीर का उपयोग करें, या डेटा लाइन को 8 बार दोहराएं (क्योंकि JPEG ब्लॉक 8x8 होते हैं), और आपका डेटा बिना हानि के संग्रहीत होता है और PDF पृष्ठों द्वारा संदर्भित किया जाता है।
JPEG पेज डेटा (रंग प्रस्तुत करने वाली ग्रेस्केल तस्वीर) के माध्यम से SHA-1 कोलिजन करने वाले दो PDFs के उदाहरण, वेक्टर पेज सामग्री के रूप में:
छवि डेटा के रूप में JPG में संग्रहीत 2 SHA-1 कोलिजन PDFs
टकराने वाले JPG को दो बार संदर्भित करना संभव है: पेज सामग्री के रूप में, बिना हानि के, जो स्वयं को प्रदर्शित किए जाने वाले हानिपूर्ण छवि के रूप में भी संदर्भित करता है। फिर से, प्रदर्शित की जाने वाली छवि ग्रेस्केल है, लेकिन पेज सामग्री PDF ऑपरेटरों के माध्यम से कुछ रंग प्रस्तुत कर सकती है।
छवि का शीर्ष भाग पेज सामग्री को 8 बार दोहराया हुआ दिखाता है।
पेज डेटा और प्रदर्शित की जाने वाली तस्वीर के रूप में उपयोग किए गए JPEG के माध्यम से SHA-1 कोलिजन करने वाले दो PDFs के उदाहरण:
Skulls & Crossbones ⟷ Golden Axe
JPG को छवि और पेज सामग्री के रूप में उपयोग करने वाले 2 SHA-1 कोलिजन PDFs
TL;DR ZIP के लिए कोई सामान्य पुन: उपयोग योग्य कोलिजन नहीं है, लेकिन ZIP-आधारित प्रारूप के लिए है। 2h.core में दो फाइलों को टकराना संभव होना चाहिए (chosen-prefix से 36 गुना तेज़)
ZIP संग्रह 3 परतों का सैंडविच हैं (कम से कम)।
पहले फाइलों की सामग्री आती है (Local File Header संरचनाओं का क्रम, प्रत्येक संग्रहीत फ़ाइल या निर्देशिका के लिए एक),
फिर कुछ इंडेक्स (फिर से, Central Directory का एक क्रम),
फिर एक एकल संरचना जो इस इंडेक्स की ओर इंगित करती है (End Of Central Directory)।
इन परतों के क्रम को इधर-उधर नहीं ले जाया जा सकता। कुछ पार्सर को केवल फ़ाइल सामग्री की संरचना की आवश्यकता होती है, लेकिन यह पार्स करने का सही तरीका नहीं है और इसका दुरुपयोग किया जा सकता है।
इस आवश्यक क्रम के कारण, कोई सामान्य उपसर्ग नहीं है जो किसी भी कोलिजन में मदद कर सके।
गैर-सामान्य दृष्टिकोण
एक अन्य दृष्टिकोण केवल दोनों संग्रहों को उनकी मर्ज की गई परतों के साथ मर्ज करना हो सकता है, और UniColl का उपयोग करना - लेकिन N=2 के साथ, जो चौथे बाइट में अंतर पेश करता है - End of Central Directory के मैजिक सिग्नेचर को खत्म करने के लिए।
इसका मतलब है कि कोई व्यक्ति एक ही UniColl और 24 बाइट्स के सेट उपसर्ग के साथ दो मनमाने ZIP को टकरा सकता है।
एक विशिष्ट End of Central Directory, जो टिप्पणी खाली होने पर 22 बाइट्स का होता है:``` 00: 504b 0506 0000 0000 0000 0000 0000 0000 PK.............. 10: 0000 0000 0000 ......
यदि हम इसे UniColl के लिए उपसर्ग के रूप में उपयोग करते हैं (उपसर्ग को 16 बिट्स में पैड करें) और `N=2`, अंतर चौथे बाइट पर है, जो मैजिक `.P .K 05 06` को बदलकर अनुमानित रूप से `.P .K 05 86` कर देता है।```
00: 504b 0506 0000 0000 0000 0000 0000 0000 PK..............
10: 0000 0000 0000 2121 eb66 cf9d db01 83bb ......!!.f......
20: 2888 4c41 e345 7d07 1634 5d4a 3b61 89a0 (.LA.E}..4]J;a..
30: 0029 94af 4168 2517 0bbc b841 cbf2 9587 .)..Ah%....A....
40: e438 0043 6390 279d 7c9e a01e e476 4c36 .8.Cc.'.|....vL6
50: 527f b1f4 653e d866 f98d 7278 5324 0bd5 R...e>.f..rxS$..
60: b31d ef6d d5d6 1163 5a2e a8a5 21bf eab4 ...m...cZ...!...
70: c59c 028e a913 f6b7 0036 c93f 5092 a628 .........6.?P..(
यह बिल्कुल सामान्य नहीं है, लेकिन chosen-prefix collision की तुलना में बहुत तेज़ है:```
real 12m23.993s
user 112m24.072s
sys 2m0.194s
एक समस्या यह है कि कुछ पार्सर ZIP फ़ाइलों को उल्टा पार्स करते हैं, भले ही उन्हें bottom-up पार्स किया जाना चाहिए:
दोनों फ़ाइलों के ठीक से पार्स होने का सुनिश्चित करने का एक तरीका है दो UniColl ब्लॉकों को श्रृंखलाबद्ध करना,
प्रत्येक End of Central Directory को सक्षम/अक्षम करने के लिए।
ZIP पार्सरों को अप्रयुक्त स्थान के बारे में शिकायत करने से रोकने के लिए,
कोई Extra Fields का दुरुपयोग कर सकता है,
Central Directory में फ़ाइल टिप्पणियाँ और End of Central Directory में आर्काइव टिप्पणियाँ।
उदाहरण: यहाँ एक असेंबली स्रोत है जो ड्यूल ZIP की संरचना का वर्णन करता है, जो दो अलग-अलग आर्काइव फ़ाइलों को होस्ट कर सकता है।
दो Unicoll गणनाओं के बाद, यह दो टकराने वाली फ़ाइलें देता है: collision1.zip ⟷ collision2.zip
भले ही Zip प्रारूप को स्वयं Gzip की तरह सामान्य रूप से शोषित नहीं किया जा सकता, फिर भी Zip पर निर्भर कुछ प्रारूप कर सकते हैं — उन्हें पूर्व-परिभाषित संरचना वाले Zip अभिलेखागार के अंदर सामान्य रूप से शोषित किया जा सकता है। Zip टक्कर को सामान्य बनाने के लिए कुछ सावधानियाँ बरतनी पड़ती हैं।
कुछ प्रारूप एक Zip संग्रह में संग्रहीत बहु-फ़ाइल होते हैं, और एक निश्चित फ़ाइलनाम वाली रूट फ़ाइल पर निर्भर होते हैं जो संग्रह में अन्य फ़ाइलों की ओर इंगित करती है। उनमें से कई रूट फ़ाइल के लिए XML या टेक्स्ट का उपयोग करते हैं, और अन्य फ़ाइलों को यथावत संग्रहीत करते हैं।
विचार : एक ही संग्रह में 2 फ़ाइल सेटों को सह-अस्तित्व में लाना, और फ़ाइलों के किसी भी सेट की ओर संकेत करना। एक सामान्य रूट को फ़ाइल की शुरुआत में पहले संग्रहीत किया जा सकता है, लेकिन टक्कर ब्लॉक फ़ाइल सामग्री के बाहर, संग्रह में संग्रहीत होते हैं (चूँकि टक्करों में बहुत उच्च एन्ट्रॉपी होती है, केवल XML या ASCII-युक्त फ़ाइलों के साथ टक्करों का शोषण करना असंभव है)।
चरण:
एक ही संग्रह में 2 अलग-अलग मूलों से फ़ाइलों के 2 सेट रखें - यानी अलग-अलग उपनिर्देशिकाओं में।
रूट फ़ाइल को संशोधित करें ताकि वह वैकल्पिक रूप से प्रत्येक सेट की ओर इंगित करे।
चूंकि रूट फ़ाइल का टाइमस्टैम्प, लंबाई और CRC दोनों में संग्रहीत होते हैं - फ़ाइल की सामग्री से पहले Local File Header में - और Central Directory में - सामग्री के बाद - इसलिए इन मानों को फ़ाइलों के दो संस्करणों के बीच नहीं बदलना चाहिए।
Central Directory में CRC32 गलत है, तो मान की यह प्रति पार्सर द्वारा अनदेखी की जा सकती है, लेकिन CRC32 को एक स्थिर मान पर जाली बनाना समस्या को पूरी तरह से टालने में सहायक है।
4 यादृच्छिक बाइट्स जोड़कर CRC को जाली बनाना संभवतः पर्याप्त नहीं होगा, क्योंकि ये रूट फ़ाइलें आमतौर पर कठोर सिंटैक्स वाले XML या टेक्स्ट में होती हैं, इसलिए वे अमान्य हो जाएँगी।
CrcHack मनमाने बिट्स के साथ और बिना ब्रूटफोर्सिंग के CRC बनाने में बहुत सहायता करता है, यह सुनिश्चित करता है कि आउटपुट फ़ाइल ASCII है, और संशोधित बिट्स अभी भी एक टिप्पणी में हैं।रूट फ़ाइल के बाद संग्रह में एक अतिरिक्त डमी फ़ाइल के extra field का उपयोग करना -- यहाँ तक कि खाली -- Hashclash टक्कर ब्लॉकों को संग्रहीत करने का एक सुरुचिपूर्ण तरीका है: इस तरह, Zip संग्रह एक मानक संरचना बनाए रखता है और बाद में मानक उपकरणों के साथ भी आसानी से हेरफेर किया जा सकता है।
Extra Fields में CRC32 नहीं होता है, और उनकी 16-बिट लंबाई पहले वाले हेडर में घोषित की जाती है। उनका अपना आंतरिक ID:2 Size:2 Data प्रारूप होता है लेकिन इसे आमतौर पर अनदेखा किया जाता है, और वे Local File Header और Central Directory दोनों में होते हैं, लेकिन टक्कर ब्लॉकों के बाद सफ़िक्स को समान रखने के लिए इसे Central Directory से अनुपस्थित किया जा सकता है।
अतिरिक्त फ़ाइल की उपस्थिति, जो अपने extra field में टक्कर ब्लॉकों को कवर करती है, को प्रारूप संरचना में घोषित करने की आवश्यकता हो सकती है, जैसे कि OOXML दस्तावेज़ में [Content_Types].xml फ़ाइल में। सफ़िक्स में अन्य XML फ़ाइलों को संशोधित करने की आवश्यकता हो सकती है, क्योंकि कुछ प्रारूपों में पूर्ण पथ (absolute paths) के उपयोग की आवश्यकता होती है।
यहाँ एक विशिष्ट zip-आधारित प्रारूप के लिए सामान्य शोषण की समग्र संरचना है:``` [Root file] (with constant CRC32)
[Dummy file] (with collision blocks in the extra field)
[...] <- rest of the archive, with 2 documents merged
So by predefining the root file contents and forging ASCII CRC32s, one can compute a generic re-usable Hashclash collision for a specific zip-based format.
इस प्रकार, रूट फ़ाइल की सामग्री को पूर्व-परिभाषित करके और ASCII CRC32 को जाली (forge) बनाकर, कोई भी व्यक्ति किसी विशिष्ट zip-आधारित प्रारूप के लिए एक सामान्य पुन: प्रयोज्य Hashclash collision की गणना कर सकता है।
### Requirements summary
### आवश्यकताओं का सारांश
- two or more prefixes
- दो या अधिक प्रीफ़िक्स
- one or more file types (polyglots work without problems)
- एक या अधिक फ़ाइल प्रकार (पॉलीग्लॉट बिना किसी समस्या के काम करते हैं)
- an XML root file with fixed filename, file length and CRC: this info is present twice, before and after the collision blocks
- contents are arbitrary XML
- padding is possible, even via XML comment, to reach the same length.
- CRC can be set (via CrcHack) on each content.
- निश्चित फ़ाइलनाम, फ़ाइल लंबाई और CRC वाली एक XML रूट फ़ाइल: यह जानकारी collision ब्लॉकों से पहले और बाद में दो बार मौजूद होती है
- सामग्री मनमाना XML होती है
- समान लंबाई तक पहुँचने के लिए, XML टिप्पणी के माध्यम से भी, पैडिंग संभव है।
- CRC को प्रत्येक सामग्री पर (CrcHack के माध्यम से) सेट किया जा सकता है।
- both set of files co-exist in the suffix, likely in different directories. Some tools hardcode the path, which may reduce compatibility.
- फ़ाइलों के दोनों सेट सफ़िक्स में सह-अस्तित्व में होते हैं, संभवतः अलग-अलग निर्देशिकाओं में। कुछ उपकरण पथ को हार्डकोड करते हैं, जो संगतता को कम कर सकता है।
- a *Content type* XML file may need to be merged to cover all files, supported and unsupported (collision blocks, and alternate document)
- एक *Content type* XML फ़ाइल को सभी फ़ाइलों को कवर करने के लिए मर्ज करने की आवश्यकता हो सकती है, समर्थित और असमर्थित (collision ब्लॉक, और वैकल्पिक दस्तावेज़)
### Examples
### उदाहरण
#### CRC32
#### CRC32
A minimal XML comment (ASCII-only) with a forged CRC32 (instant computation) with CrcHack.
एक न्यूनतम XML टिप्पणी (केवल ASCII) जिसमें CrcHack के साथ जाली CRC32 (तत्काल गणना) होती है।``` bash
echo "<!--ABCDEF-->" | crchack -b 4.0:+.8*6:1 -b 4.1:+.8*6:1 -b 4.2:+.8*6:1 -b 4.3:+.8*6:1 -b 4.4:+.8*6:1 -b 4.5:+.8*5:1 - 0xdeadf00d
<!--X{]EZF-->
एक और उदाहरण जहाँ आप किसी वर्णमाला संदेश के केस के अनुसार CRC समायोजित करते हैं।```bash echo "" | crchack.exe -b 4:+.8*32:.8 - 0xcafebabe
#### टकराव
[zInsider](https://github.com/decalage2/collisions/blob/HEAD/scripts/zinsider.py) एक स्क्रिप्ट है जो इन ZIP+XML प्रारूपों का उपयोग करके मनमाने दस्तावेज़ों के जोड़ों के MD5 टकराव तुरंत उत्पन्न करती है:
- Office Open XML: docx / pptx / xlsx
- Open Container Format: epub
- Open Packaging Conventions:
- 3D manufacturing format: 3mf
- XML Paper Specification: xps / oxps
अपने स्वयं के टकराव उपसर्ग उत्पन्न करने के लिए, [यह स्क्रिप्ट](https://github.com/decalage2/collisions/blob/HEAD/scripts/makezip.py) एक रूट zip जोड़ी उत्पन्न करती है।
टकरावों की गणना करने के बाद, [इस अन्य स्क्रिप्ट](https://github.com/decalage2/collisions/blob/HEAD/scripts/extendzip.py) का उपयोग करके इन रूट जोड़ियों को एक सामान्य प्रत्यय के साथ जोड़ें।
कुछ टकराव PoCs:
- Office Open XML: Excel ([1](https://github.com/decalage2/collisions/blob/HEAD/examples/free/md5-1.xls) - [2](https://github.com/decalage2/collisions/blob/HEAD/examples/free/md5-2.xls)), Powerpoint ([1](https://github.com/decalage2/collisions/blob/HEAD/examples/free/md5-1.pptx) - [2](https://github.com/decalage2/collisions/blob/HEAD/examples/free/md5-2.pptx)), Word ([1](https://github.com/decalage2/collisions/blob/HEAD/examples/free/md5-1.docx) - [2](https://github.com/decalage2/collisions/blob/HEAD/examples/free/md5-2.docx))।
- Open Container Format: Epub ([1](https://github.com/decalage2/collisions/blob/HEAD/examples/collision-1.epub) - [2](https://github.com/decalage2/collisions/blob/HEAD/examples/collision-2.epub))।
- Open Packaging Conventions: 3MF ([1](https://github.com/decalage2/collisions/blob/HEAD/examples/collision-1.3mf) - [2](https://github.com/decalage2/collisions/blob/HEAD/examples/collision-2.3mf)), XPS ([1](https://github.com/decalage2/collisions/blob/HEAD/examples/collision-1.xps) - [2](https://github.com/decalage2/collisions/blob/HEAD/examples/collision-2.xps))।
Zip पर आधारित कुछ बहु-फ़ाइल प्रारूपों का सामान्य रूप से शोषण नहीं किया जा सकता:
- Quake PK3: बिना किसी विशिष्ट रूट वाली फ़ाइलों का एक zip।
- Open Document Format: `META-INF/manifest.xml` फ़ाइल को हर दूसरी फ़ाइल का उल्लेख करना पड़ता है, इसलिए यह सामान्य नहीं हो सकता।
- APK, JAR, XPI: `META-INF/MANIFEST.mf` फ़ाइल को भी अपने हैशों के साथ हर दूसरी फ़ाइल का उल्लेख करना पड़ता है।
[Philippe Lagadec](https://twitter.com/decalage2) को Office फ़ाइल प्रारूपों पर उनकी मदद के लिए धन्यवाद!
## असामान्य रणनीतियाँ
टकराव आमतौर पर एक ही प्रकार की दो मान्य फ़ाइलों के बारे में होते हैं।
### MultiColls: एकाधिक टकराव श्रृंखला
कोई भी चीज़ कई टकराव ब्लॉकों को श्रृंखलाबद्ध करने और समान हैश मान वाली दो से अधिक सामग्री रखने से नहीं रोकती है।
इसका एक उदाहरण *hashquines* हैं - जो अपना स्वयं का MD5 मान दिखाते हैं।
[PoCGTFO 14](https://github.com/angea/pocorgtfo#0x14) फ़ाइल में 609 FastColl टकराव हैं,
जो एक ही फ़ाइल में दो फ़ाइल प्रकारों के माध्यम से ऐसा करते हैं।
### वैधता
एक अलग रणनीति फ़ाइल प्रकार को मारना होगा ताकि भ्रष्ट फ़ाइल के रूप में स्कैनिंग को बायपास किया जा सके।
केवल मैजिक सिग्नेचर को अधिलेखित करना पर्याप्त होगा।
दोनों फ़ाइलों को (मान्य या अमान्य) ऐसे प्रारूप के साथ जोड़ना
जिसे ऑफसेट 0 पर होने की आवश्यकता नहीं है (संग्रह, जैसे ZIP/RAR/...), दूसरे फ़ाइल प्रकार को प्रकट करेगा।
यह चुने हुए-उपसर्ग टकराव का उपयोग किए बिना पॉलीग्लॉट टकराव सक्षम बनाता है:
1. मैजिक सिग्नेचर को सक्षम या अक्षम करने के लिए UniColl का उपयोग करें, उदाहरण के लिए PNG:
2. एक ZIP संग्रह जोड़ें
हालांकि तकनीकी रूप से दोनों फ़ाइलें मान्य ZIP हैं, चूंकि अधिकांश पार्सर पाया गया पहला फ़ाइल प्रकार लौटाते हैं और वे ऑफसेट 0 पर स्कैन करना शुरू करते हैं, वे एक अलग फ़ाइल प्रकार देखेंगे।
उदाहरण:
⟷ [अमान्य](https://github.com/decalage2/collisions/blob/HEAD/examples/png-invalid.png)
### PolyColls: विभिन्न फ़ाइल प्रकारों के टकराव
संदेह कम करने के लिए टकराव के दोनों पक्षों का प्रकार अलग होना भी संभव है:
हमला परिदृश्य:
1. `holiday.jpg` भेजें
2. इसे व्हाइटलिस्ट करवाएँ
3. `evil.exe` भेजें, जिसका MD5 समान है।
इन मामलों में, चुने हुए-उपसर्ग टकराव आवश्यक है
यदि दोनों फ़ाइल प्रारूपों को ऑफसेट 0 पर शुरू होने की आवश्यकता हो।
पॉलीकोल लेआउट के कुछ उदाहरण:
*PDF/JPG पॉलीकोल*
*PE/PNG पॉलीकोल*
#### PE - JPG
चूंकि PE हेडर आमतौर पर 0x500 बाइट्स से छोटा होता है, यह JPG कमेंट के लिए एकदम उपयुक्त है:
1. DOS/JPG हेडर से शुरू करें
2. JPEG-कमेंट PE हेडर के ऊपर कूद जाता है
3. पूरी JPG छवि रखें
4. संपूर्ण PE विनिर्देश रखें
फिर से, टकराव [तुरंत](https://github.com/decalage2/collisions/blob/HEAD/scripts/jpgpe.py) है
उदाहरण: [fastcoll.exe](https://github.com/decalage2/collisions/blob/HEAD/examples/jpg-pe.exe) ⟷ [Marc.jpg](https://github.com/decalage2/collisions/blob/HEAD/examples/jpg-pe.jpg)
#### PDF - PE
`mutool` के साथ एक PDF को एक डमी फ़ाइल के साथ मर्ज करना वस्तुओं को पुनः क्रमबद्ध करने का एक अच्छा सामान्य तरीका है
और फिर पहली दो वस्तुओं को त्यागने योग्य (डमी पेज और सामग्री) बनाना है,
जो अज्ञात लंबाई के `stream` ऑब्जेक्ट को `1 0` के रूप में होस्ट करने के लिए एकदम उपयुक्त है,
और इसकी लंबाई दूसरे ऑब्जेक्ट में आगे (टकराव ब्लॉकों के बाद) संदर्भित होती है।
एकमात्र समस्या यह है कि `mutool` हमेशा लंबाई को इनलाइन करेगा - और लंबाई संदर्भ को हटा देगा,
इसलिए इसे मान के बजाय PDF में पुनः सम्मिलित करना होगा,
लेकिन अधिकांश संदर्भ `2 0 R` हार्डकोडेड लंबाई से छोटे होंगे।
सौभाग्य से इसे बिना किसी ऑब्जेक्ट ऑफसेट को बदले ठीक किया जा सकता है,
इसलिए XREF को पैच करने की आवश्यकता नहीं है।
उदाहरण के लिए, [यह स्क्रिप्ट](https://github.com/decalage2/collisions/blob/HEAD/scripts/pdfpe.py) एक PDF व्यूअर ([Sumatra](https://www.sumatrapdfreader.org/free-pdf-reader.html) हल्का और स्टैंडअलोन है) और एक PDF दस्तावेज़ को तुरंत टकराने के लिए है:
उदाहरण: [Poster.pdf](https://github.com/decalage2/collisions/blob/HEAD/examples/pepdf.pdf) ⟷ [Sumatra.exe](https://github.com/decalage2/collisions/blob/HEAD/examples/pepdf.exe)
*एक PDF व्यूअर जो समान MD5 वाला PDF (स्वयं एक PDF दिखाते हुए) दिखा रहा है*
#### PDF - PNG
इसी तरह, उदाहरण के लिए मनमाने PDF और PNG फ़ाइलों को किसी भी पक्ष पर बिना किसी प्रतिबंध के टकराना संभव है। यह तुरंत, पुनः प्रयोज्य और सामान्य है।
उदाहरण: [Hello.pdf](https://github.com/decalage2/collisions/blob/HEAD/examples/png-pdf.pdf) ⟷ [1x1.png](https://github.com/decalage2/collisions/blob/HEAD/examples/png-pdf.png)
### PileUps (मल्टी-कोलिज़न)
क्रिप्टोग्राफ़िक टकराव केवल दो फ़ाइलों तक सीमित नहीं हैं!
2008 में [Nostradamus](https://www.win.tue.nl/hashclash/Nostradamus/) प्रयोग में प्रदर्शित किया गया था,
टकरावों को श्रृंखलाबद्ध करने से दो से अधिक फ़ाइलों को टकराना संभव हो जाता है।
पहले टकराव समान या चुने हुए-उपसर्ग वाले हो सकते हैं, अगले चुने हुए-उपसर्ग वाले होने चाहिए।
आप उन्हें मल्टी-कोलिज़न कह सकते हैं, मैं *पाइलअप्स* पसंद करता हूँ - यह छोटा है :)
#### PE - PNG - MP4 - PDF
पहले अर्जित सभी ज्ञान को मिलाकर,
मैंने विभिन्न फ़ाइल प्रकारों के लिए 4 अलग-अलग उपसर्ग बनाने हेतु 3 चुने हुए-उपसर्ग टकरावों का उपयोग किया:
दस्तावेज़ (PDF), वीडियो (MP4), निष्पादन योग्य (PE) और छवि (PNG)।
*PE/PNG/MP4/PDF पाइलअप का आरेख*
यह स्क्रिप्ट सामान्य और तुरंत है:
उदाहरण: [commodore.pdf](https://github.com/decalage2/collisions/blob/HEAD/examples/pileup.pdf) ⟷ [diagram.png](https://github.com/decalage2/collisions/blob/HEAD/examples/pileup.png) ⟷ [kidmo.mp4](https://github.com/decalage2/collisions/blob/HEAD/examples/pileup.mp4) ⟷ [sumatra18.exe](https://github.com/decalage2/collisions/blob/HEAD/examples/pileup.exe)
चूंकि आप केवल एक ही फ़ाइल वितरित कर सकते हैं
और उससे अन्य उपसर्ग मानों का अनुमान लगाना असंभव है,
एक समाधान यह है कि टकराव के सभी उपसर्गों को JavaScript कोड में एम्बेड करें
और उन्हें अपने PoCs में डालें,
जिससे आपकी फ़ाइलें [HTML पॉलीग्लॉट्स](https://github.com/decalage2/collisions/blob/HEAD/examples/polyglot.html) बन जाएँ
और संबंधित टकराने वाली फ़ाइलों को आसानी से साझा किया जा सके।
'PoC or GTFO' का [अंक 19](https://github.com/angea/pocorgtfo#0x19) ऐसा ही पाइलअप **और** पॉलीग्लॉट है,
जिसमें PDFLaTeX के साथ उत्पन्न 80-पृष्ठ का दस्तावेज़, Windows के लिए एक PDF व्यूअर,
एक PNG आरेख और [KidMoGraph](https://www.kidmograph.com/) का एक छोटा 'कोलिज़न' MP4 वीडियो,
साथ ही PDF रिलीज़ से अन्य फ़ाइलें उत्पन्न करने के लिए HTML पेलोड (और एक ZIP संग्रह भी) शामिल है:
JavaScript पर उनकी स्थायी मदद के लिए Rafał Hirsz को धन्यवाद।
## उपयोग के मामले
MD5 को पूरी तरह से त्याग देना बेहतर है, क्योंकि फ़ाइल निरीक्षण बहुत समय लेने वाला और बहुत जोखिम भरा है!
### सभी को टकराना होगा!
तुरंत, पुनः प्रयोज्य और सामान्य टकरावों का एक और उपयोग किसी दिए गए प्रकार की किसी भी फ़ाइल को - मान लीजिए PNG - डमी फ़ाइलों (या हर बार समान फ़ाइल) के पीछे छिपाना होगा - जो वास्तव में सिग्नेचर हटाने के बाद इसे समान उपसर्ग के साथ जोड़कर किया जाता है - आप इसे लाइब्रेरी स्तर पर भी कर सकते हैं!
सख्त पार्सिंग दृष्टिकोण से,
आपकी सभी फ़ाइलें समान सामग्री दिखाएँगी,
और दुष्ट छवियाँ पहले एकत्रित समान MD5 वाली फ़ाइल के रूप में प्रकट होंगी।
आइए दो फ़ाइलें लें:
⟷
और उन्हें समान PNG के साथ टकराएँ।
अब वे समान डमी छवि दिखाती हैं, और फ़ाइल स्तर पर दूसरी छवि तक बिल्कुल समान हैं!
⟷
उनका दुष्ट पेलोड क्रमशः समान MD5 वाली फ़ाइल के पीछे छिपा है।
### आपत्तिजनक फ़ाइलें
---
[Read more](https://github.com/decalage2/collisions)
| उपसर्ग | = | उपसर्ग |
|---|
| कोलिज़न A | ≠ | कोलिज़न B |
| A | = | |
| = | B |