Successfully downgraded iPad 1 to iPhone OS 3.2.x untethered

[TechEnthusiasm]

This is just my method for this downgrade, in case it is useful, apologies if this is the wrong place to post. I used Legacy iOS kit p0ndersn0w option for iPhone os 3.2.2, to get the appropriate NAND img3 files flashed for exploitation. Then I used a custom ipsw I found somewhere and set FlashNOR to false in the Ramdisk, to avoid flashing images again. This is for 3.2.2 and 3.2.1 btw and after that, ran ssh ramdisk to use fdisk to partition mbr to get a 64KB HFS volume. There was no need to resize other partitions. I did 64kb = 65536 bytes divided by the sector size which was 4096 bytes on my device to get 16. To get sector size just type in "p" in the interactive prompt. The commands I did are in the screenshot Then I installed the exploit using dd and set nvram variables and had to upload iBEC from the legacy iOS kit ipsw onto device rootfs, because rootfs dmg in ipsw is read-only Thanks a lot for the script, it makes it a lot for me, to set this setup, like booting SSH ramdisk!

Links to the modified custom ipsw: 3.2.1:https://drive.google.com/drive/u/1/folders/1OdK3UGIiiDgHxhYJoABi_ZmmXqH3ZSBD
3.2.2:https://drive.google.com/drive/u/1/folders/1kwY_BcN-HeA6OQJ5gGWliVWZWUrJnnUE

Original source for custom ipsw:https://drive.google.com/drive/u/1/folders/0Bx2X3o1VIqhESVY0YUsyUWFfV0U?resourcekey=0-i6kLkAZ0fmip1kVsQjfBDw

[TechEnthusiasm]

Also not all custom ipsws work for my device, some geekgrade and iFaith ones fail when connecting to asr. Used legacy iOS kit custom ipsw for restoring everything, including the custom ipsw, rather than ancient iTunes.

[LukeZGD]

Thanks for this, I will be checking this out later

[LukeZGD]

Do you know on how to proceed here when partition resizing is required? While there was also no need for resizing on my device when I tested, other testers end up with no space to create a 3rd partition for the exploit ramdisk

[Jefferyat]

This is for 3.2.2 and 3.2.1 btw and after that, ran ssh ramdisk to use fdisk to partition mbr to get a 64KB HFS volume. There was no need to resize other partitions

[Jefferyat]

I did 64kb = 65536 bytes divided by the sector size which was 4096 bytes on my device to get 16. To get sector size just type in "p" in the interactive prompt. The commands I did are in the screenshot

[LukeZGD]

yes i know, i just saw the issue on my implementation now

ill just dynamically adjust the partition offset

[TechEnthusiasm]

Tbh, I haven't really thought before about there not being enough space for the partition, apologies for overlooking this. My device has 32GB so I'd assume that those models would work fine. So far I have tried using hfs_resize and editing the mbr table on data partition, causes my device to enter a bootloop. I guess other users should test this and then maybe we'll know weather this is needed.

[LukeZGD]

ok so i tried to adjust the partition offset to other than what fdisk suggests and it doesnt help, messes with the data partition, and didnt boot anyway..

looks like there really is no space for the 3rd partition, as indicated with 0 on the partition size.. and yeah i also tried messing with the data partition before to no avail

for those that have the space for it including myself, looks like it works fine

3 other testers have tested it so far (2 ipad 1, 1 touch 3), all failed because of being unable to create a 3rd partition

[TechEnthusiasm]

Try resizing the system partition from 1.2GB to 1GB in the mbr table. That does work successfully on my device and it does boot afterwards.

[LukeZGD]

what did you do/use for resizing?

[TechEnthusiasm]

Used fdisk, edited partition 1, converted 1GB to bytes, and divided by the sector size on my device and put that in for the size. Didn't use any other tools and everything else default.

[LukeZGD]

thanks, this seems to work, will be pushing preliminary support to main for testing

[TechEnthusiasm]

Apologies, I have realised that resizing System partition doesn't give more space for exploit using default offsets, because the data partition is at the same address as it was before the process. Make sure to mount partitions before editing mbr. The offset for the exploit partition can be calculated by the start offset and the size of the system partition.

On my device the system partition starts at 63 and my modified size is 262144. Add these values up and the value is the offset that should be used for the exploit partition.

[LukeZGD]

Thanks, yeah I also noticed that when doing the resize, disk0s1 cannot be fsck'ed anymore so there's also the issue, I'll change the offset calculation

[LukeZGD]

Change pushed, closing now

Much thanks for all the help