LwVM - Revision history

Danzatt: Ugh

2015-06-12T16:11:33Z

Ugh

Rzhikharevich: Same fixes.

2015-06-12T14:26:01Z

Same fixes.

Rzhikharevich: Minor fix: GTP -> GPT

2015-06-12T14:24:09Z

Minor fix: GTP -> GPT

Danzatt at 13:42, 12 June 2015

2015-06-12T13:42:09Z

Danzatt: addded info on repartitioning + update partiton

2015-06-12T13:33:42Z

addded info on repartitioning + update partiton

Rzhikharevich at 12:39, 23 March 2015

2015-03-23T12:39:43Z

5urd: that would be why

2014-09-15T21:34:15Z

that would be why

Danzatt at 18:14, 15 September 2014

2014-09-15T18:14:59Z

Danzatt at 18:14, 15 September 2014

2014-09-15T18:14:05Z

Rzhikharevich: /* Structure */

2014-09-15T17:33:49Z

‎Structure

@@ Line 3: / Line 3: @@
 '''com.apple.driver.LightweightVolumeManager''' kext wraps the block device (<code>/dev/disk0</code>) where the actual LwVM partition table is stored and publishes <code>/dev/disk0s1</code> with emulated [[Wikipedia:GUID Partition Table|GPT]] which can be edited from user-land using conventional [[Wikipedia:GUID Partition Table|GPT]] editing tools (e.g. [http://sourceforge.net/projects/gptfdisk/ gptfdisk]) [https://code.google.com/p/iphone-dataprotection/wiki/LightweightVolumeManager]. All edits are trapped by the kext and before shutting down (after the volumes are unmounted) it writes the corresponding changes to LwVM partition table on <code>/dev/disk0</code> (implemented in <code>LightweightVolumeManager::_gptLazyRepartition()</code> function from the LwVM kext). After next boot new devices (e.g. <code>/dev/rdisk0s1s3</code>) are published by the kext. This mechanism is used during [[OTA Updates]] to create third partition where the update ramdisk is copied to and booted into by setting nvram <code>boot-command</code> to <code>upgrade</code> [https://twitter.com/iH8sn0w/status/580016602512539648] and probably also <code>boot-partition</code> to <code>2</code> (partitions are indexed from 0, so third partition).
-The update partition is set up by <code>com.apple.MobileSoftwareUpdate.CleanupPreparePathService</code> (XPC service accompanying [[softwareupdated]]). It shrinks HFS of the second (data) partition using <code>fsctl</code> as illustrated in [https://github.com/danzatt/hfs_resize hfs_resize]. It then edits [[Wikipedia:GUID Partition Table|GPT]] on <code>/dev/rdisk0s1s3</code> to reflect the size of shrunk HFS and creates new entry for the update partition in the freed space and creates new HFS on it. To create file-system manually you can use e.g.: <code>newfs_hfs -s -b 8192 -J 8192k -v Data2 /dev/rdisk0s1s4</code>.
+The update partition is set up by <code>com.apple.MobileSoftwareUpdate.CleanupPreparePathService</code> (XPC service accompanying [[softwareupdated]]). It shrinks HFS of the second (data) partition using <code>fsctl</code> as illustrated in [https://github.com/danzatt/hfs_resize hfs_resize]. It then edits [[Wikipedia:GUID Partition Table|GPT]] on <code>/dev/rdisk0s1</code> to reflect the size of shrunk HFS and creates new entry for the update partition in the freed space and creates new HFS on it. To create file-system manually you can use e.g.: <code>newfs_hfs -s -b 8192 -J 8192k -v Data2 /dev/rdisk0s1s4</code>.
 == Structure ==

@@ Line 1: / Line 1: @@
 '''LwVM''' (Lightweight Volume Manager) - partition table, which is used by iOS since 5.0.
-'''com.apple.driver.LightweightVolumeManager''' kext wraps the block device (<code>/dev/disk0</code>) where the actual LwVM partition table is stored and publishes <code>/dev/disk0s1</code> with emulated [[Wikipedia:GUID Partition Table|GPT]] which can be edited from user-land using conventional [[Wikipedia:GUID Partition Table|GTP]] editing tools (e.g. [http://sourceforge.net/projects/gptfdisk/ gptfdisk]) [https://code.google.com/p/iphone-dataprotection/wiki/LightweightVolumeManager]. All edits are trapped by the kext and before shutting down (after the volumes are unmounted) it writes the corresponding changes to LwVM partition table on <code>/dev/disk0</code> (implemented in <code>LightweightVolumeManager::_gptLazyRepartition()</code> function from the LwVM kext). After next boot new devices (e.g. <code>/dev/rdisk0s1s3</code>) are published by the kext. This mechanism is used during [[OTA Updates]] to create third partition where the update ramdisk is copied to and booted into by setting nvram <code>boot-command</code> to <code>upgrade</code> [https://twitter.com/iH8sn0w/status/580016602512539648] and probably also <code>boot-partition</code> to <code>2</code> (partitions are indexed from 0, so third partition).
+'''com.apple.driver.LightweightVolumeManager''' kext wraps the block device (<code>/dev/disk0</code>) where the actual LwVM partition table is stored and publishes <code>/dev/disk0s1</code> with emulated [[Wikipedia:GUID Partition Table|GPT]] which can be edited from user-land using conventional [[Wikipedia:GUID Partition Table|GPT]] editing tools (e.g. [http://sourceforge.net/projects/gptfdisk/ gptfdisk]) [https://code.google.com/p/iphone-dataprotection/wiki/LightweightVolumeManager]. All edits are trapped by the kext and before shutting down (after the volumes are unmounted) it writes the corresponding changes to LwVM partition table on <code>/dev/disk0</code> (implemented in <code>LightweightVolumeManager::_gptLazyRepartition()</code> function from the LwVM kext). After next boot new devices (e.g. <code>/dev/rdisk0s1s3</code>) are published by the kext. This mechanism is used during [[OTA Updates]] to create third partition where the update ramdisk is copied to and booted into by setting nvram <code>boot-command</code> to <code>upgrade</code> [https://twitter.com/iH8sn0w/status/580016602512539648] and probably also <code>boot-partition</code> to <code>2</code> (partitions are indexed from 0, so third partition).
-The update partition is set up by <code>com.apple.MobileSoftwareUpdate.CleanupPreparePathService</code> (XPC service accompanying [[softwareupdated]]). It shrinks HFS of the second (data) partition using <code>fsctl</code> as illustrated in [https://github.com/danzatt/hfs_resize hfs_resize]. It then edits [[Wikipedia:GUID Partition Table|GTP]] on <code>/dev/rdisk0s1s3</code> to reflect the size of shrunk HFS and creates new entry for the update partition in the freed space and creates new HFS on it. To create file-system manually you can use e.g.: <code>newfs_hfs -s -b 8192 -J 8192k -v Data2 /dev/rdisk0s1s4</code>.
+The update partition is set up by <code>com.apple.MobileSoftwareUpdate.CleanupPreparePathService</code> (XPC service accompanying [[softwareupdated]]). It shrinks HFS of the second (data) partition using <code>fsctl</code> as illustrated in [https://github.com/danzatt/hfs_resize hfs_resize]. It then edits [[Wikipedia:GUID Partition Table|GPT]] on <code>/dev/rdisk0s1s3</code> to reflect the size of shrunk HFS and creates new entry for the update partition in the freed space and creates new HFS on it. To create file-system manually you can use e.g.: <code>newfs_hfs -s -b 8192 -J 8192k -v Data2 /dev/rdisk0s1s4</code>.
 == Structure ==

@@ Line 1: / Line 1: @@
 '''LwVM''' (Lightweight Volume Manager) - partition table, which is used by iOS since 5.0.
-'''com.apple.driver.LightweightVolumeManager''' kext wraps the block device (<code>/dev/disk0</code>) where the actual LwVM partition table is stored and publishes <code>/dev/disk0s1</code> with emulated [[Wikipedia:GUID Partition Table|GTP]] which can be edited from user-land using conventional [[Wikipedia:GUID Partition Table|GTP]] editing tools (e.g. [http://sourceforge.net/projects/gptfdisk/ gptfdisk]) [https://code.google.com/p/iphone-dataprotection/wiki/LightweightVolumeManager]. All edits are trapped by the kext and before shutting down (after the volumes are unmounted) it writes the corresponding changes to LwVM partition table on <code>/dev/disk0</code> (implemented in <code>LightweightVolumeManager::_gptLazyRepartition()</code> function from the LwVM kext). After next boot new devices (e.g. <code>/dev/rdisk0s1s3</code>) are published by the kext. This mechanism is used during [[OTA Updates]] to create third partition where the update ramdisk is copied to and booted into by setting nvram <code>boot-command</code> to <code>upgrade</code> [https://twitter.com/iH8sn0w/status/580016602512539648] and probably also <code>boot-partition</code> to <code>2</code> (partitions are indexed from 0, so third partition).
+'''com.apple.driver.LightweightVolumeManager''' kext wraps the block device (<code>/dev/disk0</code>) where the actual LwVM partition table is stored and publishes <code>/dev/disk0s1</code> with emulated [[Wikipedia:GUID Partition Table|GPT]] which can be edited from user-land using conventional [[Wikipedia:GUID Partition Table|GTP]] editing tools (e.g. [http://sourceforge.net/projects/gptfdisk/ gptfdisk]) [https://code.google.com/p/iphone-dataprotection/wiki/LightweightVolumeManager]. All edits are trapped by the kext and before shutting down (after the volumes are unmounted) it writes the corresponding changes to LwVM partition table on <code>/dev/disk0</code> (implemented in <code>LightweightVolumeManager::_gptLazyRepartition()</code> function from the LwVM kext). After next boot new devices (e.g. <code>/dev/rdisk0s1s3</code>) are published by the kext. This mechanism is used during [[OTA Updates]] to create third partition where the update ramdisk is copied to and booted into by setting nvram <code>boot-command</code> to <code>upgrade</code> [https://twitter.com/iH8sn0w/status/580016602512539648] and probably also <code>boot-partition</code> to <code>2</code> (partitions are indexed from 0, so third partition).
 The update partition is set up by <code>com.apple.MobileSoftwareUpdate.CleanupPreparePathService</code> (XPC service accompanying [[softwareupdated]]). It shrinks HFS of the second (data) partition using <code>fsctl</code> as illustrated in [https://github.com/danzatt/hfs_resize hfs_resize]. It then edits [[Wikipedia:GUID Partition Table|GTP]] on <code>/dev/rdisk0s1s3</code> to reflect the size of shrunk HFS and creates new entry for the update partition in the freed space and creates new HFS on it. To create file-system manually you can use e.g.: <code>newfs_hfs -s -b 8192 -J 8192k -v Data2 /dev/rdisk0s1s4</code>.

@@ Line 47: / Line 47: @@
 </pre>
 All disk read operations started resulting with errors. Then my device rebooted and entered a boot loop. The code possibly messed the partition table up.
 == Tools ==

← Older revision		Revision as of 13:33, 12 June 2015
Line 1:		Line 1:
	'''LwVM''' (Lightweight Volume Manager) - partition table, which is used by iOS since 5.0.		'''LwVM''' (Lightweight Volume Manager) - partition table, which is used by iOS since 5.0.

		+	'''com.apple.driver.LightweightVolumeManager''' kext wraps the block device (<code>/dev/disk0</code>) where the actual LwVM partition table is stored and publishes <code>/dev/disk0s1</code> with emulated [[Wikipedia:GUID Partition Table\|GTP]] which can be edited from user-land using conventional [[Wikipedia:GUID Partition Table\|GTP]] editing tools (e.g. [http://sourceforge.net/projects/gptfdisk/ gptfdisk]) [https://code.google.com/p/iphone-dataprotection/wiki/LightweightVolumeManager]. All edits are trapped by the kext and before shutting down (after the volumes are unmounted) it writes the corresponding changes to LwVM partition table on <code>/dev/disk0</code> (implemented in <code>LightweightVolumeManager::_gptLazyRepartition()</code> function from the LwVM kext). After next boot new devices (e.g. <code>/dev/rdisk0s1s3</code>) are published by the kext. This mechanism is used during [[OTA Updates]] to create third partition where the update ramdisk is copied to and booted into by setting nvram <code>boot-command</code> to <code>upgrade</code> [https://twitter.com/iH8sn0w/status/580016602512539648] and probably also <code>boot-partition</code> to <code>2</code> (partitions are indexed from 0, so third partition).
		+
		+	The update partition is set up by <code>com.apple.MobileSoftwareUpdate.CleanupPreparePathService</code> (XPC service accompanying [[softwareupdated]]). It shrinks HFS of the second (data) partition using <code>fsctl</code> as illustrated in [https://github.com/danzatt/hfs_resize hfs_resize]. It then edits [[Wikipedia:GUID Partition Table\|GTP]] on <code>/dev/rdisk0s1s3</code> to reflect the size of shrunk HFS and creates new entry for the update partition in the freed space and creates new HFS on it. To create file-system manually you can use e.g.: <code>newfs_hfs -s -b 8192 -J 8192k -v Data2 /dev/rdisk0s1s4</code>.

	== Structure ==		== Structure ==

@@ Line 30: / Line 30: @@
 static const char LwVMPartitionTypeHFS[] = { 0x48, 0x46, 0x53, 0x00, 0x00, 0x00, 0x11, 0xAA, 0xAA, 0x11, 0x00, 0x30, 0x65, 0x43, 0xEC, 0xAC };
 </pre>
 == Tools ==

@@ Line 10: / Line 10: @@
         uint64_t end; //End.
         uint64_t attribute; // 0 == unencrypted; 0x1000000000000 == encrypted
-        char partitionName[0x48]; //For an unknown reason every char is separated by null.
+        uint16_t partitionName[0x24]; // UTF-16 encoded
 } __attribute__ ((packed)) LwVMPartitionRecord;

← Older revision		Revision as of 18:14, 15 September 2014
Line 35:		Line 35:

	== External links ==		== External links ==
−	[https://code.google.com/p/iphone-dataprotection/wiki/LightweightVolumeManager ~~description of LwVM on~~ iPhone dataprotection wiki]	+	[https://code.google.com/p/iphone-dataprotection/wiki/LightweightVolumeManager iPhone dataprotection wiki]

← Older revision		Revision as of 18:14, 15 September 2014
Line 33:		Line 33:
	== Tools ==		== Tools ==
	[http://www.github.com/rzhikharevich/lwvmedit lwvmedit]		[http://www.github.com/rzhikharevich/lwvmedit lwvmedit]
		+
		+	== External links ==
		+	[https://code.google.com/p/iphone-dataprotection/wiki/LightweightVolumeManager description of LwVM on iPhone dataprotection wiki]

@@ Line 5: / Line 5: @@
 <pre>
 typedef struct _LwVMPartitionRecord {
-        uint64_t type[2];
+        uint64_t type[2]; //Should be equal to LwVMPartitionTypeHFS (see below) on an unmodified device.
-        uint64_t guid[2];
+        uint64_t guid[2]; //Random.
-        uint64_t begin;
+        uint64_t begin; //Partitions begin in bytes.
-        uint64_t end;
+        uint64_t end; //End.
         uint64_t attribute; // 0 == unencrypted; 0x1000000000000 == encrypted
-        char partitionName[0x48];
+        char partitionName[0x48]; //For an unknown reason every char is separated by null.
 } __attribute__ ((packed)) LwVMPartitionRecord;
 typedef struct _LwVM {
-        uint64_t type[2];
+        uint64_t type[2]; //Should be LwVMType or LwVMType_noCRC.
-        uint64_t guid[2];
+        uint64_t guid[2]; //Random.
-        uint64_t mediaSize;
+        uint64_t mediaSize; //Size in bytes.
-        uint32_t numPartitions;
+        uint32_t numPartitions; //Number of partitions.
         uint32_t crc32;
-        uint8_t unkn[464];
+        uint8_t unkn[464]; //Some unknown bytes, usually nulls.
         LwVMPartitionRecord partitions[12];
         uint16_t chunks[1024]; // chunks[0] should be 0xF000