Android Oreo-ს უკან დაბრუნების დაცვა საჭიროა Android Pie-ით გაშვებულ ტელეფონებზე

Android Pie-ით (Android 9) გაშვებულ ყველა მოწყობილობას მოეთხოვება Verified Boot-ის მხარდაჭერა (Android Verified Boot 2.0), რაც იძლევა უკან დაბრუნების დაცვის საშუალებას.

Android Pie (Android 9) პირდაპირ ეთერში დღეს გავიდა Google Pixel-ისთვის, Google Pixel 2 და თუნდაც აუცილებელი ტელეფონი. ჩვენ მაქსიმალურად ვსწავლობთ ინტერვიუებიდან გამოშვების შესახებ (Google Pixel 3 ექნება მხოლოდ ჟესტების ნავიგაცია!), AOSP კოდის დაცემადა ბოლოს თავსებადობის განმარტების დოკუმენტი (CDD). ჩვენ გამოვაქვეყნეთ დაახლოებით ა ახალი ფუნქცია "მძიმე წონის" აპებისთვის დღეს ადრე, მაგრამ ახლა ჩვენ აღმოვაჩინეთ, რომ Google-მა შეცვალა თავისი ფორმულირება Android Oreo-ში დანერგილ ფუნქციაზე: უკან დაბრუნების დაცვა. ფუნქცია შესაძლებელი ხდება Android Verified Boot 2.0 (ასევე ცნობილია როგორც Verified Boot), თუმცა OEM-ებს არ მოეთხოვებოდათ AVB 2.0-ის დანერგვა Oreo-ს გამოშვებაში. ახლა Google ავალდებულებს, რომ Android Pie-ით გაშვებულმა ყველა მოწყობილობამ მხარი დაუჭიროს Verified Boot-ს და გაფართოებით, უკან დაბრუნების დაცვას.

უკან დაბრუნების დაცვა Android Oreo-ში

ფუნქციის არსი ის არის, რომ ის ხელს შეუშლის თქვენი ტელეფონის ჩატვირთვას, თუ აღმოაჩენს, რომ მოწყობილობა დაქვეითებულია პროგრამული უზრუნველყოფის ადრინდელ, ახლა დაუმტკიცებელ ვერსიაზე, რომელიც დაუცველად იქნა მიჩნეული უსაფრთხოების გამო დაუცველობა. ოდნავ უფრო ტექნიკური ახსნა არის ის, რომ VBMeta მონაცემთა სტრუქტურა, რომელიც ინახავს ჰეშს ჩატვირთვის დანაყოფისთვის და ჰეშტრის მეტამონაცემები სისტემისა და გამყიდველის ტიხრებისთვის, იყენებს rollback ინდექსს იმ სურათების უარსაყოფად, რომლებსაც აქვთ ძველი დაბრუნება ინდექსი.

უკან დაბრუნების დაცვა Android Verified Boot-ში. წყარო: Google.

ეს ფუნქცია წარმოდგენილია ისეთ მოწყობილობებზე, როგორიცაა Google Pixel 2, Razer Phone და OnePlus 6, მაგრამ არ არის წარმოდგენილი ბევრ სხვა მოწყობილობაზე, როგორიცაა Samsung Galaxy S9 (თუმცა Samsung გთავაზობთ საკუთარ ფორმას. უკან დაბრუნების დაცვა Knox-ში.) ახლა Google ამ ფუნქციას სავალდებულოს ხდის Android Pie-ით გაშვებული ნებისმიერი მოწყობილობისთვის.

დადასტურებული ჩატვირთვა Android Pie-ში

თავსებადობის განმარტების დოკუმენტში "მოწყობილობის მთლიანობის" განყოფილებაში განახლებული ფორმულირების მიხედვით, Android 9-ით გაშვებულ მოწყობილობებს უნდა დაუჭიროთ მხარი Verified Boot.

9.10. მოწყობილობის მთლიანობა

შემდეგი მოთხოვნები უზრუნველყოფს მოწყობილობის მთლიანობის სტატუსის გამჭვირვალობას. მოწყობილობის დანერგვა:

  • [C-0-1] სწორად უნდა მოახსენოს System API მეთოდის მეშვეობით PersistentDataBlockManager.getFlashLockState() იძლევა თუ არა მათი ჩამტვირთველის მდგომარეობა სისტემის გამოსახულების ციმციმის საშუალებას. FLASH_LOCK_UNKNOWN მდგომარეობა რეზერვირებულია Android-ის ადრინდელი ვერსიიდან განახლებული მოწყობილობის განხორციელებისთვის, სადაც ეს ახალი სისტემის API მეთოდი არ არსებობდა.
  • [C-0-2] უნდა მხარი დაუჭიროს Verified Boot მოწყობილობის მთლიანობას.

თუ მოწყობილობის დანერგვა უკვე დაწყებულია Android-ის უფრო ადრეულ ვერსიაზე Verified Boot-ის მხარდაჭერის გარეშე და არ შეიძლება ამ ფუნქციის მხარდაჭერა სისტემის პროგრამული უზრუნველყოფის განახლებით, ისინი შეიძლება გათავისუფლდნენ მოთხოვნა.

...

  • [C-1-10] უნდა განხორციელდეს უკან დაბრუნების დაცვა Android-ის მიერ გამოყენებული დანაყოფებისთვის (მაგ. ჩატვირთვა, სისტემის დანაყოფები) და გამოიყენე შეცდომის აშკარა მეხსიერება მეტამონაცემების შესანახად, რომელიც გამოიყენება მინიმალური დასაშვები OS-ის დასადგენად ვერსია.
  • უნდა განახორციელოს უკან დაბრუნების დაცვა მუდმივი პროგრამული უზრუნველყოფის მქონე ნებისმიერი კომპონენტისთვის (მაგ. მოდემი, კამერა) და უნდა გამოიყენოს არასწორად გამოვლენილი საცავი მეტამონაცემების შესანახად, რომელიც გამოიყენება მინიმალური დასაშვების დასადგენად ვერსია.

როგორც ხედავთ ბოლო ორ პუნქტში, უნდა აღინიშნოს ერთი გაფრთხილება. უკან დაბრუნების დაცვა საჭიროა Android-ის მიერ გამოყენებული დანაყოფებისთვის (ჩატვირთვა, სისტემა, გამყიდველი და ა.შ.), მაგრამ არა მუდმივი პროგრამული უზრუნველყოფის მქონე დანაყოფებისთვის (მოდემი, კამერა და ა.შ.). დანაყოფების ყოფილი ნაკრები არის სადაც უსაფრთხოების ხარვეზების უმეტესი ნაწილი აღმოჩენილია და შესწორებულია, ამიტომ სასიამოვნოა იმის დანახვა, რომ ამ დანაყოფების დაცვა სავალდებულოა. თუმცა, იყო ექსპლოიტები, რომლებიც მიზნად ისახავს ტიხრებს მუდმივი firmware-ით, ასე რომ, ჩვენ არ ვართ დარწმუნებული, რატომ არ ავალდებულებს Google მათ უკან დაბრუნების დაცვას.

XDA-ს უფროსი წევრი ნპჯონსონიLineageOS-ის გუნდის წევრი, ვარაუდობს, რომ მუდმივი პროგრამული უზრუნველყოფის მქონე დანაყოფებზე უკან დაბრუნების დაცვის მოთხოვნა იქნება საჭიროებს მეორადი ჩამტვირთველის (SBL) და გაფართოებული ჩამტვირთველის (XBL) კავშირებს, რადგან ეს დანაყოფები ჩატვირთვისას უფრო ადრეა დამონტაჟებული. პროცესი. მცირე OEM-ებისთვის ძვირი დაჯდება მორგებული XBL-ების დანერგვა მორგებულ მოდემებთან და სხვა მუდმივ დანაყოფებთან შესატყვისად. ასე რომ, შესაძლოა Google არ აყენებს ამ მოთხოვნას, რათა გაუადვილოს მოწყობილობების შემქმნელებს CDD-ის უახლესი მოთხოვნების დაკმაყოფილება.

როგორ შეამოწმოთ თქვენი ტელეფონი მხარს უჭერს AVB 2.0

არსებობს ორი ADB shell ბრძანება, რომელთა გამოყენება შეგიძლიათ, რათა შეამოწმოთ, თუ თქვენი ტელეფონი მხარს უჭერს AVB 2.0.

adb shell
dumpsys package | grep "verified_boot"

ან

adb shell
getprop | grep "avb"

თუ პირველი ბრძანების გამომავალი არის "android.software.verified_boot", მაშინ AVB 2.0 მხარდაჭერილია. თუ მეორე ბრძანების გამოსავალში ნაჩვენებია "[ro.boot.avb_version]" და "[ro.boot.vbmeta.avb_version]" და ჩამოთვლილია თითოეული ვერსიის ნომერი, მაშინ ის მხარდაჭერილია.

დამოწმებული ჩატვირთვა და მორგებული განვითარება

Android Verified Boot ნამდვილად არ ახდენს გავლენას მორგებული ROM მომხმარებელთა უმეტესობაზე, თუმცა ის ამატებს უსაფრთხოების დამატებით ფენას, რომლის გარშემოც უნდა იმუშაოთ ზოგიერთ შემთხვევაში. Მაგალითად, ციმციმებს ზოგადი სისტემის გამოსახულება მოითხოვს AVB-ის გამორთვას. გარკვეული ტიხრების შეცვლა, როგორიცაა გამყიდველი OnePlus 6-ზე, მოითხოვს ასევე AVB-ის გამორთვას, როგორც ცოტა ხნის წინ გავიგე. Მიხედვით ნპჯონსონი, სწორად დანერგილი AVB 2.0 შესაძლებელს ხდის პერსონალური ჩატვირთვის სურათების მუშაობას ჩაკეტილ ჩამტვირთველთან. ჩვენ დავინახავთ, თუ როგორ იმოქმედებს AVB 2.0-ის ჩართვა Android Pie-ით მიწოდებულ მოწყობილობებზე, მაგრამ ვიმედოვნებთ, რომ ეს არ გამოიწვევს მსგავს სიტუაციებს. ბოლოდროინდელი აგურის შეშინება Xiaomi Redmi Note 5 Pro საზოგადოებაში. სავალდებულო AVB 2.0 არის კიდევ ერთი გზა Google-ისთვის გააუმჯობესეთ Android პლატფორმის უსაფრთხოება, მაგრამ ყველაზე დიდი ცვლილება, ჩვენი აზრით, არის OEM შეთანხმებების ხელახალი მუშაობა უსაფრთხოების რეგულარული პატჩების მანდატისთვის.