अच्छा सॉफ्टवेयर इंजीनियरिंग बनाम सुरक्षा

Question

Security and Design दिशा निर्देशों विभिन्न तरीकों रूपरेखा महान लंबाई करने के लिए जाना इसे और अधिक मुश्किल एप्लिकेशन के तहत बिलिंग कार्यान्वयन समझौता करने के लिए एक हमलावर बनाने के लिए।

विशेष रूप से ध्यान दिया गया है कि .apk फ़ाइल को रिवर्स-इंजीनियर करना कितना आसान है, भले ही प्रोगार्ड के माध्यम से obfuscated। इसलिए वे सभी नमूना आवेदन कोड को संशोधित करने की भी सिफारिश करते हैं, खासकर "ज्ञात प्रवेश बिंदु और निकास बिंदु"।

क्या मैं याद आ रही खोजने के स्थिर Security.verify() जो boolean रिटर्न की तरह एक भी विधि में रैपिंग कुछ सत्यापन विधियों के लिए किसी भी संदर्भ, है: एक अच्छा डिजाइन अभ्यास (कम करने कोड दोहराव, पुन: प्रयोज्य, डिबग करने के लिए आसान, स्वयं कुछ दस्तावेज़ीकृत, आदि ।) लेकिन सभी एक हमलावर अब क्या करने की जरूरत है कि विधि की पहचान करने और यह हमेशा true वापसी कर ... तो परवाह किए बिना कितनी बार मैं इसे इस्तेमाल किया, देरी या नहीं देरी, बेतरतीब ढंग से है या नहीं, यह बस कोई फर्क नहीं पड़ता है।

दूसरी ओर, जावा C/C++, जो कम करने की अनुमति देता है स्रोत कोड दोहराव में की तरह मैक्रो नहीं है, लेकिन एक verify() समारोह के लिए एक एकल निकास बिंदु नहीं है।

तो मेरे सवालों का:

वहाँ अच्छी तरह से ज्ञात सॉफ्टवेयर इंजीनियरिंग/कोडिंग प्रथाओं और तथाकथित सुरक्षा के लिए डिजाइन के बीच एक अंतर्निहित विवाद है? (जावा/एंड्रॉइड/सुरक्षित लेनदेन के संदर्भ में कम से कम)

"सुरक्षा के लिए डिज़ाइन" के साइड इफेक्ट्स को कम करने के लिए क्या किया जा सकता है जो अधिक जटिल होने के मामले में "पैर में खुद को शूटिंग" जैसा लगता है सॉफ़्टवेयर जो सरल, अधिक रखरखाव और डीबग करना आसान हो सकता था?

आप आगे इस विषय के अध्ययन के लिए अच्छा स्रोत की सिफारिश कर सकते हैं?

Answer 1

हमेशा की तरह, यह एक दुविधा यह है। रिवर्स-इंजीनियर/क्रैक के लिए अपना कोड कठिन बनाना, इसे कम पढ़ने योग्य और बनाए रखने में कठिन बनाना शामिल है। आप तय करते हैं कि आपके इच्छित उपयोगकर्ता आधार, क्षेत्र में अपने कौशल, समय/लागत इत्यादि के आधार पर कितना दूर जाना है। यह एंड्रॉइड के लिए विशिष्ट नहीं है। Obfuscating के विभिन्न चरणों के लिए this Google I/O presentation देखें और अपने कोड को प्रतिरोधी छेड़छाड़ कर दें। फिर तय करें कि आप अपने ऐप्स के लिए कितनी दूर जाने के इच्छुक हैं।

दूसरी ओर, आप अंधेरा करना/कठोर, आदि की जरूरत नहीं है अपने कोड, बस बात यह है कि लाइसेंस के साथ संबंधित, आदि आमतौर पर पूरे codebase का एक बहुत छोटा हिस्सा है यही कारण है कि सभी के और वास्तव में इसे अक्सर बदलने की ज़रूरत नहीं है, इसलिए आप शायद इसके साथ रहना/बनाए रखना मुश्किल हो सकते हैं, इत्यादि। बस कुछ नोट्स रखें कि यह कैसे काम करता है, इसलिए आप 2 साल बाद खुद को याद दिलाते हैं :)।

Answer 2

काउंटर उत्पादकता जो आप वर्णन कर रहे हैं वह हिमशैल की नोक है ... रिलीज पर कोई सॉफ़्टवेयर 100% बग-फ्री नहीं है, तो जब उपयोगकर्ता रिपोर्टिंग समस्याओं को शुरू करते हैं तो आप क्या करते हैं?

लॉगिंग, स्टैक ट्रेसिंग और अन्य सभी प्रकार की अन्य जानकारी जो आप रिवर्स-इंजीनियरों की मदद करते हैं, लेकिन वैध विकास टीम की सहायता करने के बाद फील्ड समस्याओं का निवारण या डीबग कैसे करते हैं?

Answer 3

हालांकि कठिन कहानियो तरीके हैं, वहाँ हमेशा उल्टा उन्हें इंजीनियर के लिए एक रास्ता है। मेरा मतलब है, अगर आपका सॉफ़्टवेयर हैकर्स समुदाय के बीच अधिक लोकप्रिय हो जाता है, तो अंततः कोई इसे रिवर्स-इंजीनियर करने का प्रयास करेगा।

कहानियो को रिवर्स इंजीनियरिंग मुश्किल की प्रक्रिया बनाने के लिए सिर्फ एक तरीका है।

तो पैकिंग है।मुझे लगता है कि कई पैकिंग विधियां उपलब्ध हैं, लेकिन इन्हें रिवर्स-इंजीनियर करने की प्रक्रिया भी है।

आप यह देखने के लिए www.tuts4you.com देख सकते हैं कि कितने गाइड उपलब्ध हैं।

मैं कई अन्य लोगों की तरह एक विशेषज्ञ नहीं हूँ, लेकिन यह रिवर्स इंजीनियरिंग सीखने की प्रक्रिया में मेरा अनुभव है। हाल ही में मैंने एंड्रॉइड एप्लिकेशन रिवर्स इंजीनियरिंग के लिए बहुत सारे गाइड देखे हैं। मैंने nullc0n (यकीन नहीं) सीटीएफ में भी देखा है, एंड्रॉइड रिवर्सिंग में एक ऐप था। यदि आप चाहते हैं, तो मैं खोज के बाद साइट का उल्लेख कर सकता हूं।