Pages

Android 4.4 KitKat: Google takes aim at developers of Custom ROMs?



KitKat With Android 4.4, Google has introduced a host of new capabilities, especially with regard to the safety of the device. In addition to SELinux enabled by default in Android 4.4 Google has added a new feature: dm-verity, which could also affect the work of many developers of Custom ROMs.

As mentioned above , Android 4.4 KitKat has introduced new features and enhancements , including with regard to the safety of the device. Among these dm- verity , a feature of the kernel that is responsible to check the integrity of the boot blocks of the file system.
 (The blocks are nothing more than a sequence of bytes or bits of fixed length [ block size ] . Generally Flash devices on the block size is 4KB . To clarify the concept , a file of 1Mb will be physically stored on the flash memory 250 4KB block).

Dm- verity , according to what is stated on the official website , and will need to avoid to rootkits and malware to make changes to the file system. In essence, each time it is written on a data disk , the hash of the block changes, and if this change is not authorized by the system, dm- verity the next boot will detect the change , blocking execution.

 The basic concept of DM-Verity



 Dm- verity reside in the kernel. So if a software impair the filesystem before the kernel , this will block startup of the device.For now , manufacturers use a unique key for each device, written in some remote corner of the memory of the same , which can not be changed once the device has left the factory. With this key , producers determine the integrity of the first stage of the boot loader , which then will be responsible for verification of higher levels.At the moment though, the check is performed only on bootloaders , leaving the verification of the kernel and then the File System . Here comes into play dm- verity , which is responsible for checking in parallel hash of each block when the system accesses (to avoid excessive delays when accessing memory) and compares it with the " hash tree " previously saved ( picture above). if they diverge , with each block hash different from the previously generated , will be made inaccessible and as a result you will get an I / O error , indicating that the block does not make sense . In other words , the file system will be corrupted.

Will operate as physically dm-verity

 Generation of a system image format EXT4
 Generate hash tree, To generate the hash "root" the system image will be divided into 4KB block (layer 0), each of which is assigned a SHA256 hash . Layer 1 is composed by combining the previous SHA256 and dividing the result in 4KB block , generating an image of smaller size . The process will be repeated until the SHA256 can be within a single 4k block.
The size of the hash tree will vary according to the size of the partition, but on average below 30Mb.
 Construction of the mapping table
 This table identifies the block ( portion ) of the analyzed file system when generating the hash. Will
also contain the position of the hash and the offset / position of the starting block .
 Signature and validation of the generated table above.
 The generated table above will be " signed" with an RSA key - 2048 placed in the / boot partition. Generally these private keys are generated and in the production phase of the device.

The problem from the point of view of the rooting and modding

Well, I have written the function of dm- verity , now is the time to analyze the situation modding/ rooting applied to this new feature.With the exception of Nexus devices , which are known to be unlocked with a simple " fastboot oem unlock " , all other devices could, in future , no longer see the root or custom roms . Why do I say this ? simply because dm- verity intercept any changes made to the file -system and, consequently, any file written or modified without permission. It goes without saying then that for devices with bootloader locked and unlocked only by a unique key, find an exploit to gain access as an administrator will be much more ' difficult. This means that if the manufacturer decides not to grant any tool to unlock the bootloader , you can not find a way to unlock the bootloader . It ' also true that dm- verity can be disabled in the kernel or modified so that it reads an RSA key personnel instead of the OEM , but to do whatever is necessary to have an unlocked bootloader to write a new kernel on partition / boot .I conclude by saying that dm- verity is definitely a new feature that will significantly enhance the safety of the devices with respect to malware, but it may be counterproductive to the whole world that revolves around the root and custom rom.





Alerts: Want to know more topics when we update our site? Enter your email address below and be notified by mail every time we update our site.

Enter your email address:

Delivered by FeedBurner


0 comments:

Post a Comment