کنیکشن، پراکسیز اور ڈیٹا کی حفاظت

یہ دستاویز TgWitness 0.7.0 کے طرز عمل اور اس کی حدود کو بیان کرتی ہے۔ تصدیق، ماخذ تک رسائی، نیٹ ورک کنیکٹیویٹی اور مکمل کپچر الگ الگ حالتें ہیں۔ سائن ان کے مراحل، فائل فارمیٹس، اور متعدد اکاؤنٹس کے لیے، اکاؤنٹس اور سیشن فارمیٹس سے شروع کریں۔ ایونٹ پالیسیاں اور دوبارہ شروع کرنے کے طرز عمل کے لیے، دیکھیں کہ کلیکشن کیسے کام کرتی ہے۔

تصدیقی طریقے#

API ID اور API ہیش ایک ایپلیکیشن کی شناخت کرتے ہیں؛ یہ اکاؤنٹ لاگ ان کا متبادل نہیں ہیں۔ یہ TgWitness میں اختیاری ہیں۔ ترجیح: فارم میں داخل کی گئی جوڑی، پھر درآمد شدہ اکاؤنٹ JSON سے، پھر ورک اسپیس میں محفوظ شدہ جوڑی، پھر 50 کی بلٹ ان پول پبلک جوڑے، جنہیں بے ترتیب ترتیب میں آزمایا جاتا ہے اور جب ٹیلیگرام کسی ایک کو مسترد کر دیتا ہے تو خودکار طور پر تبدیل کیا جاتا ہے۔ صرف ٹیلیگرام ڈیسک ٹاپ جوڑا (2040) ایک مطابقت پذیر ٹیلیگرام ڈیسک ٹاپ کلائنٹ کی تفصیل کے ساتھ بھیجا جاتا ہے۔ my.telegram.org پر موجود API ڈیولپمنٹ ٹولز سے آپ کا اپنا جوڑا آپ کے تمام اکاؤنٹس کے ساتھ استعمال کیا جا سکتا ہے؛ ہر اکاؤنٹ کی اپنی علیحدہ اجازت نامہ برقرار رہتی ہے۔

ٹیلیگرام کوڈ کی ترسیل کا انتخاب کرتا ہے؛ ایس ایم ایس کی ضمانت نہیں ہے۔ ایک API ہیش منسوخ شدہ سیشن کو ٹھیک نہیں کر سکتا یا بھولے ہوئے 2FA پاس ورڈ کو تبدیل نہیں کر سکتا۔ TgWitness لاگ ان کوڈز یا ٹیلیگرام 2FA پاس ورڈ کو ڈسک پر محفوظ نہیں کرتا۔

نجی ذریعے کے لیے، اکاؤنٹ کے پاس پہلے سے ہی رسائی ہونی چاہیے۔ گروپ کا صارف نام غیر ضروری ہے۔ پروکسی یا سیشن امپورٹ سے نہ رکنیت ملتی ہے اور نہ ہی منتظم کے حقوق۔ موجودہ رکنیت سے پہلے شامل ہونے کی تاریخ تک رسائی کی ضمانت نہیں ملتی۔

ٹیلی تھون سیشن فائل درآمد کریں#

Telethon SQLite، Pyrogram SQLite، اور Telegram Desktop TData مختلف فارمیٹس استعمال کرتے ہیں۔ پینل سپورٹ شدہ ڈھانچوں کا پتہ لگاتا ہے اور انہیں تبدیل کرتا ہے؛ فائل کا نام تبدیل کرنا تبدیلی نہیں ہے۔ Files کے تحت ایک سیشن اور اس کے ساتھ والی JSON کو منتخب کریں، پھر Connect account دبائیں۔ چار تک مماثل فائلیں اور کل 8 MiB قبول کیے جاتے ہیں۔ TData/JSON کی تفصیلات کے لیے فارمیٹ کی حدیں دیکھیں۔ پاس کوڈ کی بازیابی کا کوئی طریقہ نہیں ہے۔ فون/2FA یا QR لاگ ان ایک علیحدہ اجازت نامہ بناتا ہے۔

اختیاری صرف ٹیلی تھون کمانڈ لائن راستہ دستیاب ہے:

1. اصلی سیشن استعمال کرنے والے کلائنٹ کو روکیں اور ایک مستقل کاپی بنائیں۔ کنورٹر ان فائلوں کو مسترد کر دیتا ہے جن کا WAL/جرنل نامکمل ہو۔ ان فائلوں کو حذف کر کے چیک کو بائی پاس کرنے کے بجائے اصلی کلائنٹ کو مناسب طریقے سے بند کریں۔
2. TgWitness کے ماحول سے، چلائیں:

python -m tgwitness.sessions account.session --out account.tgwitness-session

3. Add account → Files کے تحت نتیجہ لوڈ کریں یا اس کی سٹرنگ پیسٹ کریں اور جاری رکھیں۔
4. دکھائی گئی عددی اکاؤنٹ آئی ڈی چیک کریں، ذرائع منتخب کریں اور مشاہدہ شروع کریں۔

کنورٹر SQLite کو صرف پڑھنے کے لیے (read-only) کھولتا ہے، کوئی اسکیما اپ گریڈ یا نیٹ ورک درخواست نہیں کرتا، اور سیشن کو پرنٹ نہیں کرتا۔ یہ اسکیما ورژن، ٹیبل کی اقسام، ایک سیشن قطار، IP/پورٹ/DC اور کلید کی لمبائی کی جانچ کرتا ہے۔ CLI ان پٹ 64 MiB تک محدود ہے؛ StringSession متن 4 KiB تک محدود ہے۔ پینل کنورژن فائلوں کو تصدیق شدہ TgWitness سرور پر اپ لوڈ کرتا ہے، انہیں میموری میں پراسیس کرتا ہے، اور اپ لوڈ کی گئی اصل فائلوں کو محفوظ کیے بغیر اس براؤزر کو معیاری شدہ اسناد واپس کر دیتا ہے۔ دور دراز سرور کے لیے HTTPS استعمال کریں۔

تبدیل شدہ فائل ایک غیر خفیہ شدہ اکاؤنٹ رسائی راز ہے۔ اسے محفوظ اسٹوریج میں رکھیں اور اسے کبھی بھی کمٹ یا کسی تیسری پارٹی کی کنورژن سروس کو نہ بھیجیں۔ TgWitness مجاز سیشن کو اپنے انکرپٹڈ والٹ میں محفوظ کرتا ہے۔ سیشن کی کاپی کرنے سے ایک علیحدہ اجازت نامہ پیدا نہیں ہوتا: کلون شدہ auth کیز کے ساتھ بیک وقت کلائنٹس نہ چلائیں اور آزادانہ اپ ڈیٹ کی ترسیل کا تصور نہ کریں۔

تبدیلی اجازت نامہ منتقل کرتی ہے، اصل پیغامات، اینٹیٹی کیش یا ایک پائیدار اپ ڈیٹ کرسر نہیں۔ یہ عمل دوبارہ شروع ہونے پر اپ ڈیٹ کی بحالی کو درست نہیں کرتی۔

MTProto، Telethon اور پروکسیز#

MTProto ٹیلیگرام کا پروٹوکول ہے۔ Telethon وہ پائتھن کلائنٹ لائبریری ہے جسے TgWitness استعمال کرتا ہے۔ MTProxy ایک ٹیلیگرام ٹرانسپورٹ پراکسی ہے؛ SOCKS5 اور HTTP CONNECT عمومی سرنگیں فراہم کرتے ہیں۔ ان میں سے کوئی بھی اکاؤنٹ کی تصدیق کا متبادل نہیں ہے۔

ہر ورک اسپیس کے لیے راستہ محفوظ کریں۔ اکاؤنٹ → ترتیبات → کنکشن کی ترتیبات → سائن ان کرنے سے پہلے کنکشن کا راستہ تبدیل کریں۔ نئے ورک اسپیسز بطورِ ڈیفالٹ خودکار MTProxy · عوامی فہرستوں کے ساتھ آئی پی چھپانے کے رویے کے ساتھ ہوتے ہیں۔ موجودہ ورک اسپیسز جنہوں نے واضح طور پر Direct استعمال کیا تھا، وہ ایک ایسا موڈ برقرار رکھتے ہیں جو اسے اجازت دیتا ہے۔

آئی پی موڈز#

روٹ کنکشن کا انتخاب کرتا ہے۔ آئی پی موڈ طے کرتا ہے کہ سرور کا پتہ کب ظاہر ہو سکتا ہے۔ یہ کنٹرولز VPN انسٹال نہیں کرتے اور نہ ہی مشین کے تمام ٹریفک کو روٹ کرتے ہیں۔

ٹنل/VPN موڈ اس مفروضے پر مبنی ہے کہ آپ اس نیٹ ورک کو الگ سے منظم کرتے ہیں۔ اگر ایک فعال ٹنل موجود نہ ہو تو منزل والا سرور کا اپنا پتہ دیکھ سکتا ہے۔ موڈ کا انتخاب آپ کے حقیقی نیٹ ورک کے مطابق کریں، نہ کہ آپشن کے نام کے مطابق۔

ایک راستہ منتخب کریں#

جعلی TLS ee کے راز مسترد کر دیے جاتے ہیں۔ Telethon 1.45 کی نارملائزیشن پری فکس اور ڈومین ہٹا سکتی ہے، لیکن اس میں Fake TLS نافذ نہیں ہوتا۔ tg://proxy?server=…&port=…&secret=… یا https://t.me/proxy?server=…&port=…&secret=… کو پیسٹ کریں اور لنک سے 'فیلڈز بھرنا' منتخب کریں۔ یہ کنکٹ یا محفوظ کیے بغیر فیلڈز کو تصدیق اور پُر کرتا ہے؛ راستے کا جائزہ الگ سے لیں اور محفوظ کریں۔ دستی فیلڈز دستیاب رہتی ہیں۔ ٹیلیگرام پروکسی لنکس دیکھیں۔

آپ کی تنصیب کے فراہم کردہ عوامی پروکسیز#

بلٹ ان فہرست چار ذرائع کو یکجا کرتی ہے: SoliSpirit/mtproto، zakky8/mtproto-proxy-pro، kort0881/telegram-proxy-collector اور 3yed-61/MTP-Collector۔ اس کے ساتھ منسلک سنپ شاٹ میں اینڈ پوائنٹ کے حقائق، ماخذ کی شناخت اور ڈاؤن لوڈ کی تاریخیں شامل ہیں۔ کسی فراہم کنندہ کی فہرست اس بات کا ثبوت نہیں ہے کہ پروکسی کام کرتی ہے یا ہر ٹیلیگرام اپ ڈیٹ فراہم کرتی ہے۔

خودکار MTProxy ٹیلیگرام ٹرانسپورٹ کنیکٹیویٹی کی جانچ کرتا ہے، ایک فعال پروکسی کو برقرار رکھتا ہے اور اس کے ناکام ہونے پر دوسری پروکسی پر سوئچ کر جاتا ہے۔ جب کافی فعال اندراجات دستیاب ہوں تو ورک اسپیسز مختلف پروکسیز کو ترجیح دیتے ہیں؛ ایک منفرد ایگزٹ ایڈریس کی ضمانت نہیں دی جاتی۔ ناکام پروکسیز اگلی کوشش سے پہلے آرام کرتی ہیں۔ اگر کوئی بھی کام نہ کرے، تو IP موڈ یہ طے کرتا ہے کہ کیا کلیکشن کو انتظار کرنا چاہیے یا براہِ راست کنکشن استعمال کیا جا سکتا ہے۔ پروکسیز تبدیل کرنے سے اکاؤنٹ تبدیل نہیں ہوتا یا اس کا جرنل مٹ نہیں جاتا۔ راستے کے انتخاب اور تبدیلیاں دستخط شدہ جرنل میں ریکارڈ ہوتی ہیں۔

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

ہر فیڈ کا جواب آٹھ سیکنڈ کے درخواست ٹائم آؤٹ اور 20 سیکنڈ کی مجموعی ڈاؤن لوڈ ڈیڈ لائن کے ساتھ 1 MiB تک محدود ہے۔ ری ڈائریکٹس کو مسترد کر دیا جاتا ہے۔ فی ماخذ 64 تک مطابقت رکھنے والی اندراجات کو برقرار رکھا جاتا ہے اور ان کی ڈوپلیکیشن ختم کی جاتی ہے۔ پارسر معاون ہیکساڈیسمل اور base64url سیکرٹس اور JSON فیڈ کو قبول کرتا ہے۔ جعلی TLS ee، غیر معتبر لنکس، نجی/محفوظ شدہ آئی پی لیٹرلز اور مقامی ہوسٹ نیمز کو نظر انداز کیا جاتا ہے۔ ہوسٹ نیمز کو استعمال سے پہلے حل (resolved) اور چیک کیا جاتا ہے، اور منتخب کردہ آئی پی کو اس کنکشن کے لیے پن (pin) کر دیا جاتا ہے۔ خودکار دوبارہ حصول (Automatic reacquisition) ہوسٹ نیم کو دوبارہ حل کرتا ہے؛ اسے دوبارہ حل کرنے کے لیے ایک دستی اندراج (manual entry) دوبارہ لگائیں۔

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

ٹیلیگرام ٹریفک اور HTTPS درخواستیں مختلف راستوں کا استعمال کرتی ہیں۔ فہرست کی ڈاؤن لوڈز ایک الگ HTTPS کنکشن اور فراہم کردہ external-request راستے کا استعمال کرتی ہیں۔ TGWITNESS_PROXY_FEED_PROXY واضح طور پر اس راستے کو ایک HTTP/SOCKS5 پروکسی کے ساتھ اووررائڈ کرتا ہے؛ دونوں collector Compose ویریئنٹس اسے آگے بھیجتے ہیں۔ بیک گراؤنڈ پول مرکزی ورک اسپیس کی پیروی کرتا ہے۔ فیڈ فراہم کنندگان کو کوئی ٹیلیگرام سیشن، API کی تفصیلات، پینل ٹوکن یا بوٹ ٹوکن بھیجا نہیں جاتا۔ فراہم کنندہ کے نام، سنپ شاٹ کی تاریخیں اور ڈاؤن لوڈ کا راستہ 'فہرست کہاں سے آتی ہے' کے تحت ظاہر ہوتے ہیں۔

ایک MTProxy صرف ٹیلیگرام ٹریفک منتقل کرتا ہے۔ ورک اسپیس HTTP آپریشنز جیسے ٹائم اسٹیمپ، نوٹیفیکیشنز، آف سائٹ کاپیاں اور سورس چیکس، کنفیگر کیے جانے پر ایک علیحدہ SOCKS5/HTTP پروکسی استعمال کرتے ہیں، اور پھر اکاؤنٹ کے SOCKS5/HTTP روٹ کا استعمال کرتے ہیں۔ ان دونوں کے بغیر، Hide IP درخواست مسترد کر دیتا ہے؛ دیگر موڈز Direct کی اجازت دیتے ہیں۔ بیرونی درخواستیں غیر فعال کی جا سکتی ہیں۔ ایک واضح طور پر ترتیب دی گئی فیڈ-ڈاؤن لوڈ پراکسی ایک علیحدہ آپریٹر اوور رائیڈ کے طور پر رہتی ہے۔ آزاد شاہد سروس اپنا راستہ خود برقرار رکھتی ہے۔

خودکار پول کے پیرامیٹرز

**پیرامیٹرز → خودکار MTProxy** کے تحت، ناکامی کی حد، کول ڈاؤن، منصوبہ بند گردش، پروکسی شیئرنگ اور اجازت یافتہ فال بیک تاخیر کو ترتیب دیں۔ | کنٹرول | ڈیفالٹ | | --- | --- | | متبادل سے پہلے منقطع | 10 منٹ کے اندر 3 | | ہر کنکشن کی کوشش پر آزمائے جانے والے پروکسیز | 3 | | ناکامی کے بعد پہلی / زیادہ سے زیادہ آرام کی مدت | 10 منٹ / 6 گھنٹے | | منصوبہ بند گردش | غیر فعال؛ ناکامی پر فعال کریں | | فی پروکسی اکاؤنٹس | 0: علیحدہ انٹریاں ترجیح دیں، ضرورت پڑنے پر شیئر کریں۔ خصوصی انٹری کے لیے 1 سیٹ کریں۔ | | مجاز ڈائریکٹ فال بیک سے پہلے تاخیر | 10 منٹ؛ Hide IP اب بھی ڈائریکٹ کو مسترد کرتا ہے | | فیڈ ریفریش / ٹرانسپورٹ چیکس | 60 / 10 منٹ؛ مرکزی ورک اسپیس کی قدریں مشترکہ پول پر لاگو ہوتی ہیں | مختلف پراکسیز مختلف ایگزٹ ایڈریسز کی ضمانت نہیں دیتیں۔ یہ ترتیبات ٹیلیگرام کی حدوں کو ختم نہیں کرتیں یا گمنامی ثابت نہیں کرتیں۔

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

خالی کیٹلاگ کو proxy-config/proxies.json پر کاپی کریں اور اپنے تعینات کردہ عوامی اینڈ پوائنٹس شامل کریں:

{"format": "tgwitness-proxy-catalog-v1", "proxies": [
  {"id": "project-eu", "label": "Project EU",
   "link": "tg://proxy?server=REPLACE_HOST&port=443&secret=REPLACE_SECRET"}
]}

مثال کے اقدار کو تبدیل کرنا ضروری ہے۔ زیادہ سے زیادہ 32 منفرد اندراجات قبول کیے جاتے ہیں۔ تصدیق شدہ فہرست لیبلز/ہوسٹس/پورٹس واپس کرتی ہے بغیر مشترکہ راز کے؛ ایک کو منتخب کرنے سے اس کی اسناد ورک اسپیس والٹ میں محفوظ ہو جاتی ہیں۔ دستیابیت ایک واضح ٹرانسپورٹ ٹیسٹ تک غیر آزمایا ہوا رہتا ہے۔ خراب ترتیب والا کیٹلاگ دستی کنفیگریشن کو دستیاب چھوڑ دیتا ہے۔

نیٹیو لانچ: مقامی JSON راستے کے لیے TGWITNESS_PROXY_CATALOG سیٹ کریں۔ ڈاکر:

docker compose -f compose.yaml -f deploy/compose/compose.proxies.yaml up -d --build

اوورلے صرف پڑھنے کے لیےproxy-config کو ماؤنٹ کرتا ہے؛ فائلوں کو کنٹینر UID 10001 کے ذریعے قابلِ مطالعہ ہونا چاہیے۔ یہ ڈائریکٹری Git، Docker بلڈ کنٹیکسٹ اور ماخذ آرکائیوز سے خارج ہے۔ یہ کیٹلاگ اکاؤنٹس کو جمع کرنے کے لیے ترتیب دیتا ہے؛ وِٹنس بوٹ اپنا HTTP/SOCKS5 راستہ استعمال کرتا ہے، MTProxy نہیں۔

براہِ راست واپسی اوپر بیان کردہ آئی پی موڈ کے تحت کنٹرول ہوتی ہے۔ راستہ تبدیل کرنے سے پہلے مشاہدہ معطل کریں۔ محفوظ شدہ راستہ پرانے کلائنٹس کو منقطع کر دیتا ہے اور نامکمل لاگ ان کو منسوخ کر دیتا ہے؛ ایک نیا کلائنٹ محفوظ شدہ راستے کا استعمال کرتا ہے۔ اکاؤنٹ کا جرنل/سیشن بائنڈنگ برقرار رہتا ہے۔ ترتیبات پچھلے راستے کی جگہ لے لیتی ہیں: اسے ترمیم کرتے وقت پروکسی کی تفصیلات دوبارہ درج کریں۔

سندیں 'network.enc' میں خفیہ کردی جاتی ہیں۔ API صارف نام، پاس ورڈ یا سیکرٹ واپس نہیں کرتی۔ دستخط شدہ ریکارڈز میں راستے کی قسم اور اس بات کی نشاندہی ہوتی ہے کہ سندیں موجود ہیں یا نہیں، جبکہ اینڈ پوائنٹ اور سیکرٹس شامل نہیں ہوتے۔ آپریٹر پینل میں اینڈ پوائنٹ دیکھ سکتا ہے۔ سیکرٹ فیلڈز محفوظ کرنے، لاک کرنے یا ورک اسپیس تبدیل کرنے کے بعد صاف ہو جاتی ہیں۔

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

پراکسی ٹیلیگرام کلائنٹ کے کنکشنز پر لاگو ہوتی ہے، بشمول ٹیلیگرام ڈی سی میڈیا ڈاؤن لوڈز۔ براؤزر، پی آئی پی، ایس ایس ایچ اور دستی طور پر چلائے جانے والے ٹی ایس اے ٹولز کے الگ راستے ہیں۔ پراکسی ہوسٹ نیم کو مقامی طور پر حل کیا جا سکتا ہے۔ rdns منزل کے ہوسٹ نیمز کو متاثر کرتا ہے؛ ٹیلیگرام اکثر عددی ڈی سی آئی پیز فراہم کرتا ہے۔

SOCKS5 اور سادہ HTTP CONNECT خود پروکسی کی شناختی معلومات یا کلائنٹ سے پروکسی ٹنل کو انکرپٹ نہیں کرتے۔ MTProto الگ سے ٹیلیگرام ٹریفک کو محفوظ کرتا ہے۔ ایک غیر قابلِ اعتماد نیٹ ورک پر پروکسی کے لیے ایک مناسب محفوظ چینل استعمال کریں۔ نجی گروپس کلاؤڈ چیٹس ہیں؛ MTProto انہیں اینڈ ٹو اینڈ انکرپٹڈ سیکرٹ چیٹس میں تبدیل نہیں کرتا۔

انکرپشن اور دستخط#

اکاؤنٹ میں اسٹوریج تحفظ ان ریاستوں کو دکھاتا ہے۔ پینل ٹوکن ایک رسائی راز ہے، انکرپشن پاس ورڈ نہیں۔ یہ منتظم کو رسائی فراہم کرتا ہے؛ جاری کردہ ٹوکنز کو اکاؤنٹس اور چیٹس تک محدود کیا جا سکتا ہے۔ ورک اسپیسز ہوسٹ پراسیس شیئر کرتے ہیں اور الگ الگ کرایہ دار نہیں ہوتے۔

ایک واضح طور پر شروع کیا گیا، الگ تھلگ مصنوعی ڈیمو براہِ راست لوپ بیک کنکشن پر خودکار طور پر کھل سکتا ہے۔ یہ ایک الگ پراسیس-لائف ٹائم صلاحیت استعمال کرتا ہے؛ یہ نہ تو ترتیب دیا گیا پینل ٹوکن ظاہر کرتا ہے اور نہ ہی حقیقی ورک اسپیسز تک رسائی فراہم کرتا ہے۔ ریموٹ، پراکسی شدہ یا کراس-اورجن درخواستیں اس خودکار-داخلے کی صلاحیت کو حاصل/استعمال نہیں کر سکتیں۔ یہ سہولت حقیقی اکاؤنٹ کے ڈیٹا کے لیے تصدیقی حد کو ختم نہیں کرتی۔

BitLocker، LUKS، FileVault یا ایک منظم انکرپٹڈ والیوم اپنے متعلقہ خطرے کے ماڈلز کے تحت اسٹوریج کی حفاظت کر سکتے ہیں۔ ایک انلاک شدہ چلتی ہوئی مشین کا منتظم پھر بھی ڈیٹا پڑھ سکتا ہے۔ اسٹوریج کی منصوبہ بندی میں SQLite WAL/SHM، میڈیا، عارضی ایکسپورٹس، سوئپ، بیک اپس اور براؤزر ڈاؤن لوڈز کو شامل کریں۔ ایک ڈاکر والیوم صرف اس لیے انکرپٹڈ نہیں ہوتا کیونکہ یہ ایک والیوم ہے۔ TgWitness، SQLCipher یا آبجیکٹ انکرپشن کو نافذ نہیں کرتا۔

بیرونی ماسٹر کلید#

نئی تنصیب کے لیے، ماسٹر کی کو ڈیٹا ڈائریکٹری کے باہر رکھیں۔ یہ خودکار طور پر موجودہ لوکل-کی والٹ کو منتقل نہیں کرتا۔ ایک کی ڈائریکٹری تیار کریں جس تک صرف سروس شناختی نام کی رسائی ہو، پھر چلائیں:

python -m tgwitness.security create-master-key /private/keys/tgwitness-master.key
export TGWITNESS_VAULT_KEY_FILE=/private/keys/tgwitness-master.key
python -m tgwitness --data-dir /private/observations/new-case

پاور شیل، انسٹال شدہ پروجیکٹ ماحول استعمال کرتے ہوئے:

python -m tgwitness.security create-master-key E:\PrivateKeys\tgwitness-master.key
$env:TGWITNESS_VAULT_KEY_FILE = 'E:\PrivateKeys\tgwitness-master.key'
python -m tgwitness --data-dir E:\PrivateData\new-case

Docker میں، فائل کو /data کے باہر صرف-پڑھنے کے لیے ماؤنٹ کریں، مثال کے طور پر /run/secrets/tgwitness-master.key پر، اور ماحول کا متغیر اسی راستے پر سیٹ کریں۔ سروس UID کو اسے پڑھنے کے قابل ہونا چاہیے۔ ماحول/تشکیلاتی فائلوں کے ذریعے راستہ بھیجیں، نہ کہ کلید کے بائٹس۔

ہر ورک اسپیس کو ایک بے ترتیب عوامی سالٹ اور اپنی مخصوص فرنیٹ کلید ملتی ہے جو HKDF-SHA256 کے ذریعے حاصل کی جاتی ہے۔vault.external.json صرف ڈی ریویشن میٹا ڈیٹا محفوظ کرتا ہے، ماسٹر کلید نہیں۔ اگر کلید غائب ہو یا غلط ہو تو یہ خاموشی سے اسے تبدیل کیے بغیر آغاز کرنے میں ناکام رہتا ہے۔ بحالی کے لیے سالٹ میٹا ڈیٹا اور ماسٹر کلید دونوں کو محفوظ رکھیں۔

تمام ورک اسپیسز ایک ہی ماسٹر کی سے مشتق ہیں؛ اس کے سمجھوتے سے پوری تنصیب متاثر ہوتی ہے۔ چلنے والا عمل راز کو ڈیکرپٹ کر سکتا ہے۔ یہ HSM یا پاس ورڈ KDF نہیں ہے۔ بے ترتیب کلید کے متبادل کے طور پر کسی بھی انسانی پاس ورڈ کو قبول نہیں کیا جاتا۔

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

ماخذ اور تصدیق کا دائرہ#

26 اکتوبر 2026 کو جائزہ لیا گیا:

• https://core.telegram.org/api/auth
• https://core.telegram.org/api/obtaining_api_id
• https://docs.telethon.dev/en/stable/basic/signing-in.html
• https://docs.telethon.dev/en/stable/concepts/sessions.html
• https://core.telegram.org/mtproto/mtproto-transports
• https://github.com/telegramdesktop/tdesktop/blob/dev/Telegram/SourceFiles/storage/storage_account.cpp
• Telethon 1.45.0: SQLiteSession، StringSession، Connection._proxy_connect، TcpMTProxy.normalize_secret اور ڈاؤن لوڈ کے طریقے۔

مقامی ٹیسٹ لوپ بیک SOCKS5/HTTP CONNECT فکسچرز، مصنوعی SQLite سیشنز، راستے کی علیحدگی، خفیہ استثناء اور غیر موجود کلید کی انکار کو کور کرتے ہیں۔ یہ حقیقی Telegram/proxy باہمی ہم آہنگی یا لائیو MTProxy کے رویے کو قائم نہیں کرتے۔ ملاحظہ کریں VERIFICATION.md اور LIVE_ACCEPTANCE.md۔