Proxmark3 RDV4 چیست؟
Proxmark3 RDV4 نسخه کوچک و ماژولار پلتفرم Proxmark3 برای پژوهش RFID است. آنتن‌های داخلی LF و HF، خواننده Smart Card و امکان توسعه ماژول‌های بی‌سیم آن را برای آزمایشگاه RFID مناسب می‌کند.
نقطه قوت
برخلاف مولتی‌تول‌های عمومی، Proxmark روی تحلیل عمیق پروتکل‌های RFID و Smart Card تمرکز دارد. اکوسیستم Firmware/Client و ابزارهای اندازه‌گیری و تحلیل سیگنال از مزیت‌های اصلی آن هستند.
وضعیت محصول
نسخه اصلی Proxmark3 قدیمی شده، اما RDV4 همچنان در فهرست سخت‌افزارهای فعلی و پشتیبانی‌شده قرار دارد؛ Proxmark5 نیز به‌عنوان نسل جدیدتر عرضه شده است.
تست کارت و کنترل دسترسی فقط با مجوز مالک سامانه انجام شود.
مسئله را از نوع فناوری شروع کنید
RFID نام یک خانواده گسترده از فناوری‌هاست. کارت‌هایی که ظاهر مشابه دارند ممکن است فرکانس، روش مدولاسیون، حافظه و قرارداد احراز هویت متفاوتی داشته باشند. Proxmark3 ابزار پژوهش این تفاوت‌هاست و نباید از توانایی خواندن یک شناسه نتیجه گرفت همه کارت‌ها قابل تحلیل یکسان‌اند. پیش از آزمایش، شماره مدل کارت آزمایشی، اطلاعات سازنده و نوع reader را ثبت کنید. اگر نوع دقیق معلوم نیست، مرحله نخست باید شناسایی غیرمخرب و مشاهده باشد.
LF و HF دو حوزه کاری متفاوت‌اند و آنتن و روش آزمایش باید با آن‌ها هماهنگ باشد. قرار دادن کارت در نزدیکی آنتن نامتناسب می‌تواند هیچ پاسخ معناداری ندهد، بدون آنکه کارت خراب باشد. حتی در یک حوزه فرکانسی، پروتکل‌ها یکسان نیستند. به همین دلیل نتیجه یک کارت آموزشی را به همه کارت‌های یک ساختمان تعمیم ندهید. مشخصات RDV4 نقطه شروع انتخاب تجهیزات است؛ قابلیت هر عملیات به firmware، client و نوع کارت نیز وابسته می‌ماند.
شناسه کارت با اعتبارنامه امن فرق دارد
بعضی سامانه‌ها از شناسه عمومی کارت برای شناسایی استفاده می‌کنند و برخی علاوه بر آن تبادل احراز هویت دارند. دیده‌شدن یک UID به معنی دستیابی به کلید یا محتوای محافظت‌شده نیست. در گزارش آزمایش باید دقیقاً بنویسید چه چیزی مشاهده شده: نوع کارت، شناسه عمومی، اطلاعات پروتکل یا داده‌ای که با مجوز خوانده شده است. استفاده از عبارت مبهم «کارت خوانده شد» می‌تواند مخاطب را درباره میزان دسترسی گمراه کند.
برای ارزیابی طراحی خودتان، از مالک سامانه بپرسید تصمیم پذیرش در کدام لایه گرفته می‌شود. reader ممکن است صرفاً داده را به کنترلر بفرستد و منطق اصلی در بخش دیگری باشد. مشاهده رادیویی تنها بخشی از زنجیره است. کنترلر، پایگاه داده کاربران و ثبت رخداد نیز بر امنیت اثر دارند. اگر هدف سنجش مقاومت سامانه کنترل دسترسی است، نتیجه باید از رفتار واقعی پذیرش و رد در آزمایش مجاز بیاید، نه تنها از وجود یک عدد در خروجی ابزار.
آماده‌سازی میز کار
یک کارت آزمایشی غیرعملیاتی، reader متعلق به آزمایشگاه و سطح کار غیررسانا آماده کنید. کارت‌های فعال شخصی را از نزدیکی آنتن دور نگه دارید تا پاسخ ناخواسته وارد اندازه‌گیری نشود. وضعیت آنتن، کابل و منبع تغذیه را بررسی کنید. نزدیکی فلز، جهت کارت و فاصله می‌توانند کیفیت کوپلینگ را تغییر دهند. برای مقایسه دو capture، موقعیت فیزیکی را ثابت نگه دارید یا تغییر آن را ثبت کنید.
پیش از فرمان‌های اختصاصی، ارتباط client با سخت‌افزار و سازگاری نسخه‌ها را تأیید کنید. اختلاف firmware و client ممکن است خروجی یا رفتار نامطمئن ایجاد کند. روش نصب و به‌روزرسانی را از مخزن و راهنمای مرتبط با سخت‌افزار خود بگیرید؛ فایل یک مدل دیگر را صرفاً به دلیل شباهت نام روی دستگاه ننویسید. نسخه و شناسه build را در یادداشت آزمایش ثبت کنید تا نتیجه قابل بازتولید باشد. به‌روزرسانی میان دو اندازه‌گیری باید به عنوان متغیر آزمایش در نظر گرفته شود.
از مشاهده غیرفعال به آزمایش محدود
نخست تلاش کنید رفتار عادی کارت و reader آزمایشگاهی را بفهمید. زمان حضور کارت، آغاز تبادل و نتیجه نمایش‌داده‌شده توسط reader را ثبت کنید. هدف این مرحله ساختن یک نمونه سالم مرجع است. بدون نمونه مرجع، تشخیص پاسخ ناقص از پاسخ عادی دشوار می‌شود. اگر داده ضبط‌شده قابل decode نیست، پیش از فرض ضعف رمزنگاری، کیفیت دریافت و تنظیم پروتکل را بررسی کنید.
هر قابلیت فعال باید با هدف مشخص و روی نمونه مجاز استفاده شود. خواندن، شبیه‌سازی و نوشتن عملیات هم‌معنا نیستند و اثر یکسان ندارند. برای یادگیری نوشتن، کارت مصرفی و غیرحیاتی انتخاب کنید و وضعیت اولیه را ذخیره کنید. اگر ساختار حافظه یا ناحیه قفل را نمی‌شناسید، نوشتن تصادفی می‌تواند نمونه را برای استفاده عادی نامناسب کند. راهنمای نوع کارت و فرمان همان نسخه باید مرجع تصمیم باشد؛ این مقاله دستور عمومی تغییر کارت‌های ناشناخته ارائه نمی‌کند.
خواندن capture با چند شاهد
در یک trace، جهت تبادل، طول پیام، فاصله زمانی و صحت ساختار اهمیت دارند. یک رشته بایت بدون دانستن اینکه از کارت آمده یا reader، تفسیر محدودی دارد. همچنین نتیجه decode می‌تواند از تنظیمات اشتباه یا دریافت ناقص تأثیر بگیرد. چند بار آزمایش یکسان انجام دهید و الگوهای پایدار را از موارد تصادفی جدا کنید. اگر تنها یک capture غیرعادی دارید، آن را نشانه اولیه بدانید و برای نتیجه قطعی داده بیشتری جمع کنید.
زمان‌های ابزار را با رخداد قابل مشاهده مانند روشن شدن چراغ reader تطبیق دهید. این کار کمک می‌کند تبادل مربوط به همان ارائه کارت را از تبادل قبلی یا فعالیت background جدا کنید. در گزارش، نمونه خام و تنظیمات decode را هر دو نگه دارید. خروجی تفسیرشده بدون داده خام امکان بازبینی فرض‌ها را کم می‌کند. البته اگر capture حاوی اطلاعات حساس است، نسخه خام باید فقط در محل کنترل‌شده و با دسترسی محدود باقی بماند.
عیب‌یابی نبود پاسخ
نبود پاسخ می‌تواند از کارت نامتناسب، آنتن، فاصله، جهت، تنظیمات یا تغذیه باشد. این احتمال‌ها را یکی‌یکی بررسی کنید. ابتدا یک کارت سالم شناخته‌شده را در همان شرایط آزمایش کنید. اگر آن هم پاسخ نمی‌دهد، دامنه مشکل به ابزار یا محیط نزدیک‌تر می‌شود. اگر نمونه مرجع سالم است ولی کارت مورد بررسی نیست، نوع پروتکل و شرایط تغذیه کارت را دوباره بخوانید. تغییر هم‌زمان همه گزینه‌ها مانع تشخیص علت می‌شود.
اگر پاسخ با جابه‌جایی کوچک کارت تغییر می‌کند، موقعیت را در گزارش ثبت کنید و آزمایش را در چند تکرار انجام دهید. برد اعلام‌شده یا تجربه فرد دیگر برای محیط شما تضمین نیست. جنس کارت، آنتن، اشیای اطراف و روش اندازه‌گیری روی نتیجه اثر دارند. از یک اندازه‌گیری محدود، ادعای فاصله قطعی برای همه کارت‌ها نسازید. نتیجه علمی باید شرایط و عدم قطعیت را همراه خود داشته باشد.
آزمایش سازگاری reader و کارت
برای طراحی محصول خود، یک ماتریس کوچک از کارت‌ها و readerهای مجاز بسازید. برای هر جفت، شناسایی، زمان پاسخ، تکرارپذیری و نتیجه کاربردی را ثبت کنید. یک جفت موفق کافی نیست تا سازگاری کلی ثابت شود. اگر کارت در reader اول کار می‌کند و در دوم نه، تفاوت پروتکل، تنظیمات و کیفیت میدان را بررسی کنید. ابزار پژوهش به یافتن مرحله اختلاف کمک می‌کند، ولی جای مستندات دو محصول را نمی‌گیرد.
آزمایش‌های منفی نیز ارزش دارند. کارت نامرتبط یا نمونه‌ای که در پایگاه آزمایش مجاز نشده باید به شکل مورد انتظار رد شود. رد شدن باید در log کنترلر با زمان صحیح دیده شود. این آزمون نشان می‌دهد مسیر تصمیم و ثبت رخداد کار می‌کند. اگر reader فقط صدایی تولید می‌کند ولی هیچ شاهدی در سامانه نیست، هنوز نمی‌دانید کدام لایه تصمیم گرفته است. ارزیابی کامل باید این ابهام را برطرف کند.
نگه‌داری داده و مسئولیت پژوهش
شناسه کارت می‌تواند به شخص یا دسترسی فیزیکی مربوط باشد. آن را مثل داده عمومی در تصویر یا گزارش منتشر نکنید. برای آموزش از شناسه ساختگی یا کارت آزمایشگاهی استفاده کنید و نمونه‌های واقعی را بی‌دلیل جمع نکنید. دامنه مجوز باید کارت، reader، محل و نوع عملیات را روشن کند. داشتن دستگاه پژوهشی به خودی خود اجازه بررسی سامانه اطراف را ایجاد نمی‌کند، به‌ویژه در محیطی که کارت‌های افراد دیگر نزدیک آنتن قرار می‌گیرند.
پس از پایان، تجهیزات را به وضعیت شناخته‌شده برگردانید و فایل‌های آزمایش را با نام روشن نگه دارید. نتیجه گزارش باید شامل فرضیه، مشخصات نمونه، روش مشاهده، شواهد و محدودیت‌ها باشد. اگر ضعف طراحی پیدا شده، پیشنهاد اصلاح را به کنترل مناسب وصل کنید؛ برای مثال اتکا نکردن صرف به شناسه عمومی، حفاظت از کلیدها و پایش تصمیم‌های کنترلر. Proxmark3 در این فرایند ابزار تولید شواهد است و ارزش آن به کیفیت سؤال و روش آزمایش وابسته می‌ماند.
پرسش‌هایی که پیش از انتخاب ابزار باید پاسخ دهید
اگر هدف شما تنها خواندن شماره یک نوع تگ برای یک برنامه کاربردی است، شاید reader اختصاصی همان استاندارد ساده‌تر باشد. Proxmark زمانی ارزش بیشتری دارد که بخواهید رفتار پروتکل، کیفیت تبادل یا سازگاری چند نمونه را بررسی کنید. انعطاف زیاد به معنی نیاز بیشتر به دانش و زمان تفسیر است. هزینه آزمایشگاه فقط قیمت سخت‌افزار نیست؛ کارت مرجع، reader، زمان آموزش و نگه‌داری داده نیز بخشی از آن‌اند. پیش از تهیه تجهیزات، یک سؤال واقعی و معیار پایان آزمایش تعریف کنید.
ماژولار بودن آنتن یا امکان توسعه نیز باید با نیاز اندازه‌گیری مرتبط شود. آنتن دیگر ممکن است برای یک سناریو مناسب‌تر باشد ولی مقایسه مستقیم نتیجه با setup قبلی را دشوار کند. هر تغییر سخت‌افزار را در پرونده ثبت کنید و نمونه مرجع را دوباره اندازه بگیرید. اگر پژوهش در چند نوبت انجام می‌شود، عکس چیدمان فیزیکی با حذف اطلاعات حساس می‌تواند به بازسازی شرایط کمک کند. نام دستگاه به تنهایی مشخصات کامل setup را توصیف نمی‌کند.
مرز نتیجه رمزنگاری
مشاهده داده رمز‌شده به معنی امکان خواندن محتوای آن نیست. همچنین موفقیت در تحلیل یک نمونه قدیمی را نباید به همه فناوری‌های جدید تعمیم داد. برای ارزیابی رمزنگاری، نوع الگوریتم، مدیریت کلید، تازگی چالش و قرارداد احراز هویت اهمیت دارند. این موضوع از صرف دریافت موج و decode کردن پیام جداست. گزارش باید میان ضعف شناخته‌شده پروتکل، تنظیم ضعیف سامانه و خطای پیاده‌سازی مشخص تفاوت بگذارد.
اگر شواهد کافی برای نتیجه امنیتی ندارید، همان محدودیت را بنویسید و مرحله بعدی را به صورت پرسش مشخص تعریف کنید. مثلاً «باید معلوم شود کنترلر علاوه بر شناسه عمومی چه داده‌ای را اعتبارسنجی می‌کند» از ادعای کلی ناامن بودن کارت دقیق‌تر است. این شیوه به مالک سامانه امکان می‌دهد اقدام اصلاحی مناسب انتخاب کند و از تعویض پرهزینه تجهیزات بر پایه برداشت ناقص جلوگیری می‌کند.
