صد رازِ نهان

یک شمع، با روشن کردن شمعی دیگر چیزی از دست نمی‌دهد!

۱۷ مطلب در مهر ۱۳۹۴ ثبت شده است

رمزنگاری/5-الگوریتم های Caesar و Enigma (سِزار و اِنیگما)

قسمت قبلی: معیارهای امنیت

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


الگوریتم سزار:

"باب" جلسه ای دو نفره و محرمانه با "آلیس" تشکیل داد و با او در مورد نحوه‌ی ارسال نامه ها مشورت کرد. چیزی که در ابتدا باب می‌خواست این بود که هیچ کسی جز آلیس قادر به فهمیدن محتوای نامه و دستورات نباشد. در این جلسه تصمیم باب و آلیس بر این شد که در متن نامه به جای هر حرف، حرف سه جایگاه قبل تر را جایگزین کنند. به این صورت که به جای A حرف X، به جای B حرف Y و ... 



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

[پایان داستان باب و آلیس!!!/به علت زیاد بودن مطالب]


شکل: نسبت تکرار حروف مختلف در یک متن انگلیسی

نکته: در دنیای رمزنگاری، الگوریتم فوق به نام الگوریتم سزار معروف است، زیرا برای اولین بار ژولیوس سزار پادشاه رومی برای ارتباط با فرماندهانش استفاده شد. از نام های دیگر آن می‌توان به Shift Cipher، Caesar Code و Caesar shift اشاره کرد.


ماشین Enigma:

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



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


قسمت بعدی: بررسی تقسیم بندی الگوریتم‌های رمزنگاری


دیدار تو گر صبح ابد هم دَهَدَم دست
من سرخوشم از لذتِِ این چشم به راهی ...
#فریدون_مشیری
۲۷ مهر ۹۴ ، ۱۸:۵۳ ۱ نظر موافقین ۰ مخالفین ۰
ابراهیم قاسمی

جاواکارت-مقدماتی/6-نسخه‌های جاواکارت و اصطلاحات

قسمت قبلی:  ابزارهای مورد نیازقسمت قبلی:  ابزارهای مورد نیاز

در پست قبلی اشاره کردیم که انتخاب ابزار کار مورد نیاز (Eclipse یا Netbeans) ارتباط نزدیکی با نسخه‌ی جاواکارت مد نظر ما برای برنامه‌نویسی دارد. در این پست، علت ایجاد نسخه‌های مختلف جاواکارت را بیان کرده و تفاوت های آن‌ها را به صورت مختصر با یکدیگر بررسی می‌کنیم. 


نسخه‌های جاواکارت:

همانطور که پیش‌تر اشاره شد، مستندات استاندارد JavaCard در دهه‌ی 1990 میلادی توسط موسسه‌ی Sun [که بعدها به Oracle واگذار شد] برای سهولت برنامه‌نویسی کارت های هوشمند و همچنین ایجاد قابلیت Portability (نصب اپلت نوشت شده برای کارت های تولید سازنده‌ی A، روی کارت‌های تولید شده توسط سازنده‌ی B، بدون ایجاد تغییر و مواجه شدن با خطا) ارائه شد. در آن زمان، موسسه‌ی Sun/Oracle برای این که بتوانند یک استاندارد قابل پیاده‌سازی ارائه دهند، باید توانایی مدارات الکترونیکی آن زمان را در نظر می‌گرفتند و با توجه به آن، قابلیت های ضروری را در استاندارد خود قرار می‌دادند. پس از گذشت چند سال از ارائه‌ی نسخه‌ی اولیه‌ی استاندارد JavaCard، با پیشرفت علم الکترونیک، توانایی بردهای الکترونیکی از قبیل ظرفیت حافظه‌های مختلف مانا و گذرا در همان مقیاس قبلی، و توانایی پردازنده برای انجام پردازش در همان زمان قبلی، افزایش چشم گیری یافت و با توجه به آن، استانداردهای Javacard 2.1.1، Javacard 2.1.2، Javacard 2.2.1 و در نهایت  Javacard 2.2.2 در پی یکدیگر با حفظ کلیّت استاندارد نسخه‌ی قبلی و صرفا با افزودن یک سری قابلیت و توانایی جدید نسبت به نسخه‌ی پیشین خود، ارائه شدند (مثلا الگوریتم‌‎های رمزنگاری قوی‌تر اضافه شدند). تا اینجای کار، نفس ارتباط بین کارت و کارتخوان در تمام نسخه‌ها یکسان بود، یعنی دستورات در رشته‌هایی از اعداد هگزادسیمال به نام APDU Command به یک اپلت روی کارت ارسال می‌شدند و در پاسخ هم یک رشته از اعداد هگزادسیمال تحت عنوان APDU Response از اپلت به کاربر باز می‌گشت.

اما، در سال‌های اخیر با توجه به رشد بیشتر توانایی‌های قطعات الکترونیکی، Oracle تصمیم گرفت که این روندِ استانداردهای اپلت محورِ خود را ]که ارتباط با آن‌ها مستلزم فهمیدن عناصری به نام APDU Command و APDU Response  است[ به گونه ای جدید تغییر دهد که قابل فهم تر و مرسوم تر باشد. جایگزینی که برای شیوه‌ی ارتباطی قبلی ارائه شد، پَکِت‌های HTTP/HTTPS بودند؛ یعنی Oracle تصمیم گرفت استانداردی معرفی کند که کارت‌های منطبق با آن، عملا به یک WebServer  تبدیل شوند و از طریق پکت‌های HTTP/HTTPS با دنیای خارج ارتباط برقرار کنند. از آنجا که این نسخه از استانداردها با نسخه‌های پیشین تفاوت چشم‌گیری داشتند، شماره گذاری آنها را از 3.0.1 آغاز کرد و اولین نسخه‌ی آن را Javacard Platform 3.0.1 Connected Edition  نامید.


اما Connected Edition  به چه معناست؟

پاسخ: از آنجا قرار بر این نبود که با ظهور این نوع کارت‌های جدید، Oracle روند توسعه‌ی استاندارد کارت‌های قبلی را تعطیل کند، پس تصمیم گرفت که برای هر دو نوع کارت استانداردهای جداگانه‌ای به صورت موازی توسعه دهد و ارائه کند؛ و برای این که بتوان آن‌ها را از هم تشخیص داد، دو واژه ی Connected Edition و Classic Edition را استفاده کرد. Connected Edition  استاندارد مربوط به کارت‌هایی است که قابلیت تبدیل شدن به Web Server  و ارتباط HTTP/HTTPS را دارند و Classic Edition  استاندارد کارت‌هایی است که در ادامه‌ی روند توسعه ی  استاندارد Javacard 2.2.2 ارائه شده اند.

لازم به ذکر است که استانداردهای مختلف جاواکارت Backward Compatible  هستند. بدین معنا که، اپلت هایی که برای یک نسخه نوشته شده اند، روی کارت‌های همان نسخه و نسخه‌های بالاتر نصب می‌شوند.


اصطلاحات این حوزه:

ATR یا Answer To Reset:

در بخش استانداردها گفتیم که ویژگی‌های الکتریکی خط ارتباطی کارت‌های تماسی و کارتخوان مربوطه در جلد سومِ استاندارد ISO/IEC 7816 تعریف شده اند. این استاندارد برای تولیدکنندگان کارت‌های هوشمند آزادی عمل زیادی در نظر گرفته است. به عنوان مثال، سه سطح ولتاژ مختلف 1.8 ولت، 3 ولت و 5 ولت را به عنوان ولتاژهای معتبر کارکردی کارت در نظر گرفته است و به تولید کننده اجازه داده است که یکی از این موارد یا یک زیرمجموعه از آن را برای کارت خود استفاده کند. همچنین به سازنده اجازه داده است که پروتکل ارتباطی را T=0 یا T=1 یا هر دو انتخاب کند و قسّ علی هذا! در مقابل هنگام آغاز ارتباط کارتخوان و کارت، کارت باید به نحوی کارتخوان را از این انتخاب‌های خود آگاه کند. آنچه که این اطلاعات را در بر دارد ATR نامیده می‌شود. و عملکرد آن به این صورت است که بلافاصله پس از اتصال کارت به کارتخوان (به عبارت دیگر، بلافاصله پس از اتصال خطوط تغذیه‌ی کارت) یک رشته از اعداد که حاوی این اطلاعات است، از کارت به کارتخوان ارسال می‌شود. لازم به ذکر است که ارسال ATR از کارت به کارتخوان می‌تواند با خروج و ورود کارت از/به کارتخوان انجام شود که در این صورت Cold Reset ATR نامیده می‌شود و یا می‌تواند با ارسال دستور RESET از رایانه به کارت‌خوان انجام شود که در این صورت Warm Reset ATR نامیده می‌شود. مقادیر این دو ATR می‌تواند یکسان و یا متفاوت از باشد. هر چند که ATR یک جزء اجباری برای کارت است که باید حتما توسط سازنده به فرمت خاصی پیاده سازی شود، اما یک بخش Optional در آن وجود دارد که Historical Bytes نامیده می‌شود. سازنده می‌تواند در این بخش اطلاعاتی از خود یا کارت به صورت دلخواه قرار دهد. 

ATS یا Answer To Reset:

تقریبا مشابه ATR است، با این تفاوت که خاصِ کارت‌های غیر تماسی است و در استاندارد ISO/IEC 14443 فرمت و مقادیر آن تعریف شده است.

SD یا Security Domain و CM یا Card Manager:

همانطور که پیش‌تر در بخش ساده سازی ذکر کرده بودیم، کارت‌های هوشمند، در هنگام تولید در کارخانه، به صورت پیش‌فرض همراه با یک اپلت نصب شده ارائه‌ می‌شوند و این اپلت مسئولیت کارهای مدیریتی کارت از قبیل احراز هویت، نصب و حذف اپلت‌های دیگر، تغییر کلیدهای امنیتی کارت، حفظ امنیت کارت و ... را به عهده دارد. اپلت مذکور در بعضی موارد SD و در بعضی موارد CM نامیده می‌شود. 

AID یا Application Identifier:

همانطور که فایل‌ها و دایرکتوری های روی کامپیوتر دارای یک نام هستند که متشکل از حروف و اعداد و کاراکترهای خاص است، اپلت‌ها و پکیج‌های روی کارت هم دارای یک نام می‌باشند که تنها شامل اعداد است. طول این عدد باید بین 5 تا 16 بایت باشد. یعنی این که ما برای پکیج یک AID پنج تا شانزده بایتی و برای هرکدام از اپلت یا اپلت‌های درون آن نیز یک AID پنج تا شانزده بایتی خواهیم داشت. (همه‎ی اپلت‌هایی که می‌نویسیم و روی کارت بارگذاری و نصب می‌کنیم، درون یک پکیج خاص آن اپلت قرار می‌گیرند- بعدها این موضوع روشن تر خواهد شد). لازم به ذکر است که نام همه‌ی پکیج‌ها و اپلت‌های روی یک کارت باید منحصر به فرد باشد. همچنین بد نیست بدانیم که چنانچه یک برنامه نویس/شرکت بخواهد اپلت‌هایی بنویسد که به صورت بین المللی استفاده شوند، باید در مورد AID پکیج‌ها و اپلت‌هایش قوانینی را رعایت کند که با پکیج‌ها و اپلت‌های دیگر شرکت‌ها تداخل نداشت باشند (دارای AID یکسان نباشند). قوانین مزبور به این صورت است که توسط سازمان ISO یک رشته‌ی 5 بایتی منحصربفرد به آن شرکت اختصاص داده می‌شود و این شرکت موظف است که AID پکیج‌ها و اپلت‌های خود را با این 5 بایت آغاز کند.

RID یا Registered application provider Identifier و PIX یا  Proprietary Identifier eXtention:

گفتیم که هر اپلت یا پکیج روی کارت دارای یک شناسه‌ی حداقل 5 بایتی و حداکثر 16 بایتی منحصربفرد است. و گفتیم چنانچه شرکتی بخواهد یک اپلت با استفاده‌ی بین المللی بنویسد، باید از سازمان ISO یک رشته‌ی 5 بایتی منحصر به خود درخواست کند. آن حداقل 5 بایت ابتدای AID که همین 5 بایت دریافتی از ISO است را RID و آن 11 بایت Optional را PIX می‌نامند. بنابراین:

AID = RID [+ PIX ] 

* از آنجا که ما [فعلا] برنامه‌ای برای نوشتن اپلت‌های جهانی نداریم، در اپلت‌های خود، AID را کاملا دلخواه انتخاب خواهیم کرد.

APDU یا Application Protocol Data Unit:

در یک شبکه‌ی کامپیوتر، داده ها برای انتقال از یک رایانه به یک رایانه‌ی دیگر، با فرمت خاصی، در بسته هایی با نام Packet و سپس Frame قرار می‌گیرند و ارسال می‌شوند. در ارتباط بین یک کارت و کارتخوان هم دستوراتی/داده‌هایی که از کارتخوان به کارت ارسال می‌شوند و همچنین پاسخ‌ها/داده‌هایی که از کارت به کارتخوان ارسال می‌شوند، با فرمت مخصوصی در بسته‌هایی با عنوان APDU تبادل می‌شوند. آنچه از کارتخوان به کارت ارسال می‌شود APDU Command و آنچه از کارت به کارتخوان ارسال می‌شود APDU Response نامیده می‌شود. APDU Command با توجه به آنچه که قرار است در بر داشته باشد به چهار نوع مختلف تقسیم بندی می‌شود که Case 1 تا  Case 4 نامگذاری شده اند. APDU Response هم شامل یک بخش اجباری دو بایتی به نام Status Word و یک بخش Data با طول نامحدود است. در پست‌های بعدی به صورت جزئی تر با این ساختار آشنا خواهیم شد.


قسمت بعدی: کدنویسی JavaCard در محیط Netbeans


داره بارون میاد ...
۲۵ مهر ۹۴ ، ۲۱:۰۲ ۱ نظر موافقین ۱ مخالفین ۰
ابراهیم قاسمی

رمزنگاری/4-معیارهای امنیت

قسمت قبلی: مشکلات مربوط به Encoding

تا پیش از این با Hash کردن و Encoding و Decoding آشنا شدیم و دانستیم که Hashing استفاده از تابعی است که یک طرفه می‌باشد و پس از Hash کردن داده ها قابلیت بازیابی مجدد آن‌ها را نداریم، و در مقابل دانستیم که Encoding و Decoding تابع هایی دو طرفه برای تغییر Form داده ها هستند؛ که برای استفاده از آن‌ها نیاز به چیزی تحت عنوان کلید یا رمز نیست و هر فردی که از الگوریتم مطلع باشد می‌تواند داده های Encode شده را با استفاده از تابع Decode به داده های اصلی تبدیل کند.(لازم به ذکر است که ماهیت Public بودن قریب به اتفاق الگوریتم های Encoding/Decoding باعث می‌شود همه بتوانند از آن‌ها استفاده کنند).


معیارهای امنیت:

 در این قسمت ابتدا یک سناریو تعریف می‌کنیم و سپس بر اساس آن، علت نیاز به الگوریتم‌هایی فراتر از الگوریتم‌های Hash و Encoding/Decoding را متوجه خواهیم شد و در خلال قسمت های بعدی روند توسعه‌ی این الگوریتم‌های مورد نیاز را توضیح می‌دهیم.

در این سناریو شما فرمانده ی یک سپاه جنگی هستید و به سبب لزوم نظارت بر اتفاقات خط نبردِ نیروهایتان و نیز مدیریت کارهای مملکتی، ناچارید که مدام بین میدان کارزار و مقرّ فرماندهی آمد و شد کنید(بگذارید حداقل در این داستان سناریو را طوری تعریف کنیم که گویا نعلین فرماندهان نیز گَرد خطوط نبرد را به شیارهای خود دیده است!). بنابرین شما نیاز دارید که گاهی از این مقر، به یکی از سربازان عالی‌رتبه‌ی خود که وِی را به عنوان جانشین بر مسند فرماندهی گمارده‌اید نامه ای ارسال کنید و او را در جریان کارهایی که باید انجام دهد قرار دهید. همچنین، فرمانده ی مذکور، باید گزارشاتی از عملکرد خودش و اوضاع به شما ارسال کند. پیش از این که ادامه‌ی داستان را تعریف کنیم، یک نام برای شما، و یک نام برای آن افسر عالی‌رتبه انتخاب می‌کنیم. نام شما Bob است، و نام آن افسر Alice (چرا تعجب کردید؟ یک افسر عالی‌رتبه نمی‌تواند خانم باشد؟).


سوال: چرا Bob و چرا Alice؟ 

پاسخ: آلیس و باب در واقع دو عضو از یک خانواده‌ی بزرگ هستند تحت عنوان خانواده‌ی کاراکترهای رمزنگاری! به صورت واضح تر، در سال 1978 یکی از اساتید دانشگاه MIT به نام رونالد ریوست، در مقاله ای که برای ارائه‌ی الگوریتم رمزنگاری RSA آماده کرده بود، از این اسامی برای مثال‌های خود به عنوان فرستنده و گیرنده‌ی پیام استفاده کرد. بعدها در دیگر سناریوهایی که طراحی شد، این اسامی شهرت یافتند و کم کم کاراکترهای دیگری هم به جمع آن‌ها پیوستند. برای رعایت این رسم، ما نیز در سناریوی خود همین کاراکترها را به کار می‌بریم. به عنوان یک مطلب اضافه، حرف R در الگوریتم RSA، از فامیل آقای Rivest گرفته شده است. دو حرف دیگر هم از نام دو طرِاح دیگر الگوریتم آمده اند.

دکتر ریوست (نفر وسط)

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

اما بیایید پیش از آنکه اتفاقات و راهکارهایی که "باب" و "آلیس" استفاده کردند را بیان کنیم، خودمان بررسی کنیم و ببینیم که چه مسائلی باید در نظر می‌گرفتند؟ [بعدها خواهیم دید این مسائل مبنای امنیت یک خط ارتباطی را تشکیل می‌دهند]:

  1. "باب" و "آلیس" باید به نحوی در نامه هایشان، خود را به گونه‌ای به یکدیگر معرفی کنند که هر کدام هنگام دریافت نامه‌ی دیگری بتواند مطمئن شود که نامه از جانب همان شخصی آمده است که باید بیاید. حتی در صورتی که نیروهای دشمن رونوشتی را که هفته‌ی پیش در کاروان‌سرای بین راه از نامه‌ی قاصد تهیه کردند جایگزین نامه‌ی امروز قاصد کنند، دریافت کننده باید متوجه معتبر نبودن آن بشود. [بعد ها این بند را با نام Authenticity خواهید شناخت]
  2. در صورتی که نیروهای دشمن در میانه‌ی مسیر قاصد را تطمیع کردند یا به قتل رساندند و به دستوراتِ "باب" یا گزارشِ "آلیس" دست یافتند، نباید از آن چیزی متوجه شوند! [بعد ها این بند را با نام Confidentiality خواهید شناخت]
  3. در صورتی که نیروهای دشمن در کاروان سراهای میان راه کمین کردند و نامه‌ اصلیِ قاصد را دزدیدند و محتوای آن را عوض کردند یا نامه‌ی جدیدی که خودشان نوشته اند جایگزین آن کردند، دریافت کننده‌ی نامه‌ی جدید باید متوجه جعلی بودن آن بشود. [بعد ها این بند را با نام Integrity خواهید شناخت]
  4. چنانچه "باب" دستوری به آلیس فرستاد و مثلا به وی فرمانِ "حمله" داد و آلیس بعد از خواندن دستور، به خاطر ترس یا ... به آن عمل نکرد، بعدها نباید بتواند ادعا کند که نامه را دریافت نکرده است! همینطور اگر "باب" در موقیعت مشابهی، مثلا در حالت مستی، تصمیم اشتباهی گرفت و فرمانی صادر کرد و به آلیس فرستاد و اجرای آن تصمیمِ اشتباه منجر به اتفاق بدی شد که آبروی "باب" را به خطر می‌انداخت، وی نباید قادر به این باشد که ارسال آن دستور را انکار کند. [بعد ها این بند را با نام Non-Repdiation خواهید شناخت]
  5. قاصد و اسب پر انرژی اش همیشه باید در دسترس "باب" و آلیس باشد. [بعد ها این بند را با نام Availability خواهید شناخت]
لازم به ذکر است که پیاده سازی کردن بعضی الزامات بالا ممکن است به پیاده سازی مورد دیگر نیز منجر شود. یعنی این که، موارد بالا ارتباط تنگاتنگی با یکدیگر دارند. در پست های بعدی با تفاوت آن‌ها آشنا خواهیم شد.


To be yourself in a world that is constantly trying to make you something else is the greatest accomplishment.
Ralph Waldo Emerson
۲۳ مهر ۹۴ ، ۰۰:۲۴ ۱ نظر موافقین ۰ مخالفین ۰
ابراهیم قاسمی

جاواکارت-مقدماتی/5-ابزارهای مورد نیاز

قسمت قبلی: من یک جاواکار نیستم!

در این قسمت، به عنوان ادامه‌ای بر مباحث پیشین، ابزارهایی که از آغاز به نوشتن یک اپلت تا نصب آن روی کارت و ارتباط با آن نیاز است را معرفی می‌کنیم. در یک دید کلّی، ابزارهای مورد نیاز به دو دسته تقسیم می‌شوند:


1- سخت افزار: 
طبیعتا برای این که کارت بتواند داده ای از سمت رایانه دریافت کند یا داده ای به آن ارسال کند، نیازمند سخت افزاری است که "کارت خوان" (Card Reader) نامیده می‌شود. نکته‌ی جالب توجه اینجاست که دستگاهی به نام "کارت نویس" (Card Writer) نداریم و همان کارتخوان هر دو عمل نوشتن و خواندن را انجام می‌دهد. بدیهتا، کارتخوان کارت‌های تماسی با کارتخوان کارت‌های غیر تماسی متفاوت است و هنگام خرید باید این را مد نظر قرار دهیم که قرار است با چه نوع کارتی کار کنیم. ACR38 و ACR122U دو نمونه کارتخوان به ترتیب برای کارت های تماسی و کارت‌های غیرتماسی اند. همچنین ممکن است هنگام خرید کارتخوان، دستگاه هایی به نام Encoder و Decoder نیز به شما پیشنهاد شوند، که هیچ نیازی به آن ندارید. در واقع، این دو دستگاه برای ارتباط با کارت‌های مغناطیسی (کارت‌های با نوار مشکی- مانند کارت‌های بانکی) استفاده می‌شوند. کارت های مغناطیسی بر خلاف کارت‌های الکترونیکی تراشه دار، برای خواندن و نوشتن به دو دستگاه متفاوت نیاز دارند. دستگاهی که برای خواندن محتویات کارت‌های مغناطیسی استفاده می‌شود Decoder و دستگاهی که برای نوشتن روی این کارت‌ها استفاده می‌شود، Encoder نام دارد. 
شایان ذکر است که الزامی برای جدا بودن کارت‌خوان کارت های تماسی و کارت‌خوان کارت های غیر تماسی از یک دیگر وجود ندارد؛ یعنی هم کارت‌خوان هایی موجود است که فقط یک واسط را پشتیبانی می‌کنند و هم کارت‌خوان هایی وجود دارند دارای دو واسط ارتباطی اند. در مورد Encoder و Decoder هم به همین صورت است؛ یعنی هم به صورت مجزا و هم به صورت یک مجموعه‌ی واحد به فروش ‌می‌رسند.

2- نرم افزار:
بحث در مورد نرم افزارهای مورد نیاز در زمینه‌ی کارت‌های هوشمند را با دو مثال متفاوت آغاز می‌کنیم:
اگر دانشجوی الکترونیک باشید، حتما تجربه‌ی کار با میکروکنترلرها را در پرونده‌ی خود خواهید داشت. برای عملی کردن یک پروژه‌ی ساده‌ی خواندن اطلاعات یک سنسور و ارسال به پورت سریال رایانه، شما به سه مجموعه نرم افزار نیاز خواهید داشت:
  1. نرم افزاری که در آن برنامه‌ی مورد نظر را بنویسید (مانند Code vision، Bascom یا AVR Studio برای میکروهای AVR).
  2. نرم افزاری که به وسیله‌ی آن فایل ساخته شده را به میکرو منتقل کنید (مانند ProgISP یا Pony Prog).
  3. نرم افزاری که به وسیله‌ی آن داده های میکرو را از پورت سریال دریافت کنید (مانند Terminal یا Hyper Terminal یا Termite).
و اگر دانشجوی نرم افزار باشید و تجربه‌ی توسعه ی یک صفحه ی وب را داشته باشید هم می‌دانید برای انجام یک پروژه ی طراحی ساده حداقل به سه دسته ابزار زیر نیاز دارید:
  1. نرم افزاری که در آن کد برنامه‌/صفحه ی خود را می‌نویسید (مانند PHP Storm یا PyCharm).
  2. نرم افزاری که به وسیله ی آن برنامه/صفحه ی نوشته شده را به Host(فضای روی اینترنت) منتقل می‌کنید (مانند Git، FileZila یا Free FTP).
  3. نرم افزاری که با صفحه وب نوشته شده ارتباط برقرار می‌کنید (مانند Chrome, FireFox)
خب، در مورد کارت هوشمند هم [که در واقع یک میکرو کنترلر است] روال به همین صورت بالاست. یعنی شما به سه مجموعه نرم افزار مختلف برای نوشتن اپلت، بارگذاری و نصب اپلت و ارتباط با اپلت نیاز دارید. و مجددا همانطور که در مثال های بالا، نرم افزارهای چند گروه می‌توانند به صورت یک Package در یک ابزار ارائه شوند، در کارت هوشمند هم این سه دسته ابزار می‌توانند در یک بسته ارائه گردند. در زیر به صورت خلاصه نرم افزارهای موجود برای هر گروه را نام می‌بریم و در خلال پست های بعدی به صورت عملی با هر کدام آشنا خواهیم شد:

نوشتن اپلت:
بارگذاری و نصب اپلت:
ارتباط با اپلت ها:
  • OpenSCTool
  • PyAPDUTool
  • Your Reader SDK Tools
  • Python library that is named "PySCard"
  • Java package that is named "javax.smartcardio" (I think it is deprecated and is not available in JDK 1.7 and newer versions)
  • C/C++ library that is named "winscard" (:-?)

نکته: شما در هر کدام از مجموعه های بالا تنها به یک ابزار نیاز دارید و بسته به این که با کدام یک ارتباط بهتری برقرار می‌کنید، در آینده یکی را انتخاب خواهید کرد. لازم به ذکر است که همانگونه که پیشتر بیان شد ابزارهایی نیز ارائه شده اند که نرم افزارهای هر سه مجموعه را در یک Package گرد آورده اند، لکن از آنجا که غالب آنها یا به خاطر تحریم یا بنا به دلایلی از قبیل داشتن مشتری های حقوقی (و نه حقیقی) و انحصاری در دسترس نیستند یا به صورت رایگان نمی‌باشند، در این مجموعه در مورد آن ها صحبتی نخواهیم کرد (احتمالا). به عنوان مثال JCOP Tools و Gemalto Developer Suite دو نرم افزاری هستند که به ترتیب توسط شرکت NXP (یکی از بزرگترین تولیدکنندگان تراشه های کارت هوشمند) و شرکت Gemalto (یکی از بزرگترین تولیدکنندگان سیم کارت‌ها) ارائه شده اند و متشکل از تعداد زیادی پلاگین اند که روی هسته ی Eclipse سوار شده اند. 

سوال: Netbeans یا Eclipse؟
جواب: هر دو! پاسخ به این سوال ارتباط زیادی با نسخه‌ی جاواکارتی که قرار است با آن کار کنید دارد. از آنجا که Eclipse به صورت پیشفرض قابلیتی برای افزودن JCDK به آن ندارد، ما ناگریز باید از یک پلاگین استفاده کنیم (Eclipse-JCDE)  و از آنجا که این پلاگین به صورت عادی تنها با نسخه‌ی JCDK 2.2.2 و با کمی ترفند با نسخه های پایین تر از این ورژن کار می‌کند، پس برای کار با کارت‌های نسخه‌ی 2.2.2 و قبل از آن، Eclipse را انتخاب می‌کنیم. در مقابل، نرم افزار Netbeans به صورت پیشفرض با نسخه‌ی JCDK 3.0.1 Classic & Connected ارائه می‌شود و چنانچه ما برنامه ی برای نوشتن روی کارت‌های نسخه‌ی 3 و  بالاتر داریم، از این محیط برنامه نویسی استفاده خواهیم کرد.


"A ship is safe in harbor, but that’s not what ships are for." | William G.T. Shedd

۲۰ مهر ۹۴ ، ۲۲:۲۸ ۰ نظر موافقین ۱ مخالفین ۰
ابراهیم قاسمی

رمزنگاری-مقدمه/3-حل مشکلات مرتبط با Encoding

قسمت قبلی: انکدینگ و دیکدینگ

طبق قرار پیشین، به عنوانِ ادامه‌ی مبحث اِنکدینگ و دیکدینگ (پیش زمینه ای بر مباحث رمزنگاری)، در این پست دو مشکلی را بررسی می‌کنیم که با احتمال زیاد تابحال حداقل یکبار با آن‌ها مواجه شده اید و با Encoding ارتباط مستقیم دارند:

مشکل اول: زیرنویس های خرچنگ قورباغه و ناخوانا

 گاها، بعد از دانلود کردن زیرنویس فارسی یک فیلم و افزودن آن به Player، به جای حروف فارسی، با تصویری مشابه زیر مواجه می‌شویم:


علت مواجه شدن با این خطوط ناخوانا، تنظیم نبودن Encoding محتوای فایل زیرنویس روی Encoding مناسب حروف فارسی است. برای رفع این مشکل چند راهکار ساده وجود دارد که در این پست با سه مورد آنها آشنا می‌شوید. 

راهکار اول: (موقتی)
نرم افزار Microsoft Office Word را باز کنید و از منوی File و سپس Open فایل زیرنویس دانلود شده را داخل آن Import کنید. بلافاصله بعد از کلیک کردن روی دکمه ی Open برای باز شدن فایل در نرم افزار Word پنجره ای مشابه زیر باز خواهد شد که باید از منوی سمت راست گزینه ی Unicode  UTF-8 را انتخاب کنید (معمولا به صورت اتوماتیک این کار انجام شده است و شما در کادر بزرگ پایین، متن فارسی را به صورت درست مشاهده می‌کنید؛ در ایصورت حتی اگر Encoding چیزی مغایر با آنچه که گفتیم بود، به آن دست نزنید) و کلید OK را بزنید:


پس از کلیک روی OK محتوای زیرنویس به صورت خوانا داخل Microsoft Word باز می‌شود. کاری که لازم است در این مرحله انجام دهید این است که از منوی File گزینه‌ی Save As را انتخاب کنید و سپس این محتوا را به صورت یک فایل با پسوند txt. ذخیره کنید. در نهایت، فایل جدید را با موس به داخل Player بکشید تا تصویری مشابه زیر داشته باشید:


راهکار دوم: (موقتی)
در این روش که مشابه روش پیشین است، به جای استفاده از نرم افزار Microsoft Word از نرم افزاری به نام ++Notepad [دانلود کنید] استفاده میکنیم.
برای این منظور، ابتدا زیرنویس را در این محیط باز می‌کنیم. در این مرحله محتویات آن را به همان صورت ناخوانا می‌بینیم. از منوی Encoding به صورت زیر، Windows-256 را انتخاب می‌کنیم تا متن فارسی به صورت خوانا ظاهر شود:


و سپس، باز از منوی File گزینه‌س Save As را انتخاب کرده و محتویات را به صورت یک فایل txt. ذخیره می‌کنیم و فایل جدید را به عنوان زیرنویس استفاده می‌کنیم.

راهکار سوم: (دائمی)
اگر دقت کرده باشید، چنانچه بخواهیم از راهکارهای بالا استفاده کنیم، برای هر زیرنویس باید یکبار مراحل را تکرار کنیم. برای این که مجبور به این روال تکراری نباشیم، می‌توان از راهکار زیر استفاده کرد. 
از منوی Start روی Control Panel کلیک کنید و سپس در پنجره ی باز شده روی  Clock, Language and Region (در ویندوز XP روی Region and Language) انتخاب کنید. در پنجره ی باز شده، ابتدا در تَبِ Format، از قسمت کشویی، Persian را انتخاب کنید و سپس به تَبِ Administrative رفته و با کلیک روی Change System Locale مجددا مشابه تصویر زیر Persian را انتخاب کرده و با زدن OK سیستم خود را Restart کنید:

از این به بعد، زیرنویس های دانلود شده، بدون مشکل ناخوانا شدن داخل Player باز می‌شوند. 

مشکل دوم: صفحات وب و ایمیل های خرچنگ قورباغه و ناخوانا

خوشبختانه منشاء این مشکل نیز همان مسئله‌ی انکدینگ است. برای رفع این مسئله چنانچه با یک ایمیل فارسی ناخانوا مواجه هستیم، می‌توانیم با Copy & Paste کردن محتوای آن در یک فایل متنی و انجام مراحل ذکر شده در راهکار اول و راهکار دوم برای زیرنویس ها، متن آن را بخوانیم؛ و چنانچه یا با یک صفحه ی وب فارسی مواجه هستیم، یا تمایلی به Copy & Paste کردن محتوای ایمیل نداریم، می‌توانیم تنظیمات Encoding مرورگر وب خود را به صورت زیر تغییر دهیم (هر بار یکی از گزینه های مشخص شده انتخاب می‌کنیم) تا نتیجه‌ی مطلوب را مشاهده کنیم:

برای مرورگر Google Chrome:


برای مرورگر Fire Fox:
Sorry, I don't like it :D use dear Google Chrome, or Google "How to change encoding in fire fox?" and follow the above steps!


Well you only need the light when it's burning low
Only miss the sun when it starts to snow
Only know you love her when you let her go ...

۱۹ مهر ۹۴ ، ۲۰:۰۳ ۱ نظر موافقین ۰ مخالفین ۰
ابراهیم قاسمی

زخم‌های روحی

انگشت اشاره‌ی دستِ راستم دیروز زخم شد! به صورت جزئی تر، دقیقا از روی شیار بین بند اول و دوم؛ موقع خرد کردن پیاز، به صورت عادیِ متمایل به "بد" بریده شد و من به خاطر دمِ دست نبودن جعبه‌ی کمک‌های پزشکی، با دستمال کاغذی و چسب برق مانع خونریزی بیشترش شدم. بعد، امروز غروب نگران شدم که نکنه اون دستمالِ کاغذی، به خاطر چند بار شستن دستم، رطوبت رو به خودش جذب کرده باشه و یه آلودگی ساده برای انگشتم مشکلی پیش بیاره! به خاطر همین نگرانی، دردِ1 تعویض کردن پانسمانش رو پذیرفتم و با بتادین اون قسمت رو ضد عفونی کردم و یه دستمال جدید جایگزین دستمال قبلی کردم. الان که طاق باز دراز کشیده بودم و از پنجره غرقِ سیاهی آسمون بودم، این فکر ذهنم رو مشغول کرد که چرا ما آدم‌ها قسمتی از تنهایی هامون رو به واکاویِ زخم‌های روحی و دلیل‌هایی که اون ها رو بوجود آوردند اختصاص نمی‌دیم؟ یعنی زخم‌های روحی -که ما قدم از قدم براشون برنمی‌داریم و بیشترین توجهی که بهشون می‌کنیم یه آهنگ و یه قدم زدن‌ِ شبانه‌است- تاثیر کمتری داخل زندگی آینده‌ی ما دارند تا زخمِ سطحی روی شیار بین بند اول و دومِ انگشتِ اشاره ی دستِ راست؟ (با در نظر گرفتن چپ دست بودن من! :دی)

1- Pain is weakness leaving the body.


بعد نوشت: به نظرم اون قدم زدن‌ها و آهنگ گوش دادن‌های بعد زخم، فقط نقش مسکّن دارند و آدمی حتما باید زمانی رو اختصاص بده به سبک و سنگین کردن اتفاقات و نقاط ضعفی که عامل اون شد ...

۱۸ مهر ۹۴ ، ۲۲:۳۳ ۰ نظر موافقین ۰ مخالفین ۰
ابراهیم قاسمی

جاواکارت-مقدماتی/4-من یک جاواکار نیستم!

قسمت قبلی: احراز هویت

در قسمت های پیشین به صورت اجمالی با تقسیم بندی کارت های الکترونیکی، استانداردهای کلی این حوزه و نحوه ی احراز هویت کارت ها آشنا شدیم. در این پست قصد داریم ابتدا به معرفی زبان‌های برنامه نویسی Cross Platform و سپس به بیان نحوه ی اجرای برنامه های جاوا و جاواکارت و مسیر پیش رو برای ساخت یک برنامه جاواکارت بپردازیم.

 

زبان‌های برنامه نویسی Cross Platform:

چنانچه از قبل آشنایی اندکی با یک زبان برنامه نویسی Cross-Platform (همان Multi Platform - همان Platform Independent) داشته باشید، باید عرض کنیم که زبان های جاوا و جاواکارت هم مانند پایتون سیاست تقریبا مشابهی را دنبال می‌کنند و جزو زبان های کراس پلتفرم به حساب می‌آیند. "کراس پلتفرم" بدین معناست که برنامه نویس فقط یکبار و برای همیشه برنامه‌ی خود را می‌نویسد و همان برنامه را بدون تغییر روی سیستم عامل‌ها و دستگاه های مختلف اجرا می‌کند. به صورت ملموس تر، برنامه نویس برنامه خود را به عنوان مثال روی سیستم عامل لینوکس می‌نویسد و یک فایل از آن می سازد، آنگاه همان فایل بدون تغییر کد، در لینوکس، ویندوز و سیستم عامل MAC اجرا می‌شود.

اما چگونه؟

در پاسخ به این سوال، ابتدا علّت این که برنامه های زبان هایی مانند C و ++C و سایر زبان های Native Platform(نقطه ی مقابل Cross Platform) باید برای هر سیستم عامل به صورت جداگانه Compile شوند را بیان می‌کنیم. علت این امر به صورت ساده این است که برنامه های نوشته شده به این زبان ها برای اجرا  روی سیستم عامل یک مرحله را طی می‌کنند و بعد به صورت مستقیم با سیستم عاملی که روی آن در حال اجرا می باشند تعامل می‌کنند و از آنجا که سیستم عامل های مختلف واسط های تعاملی و به بیان ساده تر زبان گویش تعاملی متفاوتی دارند، برنامه ای که برای گفتگو با یک سیستم عامل Compile(بخوانید "ساخته") شده است، قادر به صحبت با یک سیستم عامل دیگر نیست و باید مجددا به گونه ای که زبان سیستم عامل جدید را بفهمد Compile شوند. 


خب، در مقابل برنامه های زبان های Cross Platfrom چگونه اند؟ 

برنامه‌های این زبان‌ها به گونه‌ای می‌باشند که پس از این که برنامه نویس کد آنها را نوشت، برای اجرا شدن دو مرحله را طی می‌کنند؛ مرحله‌ی اول که توسط خود برنامه نویس انجام می‌شود، ساخت فایلی است که به عنوان ورودی موجودیتی به نام Virtual Machine استفاده می‌شود و مرحله‌ی دوم که توسط آن Virtual Machine انجام می‌شود خواندن فایل ورودی و ترجمه‌ی محتوای آن به زبان قابل فهم سیستم عامل است.

تصاویر زیر به روشنی نقش Virtual Machineرا در اجرای یک برنامه مشخص می‌کند: 

 



با توجه به تصاویر بالا، برنامه نویس‌های زبان های Cross Platform و Platform Dependent هر دو، برنامه های خود را یک بار می‌نویسند، ولیکن برنامه نویس زبان های Platform Dependent چند بار از آن فایل اجرایی می‌سازد. (در مواقع فراخوانی بعضی توابع سیستمی، هر دو گروه ناگزیر از ایجاد تغییراتی در کد برنامه ی خود نیز می باشند؛ هرچند با در نظر گرفتن بعضی نکات حین نوشتن برنامه می‌توانند، برنامه را از تغییر بی نیاز کنند.)

حال که با سیستم زبان های Cross Platform آشنا شدیم می‌توانیم علت انتخاب یک عضو از خانواده ی جاوا به عنوان زبان برنامه نویسی کارت های هوشند را بیان کنیم.


تاثیرات انتخاب جاواکارت به عنوان زبان برنامه نویسی کارت های هوشمند:

پیش از ارائه‌ی جاواکارت توسط شرکت Sun، تولیدکنندگان مختلف کارت های هوشمند هر کدام به صورت سلیقه ای استانداردی ارائه کرده بودند که منحصرا در اختیار افراد خاصی قرار می‌گرفت و برای یک برنامه نویس عادی، اولا در دسترسی نبود، و ثانیا به خاطر تعدد استانداردها یادگرفتن آن ها قابل پذیرش نبود. علاوه بر آن برنامه هایی که برای یک نوع کارت نوشته می‌شد، در صورت تمایل به ارتقای کارت یا تعویض کارت، دیگر قابل استفاده نبود و در اصطلاح Portability کافی نداشتند. با ظهور جاواکارت و پذیرش سازندگان مختلف به استفاده از این استاندارد و قرار دادن ماشین مجازی جاواکارت در کارت های خود، همه ی مشکلات فوق از بین رفتند و راه برای توسعه دهندگان نرم افزارهای کارت های جاواکارت یا همان توسعه دهندگان Appletها هموار شد. 


و اما:

قسمت 4: من یک جاواکار نیستم!

به عنوان یک مقدمه، روند نوشتن یک برنامه‌ی جاوا و سپس روند نوشتن یک برنامه‌ی جاواکارت را توضیح می‌دهیم، و از آن پس از شما انتظار می‌رود در خلال این مجموعه آموزش ها، به صورت Self-Study جاوا را بیاموزید.

برای نوشتن یک برنامه ی جاوا شما به یک IDE (= محیط برنامه نویسی =  Integrated Development Environment) مانند Eclipse یا Netbeans یا IntelliJ یا ... و همچنین به Java Development Kit نیاز دارید. 

سوال: Java Development Kit یا JDK چیست؟

جواب: گفتیم در زبان های برنامه نویسی Cross Platform یک ماشین مجازی وجود دارد که برنامه را از کاربر دریافت می کند و برای سیستم عامل ترجمه می‌کند. به صورت پیشفرض روی یک سیستم عامل نه آن Virtual Machine وجود دارد و نه ابزارهای لازم برای ساخت فایل ورودی آن ماشین مجازی. پس برنامه نویس باید هر دو دسته ابزار را به کامپیوتر خود اضافه کند. مجموعه ی ابزارهای مورد نیاز برای ساخت فایل و همچنین اجرای فایل های زبان جاوا، در یک مجموعه جمع آوری شده اند و نام آن مجموعه Java Development Kit است. شما می توانید با مراجعه به سایت Oracle این بسته را دانلود کنید(نیاز به فــــــــــیل‌ترشکن :دی). هنگام مراجعه به این سایت در کنار نسخه های مختلف JDK به بسته هایی با نام JRE نیز بر‌خواهید خورد. JRE یا Java Runtime Environment در واقع تنها قسمت دوم ماجرا می باشند! یعنی ابزارهای مورد نیاز برای اجرای فایل های جاوا! به بیان ساده تر JRE شامل JVM و یک سری ابزارهای خردِ دیگر است و به کاربران تنها اجازه ی اجرای فایل های جاوا را می‌دهد. برای درک نسبت JVM و JRE و JDK تصویر زیر را مشاهده کنید:


خیلی خب، پس از دانلود JDK و افزودن آن به IDE خود (IDEهای جدید به صورت خودکار این کار را برای شما انجام می‌دهند) شروع به برنامه نویسی می‌کنید. برنامه ای که نوشتید توسط IDE در ابتدا درون یک فایل با پسوند java. قرار می‌گیرد، و سپس با کلیک کردن روی یک دکمه، به صورت اتوماتیک به فایل class. و سپس به jar. تبدیل می‌شود و این فایل jar. فایلی است که هنگام کلیک شدن روی آن توسط کاربر، سیستم عامل آن را  به عنوان ورودی به JVM ارسال می‌کند.


سوال: روند نوشتن یک برنامه ی "جاواکارت" چگونه است؟

جواب: روند تقریبا مشابهی برای نوشتن برنامه های جاواکارت (یا همان اپلت ها) طی می‌شود. همانگونه که برای نوشتن یک برنامه ی جاوا به JDK نیاز داشتیم، برای نوشتن یه برنامه‌ی جاواکارت هم به JCDK یا همان Java Card Development Kit نیاز داریم (علاوه بر JDK). پس با مراجعه ی مجدد به سایت Oracle یک نسخه از JCDK را دانلود می‌کنیم. در حین انتخاب نسخه ی دلخواهمان باید این را در نظر داشته باشیم که برنامه های ساخته شده با یک ورژن، تنها روی کارت هایی که آن نسخه را پشتیبانی می‌کنند یا کارت هایی که نسخه های بالاتر را پشتیبانی می‌کنند قابل اجرا است.(جمله دوم معادل کلمه ی Backward Compatible می باشد. یعنی یک نسخه، برنامه های نسخه های قبلی را نیز اجرا می کند). پس از دانلود باید محتویات فایل فشرده را Extract کنیم و مسیر آن ها را به IDE  خود بدهیم. بعدتر خواهیم دید که Eclipse به صورت پیشفرض جایی برای دریافت آدرس JCDK ندارد. و بعدتر-تر خواهیم دید که با افزودن یک پلاگین به آن می‌توانیم این قابلیت را به آن اضافه کنیم. بعدتر ها باز خواهیم دید که:

  • پلاگین مذکور به صورت عادی فقط برای JCDK 2.2.2 طراحی شده است.
  • می‌توانیم با یک ترفند نسخه های قدیمی تر یعنی JCDK 2.2.1، JCDK 2.1.2 و JCDK 2.1.1 را نیز به کمک این Plugin استفاده کنیم.
  • نسخه های جدید نرم افزار Netbeans به صورت پیشفرض به JCDK 3.0.1 مجهز شده اند.
خب، بعد از مجهز شدن IDE دلخواه خود به نسخه ی JCDK مورد نظرمان، نوبت به برنامه نویسی می‌رسد. پس از نوشتن یک اپلت (که در پست های بعدی قدم به قدم آن را توضیح می‌دهیم) IDE مشابه قبل یک فایل java. تولید می‌کند که با چند کلیک این فایل ابتدا به class. و سپس به cap. (به جای jar.)  تبدیل می‌شود. تبدیل فایل java. به فایل class. را ابزارهای جاوا و تبدیل فایل class. به cap. را یکی از ابزارهای جاواکارت به نام Converter انجام می‌دهند. فایل cap. تولید شده، فایلی است که ما روی کارت بارگذاری و نصب می‌کنیم. در آینده به صورت جزئی تر با نقش Converter و سایر ابزارها آشنا خواهیم شد.


کوچ تا چند؟ مگر می‌شود از خویش گریخت؟
بال تنها غم غربت به پرستوها داد ....
۱۷ مهر ۹۴ ، ۱۸:۱۱ ۱ نظر موافقین ۰ مخالفین ۰
ابراهیم قاسمی

درخواست‌های HTTP

در این مطلب تا جایی که دانشم کفاف می‌دهد درباره‌ی درخواست‌های HTTP صحبت می‌کنم.

در قسمتِ «شروع سریع» از پستِ «هدف‌گذاری و یک شروع در حوزه‌ی بات‌ها!»، راه‌اندازیِ پراکسی‌سرورِ واسطِ BurpSuite را شرح دادم؛ در نتیجه برای شروعِ کار با شنودگرِ BurpSuite، شاید لازم باشد آن قسمت را مطالعه کنید.

ادامه مطلب...
۱۷ مهر ۹۴ ، ۱۳:۳۷ ۳ نظر موافقین ۱ مخالفین ۰

هدف‌گذاری و یک شروع در حوزه‌ی بات‌ها!

برای ادامه‌ی کار ترجیح می‌دهم ابتدا مشخص کنیم که قرار است چه کنیم؛ زیرا معتقدم اگر هدف از ابتدا مشخص باشد، حاشیه‌پردازی و یادگیریِ اضافات رخ نخواهد داد و ما صرفاً مواردی را خواهیم آموخت که برای انجامِ آن هدف نیاز است.

ما در این سلسله‌مطالب، از سایتِ «دیوار»، که یک پایگاه برای ارسالِ آگهی‌های آنلاین است استفاده خواهیم کرد.
دلیلِ این‌که از دیوار استفاده می‌کنیم؛ پتانسیلِ بالای این سایت است؛ این پتانسیلِ بالا به سببِ آن تولید شده است که APIهای مورد استفاده برای ارسالِ درخواست‌ها به خوبی طراحی شده‌اند و از قالبِ خوبی تبعیت می‌کنند.
همچنین وسعتِ زیادِ عملکردهای در دسترس که در این سایت قرار دارند، به ما این امکان را می‌دهد که چیزهای بیشتری یاد بگیریم.
و دلیلِ استفاده از یک سایتِ معروف، اضافه کردنِ کمی هیجان و لذت به کار است تا بازدهِ یادگیری را افزایش دهد.

این‌نیز جالب به ذکر است که حتی اگر دیواری‌ها از این مطالب خوششان نیاید هم من قادر به انجامِ کاری برایشان نخواهم بود و چاره‌شان در تغییرِ ساختارِ درخواست‌ها و اذیت کردنِ بات‌نویس‌ها نهفته است!

ادامه مطلب...
۱۶ مهر ۹۴ ، ۲۱:۴۰ ۰ نظر موافقین ۱ مخالفین ۰

شروعی در موردِ روبات‌ها

«روبات» واژه‌ایست که به گروهِ عظیمی از «چیز»ها اطلاق می‌شود؛ «چیز»های نرم و چیزهای سخت؛ سخت مثلِ BigDog و نرم مثلِ روبات‌هایی که با تکثیرِ سریعشان باعثِ تولیدِ مفهومی به نامِ Captcha شدند!

بعضی مواقع به روبات‌های نرم، «بات» هم گفته می‌شود. اما من در پست‌های آتی، ممکن است در مواقعی از هر دو واژه به مفهومِ روبات‌های نرم استفاده کنم.

و البته باید ذکر کنم که مطالبِ این دسته در موردِ بات‌ها، یا روبات‌های نرم خواهد بود.

ادامه مطلب...
۱۶ مهر ۹۴ ، ۲۱:۱۷ ۰ نظر موافقین ۱ مخالفین ۰