معرفی
این ابزار برای آزمایشگاه، توسعه، پژوهش و ارزیابی مجاز معرفی شده است. مشخصات و تصویر از منبع رسمی پروژه یا سازنده آمده‌اند.
نکته 1
تمرکز ChameleonUltra روی پژوهش کارت‌ها و پروتکل‌های RFID/NFC است.
نکته 2
پروژه متن‌باز است و firmware و client در مخزن رسمی توسعه پیدا می‌کنند.
نکته 3
استفاده باید فقط روی کارت‌ها و سامانه‌های متعلق به خودتان یا با مجوز صریح باشد.
استفاده مسئولانه
قابلیت‌های RF، RFID، اسکن، credential audit، تحلیل ترافیک و تست امنیت فقط باید روی دارایی‌های خودتان، آزمایشگاه یا Scope دارای مجوز صریح استفاده شوند.
پژوهش کارت را از شبیه‌سازی سامانه جدا کنید
ChameleonUltra در یک آزمایشگاه RFID و NFC می‌تواند برای مطالعه رفتار کارت و تعامل آن با خوانشگر به کار رود. با این حال کارت تنها یک جزء سامانه است. خوانشگر، نرم‌افزار تصمیم‌گیر و پایگاه داده پشت آن نیز در نتیجه نقش دارند. اگر یک خوانشگر آزمایشی شناسه‌ای را نمایش دهد، این به تنهایی نشان نمی‌دهد سامانه‌ای دیگر همان رفتار یا همان تصمیم دسترسی را خواهد داشت. برای آزمایش معتبر، مرز هر جزء و داده‌ای که میان آنها رد می‌شود را مشخص کنید.
هدف مناسب برای شروع، مقایسه رفتار یک برچسب آموزشی با نمونه شبیه‌سازی‌شده در یک خوانشگر متعلق به آزمایشگاه است. در این تمرین، هیچ دارایی واقعی یا حساب کاربر نباید به نتیجه وابسته باشد. نام و نوع برچسب، نسخه نرم‌افزار دستگاه و مدل خوانشگر را ثبت کنید. سپس فقط یک ویژگی را در هر مرحله تغییر دهید. این روش کمک می‌کند اختلاف نتیجه به تنظیمات یا سازگاری مشخص نسبت داده شود، نه به ادعای کلی درباره قدرت ابزار.
شناسه، حافظه و احراز هویت سه مفهوم متفاوت‌اند
شناسه‌ای که در آغاز تعامل دیده می‌شود لزوماً همان داده کاربردی کارت نیست. حافظه ممکن است بخش‌بندی، مجوز یا ساختار خاص داشته باشد و بعضی عملیات به احراز هویت نیاز داشته باشند. خواندن شناسه به معنی خواندن همه محتوا یا داشتن مجوز تغییر آن نیست. در آموزش، این سه مفهوم را با کارت‌های آزمایشی دارای مستندات روشن توضیح دهید. اگر تنها شناسه در دسترس است، همان را گزارش کنید و درباره محتوای دیده‌نشده نتیجه‌گیری نکنید.
یک پروژه ساده حضور و غیاب آزمایشگاهی که فقط شناسه را مقایسه می‌کند می‌تواند برای فهم ورودی و خروجی مناسب باشد. اما محدودیت امنیتی آن باید صریح باشد. در محصول واقعی، تصمیم درباره اعتماد به کارت باید بر اساس فناوری، پروتکل و مدل تهدید انجام شود. ابزار پژوهشی می‌تواند ضعف یک فرض را نشان دهد، ولی جای طراحی درست احراز هویت را نمی‌گیرد. گزارش باید بگوید کدام فرض بررسی شده است، نه اینکه همه سامانه‌های بدون تماس یکسان‌اند.
آماده‌سازی مجموعه کارت آموزشی
چند برچسب با نوع معلوم و داده غیرحساس تهیه کنید و برای هر کدام برگه مشخصات ساده بنویسید. نام‌گذاری باید مستقل از داده واقعی افراد باشد. یک نمونه را فقط برای خواندن نگه دارید و نمونه دیگری را برای آزمایش نوشتن یا تغییر اختصاص دهید. این تفکیک باعث می‌شود یک تغییر ناخواسته، مرجع مقایسه را از بین نبرد. قبل از هر عملیات تغییردهنده، وضعیت فعلی و امکان بازگشت را طبق مستندات همان نوع برچسب بررسی کنید.
کارت‌های مختلف ممکن است محدودیت‌های متفاوتی برای نوشتن، قفل شدن یا سازگاری داشته باشند. ظاهر و اندازه یکسان دلیل رفتار یکسان نیست. از نتیجه یک نمونه به همه کارت‌های یک نام بازاری تعمیم ندهید. اگر مشخصات دقیق معلوم نیست، این عدم قطعیت را در یادداشت ثبت کنید. برای کار آموزشی، انتخاب نمونه‌ای با مستندات روشن بهتر از صرف زمان روی کارت ناشناخته است، زیرا می‌توانید مشاهده را با انتظار معتبر مقایسه کنید.
نقش Firmware و Client
نرم‌افزار روی دستگاه و برنامه کلاینت با هم یک جریان کاری می‌سازند. ناسازگاری نسخه‌ها می‌تواند به نبود فرمان، تفسیر متفاوت داده یا خطای ارتباط منجر شود. پیش از آزمایش، نسخه هر دو را ثبت کنید و از دستورالعمل رسمی پروژه برای ترکیب پشتیبانی‌شده استفاده کنید. مخزن متن‌باز علاوه بر کد، محل مناسبی برای بررسی تغییرات و محدودیت‌های شناخته‌شده است. با این حال وجود یک تغییر در شاخه توسعه به معنی حضور آن در نسخه نصب‌شده شما نیست.
به‌روزرسانی را بخشی از آزمایش کنترل‌شده بدانید. ابتدا یک سناریوی ساده شناخته‌شده را روی نسخه فعلی ثبت کنید، سپس نسخه را تغییر دهید و همان سناریو را تکرار کنید. اگر نتیجه عوض شد، تنظیمات، داده و سخت‌افزار را ثابت نگه دارید تا نسبت دادن علت ممکن باشد. نصب چند تغییر هم‌زمان بررسی را دشوار می‌کند. همچنین از داده آزمایش مهم طبق روش پشتیبانی‌شده نسخه نگه دارید تا به‌روزرسانی یا بازنشانی، کار قبلی را غیرقابل بازسازی نکند.
خوانشگر بخشی از آزمایش است
دو خوانشگر ممکن است یک کارت را با زمان‌بندی یا رابط نرم‌افزاری متفاوت ارائه کنند. یکی تنها شناسه را به برنامه بدهد و دیگری اطلاعات بیشتری نشان دهد. بنابراین نتیجه باید همراه مدل خوانشگر و نرم‌افزار میزبان ثبت شود. اگر شبیه‌سازی روی یک خوانشگر کار می‌کند و روی دیگری نه، ابتدا تفاوت قابلیت و انتظار آنها را بررسی کنید. این اختلاف لزوماً به معنی خراب بودن دستگاه یا نادرست بودن همه داده ذخیره‌شده نیست.
در آزمایشگاه، یک خوانشگر مرجع با رفتار شناخته‌شده داشته باشید. پیش از سنجش نمونه تازه، کارت سالم مرجع را روی آن امتحان کنید. اگر همان هم شکست خورد، مشکل ممکن است از تغذیه، اتصال یا نرم‌افزار خوانشگر باشد. این کنترل ساده مانع می‌شود ساعت‌ها تنظیم کارت را برای خطایی در طرف مقابل تغییر دهید. پس از هر تغییر عمده، کنترل مرجع را تکرار کنید تا سلامت مسیر اندازه‌گیری روشن بماند.
شرایط فیزیکی و تکرارپذیری
فاصله و جهت قرارگیری می‌توانند بر ارتباط بدون تماس اثر بگذارند. برای مقایسه، موقعیت دستگاه و کارت را تا حد امکان ثابت نگه دارید. وجود فلز، چند کارت روی هم یا منبع اختلال نزدیک می‌تواند نتیجه را تغییر دهد. در شروع، محیط ساده و فاصله کوتاه انتخاب کنید. اگر ارتباط ناپایدار است، قبل از تحلیل پیچیده پروتکل، همین عوامل فیزیکی را بررسی کنید. یک نتیجه پایدار در شرایط کنترل‌شده مبنای بهتری برای مراحل بعدی است.
تعداد تلاش‌های موفق و ناموفق را ثبت کنید. یک موفقیت منفرد در میان چند شکست، شاهد پایداری نیست. همچنین مشخص کنید میان تلاش‌ها چه چیزی بازنشانی شده است: دستگاه، خوانشگر یا برنامه میزبان. بعضی رفتارها به وضعیت باقی‌مانده از تعامل قبلی وابسته‌اند. اگر این وضعیت کنترل نشود، نتیجه به ظاهر تصادفی می‌شود. آزمایش خوب باید به همکار دیگری اجازه دهد با همان شرایط به رفتار مشابه برسد، حتی اگر هدفش فقط مشاهده یک محدودیت باشد.
شبیه‌سازی به معنی برابری کامل نیست
یک نمونه شبیه‌سازی‌شده ممکن است بخش‌هایی از رفتار یک کارت را بازنمایی کند، اما همه ویژگی‌های فیزیکی و پروتکلی را تضمین نمی‌کند. برای هر آزمایش، تعریف کنید چه چیزی باید برابر باشد: شناسه، پاسخ یک فرمان یا ساختار داده مشخص. اگر این معیار روشن نباشد، واژه «کار می‌کند» بیش‌ازحد مبهم است. ممکن است نمایش شناسه موفق باشد ولی برنامه کاربردی به دلیل تفاوت دیگری نتیجه را نپذیرد. گزارش باید این مرز را حفظ کند.
در طراحی محصول، چنین آزمایشی می‌تواند نشان دهد کدام بخش تصمیم بیش‌ازحد به داده قابل مشاهده تکیه دارد. اما اصلاح باید در سامانه واقعی و با در نظر گرفتن همه اجزا انجام شود. تغییر یک شناسه یا پنهان کردن قالب، لزوماً احراز هویت قوی ایجاد نمی‌کند. تیم باید نیاز امنیتی و قابلیت فناوری انتخاب‌شده را تطبیق دهد. ابزار پژوهش برای آزمودن فرض‌هاست؛ نتیجه آن باید به تصمیم طراحی قابل توضیح منجر شود.
نگهداری فایل و گزارش پژوهش
فایل‌های کارت می‌توانند اطلاعاتی داشته باشند که به یک سامانه یا فرد مربوط است. در آزمایش آموزشی، از داده ساختگی استفاده کنید و فایل‌ها را با شناسه آزمایش نام‌گذاری کنید. برای اشتراک نتیجه، فقط بخش لازم را نشان دهید. کل محتوای کارت یا داده سامانه واقعی را به عنوان ضمیمه عمومی منتشر نکنید. گزارش باید روش، انتظار و مشاهده را منتقل کند؛ بسیاری از این اطلاعات را می‌توان بدون انتشار داده حساس توضیح داد.
اگر چند نفر از دستگاه استفاده می‌کنند، وضعیت هر جلسه را ثبت کنید. کدام جایگاه یا پروفایل برای کدام آزمایش بوده و چه داده‌ای باید پیش از تحویل پاک شود؟ این کار جلوی استفاده ناخواسته از نمونه جلسه قبل را می‌گیرد. همچنین مشخص کنید چه کسی مسئول نگهداری نسخه نرم‌افزار و تجهیزات مرجع است. آزمایشگاه بدون مدیریت وضعیت، ممکن است نتیجه‌های متناقض تولید کند که از خود فناوری ناشی نیستند، بلکه از تفاوت تنظیمات باقی‌مانده‌اند.
عیب‌یابی بر اساس مرحله شکست
اگر کلاینت دستگاه را نمی‌بیند، ابتدا اتصال و سازگاری نرم‌افزار را بررسی کنید؛ این مسئله هنوز درباره کارت نیست. اگر دستگاه دیده می‌شود ولی کارت تشخیص داده نمی‌شود، نوع فناوری و شرایط فیزیکی مطرح‌اند. اگر کارت دیده می‌شود ولی یک عملیات خاص شکست می‌خورد، قابلیت آن عملیات و وضعیت داده را بررسی کنید. این ترتیب از تغییر بی‌هدف همه تنظیمات جلوگیری می‌کند و گزارش را برای دریافت کمک از جامعه پروژه قابل استفاده‌تر می‌سازد.
برای گزارش اشکال عمومی، یک نمونه حداقلی با داده ساختگی بسازید. نسخه‌ها، انتظار، نتیجه و مراحل کمینه را بنویسید و اطلاعات اختصاصی سامانه را حذف کنید. پیش از گزارش، مستندات و موارد شناخته‌شده را بررسی کنید تا محدودیت اعلام‌شده با اشکال تازه اشتباه نشود. اگر علت هنوز معلوم نیست، آن را به عنوان فرضیه بیان کنید. نتیجه‌گیری قطعی از یک آزمایش ناموفق می‌تواند مسیر بررسی را منحرف کند و دیگران را به راه‌حل نادرست برساند.
انتخاب این ابزار برای یک نیاز مشخص
اگر کار شما روی کارت و تعامل با خوانشگر متمرکز است، قابلیت‌های تخصصی و متن‌باز بودن پروژه می‌تواند برای یادگیری و توسعه مفید باشد. اگر نیاز اصلی تحلیل گسترده رادیویی، اندازه‌گیری سیگنال یا رابط‌های متنوع سخت‌افزاری است، ممکن است ابزار دیگری لازم باشد. پیش از خرید یا توسعه افزونه، سه خروجی مشخص تعریف کنید و آنها را با مستندات نسخه فعلی مقایسه کنید. نام و محبوبیت ابزار جای این تطبیق را نمی‌گیرد.
ارزیابی نهایی باید شامل یک آزمایش موفق، یک محدودیت شناخته‌شده و یک سناریوی بازیابی وضعیت باشد. این سه مورد نشان می‌دهند تیم فقط مسیر نمایشی را ندیده است. نتیجه خوب می‌تواند این باشد که ابزار برای بخشی از نیاز مناسب است و برای بخش دیگر باید از تجهیزات مکمل استفاده شود. چنین جمع‌بندی دقیقی از ادعای کلی درباره پشتیبانی همه کارت‌ها مفیدتر است و مبنای سالم‌تری برای برنامه پژوهش بعدی فراهم می‌کند.
