خط متوقف نمی‌شه، یعنی سیستم طوری طراحی شده که یه خرابی کوچک کل فرآیند رو از بین نبره، خلاصه اینکه SCADA مال شبکه‌های پراکنده‌ست، DCS مال فرآیندهای متمرکز، هرکدوم جای خودش رو دارن و انتخابشون به نوع پروژه بستگی داره، راستش وقتی عمیق‌تر توش رفتم، بیشتر به این نتیجه رسیدم که اتوماسیون صنعتی فقط یه سری تجهیزات نیست، یه جور هنر مدیریت پیچیدگیه، خیلی جالب بود برام، گفتم براتون بنویسم شاید به دردتون بخوره.

یه وب‌سرور کوچک توی اینترنت، ساده و بی‌آزار؛ اما پشتش یه شبکه‌ی صنعتی غول‌پیکر خوابیده. یه اشکال امنیتی با امتیاز ۱۰ از ۱۰ روی همین سرور کافیه تا زنجیره‌ای از نفوذ شروع بشه که تهش، کنترل کامل روی شیرها، موتورها و توربین‌های یه کارخانه‌ست. از اینترنت به سرور، از سرور به ایستگاه کاری، از اونجا به شبکه‌ی اسکادا، و نهایتاً از اسکادا به HMIای که فرمان اصلاحی می‌ده؛ این یعنی مهاجم نه فقط داره داده می‌دزده، داره به دستگاه‌های فیزیکی فرمان می‌ده! بله، دقیقاً همون کاری که یه اپراتور باتجربه انجام میده، ولی این بار با نیت شوم. جالب اینجاست که مهاجم دو راه داره: مسیر اول به پایگاه داده‌ی تاریخی ختم میشه که خطرناکه ولی کشنده نیست؛ اما مسیر دوم، از وب‌سرور به ایستگاه شرکتی، بعد به ایستگاه اسکادا، و نهایتاً به HMI2 می‌رسه، همون جایی که یه فرمان اشتباه می‌تونه یه خط تولید رو متوقف کنه یا یه نیروگاه رو به خاموشی بکشونه. اینجا دیگه بحث سرقت اطلاعات نیست؛ بحث جان آدم‌ها، خسارت‌های میلیاردی، و فاجعه‌ای صنعتیه که توی چشم به هم زدنی رخ میده. چه درسی می‌گیریم؟

اینکه لایه‌بندی شبکه، پروتکل‌های امن، و حتی فایروال‌ها، وقتی با یه سری آسیب‌پذیری ساده اما زنجیره‌ای روبرو بشیم، مثل یه قلعه‌ی شنی جلوی موج دریا می‌مونن. تنها راه نجات، احرازهویت چندمرحله‌ای، پایش بی‌وقفه‌ی ترافیک، آپدیت‌های لحظه‌ای، و مهم‌تر از همه، جداسازی کامل شبکه‌ی کنترل از شبکه‌ی شرکتیه. چون توی دنیای سایبر-فیزیک، هیچ‌چیزی به اندازه‌ی یه روزنه‌ی امنیتی باز، ترسناک نیست؛ اون روزنه می‌تونه یه تیک‌تاک خاموش باشه که تا نفهمیدی، کل زندگیت رو از کار می‌ندازه.

📌 فایل تخصصی «کالبدشکافی فنی سامانه باور ۳۷۳» منتشر شد
پس از روزها بررسی فنی، تطبیق داده‌های OSINT و تحلیل لایه‌های سخت‌افزاری و نرم‌افزاری این سامانه پدافندی، گزارش کامل آماده دانلود است.
آنچه در این فایل خواهید خواند:
🔹 معماری رادار معراج-۴ با آرایه فازی فعال (AESA) و برد کشف ۴۵۰ کیلومتر
🔹 مکانیزم LPI (احتمال کشف پایین) که عملاً رادار را برای جنگنده‌های مجهز به RWR نامرئی می‌کند
🔹 سیستم هدایت TVM (Track-via-Missile) به‌جای روش‌های نیمه‌فعال قدیمی
🔹 افزایش چشمگیر دقت درگیری و مقاومت در برابر جنگ الکترونیک (ECCM)
⚠️ تذکر جدی:
این گزارش حاصل هفته‌ها تحقیق، ترجمه و تحلیل فنی است. هرگونه بازنشر، کپی‌برداری، بازنویسی یا استفاده از محتوای آن بدون ذکر منبع رسمی (نام کانال و لینک)، نه‌تنها نقض اخلاق حرفه‌ای، بلکه مشمول پیگیری حقوقی در فضای مجازی خواهد بود. از همراهان عزیز تقاضا داریم در انتشار این اثر، امانت‌داری را رعایت کنند.

چند وقتی بود داشتم به موضوع مدیریت تغییر در پروژه‌های اتوماسیون صنعتی فکر می‌کردم. راستش خیلی از تیم‌ها فکر می‌کنند با یه نرم‌افزار یا یه فرایند ساده، همه چیز حل می‌شه، اما توی عمل، کلی مورد ریز هست که از قلم می‌افته و بعداً دردسر درست می‌کنه. مثلاً خیلی از آدم‌ها وقتی صحبت از تغییر می‌شه، ذهنشون می‌ره سمت نرم‌افزارهای اصلی یا همون اپلیکیشن‌های مهم، اما غافل از اینکه تغییرات روی سوئیچ‌های شبکه، روترها، مودم‌ها یا حتی نقطه‌های پایانی VPN رو به راحتی نادیده می‌گیرن. تازه یه بحث دیگه هم پیمانکارانه. معمولاً پیمانکارها رو توی فرایند مدیریت تغییر حسابی دست کم می‌گیرن و فرض می‌کنن خودشون می‌دونن چکار باید بکنن، درحالی که این یه اشتباه بزرگه. یه نکتهٔ دیگه که کمتر کسی بهش توجه داره، نرم‌افزارهای کم‌استفاده یا به اصطلاح غیرحیاتی هستن، مثل اون نرم‌افزارهایی که برای اعلام هشدار استفاده می‌شن یا ابزارهای پیکربندی مستقل که برای یه دستگاه خاص روی یه لپ‌تاپ نصب شدن و بس. اینها معمولاً توی هیچ فرایند مدیریت تغییری نمی‌گنجن، اما دقیقاً همین موارد کوچک می‌تونن یه بی‌نظمی بزرگ توی سیستم ایجاد کنن

یه چالش جدی‌تر که توی محیط‌های صنعتی باهاش دست و پنجه نرم می‌کنیم، بحث ویرایش برخط یا همون Online Edits توی کنترلرهاست. خیلی از کنترلرهای اتوماسیون این قابلیت رو دارن که بدون اینکه کسی فایلی رو چک‌اوت کنه، مستقیم برن روی دستگاه تغییر بدَن و برن. این یعنی یه پیمانکار یا حتی یه اپراتور می‌تونه بیاد یه تغییری توی پیکربندی بده، بدون اینکه هیچ مدرک یا مستنداتی ازش باقی بمونه و بعدش هم بره. به خاطر همین یکی از دلایل اصلی که خیلی از مراکز صنعتی اجازهٔ اتصال لپ‌تاپ‌های شخصی یا پیمانکاری رو به شبکه‌شون نمی‌دن، دقیقاً همینه. راستش من خودم چند جا دیدم که این سیاست خیلی کمک کرده به شفافیت کار

اما راهکار چیه؟ توی مستندات معتبری که دیدم، یه سری پیشنهاد عملی خیلی خوب داده شده. اول اینکه تمام فایل‌های پیکربندی رو ببریم توی یه سیستم کتابخانه‌ای که اجباری باشه برای چک‌این و چک‌اوت کردن فایل‌ها. اینطوری هیچ کسی نمی‌تونه بدون ثبت و ضبط، تغییری بده. برای اون دستگاه‌هایی هم که امکان تغییر مستقیم روشون هست، بهتره طوری تنظیم بشن که هر تغییری توشون اتفاق بیفته، یه نوتیفیکیشن به سرور لاگ‌گیری بفرستن. اینطوری حداقل ما از وقوع تغییر باخبر می‌شیم، حتی اگه نتونیم جلوی انجامش رو بگیریم

یه نکتهٔ خیلی مهم دیگه که توی عمل خیلی به کارم اومده، اینه که برای هر تغییری، حتی اگه به نظر کوچیک و بی‌اهمیت بیاد، باید یه سری اطلاعات حداقلی ثبت بشه؛ اینکه دقیقاً چه تغییری قراره انجام بشه، این تغییر چه محدوده یا مدت زمانی رو شامل می‌شه، چه کسی قراره انجامش بده و مهم‌تر از همه چه کسی مجوزش رو داده. یه مورد دیگه که خیلی از تیم‌ها ازش غافل می‌شن، تست عملیاتی بعد از تغییره. بهتره حتماً یه نفر بعد از اجرای تغییر، عملاً سیستم رو تست کنه و تأیید کنه که تغییر به درستی اعمال شده، اونم با امضا یا یه مدرک دیگه که بشه روش حساب کرد

در مورد پیمانکارها هم چندتا تجربهٔ خوب دارم. اون جاهایی که موفق بودن، یا لپ‌تاپ شرکت‌تأمین‌شده در اختیار پیمانکار می‌ذاشتن یا اینکه خط‌مشی مشخصی داشتن برای تحویل فایل‌ها و مستندات به پیمانکار. یه چیزی که خیلی جواب داده، این بوده که برای پیمانکارها، همون اول کار، یه جلسهٔ آموزشی کوتاه بذارن و قوانین رو براشون توضیح بدن. این کار باعث شده که پیمانکارها خودشون هم به شفافیت کار کمک کنن و دیگه هرجوری دوست دارن تغییر ندن.

در نهایت، به نظر من مهم‌ترین چیزی که توی مدیریت تغییر باید بهش توجه کرد، صرفاً ابزارها و فرایندها نیستن. اون چیزی که واقعاً همه چیز رو متحول می‌کنه، فرهنگ سازمانیه. تا وقتی که خود پرسنل، اپراتورها و پیمانکارها به این باور نرسن که هر تغییری، حتی کوچک، باید ثبت و ضبط بشه، هیچ ابزاری به تنهایی نمی‌تونه جلوی مشکلات رو بگیره. تغییر فرهنگ کار، سخت‌ترین بخش مدیریت تغییره، ولی اگه درست انجام بشه، بیشترین تأثیر رو هم همون داره

حاضرم تو این کتابخونه از طلوع آفتاب تا پاسی از شب درس بخونم

مدیرعامل آنتروپی خاطر نشان کردند که،
بله در آینده کدنویسی از بین میره و بعدش کل مهندسی نرم افزار.

با توجه به روند فعلی درآمدزایی شرکت آنتروپی (Claude AI) ما فقط شاهد عدم بهینگی، هدر دادن منابع ارزشمند کاربران از جمله پول و وقتشون و درنهایت کار کردن روی ساختارها و بافتارهایی که اصلا با بهینگی سنخیتی ندارند و با این عدم بهینگی جاروبرقی Claude میلیاردها دلار رو ماهانه از جهان میکشن توی خزانه شون، خلق الله هم خوشحاله چیزی که دستشه آخرین تکنولوژی بشر قرن 21 هست !!!

پ.ن: به راستی که آنتروپی (فروپاشی منابع) بهترین اسم برای این شرکت بود.

نقل از کاربری که ۳۶ میلیون تومان وجه رایج رو تقدیم مدلی کرده که طی دو روز مصرف توکنش لیمیت میشه ..!

#Claude

چند وقت پیش داشتم یه دیتا دامپ رو بررسی میکردم که به یه نکته جالب برخوردم. توی تصویر بالا، یک سری دامپ و Watch از آدرسهای ۰x۱ تا ۰x۵۷ گرفتم. اولین چیزی که جلب توجه میکنه، الگوی افزایشی صرفاً عددی نیست، بلکه با دقت به دادههایی که به تابع PRGA پاس داده شدن، یه موضوع کلیدی کشف میشه. توی معماری RC4 و الگوریتمهای مبتنی بر جریان کلید، ورودی PRGA تعیینکننده جهت عملیاته. اگر ورودیها کلید یا IV باشن، خروجی باید کاملاً شبهتصادفی باشه، اما اینجا خروجیها ساختار مشخص و معناداری دارن. با بررسی مقادیر ورودی ۱ تا ۵۷ و مقایسه با خروجیهای متناظر، متوجه میشیم که دادههای ورودی دقیقاً همون Ciphertext هستن، چون خروجیهای به دست اومده الگویی غیرتصادفی دارن که قابل تفسیر بهعنوان Plaintext هستن. به عبارت دیگه، اگه سیستم در حالت رمزنگاری بود، ورودی PRGA میبایست کلید یا IV میبود و خروجی بایستی کاملاً رندوم میرفت، ولی اینجا خروجیها بازگشت به متن اصلی رو نشون میدن. در نتیجه، سیستم در حال Decryption هست، نه Encryption و دادههای Watch درواقع همون خروجی PRGA هستن که متن آشکار رو تشکیل میدن. این روش یه راه جانبی جالب برای تشخیص جهت عملیات رمز

توی ادامه بررسی، رفتم سراغ سکشن .s7b2 داخل Ghidra. اولین چیزی که نظرمو جلب کرد، چندتا لوکیشن لیبل‌گذاری شده بود که یکی از اونا مستقیماً به دیتای رمز شده (Encrypted Config) اشاره میکرد. اما سه تا لیبل دیگه هم اونجا بودن که هدفشون مشخص نبود. با کمی جلوتر رفتن و دنبال کردن جریان، متوجه شدم که یه HW Breakpoint روی تابع رمزگشایی RC4 تنظیم شده و وقتی breakpoint میخوره، میتونیم ببینیم که دادهها چطور پردازش میشن. اینجا بود که ارتباط بین این لیبلها مشخص شد: دو تا از اون سه لیبل باقی مونده، یکی به کلید RC4 اشاره داره و اون یکی هم به سایز دیتای رمز شده. پس ساختار کلی به این صورته: یه سکشن خاص حاوی دیتای رمز شده، یه کلید RC4 در جای دیگه، یه سایز مشخص برای دیتا، و در نهایت تابع رمزگشایی که همه اینارو کنار هم میذاره و دیتا رو به حالت اصلی برمیگردونه. این روش نشون میده که چطور با تحلیل استاتیک و داینامیک همزمان، میتونیم اجزای یک رمزنگاری جریانی رو در بدافزارها شناسایی کنیم و بفهمیم که دادهها چطور محافظت میشن و چطور باید اونا رو رمزگشایی کرد.

یه نمونه‌ی اجرایی اومد دستم به اسم raas.exe. توی x32dbg لودش کردم و ScyllaHide رو هم فعال کردم. همون ابتدای کار، توی Entry Point، یه CALL به تابع 402BD6 توی افست 40125E می‌زد. بعدش مقدار EAX رو چک می‌کرد، اگر غیرصفر بود می‌رفت 4013BE و ExitProcess می‌زد. یعنی اگه اون تابع تشخیص می‌داد محیط دیباگه، برنامه خودش رو می‌کشت.

رفتم سراغ تابع، با Step Into رفتم توش و با Step Over جلو رفتم تا رسیدم به 402C16 که نوشته بود call eax. اونجا مشخص شد که EAX رو GetProcAddress پر کرده بوده و توی ECX اشاره‌گر به رشته‌ی "BlockInput" بوده. یعنی با یه رزول پویا اومده بود تابع BlockInput رو گیر آورده، بدون اینکه توی IAT دربیاد.

BlockInput ورودی ماوس و کیبورد رو برای بقیه برنامه‌ها قطع می‌کنه. اینجا با PUSH 1 فعالش کرده بود. یه تکنیک رایج توی بدافزارها که نمی‌ذاره تحلیلگر راحت کار کنه. ولی با تموم شدن فرآیند یا Ctrl+Alt+Del برطرف می‌شه.

جالب اینجاست که استاتیک با Ghidra اینو نمی‌تونستم ببینم، چون اسم تابع رو موقع اجرا رزول می‌کرد. تحلیل دینامیک اینجا خیلی کمک کرد و بی‌سرمایه‌وقت اضافی به ته ماجرا رسیدم.

زبان سیگما یک استاندارد متن‌باز برای توصیف قواعد تشخیص تهدید در لاگ‌هاست که قابلیت ترجمه به فرمت‌های بومی SIEMهایی نظیر Splunk، Elasticsearch، QRadar و ArcSight را دارد و هدف آن یکپارچه‌سازی و اشتراک‌گذاری الگوهای حمله است. هر قاعده از سه بخش اجباری تشکیل می‌شود: عنوان (۱ تا ۲۵۶ کاراکتر، بدون شروع با "Detect")، منبع لاگ شامل Category (نوع لاگ)، Product (بستر عملیاتی) و Service (سرویس خاص) و در موارد پیچیده Definition، و بخش تشخیص با شرط Condition که ترکیبی از شناسه‌های رویداد، عبارات منظم یا مقادیر هش است. فیلدهای اختیاری شامل ID، Status، Description، Author، References، Fields، Falsepositives، Level و Tags (برای نگاشت به MITRE ATT&CK) هستند. نمونه قاعده CertUtil با عنوان Suspicious Certutil Command، وضعیت experimental، توضیحات مرتبط با زیردستور decode و ارجاع به منابع معتبر، نشان‌دهنده کاربرد عملی در شناسایی ابزارهای دوگانه‌سود است. مزایای اصلی شامل خودکارسازی جستجوی تهدید، استقلال از فروشنده، دقت بالا و قابلیت شخصی‌سازی است.

چالش‌ها شامل وابستگی به لاگ‌های ساختاریافته (JSON/Syslog)، حساسیت به تنظیمات محیط و نیاز به به‌روزرسانی مستمر است. در مجموع، سیگما با ساختار شفاف و انعطاف‌پذیر، راهکاری کارآمد برای پیاده‌سازی قواعد تشخیص تهدید در محیط‌های مختلف فراهم می‌کند که تطبیق با ساختار لاگ‌های هدف و به‌روزرسانی منظم برای اثربخشی پایدار ضروری است.

شناسایی نوع سیستم فایل یکی از اقدامات پایه‌ای در مدیریت ذخیره‌سازی و تحلیل امنیتی محسوب می‌شود و روش‌های آن بسته به دسترسی به سیستم به دو شاخه پاسخ‌دهی زنده و بررسی آف‌لاین تقسیم می‌گردد. در حالت دسترسی زنده، سه دستور اصلی کاربرد دارند: دستور lsblk -f که اطلاعات ساختاریافته‌ای از تمام بلاک‌دستگاه‌ها شامل نوع سیستم فایل، UUID، اندازه و نقطه‌اتصال را به صورت ستون‌بندی و خوانا نمایش می‌دهد و در سیستم‌هایی مانند CentOS به وضوح پارتیشن‌های xfs برای /boot و ریشه و همچنین حضور LVM2_member را مشخص می‌کند؛ دستور df -Th که علاوه بر نوع سیستم فایل، اطلاعات استفاده از دیسک مانند فضای کل، استفاده‌شده، موجود و درصد استفاده را به همراه نقطه‌اتصال هر پارتیشن نشان می‌دهد، اما در سیستم‌های دارای سرویس‌هایی مانند Docker خروجی آن شلوغ شده و تشخیص نوع اصلی سیستم فایل را دشوار می‌سازد، در حالی که در همین شرایط lsblk -f خروجی تمیزتری ارائه کرده و به عنوان مثال در سیستم اوبونتو به روشنی بخش بوت را از نوع FAT32 و سیستم فایل اصلی را EXT4 معرفی می‌کند؛

و دستور cat /etc/fstab که فایل شامل اطلاعات سیستم فایل‌های ثابت mount شونده در زمان بوت را نمایش داده و در سیستم‌های زنده نمای کلی از پارتیشن‌های دائمی و نوع آن‌ها ارائه می‌دهد. در حالت بررسی آف‌لاین یا Deadbox Forensics که به Image دیسک دسترسی وجود دارد، معمولاً از دستور cat /etc/fstab بر روی Image مونت‌شده استفاده می‌شود تا جدول سیستم فایل بررسی گردد و این روش حتی در صورت عدم اجرای سیستم عامل نیز قابل انجام است و اطلاعات دقیقی از نوع و نقاط اتصال پارتیشن‌ها در اختیار تحلیلگر قرار می‌دهد. از مقایسه این روش‌ها برمی‌آید که lsblk -f به دلیل خروجی ساختاریافته و سطح پایین‌تر هسته، گزینه اولیه در پاسخ‌دهی زنده محسوب می‌شود؛ df -Th برای تحلیل فضای مصرفی و شناسایی سریع نقاط اتصال مفید است هرچند در محیط‌های مجازی‌سازی شده نویز ایجاد می‌کند؛ و cat /etc/fstab در هر دو حالت زنده و مرده نمای پایداری از سیستم فایل‌های دائمی ارائه می‌دهد که برای تأیید تنظیمات و تحلیل پس از حمله حیاتی است و ترکیب این سه روش، شناسایی کامل نوع سیستم فایل از xfs و ext4 تا FAT32 و LVM را با دقت بالا ممکن می‌سازد و برای عملیات‌هایی نظیر بازیابی داده، تحلیل بدافزار و مهندسی معکوس زیرساخت ضروری می‌باشد.