วิธีปฏิบัติที่ดีที่สุดสำหรับการจัดเก็บและปกป้องคีย์ API ส่วนตัวในแอปพลิเคชัน [ปิด]

นักพัฒนาแอพส่วนใหญ่จะรวมห้องสมุดบุคคลที่สามเข้ากับแอพของพวกเขา ถ้าเป็นการเข้าถึงบริการเช่น Dropbox หรือ YouTube หรือการบันทึกการขัดข้อง จำนวนไลบรารีและบริการของบุคคลที่สามกำลังส่าย ไลบรารี่และบริการส่วนใหญ่นั้นได้รับการบูรณาการโดยการรับรองความถูกต้องกับบริการส่วนใหญ่แล้วเกิดขึ้นผ่านคีย์ API เพื่อวัตถุประสงค์ด้านความปลอดภัยบริการมักจะสร้างสาธารณะและเอกชนมักจะเรียกว่าเป็นความลับที่สำคัญ น่าเสียดายที่เพื่อเชื่อมต่อกับบริการคีย์ส่วนตัวนี้จะต้องใช้ในการตรวจสอบและด้วยเหตุนี้อาจเป็นส่วนหนึ่งของแอปพลิเคชัน ไม่จำเป็นต้องพูดเลยว่าสิ่งนี้กำลังเผชิญกับปัญหาด้านความปลอดภัยอันยิ่งใหญ่ คีย์ API สาธารณะและส่วนตัวสามารถดึงมาจาก APK ในเวลาไม่กี่นาทีและสามารถเป็นอัตโนมัติได้อย่างง่ายดาย

สมมติว่าฉันมีบางสิ่งที่คล้ายกันนี้ฉันจะป้องกันรหัสลับได้อย่างไร:

public class DropboxService  {

    private final static String APP_KEY = "jk433g34hg3";
    private final static String APP_SECRET = "987dwdqwdqw90";
    private final static AccessType ACCESS_TYPE = AccessType.DROPBOX;

    // SOME MORE CODE HERE

}

ในความเห็นของคุณวิธีที่ดีที่สุดและปลอดภัยที่สุดในการจัดเก็บรหัสส่วนตัวคืออะไร การทำให้งงงวยการเข้ารหัสคุณคิดอย่างไร?

1. แอปพลิเคชันที่รวบรวมของคุณมีสตริงที่สำคัญ แต่ยังมีชื่อคงที่ APP_KEY และ APP_SECRET การแตกกุญแจจากรหัสการทำเอกสารด้วยตนเองนั้นเป็นเรื่องเล็กน้อยเช่นกับเครื่องมือ Android มาตรฐาน dx

2. คุณสามารถใช้ ProGuard มันจะปล่อยให้สตริงที่สำคัญแตะต้อง แต่มันจะลบชื่อคงที่ มันจะเปลี่ยนชื่อคลาสและเมธอดด้วยชื่อที่สั้นและไม่มีความหมายซึ่งเป็นไปได้ การแตกคีย์นั้นใช้เวลานานขึ้นในการหาว่าสตริงใดทำหน้าที่ตามวัตถุประสงค์

   โปรดทราบว่าการตั้งค่า ProGuard ไม่ควรยากอย่างที่คุณกลัว ในการเริ่มต้นคุณจะต้องเปิดใช้งาน ProGuard ตามที่ระบุไว้ใน project.properties หากมีปัญหาใด ๆ กับห้องสมุดของบุคคลที่สามคุณอาจต้องระงับคำเตือนและ / หรือป้องกันไม่ให้พวกเขาสับสนใน proguard-project.txt ตัวอย่างเช่น

   -dontwarn com.dropbox.**
   -keep class com.dropbox.** { *; }

   นี่เป็นวิธีการที่ดุร้าย คุณสามารถปรับแต่งการกำหนดค่าดังกล่าวได้เมื่อแอปพลิเคชันที่ประมวลผลทำงาน

3. คุณสามารถทำให้งงสตริงด้วยตนเองในรหัสของคุณเช่นด้วยการเข้ารหัส Base64 หรือโดยเฉพาะอย่างยิ่งกับสิ่งที่ซับซ้อนมากขึ้น; อาจจะเป็นรหัสพื้นเมือง แฮ็คเกอร์จะต้องย้อนกลับแบบคงที่วิศวกรการเข้ารหัสของคุณหรือขัดขวางการถอดรหัสแบบไดนามิกในสถานที่ที่เหมาะสม

4. คุณสามารถใช้ Obfuscator เชิงพาณิชย์เช่นพี่น้องเฉพาะ ProGuard ของDexGuard มันสามารถเพิ่มเติมเข้ารหัส / obfuscate สตริงและคลาสสำหรับคุณ การแตกกุญแจจะต้องใช้เวลาและความเชี่ยวชาญมากขึ้น

5. คุณอาจเรียกใช้บางส่วนของแอปพลิเคชันของคุณบนเซิร์ฟเวอร์ของคุณเอง หากคุณสามารถเก็บกุญแจไว้ที่นั่นก็จะปลอดภัย

ในท้ายที่สุดมันเป็นการแลกเปลี่ยนทางเศรษฐกิจที่คุณต้องทำ: ความสำคัญของคีย์, เวลาหรือซอฟต์แวร์ที่คุณสามารถจ่ายได้เท่าไหร่, แฮ็กเกอร์ที่สนใจกุญแจ, พวกเขาต้องการเวลาเท่าไหร่ ใช้เวลาเท่าไรความล่าช้าก่อนที่คีย์จะถูกแฮ็กข้อมูลแฮ็กเกอร์ที่ประสบความสำเร็จจะกระจายกุญแจ ฯลฯ ในระดับใดข้อมูลขนาดเล็กเช่นคีย์จะป้องกันได้ยากกว่าแอปพลิเคชั่นทั้งหมด โดยพื้นฐานแล้วไม่มีอะไรในฝั่งไคลเอ็นต์ที่ไม่สามารถแตกได้ แต่คุณสามารถยกระดับมาตรฐานได้

(ฉันเป็นผู้พัฒนา ProGuard และ DexGuard)

ในความคิดของฉันมีเพียงแนวคิดแรกเท่านั้นที่รับประกัน:

1. เก็บความลับของคุณบนเซิร์ฟเวอร์บางอย่างบนอินเทอร์เน็ตและเมื่อจำเป็นเพียงแค่หยิบมันมาใช้ หากผู้ใช้กำลังจะใช้ดรอปบ็อกซ์ไม่มีอะไรจะหยุดคุณจากการร้องขอไปยังเว็บไซต์ของคุณและรับรหัสลับของคุณ

2. ใส่ความลับของคุณในรหัส jni เพิ่มรหัสตัวแปรบางอย่างเพื่อทำให้ไลบรารีของคุณใหญ่ขึ้นและยากต่อการถอดรหัส คุณอาจแยกสตริงคีย์ในส่วนที่น้อยและเก็บไว้ในที่ต่าง ๆ

3. ใช้ obfuscator และใส่รหัสลับแฮชและหลังจากนั้นปล่อยเมื่อจำเป็นต้องใช้

4. ใส่รหัสลับของคุณเป็นพิกเซลสุดท้ายของหนึ่งในภาพของคุณในเนื้อหา จากนั้นเมื่อจำเป็นต้องอ่านมันในรหัสของคุณ การทำให้รหัสของคุณสับสนควรช่วยซ่อนรหัสที่จะอ่าน

หากคุณต้องการดูอย่างรวดเร็วว่าการอ่านโค้ด apk ของคุณนั้นง่ายแค่ไหนให้หยิบ APKAnalyser:

http://developer.sonymobile.com/knowledge-base/tool-guides/analyse-your-apks-with-apkanalyser/

อีกวิธีคือการไม่มีความลับในอุปกรณ์ตั้งแต่แรก! ดูเทคนิคความปลอดภัย API มือถือ (โดยเฉพาะตอนที่ 3)

ใช้ประเพณีที่ให้เกียรติทางอ้อมในการแบ่งปันความลับระหว่างจุดสิ้นสุด API ของคุณและบริการตรวจสอบสิทธิ์แอป

เมื่อลูกค้าของคุณต้องการโทร API ลูกค้าจะขอให้บริการรับรองความถูกต้องของแอปเพื่อตรวจสอบสิทธิ์ (ใช้เทคนิคการยืนยันระยะไกลที่รัดกุม) และรับเวลา จำกัด (โดยทั่วไปคือJWT ) โทเค็นที่ลงชื่อโดยความลับ

โทเค็นจะถูกส่งไปพร้อมกับการเรียก APIแต่ละครั้งที่ปลายทางสามารถตรวจสอบลายเซ็นได้ก่อนดำเนินการตามคำขอ

ความลับที่แท้จริงไม่เคยปรากฏบนอุปกรณ์ ในความเป็นจริงแอปไม่เคยมีความคิดใด ๆ เลยว่าแอปนั้นถูกต้องหรือไม่มันจะขอการตรวจสอบสิทธิ์และส่งผ่านโทเค็นผลลัพธ์ หากคุณต้องการเปลี่ยนความลับคุณสามารถทำได้โดยไม่ต้องให้ผู้ใช้อัปเดตแอปที่ติดตั้งไว้

ดังนั้นหากคุณต้องการที่จะปกป้องความลับของคุณการไม่มีมันไว้ในแอพของคุณตั้งแต่แรกเป็นวิธีที่ดีมาก

วิธีที่ไม่ปลอดภัยเก่า:

ทำตาม 3 ขั้นตอนง่ายๆเพื่อรักษาความปลอดภัยของ API / รหัสลับ ( คำตอบเดิม )

เราสามารถใช้ Gradle เพื่อรักษาความปลอดภัยรหัส API หรือรหัสลับ

1. gradle.properties (คุณสมบัติโครงการ):สร้างตัวแปรด้วยคีย์

GoolgeAPIKey = "Your API/Secret Key"

2. build.gradle (โมดูล: แอพ):ตั้งค่าตัวแปรใน build.gradle เพื่อเข้าถึงมันในกิจกรรมหรือส่วน เพิ่มรหัสด้านล่างเพื่อ buildTypes {}

buildTypes.each {
    it.buildConfigField 'String', 'GoogleSecAPIKEY', GoolgeAPIKey
}

3. เข้าถึงได้ในกิจกรรม / ชิ้นส่วนโดย BuildConfig ของแอป:

BuildConfig.GoogleSecAPIKEY

อัปเดต:

การแก้ปัญหาข้างต้นมีประโยชน์ในโครงการโอเพนซอร์ซที่จะส่งมอบผ่าน Git (ขอบคุณ David Rawson และ riyaz-ali สำหรับความคิดเห็นของคุณ)

ตามความเห็นของ Matthew และ Pablo Cegarra วิธีข้างต้นไม่ปลอดภัยและ Decompiler จะอนุญาตให้บางคนดู BuildConfig ด้วยรหัสลับของเรา

สารละลาย :

เราสามารถใช้ NDK เพื่อรักษาความปลอดภัยคีย์ API เราสามารถจัดเก็บคีย์ในคลาส C / C ++ และเข้าถึงคลาสเหล่านั้นในคลาส Java ของเรา

โปรดติดตามบล็อกนี้เพื่อรักษาความปลอดภัยคีย์ API โดยใช้ NDK

การติดตามวิธีจัดเก็บโทเค็นอย่างปลอดภัยใน Android

รหัสลับของแอปควรเก็บเป็นความลับ - แต่เมื่อมีการปล่อยแอพพวกเขาสามารถย้อนกลับได้โดยบางคน

สำหรับพวกนั้นมันจะไม่ซ่อน, ล็อคProGuardรหัสอย่างใดอย่างหนึ่ง มันเป็น refactor และผู้ obfuscators ที่จ่ายเงินบางส่วนกำลังแทรกตัวดำเนินการระดับบิตสองสามตัวเพื่อกลับคืนjk433g34hg3 สตริงกลับ คุณสามารถแฮ็คได้นาน 5 -15 นาทีหากคุณทำงาน 3 วัน :)

ทางที่ดีควรเก็บไว้ตามที่เป็น

แม้ว่าคุณจะจัดเก็บที่ฝั่งเซิร์ฟเวอร์ (พีซีของคุณ) คีย์สามารถแฮ็กและพิมพ์ออกมาได้ บางทีนี่อาจใช้เวลานานที่สุด? อย่างไรก็ตามมันเป็นเรื่องของไม่กี่นาทีหรือไม่กี่ชั่วโมงในกรณีที่ดีที่สุด

ผู้ใช้ปกติจะไม่ถอดรหัสรหัสของคุณ

ทางออกหนึ่งที่เป็นไปได้คือการเข้ารหัสข้อมูลในแอปของคุณและใช้การถอดรหัสที่รันไทม์ (เมื่อคุณต้องการใช้ข้อมูลนั้น) ฉันยังแนะนำให้ใช้ progaurd เพื่อทำให้อ่านและเข้าใจซอร์สโค้ดที่ถอดรหัสแล้วของแอปของคุณได้ยาก ตัวอย่างเช่นฉันใส่รหัสที่เข้ารหัสในแอพจากนั้นใช้วิธีการถอดรหัสในแอพของฉันเพื่อถอดรหัสคีย์ลับของฉันที่รันไทม์:

// "the real string is: "mypassword" "; 
//encoded 2 times with an algorithm or you can encode with other algorithms too
public String getClientSecret() {
    return Utils.decode(Utils
            .decode("Ylhsd1lYTnpkMjl5WkE9PQ=="));
}

ซอร์สโค้ดที่คอมไพล์แล้วของแอปที่ได้รับการป้องกันคือ:

 public String c()
 {
    return com.myrpoject.mypackage.g.h.a(com.myrpoject.mypackage.g.h.a("Ylhsd1lYTnpkMjl5WkE9PQ=="));
  }

อย่างน้อยมันก็ซับซ้อนพอสำหรับฉัน นี่คือวิธีที่ฉันทำเมื่อฉันไม่มีทางเลือก แต่เก็บค่าไว้ในใบสมัครของฉัน แน่นอนเราทุกคนรู้ว่ามันไม่ได้เป็นวิธีที่ดีที่สุด แต่ก็ใช้งานได้สำหรับฉัน

/**
 * @param input
 * @return decoded string
 */
public static String decode(String input) {
    // Receiving side
    String text = "";
    try {
        byte[] data = Decoder.decode(input);
        text = new String(data, "UTF-8");
        return text;
    } catch (UnsupportedEncodingException e) {
        e.printStackTrace();
    }
    return "Error";
}

เวอร์ชันที่แปลแล้ว:

 public static String a(String paramString)
  {
    try
    {
      str = new String(a.a(paramString), "UTF-8");
      return str;
    }
    catch (UnsupportedEncodingException localUnsupportedEncodingException)
    {
      while (true)
      {
        localUnsupportedEncodingException.printStackTrace();
        String str = "Error";
      }
    }
  }

และคุณสามารถค้นหาคลาสของ Encryptor จำนวนมากด้วยการค้นหาเพียงเล็กน้อยใน Google

การเพิ่มโซลูชัน @Manohar Reddy ฐานข้อมูล firebase หรือ firebase RemoteConfig (ที่มีค่าดีฟอลต์ Null) สามารถใช้ได้:

1. เข้ารหัสคีย์ของคุณ
2. เก็บไว้ในฐานข้อมูล firebase
3. รับได้ระหว่างการเริ่มต้นแอพหรือเมื่อใดก็ตามที่จำเป็น
4. ถอดรหัสคีย์และใช้งาน

อะไรคือสิ่งที่แตกต่างในโซลูชันนี้?

• ไม่มี creditintials สำหรับ firebase
• การเข้าถึง firebase ได้รับการคุ้มครองดังนั้นแอปที่มีใบรับรองที่ลงนามแล้วเท่านั้นที่มีสิทธิ์โทร API
• การเข้ารหัส / ถอดรหัสเพื่อป้องกันการสกัดกั้นชายกลาง อย่างไรก็ตามโทรไปที่ฐาน Fire แล้ว

ตัวอย่างนี้มีแง่มุมต่าง ๆ มากมาย ฉันจะพูดถึงสองประเด็นที่ฉันไม่คิดว่าได้รับการคุ้มครองอย่างชัดเจนที่อื่น

ปกป้องความลับในการขนส่ง

สิ่งแรกที่ควรทราบคือการเข้าถึง Dropbox API โดยใช้กลไกการตรวจสอบสิทธิ์แอพนั้นคุณต้องส่งคีย์และความลับของคุณ การเชื่อมต่อคือ HTTPS ซึ่งหมายความว่าคุณไม่สามารถดักจับทราฟฟิกโดยไม่ทราบว่าใบรับรอง TLS เพื่อป้องกันไม่ให้บุคคลดักจับและอ่านแพ็กเก็ตในการเดินทางจากอุปกรณ์พกพาไปยังเซิร์ฟเวอร์ สำหรับผู้ใช้ทั่วไปเป็นวิธีที่ดีในการรับรองความเป็นส่วนตัวของการรับส่งข้อมูล

สิ่งที่ไม่ดีคือป้องกันผู้ประสงค์ร้ายที่ดาวน์โหลดแอพและตรวจสอบปริมาณการใช้งาน เป็นเรื่องง่ายมากที่จะใช้พร็อกซีแบบแมน - อิน - มิดสำหรับการรับส่งข้อมูลเข้าและออกจากอุปกรณ์พกพา มันจะต้องไม่มีการถอดหรือวิศวกรรมย้อนกลับของรหัสเพื่อแยกคีย์แอปและความลับในกรณีนี้เนื่องจากลักษณะของ Dropbox API

คุณสามารถทำตรึงซึ่งการตรวจสอบว่า TLS ที่คุณได้รับจากเซิร์ฟเวอร์เป็นหนึ่งที่คุณคาดหวัง สิ่งนี้จะเพิ่มการตรวจสอบให้กับลูกค้าและทำให้การสกัดกั้นทราฟฟิกยากขึ้น สิ่งนี้จะทำให้ยากต่อการตรวจสอบการจราจรในเที่ยวบิน แต่การตรวจสอบการตรึงเกิดขึ้นในไคลเอนต์ดังนั้นจึงเป็นไปได้ที่จะปิดการทดสอบการปักหมุด มันทำให้มันยากขึ้น

ปกป้องความลับที่เหลือ

ในขั้นตอนแรกการใช้สิ่งที่คล้ายกับproguardจะช่วยให้ชัดเจนน้อยลงเมื่อมีการเก็บความลับ นอกจากนี้คุณยังสามารถใช้ NDK เพื่อเก็บคีย์และความลับและส่งคำขอโดยตรงซึ่งจะช่วยลดจำนวนคนที่มีทักษะที่เหมาะสมในการดึงข้อมูล การทำให้งงงวยเพิ่มเติมสามารถทำได้โดยไม่เก็บค่าโดยตรงในหน่วยความจำระยะเวลาใด ๆ คุณสามารถเข้ารหัสและถอดรหัสก่อนใช้ตามคำแนะนำอื่น

ตัวเลือกขั้นสูงเพิ่มเติม

หากคุณหวาดระแวงเกี่ยวกับการใส่ความลับไว้ที่ใดก็ได้ในแอปของคุณและคุณมีเวลาและเงินในการลงทุนในโซลูชันที่ครอบคลุมมากขึ้นคุณอาจพิจารณาจัดเก็บข้อมูลประจำตัวบนเซิร์ฟเวอร์ของคุณ (สมมติว่าคุณมี) วิธีนี้จะเพิ่มเวลาแฝงของการโทรไปยัง API เนื่องจากจะต้องสื่อสารผ่านเซิร์ฟเวอร์ของคุณและอาจเพิ่มค่าใช้จ่ายในการเรียกใช้บริการของคุณเนื่องจากปริมาณข้อมูลที่เพิ่มขึ้น

จากนั้นคุณต้องตัดสินใจว่าจะสื่อสารกับเซิร์ฟเวอร์ของคุณอย่างไรเพื่อให้แน่ใจว่าได้รับการปกป้อง นี่เป็นสิ่งสำคัญเพื่อป้องกันปัญหาเดียวกันทั้งหมดที่เกิดขึ้นอีกครั้งด้วย API ภายในของคุณ กฎง่ายๆที่ฉันสามารถให้ได้ก็คืออย่าส่งความลับใด ๆ โดยตรงเนื่องจากการคุกคามจากคนกลาง แต่คุณสามารถลงชื่อเข้าใช้ทราฟฟิกโดยใช้ความลับของคุณและตรวจสอบความถูกต้องของคำขอใด ๆ ที่มายังเซิร์ฟเวอร์ของคุณ วิธีหนึ่งที่เป็นมาตรฐานในการทำเช่นนี้คือการคำนวณ HMAC ของข้อความที่เป็นความลับ ฉันทำงานที่ บริษัท ที่มีผลิตภัณฑ์รักษาความปลอดภัยซึ่งทำงานในสาขานี้ด้วยเหตุนี้สิ่งต่าง ๆ ที่ฉันสนใจ อันที่จริงนี่เป็นบทความบล็อกจากหนึ่งในเพื่อนร่วมงานของฉันที่ทำเรื่องส่วนใหญ่

ฉันควรทำอย่างไร

ด้วยคำแนะนำด้านความปลอดภัยเช่นนี้คุณต้องตัดสินใจเรื่องค่าใช้จ่าย / ผลประโยชน์ว่าคุณต้องการให้ใครบางคนบุกเข้ามาได้ยากเพียงใดถ้าคุณเป็นธนาคารที่ปกป้องลูกค้านับล้านงบประมาณของคุณแตกต่างจากคนที่สนับสนุนแอป เวลาว่าง. แทบเป็นไปไม่ได้ที่จะป้องกันไม่ให้ใครบางคนทำลายระบบรักษาความปลอดภัยของคุณ แต่ในทางปฏิบัติมีเพียงไม่กี่คนที่ต้องการเสียงระฆังและเสียงนกหวีดและด้วยความระมัดระวังขั้นพื้นฐานบางอย่างคุณจึงสามารถเดินทางได้ไกล

โซลูชันที่ปลอดภัยที่สุดคือการเก็บคีย์ของคุณไว้บนเซิร์ฟเวอร์และกำหนดเส้นทางคำขอทั้งหมดที่ต้องการคีย์นั้นผ่านเซิร์ฟเวอร์ของคุณ ด้วยวิธีนี้คีย์จะไม่ออกจากเซิร์ฟเวอร์ของคุณตราบใดที่เซิร์ฟเวอร์ของคุณปลอดภัยแล้วก็เป็นกุญแจของคุณ แน่นอนว่ามีค่าใช้จ่ายด้านประสิทธิภาพด้วยโซลูชันนี้

เก็บเป็นความลับfirebase databaseและรับมันเมื่อแอพเริ่มต้นมันดีกว่าการโทรหาบริการบนเว็บ

สิ่งที่คุณทำเพื่อรักษาความปลอดภัยคีย์ลับของคุณจะไม่เป็นทางออกที่แท้จริง หากนักพัฒนาสามารถถอดรหัสแอปพลิเคชันไม่มีทางที่จะรักษาความปลอดภัยของกุญแจการซ่อนกุญแจนั้นเป็นเพียงการรักษาความปลอดภัยด้วยความคลุมเครือและเป็นรหัสที่ทำให้งงงวย ปัญหาเกี่ยวกับการรักษาความปลอดภัยของรหัสลับคือเพื่อความปลอดภัยคุณจะต้องใช้รหัสอื่นและกุญแจนั้นจะต้องได้รับการรักษาความปลอดภัยด้วย นึกถึงกุญแจที่ซ่อนอยู่ในกล่องที่ถูกล็อคด้วยกุญแจ คุณวางกล่องไว้ภายในห้องและล็อคห้อง คุณเหลือกุญแจอีกดอกไว้เพื่อความปลอดภัย และกุญแจนั้นจะยังคงถูกเข้ารหัสในแอปพลิเคชันของคุณ

ดังนั้นหากผู้ใช้ป้อน PIN หรือวลีไม่มีวิธีซ่อนรหัส แต่การทำเช่นนั้นคุณจะต้องมีแผนการจัดการ PIN ที่เกิดขึ้นนอกวงซึ่งหมายความว่าผ่านช่องทางอื่น แน่นอนว่าไม่ใช่วิธีการรักษาความปลอดภัยสำหรับคีย์สำหรับบริการเช่น Google API

อายุโพสต์เก่า แต่ก็ยังดีพอ ฉันคิดว่าการซ่อนไว้ใน. so library นั้นยอดเยี่ยมโดยใช้ NDK และ C ++ แน่นอน สามารถดูไฟล์. so ในโปรแกรมแก้ไข hex ได้ แต่ขอให้โชคดีในการถอดรหัสว่า: P

วิธีที่แท้จริงเพียงประการเดียวในการรักษาความเป็นส่วนตัวเหล่านี้คือการเก็บไว้บนเซิร์ฟเวอร์ของคุณและให้แอปส่งสิ่งที่มันไปยังเซิร์ฟเวอร์และเซิร์ฟเวอร์จะโต้ตอบกับ Dropbox ด้วยวิธีนี้คุณจะไม่แจกจ่ายคีย์ส่วนตัวของคุณในทุกรูปแบบ

จากประสบการณ์ที่ขมขื่นและหลังจากปรึกษากับผู้เชี่ยวชาญของ IDA-Pro ทางออกที่ดีที่สุดคือการย้ายส่วนสำคัญของรหัสไปยัง DLL / SharedObject จากนั้นดึงข้อมูลจากเซิร์ฟเวอร์และโหลดที่รันไทม์

ข้อมูลที่ละเอียดอ่อนต้องได้รับการเข้ารหัสเนื่องจากมันง่ายมากที่จะทำสิ่งนี้:

$ strings libsecretlib.so | grep My
  My_S3cr3t_P@$$W0rD