سنگین سیکیورٹی: مائیکروسافٹ آفس 365 نے کمزور خفیہ کاری پر حملہ کیا۔

ہمیں اس بات کا یقین نہیں ہے کہ اسے ابھی کیا کہا جائے، اس لیے ہم نے اسے ہائبرڈ نام سے سرخی میں حوالہ دیا مائیکروسافٹ آفس 365.

(مائیکروسافٹ کے ورڈ پروسیسنگ، اسپریڈشیٹ، پریزنٹیشن اور تعاون ایپس کے لیے بطور اجتماعی اسم "آفس" کا نام دیا جا رہا ہے مار ڈالا اگلے یا دو مہینوں میں، صرف "مائیکروسافٹ 365" بننے کے لیے۔)

ہمیں یقین ہے کہ لوگ ایپ کے انفرادی ناموں کا استعمال کرتے رہیں گے (لفظ, ایکسل, پاورپوائنٹ اور دوست) اور سویٹ کا مانیکر دفتر کئی سالوں سے، اگرچہ سافٹ ویئر میں نئے آنے والے شاید اسے جانتے ہوں گے۔ 365، ہر جگہ مائیکروسافٹ کا سابقہ ​​چھوڑنے کے بعد۔

جیسا کہ آپ جانتے ہوں گے، آفس اسٹینڈ ایلون ایپس (جن کو آپ مقامی طور پر انسٹال کرتے ہیں تاکہ آپ کو اپنی چیزوں پر کام کرنے کے لیے آن لائن نہ جانا پڑے) میں محفوظ شدہ دستاویزات کو خفیہ کرنے کا اپنا اختیار شامل ہوتا ہے۔

ایسا سمجھا جاتا ہے کہ اگر آپ بعد میں ان فائلوں میں سے کسی کو، حادثاتی طور پر یا ڈیزائن کے ذریعے، کسی ایسے شخص کے ساتھ شیئر کرتے ہیں جس کو انہیں موصول نہیں ہونا چاہیے تھا، تو یہ سیکیورٹی کی ایک اضافی پرت کو شامل کرے گا - ایسا کام جو ای میل کے ذریعے منسلکات کا اشتراک کرتے وقت غلطی سے کرنا حیرت انگیز طور پر آسان ہے۔

جب تک اور جب تک کہ آپ وصول کنندہ کو وہ پاس ورڈ بھی نہیں دیتے ہیں جس کی انہیں فائل کو غیر مقفل کرنے کی ضرورت ہوتی ہے، یہ ان کے لیے اتنی کٹی ہوئی گوبھی ہے۔

بلاشبہ، اگر آپ ای میل کے باڈی میں پاس ورڈ شامل کرتے ہیں، تو آپ کو کچھ حاصل نہیں ہوا، لیکن اگر آپ کسی دوسرے چینل کے ذریعے پاس ورڈ شیئر کرنے کے بارے میں قدرے محتاط بھی ہیں، تو آپ نے بدمعاشوں کے خلاف اپنے آپ کو کچھ اضافی حفاظت اور تحفظ حاصل کر لیا ہے۔ snoops اور ne'er-do-wells کو خفیہ مواد تک آسانی سے رسائی حاصل ہو رہی ہے۔

OME اسپاٹ لائٹ کے نیچے

یا آپ کے پاس ہے؟

کے مطابق محققین Finnish cybersecurity company WithSecure میں، آپ کا ڈیٹا بہت کم تحفظ سے لطف اندوز ہو سکتا ہے جس کی آپ معقول طور پر توقع کر سکتے ہیں۔

ٹیسٹرز نے جو خصوصیت استعمال کی ہے وہ وہی ہے جسے وہ کہتے ہیں۔ آفس 365 میسج انکرپشن، یا او ایم ای مختصر کے لئے.

ہم نے یہاں ان کے تجربات کو دوبارہ پیش نہیں کیا ہے، اس سادہ وجہ سے کہ کور آفس، معذرت، 365 مصنوعات مقامی طور پر لینکس پر نہیں چلتی ہیں، جسے ہم کام کے لیے استعمال کرتے ہیں۔ آفس ٹولز کے ویب پر مبنی ورژن میں مکمل ایپس کی طرح کی خصوصیت سیٹ نہیں ہوتی ہے، اس لیے جو بھی نتائج ہم حاصل کر سکتے ہیں اس کے مطابق آفس، ah, 365 کے زیادہ تر کاروباری صارفین نے Word, Excel, Outlook کو کنفیگر کیا ہے۔ اور دوست اپنے ونڈوز لیپ ٹاپ پر۔

جیسا کہ محققین اس کی وضاحت کرتے ہیں:

اس خصوصیت کی تشہیر تنظیموں کو آپ کی تنظیم کے اندر اور باہر لوگوں کے درمیان ایک محفوظ طریقے سے خفیہ کردہ ای میل پیغامات بھیجنے اور وصول کرنے کی اجازت دینے کے لیے کی جاتی ہے۔

لیکن وہ یہ بھی بتاتے ہیں کہ:

بدقسمتی سے OME پیغامات کو غیر محفوظ الیکٹرانک کوڈ بک (ECB) موڈ آف آپریشن میں انکرپٹ کیا جاتا ہے۔

ای سی بی نے وضاحت کی۔

کی وضاحت کے لئے.

بہت سے خفیہ کاری الگورتھم، خاص طور پر اعلی درجے کی خفیہ کاری کا معیار یا AES، جسے OME استعمال کرتا ہے، کے نام سے جانا جاتا ہے۔ سائفرز کو بلاک کریں، جو ترتیب میں انفرادی بٹس یا بائٹس پر کارروائی کرنے کے بجائے ایک وقت میں ڈیٹا کے بڑے ٹکڑوں کو گھماتا ہے۔

عام طور پر یہ سمجھا جاتا ہے کہ اس سے کارکردگی اور سیکیورٹی دونوں میں مدد ملے گی، کیونکہ سائفر کے پاس کریپٹوگرافک کرینک ہینڈل کے ہر موڑ پر مکس کرنے کے لیے زیادہ ان پٹ ڈیٹا ہوتا ہے جو الگورتھم کو چلاتا ہے، اور ہر موڑ آپ کو مزید آگے لے جاتا ہے۔ اس ڈیٹا کے ذریعے جسے آپ خفیہ کرنا چاہتے ہیں۔

بنیادی AES الگورتھم، مثال کے طور پر، ایک وقت میں 16 ان پٹ پلین ٹیکسٹ بائٹس (128 بٹس) استعمال کرتا ہے، اور 16 انکرپٹڈ سائفر ٹیکسٹ آؤٹ پٹ بائٹس تیار کرنے کے لیے اس ڈیٹا کو ایک خفیہ کاری کلید کے تحت کھینچتا ہے۔

(الجھنا مت بلاک سائز ساتھ کلیدی سائز - AES انکرپشن کیز 128 بٹس، 192 بٹس یا 256 بٹس لمبی ہو سکتی ہیں، اس بات پر منحصر ہے کہ آپ ان کا اندازہ لگانا کتنا کم نہیں چاہتے ہیں، لیکن جب بھی الگورتھم کو "کرینک" کیا جاتا ہے تو تینوں کلیدی سائز 128 بٹ بلاکس پر کام کرتے ہیں۔)

اس کا مطلب یہ ہے کہ اگر آپ AES کلید (لمبائی سے قطع نظر) چنتے ہیں اور پھر AES سائفر کو براہ راست ڈیٹا کے ایک حصے پر استعمال کرتے ہیں…

…پھر جب بھی آپ کو ایک ہی ان پٹ کا حصہ ملے گا، آپ کو وہی آؤٹ پٹ حصہ ملے گا۔.

واقعی ایک بڑے کوڈ بک کی طرح

اسی لیے اس ڈائریکٹ موڈ کو آپریشن کہا جاتا ہے۔ ای سی بی، مختصرا الیکٹرانک کوڈ بککیونکہ یہ ایک بہت بڑی کوڈ بک رکھنے کی طرح ہے جسے خفیہ کاری اور خفیہ کاری کے لیے تلاش کے ٹیبل کے طور پر استعمال کیا جا سکتا ہے۔

(ایک مکمل "کوڈ بک" کو حقیقی زندگی میں کبھی بھی تعمیر نہیں کیا جا سکتا، کیونکہ آپ کو 2 پر مشتمل ڈیٹا بیس کو ذخیرہ کرنے کی ضرورت ہوگی¹²⁸ 16 بائٹ اندراجات ہر ممکنہ کلید کے لیے.)

بدقسمتی سے، خاص طور پر کمپیوٹر کے فارمیٹ شدہ ڈیٹا میں، استعمال شدہ فائل فارمیٹ کی بدولت ڈیٹا کے بعض حصوں کی تکرار اکثر ناگزیر ہوتی ہے۔

مثال کے طور پر، وہ فائلیں جو ڈیٹا سیکشنز کو معمول کے مطابق پیڈ آؤٹ کرتی ہیں تاکہ وہ 512 بائٹ باؤنڈریز (ڈسک پر لکھتے وقت ایک عام سیکٹر کا سائز) یا 4096 بائٹ باؤنڈریز (میموری کو محفوظ کرتے وقت ایک عام مختص یونٹ سائز) پر لائن لگائیں اکثر فائلیں اس کے ساتھ تیار کریں گی۔ صفر بائٹس کی لمبی رنز۔

اسی طرح، متنی دستاویزات جن میں بہت سارے بوائلر پلیٹ ہوتے ہیں، جیسے کہ ہر صفحے پر ہیڈر اور فوٹر، یا کمپنی کے مکمل نام کا بار بار ذکر کیا جاتا ہے، ان میں بہت زیادہ تکرار ہوتی ہے۔

AES-ECB انکرپشن کے عمل میں جب بھی بار بار سادہ متن کا حصہ 16 بائٹ باؤنڈری پر لائن اپ ہوتا ہے، تو یہ انکرپٹڈ آؤٹ پٹ میں ابھرے گا۔ بالکل ایک ہی سائفر ٹیکسٹ کے طور پر.

لہذا، یہاں تک کہ اگر آپ باضابطہ طور پر سائفر ٹیکسٹ فائل کو ڈکرپٹ نہیں کر سکتے ہیں، تو آپ اس سے فوری طور پر، سیکورٹی کو کچلنے والے قیاس آرائیاں کرنے کے قابل ہو سکتے ہیں، اس حقیقت کی بدولت کہ ان پٹ میں پیٹرن (جس سے آپ جان سکتے ہیں، یا اندازہ لگا سکتے ہیں، یا اندازہ لگانا) آؤٹ پٹ میں محفوظ ہیں۔

یہاں ایک مضمون کی بنیاد پر ایک مثال ہے جسے ہم نے تقریباً نو سال پہلے شائع کیا تھا جب ہم نے وضاحت کی تھی کہ ایڈوب کی جانب سے اپنے صارفین کے پاس ورڈز کو "ہیش" کرنے کے لیے ECB موڈ انکرپشن کا اب بدنام زمانہ استعمال کیوں کیا گیا تھا۔ ایک اچھا خیال نہیں ہے۔:

نوٹ کریں کہ کس طرح ان پٹ میں ٹھوس سفید رنگ کے پکسلز قابل اعتماد طریقے سے آؤٹ پٹ میں بار بار ہونے والا پیٹرن بناتے ہیں، اور نیلے حصے کچھ حد تک باقاعدہ رہتے ہیں، تاکہ اصل ڈیٹا کی ساخت واضح ہو۔

اس مثال میں، اصل فائل میں ہر پکسل بالکل 4 بائٹس لیتا ہے، لہذا ان پٹ ڈیٹا میں ہر بائیں سے دائیں 4-پکسل رن 16 بائٹس لمبا ہے، جو ہر 16-بائٹ AES انکرپشن بلاک کے ساتھ بالکل سیدھ میں ہوتا ہے، اس طرح زور دیتا ہے۔ "ای سی بی اثر"۔

---

مماثل سائفر ٹیکسٹ پیٹرن

اس سے بھی بدتر، اگر آپ کے پاس دو دستاویزات ہیں جن کے بارے میں آپ جانتے ہیں کہ ایک ہی کلید کے ساتھ خفیہ کردہ ہیں، اور آپ کے پاس صرف ان میں سے ایک کا سادہ متن ہے، تو آپ سائفر ٹیکسٹ کے ذریعے دیکھ سکتے ہیں کہ آپ نہیں کر سکتا ڈکرپٹ کریں، اور اس کے حصوں کو سائفر ٹیکسٹ کے پیٹرن کے ساتھ ملانے کی کوشش کریں جو آپ کرتے ہیں۔ کر سکتے ہیں ڈکرپٹ

یاد رکھیں کہ آپ کو پہلی دستاویز کو "ڈیکرپٹ" کرنے کے لیے کلید کی ضرورت نہیں ہے اگر آپ کے پاس پہلے سے ہی یہ ڈکرپٹ شدہ شکل میں موجود ہے - یہ حیرت انگیز طور پر، ایک کے طور پر جانا جاتا ہے۔ معلوم سادہ ٹیکسٹ حملہ.

یہاں تک کہ اگر بظاہر معصوم متن کے صرف چند مماثلتیں ہیں جو بذات خود خفیہ ڈیٹا نہیں ہے، اس طرح سے جو علم ایک مخالف نکال سکتا ہے وہ دانشورانہ املاک کے جاسوسوں، سماجی انجینئروں، فرانزک تفتیش کاروں اور مزید کے لیے سونے کی کان ثابت ہوسکتا ہے۔

مثال کے طور پر، یہاں تک کہ اگر آپ کو معلوم نہیں ہے کہ کسی دستاویز کی تفصیلات سے کیا مراد ہے، متعدد فائلوں میں معلوم سادہ متن کے ٹکڑوں کو ملا کر، آپ اس بات کا تعین کرنے کے قابل ہو سکتے ہیں کہ دستاویزات کا بظاہر بے ترتیب مجموعہ:

• سب ایک ہی وصول کنندہ کو بھیجے گئے تھے، اگر ہر ایک کے اوپر ایک مشترکہ سلام ہو۔
• اسی منصوبے کا حوالہ دیتے ہیں، اگر کوئی منفرد شناخت کرنے والا ٹیکسٹ سٹرنگ ہے جو پاپ اپ ہوتا رہتا ہے۔
• ایک جیسی حفاظتی درجہ بندی ہے، اگر آپ ان چیزوں پر توجہ مرکوز کرنے کے خواہشمند ہیں جس کا واضح مطلب باقی چیزوں کے مقابلے میں "زیادہ خفیہ" ہونا ہے۔

کیا کیا جائے؟

ECB موڈ استعمال نہ کریں!

اگر آپ بلاک سائفر استعمال کر رہے ہیں، تو ایک کو منتخب کریں۔ بلاک سائفر آپریٹنگ موڈ کہ:

• اس میں شامل ہے جسے IV، یا ابتداء ویکٹر کہا جاتا ہے، ہر پیغام کے لیے بے ترتیب اور منفرد طور پر منتخب کیا گیا ہے۔
• جان بوجھ کر خفیہ کاری کے عمل کو ترتیب دیتا ہے۔ تاکہ بار بار آنے والے ان پٹ ہر بار مختلف طریقے سے سامنے آئیں۔

اگر آپ AES استعمال کر رہے ہیں، تو شاید آپ ان دنوں جس موڈ کا انتخاب کرنا چاہتے ہیں۔ AES-GCM (گیلوئس کاؤنٹر موڈ)، جو ہر بار ایک مختلف انکرپشن ڈیٹا سٹریم بنانے کے لیے نہ صرف ایک IV کا استعمال کرتا ہے، چاہے کلید وہی رہے، بلکہ اس کا حساب بھی لگاتا ہے جسے پیغام کا تصدیقی کوڈ (MAC)، یا کرپٹوگرافک چیکسم، ایک ہی وقت میں ڈیٹا کو سکیمبلنگ یا unscrambling کے طور پر۔

AES-GCM کا مطلب نہ صرف یہ ہے کہ آپ بار بار سائفر ٹیکسٹ پیٹرن سے گریز کرتے ہیں، بلکہ یہ بھی کہ آپ ہمیشہ ایک "چیکسم" کے ساتھ ختم ہوتے ہیں جو آپ کو بتائے گا کہ کیا آپ نے ابھی جو ڈیٹا ڈکرپٹ کیا ہے اس کے ساتھ راستے میں چھیڑ چھاڑ کی گئی ہے۔

یاد رکھیں کہ ایک بدمعاش جو یہ نہیں جانتا ہے کہ سائفر ٹیکسٹ کا اصل مطلب کیا ہے اس کے باوجود آپ کو یہ جانے (یا خیال رکھنے) بغیر کہ آپ کو کس قسم کی غلط آؤٹ پٹ کا سامنا کرنا پڑتا ہے ایک غیر درست ڈکرپشن پر بھروسہ کرنے میں آپ کو دھوکہ دے سکتا ہے۔

ایک MAC جس کا حساب ڈکرپشن کے عمل کے دوران کیا جاتا ہے، اسی کلید اور IV کی بنیاد پر، اس بات کو یقینی بنانے میں مدد کرے گا کہ آپ کو معلوم ہے کہ آپ کو موصول کردہ سائفر ٹیکسٹ درست ہے، اور اس وجہ سے آپ نے تقریباً یقینی طور پر ڈیکرپٹ کر لیا ہے جو اصل میں دوسرے سرے پر رکھا گیا تھا۔

متبادل طور پر، ایک وقف کا استعمال کریں سٹریم سائفر جو ایک چھدم بے ترتیب بائٹ بائی بائٹ کی اسٹریم تیار کرتا ہے جو آپ کو ایک وقت میں 16 بائٹس (یا جو بھی بلاک سائز ہو) پر کارروائی کیے بغیر ڈیٹا کو خفیہ کرنے کی اجازت دیتا ہے۔

AES-GCM بنیادی طور پر AES کو ایک سٹریم سائفر میں تبدیل کرتا ہے اور ایک MAC کی شکل میں توثیق کا اضافہ کرتا ہے، لیکن اگر آپ اس طرح کام کرنے کے لیے خاص طور پر ڈیزائن کیا گیا ایک وقف شدہ سٹریم سائفر تلاش کر رہے ہیں، تو ہم ڈینیل برنسٹین کی تجویز کرتے ہیں۔ ChaCha20-Poly1305۔ (Poly1305 حصہ MAC ہے)، جیسا کہ تفصیل میں ہے۔ آر ایف سی 8439.

ذیل میں، ہم نے دکھایا ہے کہ ہمیں AES-128-GCM اور ChaCha20-Poly1305 کا استعمال کرتے ہوئے کیا ملا ہے (ہم نے یہاں MAC کوڈز کو مسترد کر دیا ہے)، اس کے ساتھ ایک "تصویر" کے ساتھ 95,040 RGBA بائٹس (330×72 فی پکسل 4 بائٹس) پر مشتمل ہے۔ لینکس کرنل سیوڈو رینڈم جنریٹر۔

یاد رکھیں کہ صرف اس لیے کہ ڈیٹا غیر ساختہ نظر آتا ہے اس کا مطلب یہ نہیں ہے کہ یہ واقعی بے ترتیب ہے، لیکن اگر یہ بے ترتیب نظر نہیں آتا، پھر بھی یہ انکرپٹڈ ہونے کا دعویٰ کرتا ہے، تو آپ یہ بھی سمجھ سکتے ہیں کہ پیچھے کچھ ڈھانچہ رہ گیا ہے، اور یہ کہ خفیہ کاری مشتبہ:

آگے کیا ہوگا؟

WithSecure کے مطابق، مائیکروسافٹ آفس 2010 کے ساتھ پسماندہ مطابقت کی وجہ سے ظاہری طور پر اس "خطرے" کو ٹھیک کرنے کا ارادہ نہیں رکھتا ہے…

Office (2010) کے لیگیسی ورژنز کے لیے AES 128 ECB کی ضرورت ہوتی ہے، اور آفس کے دستاویزات ابھی بھی آفس ایپس کے ذریعے اس طریقے سے محفوظ ہیں۔

… اور…

[WithSecure Researchers'] کی رپورٹ کو سیکیورٹی سروسنگ کے لیے بار سے ملنے پر غور نہیں کیا گیا، اور نہ ہی اسے خلاف ورزی سمجھا جاتا ہے۔ کوڈ میں کوئی تبدیلی نہیں کی گئی اور اس لیے اس رپورٹ کے لیے کوئی CVE جاری نہیں کیا گیا۔

مختصراً، اگر آپ فی الحال OME پر انحصار کر رہے ہیں، تو ہو سکتا ہے کہ آپ اسے حساس پیغامات کے لیے فریق ثالث کے خفیہ کاری کے ٹول سے تبدیل کرنے پر غور کرنا چاہیں جو آپ کے ڈیٹا کو ان ایپس سے آزادانہ طور پر انکرپٹ کرتا ہے جنہوں نے ان پیغامات کو تخلیق کیا، اور اس طرح اندرونی خفیہ کاری سے آزادانہ طور پر کام کرتا ہے۔ آفس رینج میں کوڈ۔

اس طرح، آپ آفس 2010 میں بنائے گئے پرانے اسکول کے ڈکرپشن کوڈ پر واپس جانے کے بغیر، ایک جدید سائفر اور سائفر آپریشن کے جدید موڈ کا انتخاب کر سکتے ہیں۔

---

ہم نے آرٹیکل میں امیجز کو کیسے بنایا sop330.png سے شروع کریں، جسے آپ سب سے اوپر والی تصویر سے کلین اپ SOPHOS لوگو کو تراش کر، 2-پکسل بلیو باؤنڈری کو ہٹا کر، اور PNG فارمیٹ میں محفوظ کر کے اپنے لیے بنا سکتے ہیں۔  تصویر کا سائز 330x72 پکسلز ہونا چاہیے۔
 ImageMagick کا استعمال کرتے ہوئے RGBA میں تبدیل کریں: $convert sop330.png sop.rgba آؤٹ پٹ 330x72 پکسلز x 4 بائٹس/پکسل = 95,040 بائٹس ہے۔
 === Lua اور LuaOSSL لائبریری کا استعمال کرتے ہوئے انکرپٹ کریں (Python کی OpenSSL بائنڈنگ بہت ملتی جلتی ہے): -- load data > fdat = misc.filetostr('sop.rgba') > fdat:len() 95040 -- تخلیق سائفر آبجیکٹ > aes = openssl.cipher.new('AES-128-ECB') > gcm = openssl.cipher.new('AES-128-GCM') > cha = openssl.cipher.new('ChaCha20-Poly1305') -- پاس ورڈ اور IV شروع کریں -- AES-128-ECB کو 128 بٹ پاس ورڈ کی ضرورت ہے، لیکن IV نہیں -- AES-128-GCM کو 128 بٹ پاس ورڈ اور 12 بائٹ IV کی ضرورت ہے -- ChaCha20 کو 256 بٹ پاس ورڈ کی ضرورت ہے اور ایک 12-بائٹ IV > aes:encrypt('THEPASSWORDIS123') > gcm:encrypt('THEPASSWORDIS123','andkrokeutiv') > cha:encrypt('THEPASSWORDIS123THEPASSWORDIS123THEPASSWORDIS476' - تین فائل کے ساتھ فائل > aesout = aes:final(fdat) > gcmout = gcm:final(fdat) > chaout = cha:final(fdat) -- ایک سٹریم سائفر آؤٹ پٹ بائٹ بائی بائٹ پیدا کرتا ہے، -- اس لیے سائفر ٹیکسٹ کی لمبائی سادہ متن کے برابر ہونی چاہیے۔ > gcmout:len() 95040 > chaout:len() 95040 -- ہم یہاں GCM اور Poly1305 کے MAC کوڈز استعمال نہیں کریں گے، -- لیکن ہر سائفر ایک 128 بٹ (16 بائٹ) "چیکسم" تیار کرتا ہے -- جسے ختم ہونے کے بعد ڈکرپشن کی توثیق کرنے کے لئے استعمال کیا جاتا ہے، -- یہ معلوم کرنے کے لئے کہ آیا ان پٹ سائفر ٹیکسٹ خراب یا ہیک ہو گیا ہے -- (MAC کلید پر منحصر ہے، لہذا ایک حملہ آور اسے جعل سازی نہیں کر سکتا) > base.hex(gcm:getTag(16)) a70f204605cd5bd18c9e4da36cbc9e74 > base.hex(cha:getTag(16)) a55b97d5e9f3cb9a3be2fage/deb4 /dev040im/56/dev/95040/dev/1/8/////////// misc.filetostr('/dev/random',#fdat) -- ان سب کو محفوظ کریں - نوٹ کریں کہ ہم واضح طور پر AES-ECB کو تراشتے ہیں -- صحیح تصویر کی لمبائی تک سائفر آؤٹ پٹ کو بلاک کرتے ہیں، کیونکہ -- ECB کو میچ کرنے کے لیے پیڈنگ کی ضرورت ہوتی ہے۔ بلاک سائز کے ساتھ ان پٹ سائز rgba') > misc.strtofile(rndout,'rnd.rgba') === فائلوں کو ریگولر امیج ویور میں لوڈ کرنے کے لیے، آپ کو انہیں بغیر کسی نقصان کے واپس PNG فارمیٹ میں تبدیل کرنے کی ضرورت ہوگی: $convert -depth 330 -size 72x8 aes .rgba aes.png $ کنورٹ -گہرائی 330 -سائز 72x8 gcm.rgba gcm.png $ convert -depth 330 -size 72x8 cha.rgba cha.png $ convert -depth 330 -size 72xXNUMX rnd.rgba rnd.png === یہ دیکھتے ہوئے کہ انکرپشن کا عمل ہر RGBA پکسل میں چاروں بائٹس کو گھماتا ہے۔ ، نتیجے میں آنے والی تصویر میں متغیر شفافیت ہے (A = الفا، شفافیت کے لیے مختصر)۔
 آپ کی تصویر دیکھنے والا اس طرح کی تصویر کو بساط کے پس منظر کے ساتھ ڈسپلے کرنے کا فیصلہ کر سکتا ہے، جو کہ مبہم طور پر تصویر کا حصہ لگتا ہے، لیکن ایسا نہیں ہے۔  لہذا ہم نے انکرپٹڈ فائلوں کو دیکھنے میں آسانی پیدا کرنے کے لیے اصل تصویر سے سوفوس بلیو کو پس منظر کے طور پر استعمال کیا۔  مجموعی طور پر نیلی رنگت تصویری ڈیٹا کا حصہ نہیں ہے۔