XDA Recognized Developer topjohnwu-მ დაარწმუნა მომხმარებლები, რომ შემდეგი Magisk Beta კიდევ ერთხელ გაივლის SafetyNet შემოწმებას, მიუხედავად Google-ის ბოლო ცვლილებებისა.
დღეს ადრე, დაიწყო მოხსენებები Google-ის შესახებ, რომელიც განაახლებს Play Services-ს და იწვევს ამჟამინდელ „უსაფრთხო“ root მეთოდებს, როგორიცაა Magisk, კვლავ ვერ ახერხებს SafetyNet-ის შემოწმებებს. ეს ნიშნავს, რომ მოწყობილობები root და სხვა მოდიფიკაციებით კიდევ ერთხელ იქნა აღმოჩენილი SafetyNet-ის მიერ და შემდგომში დაბლოკილი იქნა SafetyNet-ზე დამოკიდებული აპლიკაციების გამოყენებისას, როგორიცაა Android Pay.
XDA აღიარებული დეველოპერი topjohnwu აქვს კომენტარი გააკეთა Magisk ფორუმის თემაში დაარწმუნოს მომხმარებლები, რომ მან იცის ცვლილებების შესახებ და უკვე დაასრულა რეკვიზიტი ცვლილებები Google-ის SafetyNet-ის შემოწმების ხელახლა გვერდის ავლით, სანამ კვლავ შეინარჩუნებს root და Magisk მოდულს ფუნქციონირება.
Ში შემდგომი განმარტებითი პოსტი, topjohnwu აღნიშნავს, რომ SafetyNet-ის წარუმატებლობები გამოწვეული იყო Google-ის მიერ მათი გამოვლენის კიდევ უფრო გამკაცრებით, მაგრამ დეველოპერმა შეძლო ამის გარშემო მუშაობა.
ტოპჯონვუ კიდევ უფრო აფართოებს, რომ შესაძლოა არ არსებობდეს რაიმე ეფექტური მეთოდი მაგისხიდის მუშაობის თავიდან ასაცილებლად. ასე რომ, როდესაც Google შემოაქვს SafetyNet-ის ახალ შემოწმებებს, მაგისხიდეს სჭირდება მხოლოდ განახლება, რათა დაბრუნდეს ერთი ნაბიჯით წინ. ეს შესაძლებელი გახდა იმის გამო, რომ Magisk შეიძლება იმუშაოს როგორც root, ხოლო SafetyNet-ის შემოწმებები არა. პრივილეგიის უპირატესობა Magisk-ს საშუალებას აძლევს ბევრად მეტი კონტროლი აკონტროლოს SafetyNet პროცესზე.
რაც რთულია არის მაგისკ მენეჯერის მთავარი აპლიკაციის დამალვის კარგი ხერხის პოვნა. რამდენიმე აპმა დაიწყო Magisk Manager აპლიკაციის არსებობის გამოვლენა მისი პაკეტის სახელით, რადგან Android საშუალებას აძლევს ნებისმიერ აპს იცოდეს, რა სხვა აპლიკაციებია დაინსტალირებული მოწყობილობაზე. ეს „შემოწმება“ საკმაოდ ელემენტარულია, რადგან პაკეტის სახელების შეცვლა ტრივიალური ამოცანაა აპლიკაციის მთავარი შემქმნელისთვის (თუმცა ის რჩება გადაწყვეტილებად, რომელსაც გააჩნია საკუთარი ნაკლოვანებები). უბრალოდ კონკრეტული აპლიკაციის დაყენების ქმედება ასევე არსებითად არ ადასტურებს ცვლილებების არსებობას, ამიტომ „ჩეკი“ ასევე იძლევა ცრუ პოზიტივის საკმაოდ დიდ რაოდენობას.
მაგრამ იმის გამო, რომ ამ ტიპის შემოწმება ელემენტარულია, მისი განხორციელება მარტივია დეველოპერებისთვის, რომლებიც ეძებენ „მოდიფიკაციის გარეშე“ მოწყობილობებს თავიანთი აპებისთვის. Magisk-ს შეუძლია დაიმალოს თავი ამ აპებისგან მხოლოდ პაკეტის სახელის შეცვლით, მაგრამ შემდეგ აპებს შეუძლიათ დაიწყონ პაკეტის შეცვლილი სახელის შემოწმება; და ა.შ. და ა.შ., რითაც ამ პრობლემის რეალური დასასრული არც ერთ მხარეს არ აქვს.
Magisk-ის შესაძლო გამოსავალი ამ ელემენტარული შემოწმების წინააღმდეგ არის კოდის შეყვანა Android-ის PackageManager-ში Magisk Manager-ის დაინსტალირებული აპლიკაციების სიიდან გასაფილტრად. ეს შეიძლება გაკეთდეს Xposed-ის საშუალებით (მაგრამ Xposed თავად არღვევს SafetyNet-ს და Xposed შემოიფარგლება მხოლოდ ანდროიდის უფრო ძველი ვერსიები) ან ფრეიმერის ჯავის კოდის პირდაპირ შეცვლით შეცვლილი შვრიის/დექსის მეშვეობით ფაილები.
Ახლა, ტოპჯონვუ არ სურს ფოკუსირება მოახდინოს ამ ელემენტარული შემოწმებების გვერდის ავლით, რადგან მაგისხიდის მთავარი ინტერესი არის Google-ის SafetyNet ჩეკების გვერდის ავლით. მომხმარებლებს შეუძლიათ მალე დაელოდონ განახლებას, რომელიც საშუალებას მისცემს SafetyNet-ზე დამოკიდებულ აპებს კვლავ დაიწყონ მუშაობა root და Magisk მოდულების გვერდით, თუმცა ჩვენ ვთხოვთ მომხმარებლებს არ შეაწუხონ დეველოპერი ETA-ების მოთხოვნით იგივე.
რა აზრის ხართ ამ კატა-თაგვის თამაშზე Google-ის SafetyNet-სა და Magiskhide-ს შორის? შეგვატყობინეთ ქვემოთ მოცემულ კომენტარებში!
წყარო: Magisk Forums