Hi,

I had an iPhone 4 working fine on 4.3.5 tethered JB using redsn0w.

I wanted to test something involving ssh ramdisks, so booted an 4.3.2 ibss/kernelcache/dmg.ssh on the phone using tetheredboot thinking it would be compatible.

This seemed to work fine, the empty progress bar screen came up and the device connected in itunnel. However, the instant I connected to the forwarded ssh port from my mac, the phone rebooted.

It then went into recovery mode no matter what I did. If I tried to boot 4.3.5 tethered again with redsn0w it would show the pwnapple briefly but end up on the 'connect to itunes' logo. I tried running fixrecovery43 and recovery fix in the new redsn0w_mac_0.9.9b1 to no avail.

I then built a proper 4.3.5 SSH ramdisk (using msftguy's recovery ramdisk builder v3, pwnagetool 4.3.3 with added 4.3.5 bundle). This works fine - I am able to ssh in without problems, but in /dev there is only /dev/disk0 and /dev/rdisk0, no partitions are visible.

Trying to dd from /dev/disk0 I just get 'invalid argument' so I can't even access the disk device. What has been scewed up here, and how can I fix it?

Even though I only booted the 4.3.2 SSH ramdisk and did not actually run a restore, something has been screwed up so that a 4.3.5 ramdisk or the normal OS itself booting tethered now seems unable to mount my partitions.

I have a few months of un-backed-up precious photos and other data on this phone so i really don't want to do a full restore and would be grateful for any tips

I think my NAND has been screwed up somehow.

Are there any tools I can use to dump the start of my NAND to see what's currently there?

You need to mount the partitions (although it seems a bit odd that the /dev/disk0 and /dev/rdisk0 are missing)

It's impossible to use dd to backup the filesystem on iOS 4.x due to the way the new security system/encryption is implemented.

As you say, it could be NAND that has failed (iRecovery will show you this)

The only disk-related devices I can see listed in /dev are /dev/disk0 and /dev/rdisk0. See output below running fdisk and trying to mount.

I've used ssh ramdisks successfully before on a few different devices and versions, and I'm totally at a loss to explain why attempting to boot the 4.3.2 ssh ramdisk on my 4.3.5 phone has caused this corruption.

I will try running iRecovery.

Is a NOR-only restore a possibility on an iPhone 4 with 4.3.5 if I customise /usr/local/share/restore/options.plist to disable CreateFilesystemPartitions ?

-sh-4.0# fdisk /dev/disk0
Disk: /dev/disk0 geometry: 977/64/63 [3939606 sectors]
Sector size: 8192 bytes
Signature: 0x0
Starting Ending
#: id cyl hd sec - cyl hd sec [ start - size]
------------------------------------------------------------------------
1: 00 0 0 0 - 0 0 0 [ 0 - 0] unused
2: 00 0 0 0 - 0 0 0 [ 0 - 0] unused
3: 00 0 0 0 - 0 0 0 [ 0 - 0] unused
4: 00 0 0 0 - 0 0 0 [ 0 - 0] unused

-sh-4.0# mount_hfs /dev/disk0s1 /mnt1
GetMasterBlock: Error 2 opening /dev/rdisk0s1
GetMasterBlock: Error 2 opening /dev/rdisk0s1
mount_hfs: No such file or directory

-sh-4.0# mount_hfs /dev/disk0s2s1 /mnt2
GetMasterBlock: Error 2 opening /dev/rdisk0s2s1
GetMasterBlock: Error 2 opening /dev/rdisk0s2s1
mount_hfs: No such file or directory

Originally Posted by hopelessCase

Is a NOR-only restore a possibility on an iPhone 4 with 4.3.5 if I customise /usr/local/share/restore/options.plist to disable CreateFilesystemPartitions ?

I haven't tested it myself, but have not seen anything to suggest that Apple has disabled or blocked this functionality. It can't really hurt to give it a try (you need to restore in pwned DFU mode of course)

I think I've found the explanation for what happened on my phone:

Issue 19 - iphone-dataprotection - Issues after starting a RAMdisk on a device with iOS 4.3.4 - iphone data protection tools - Google Project Hosting

This gives me some hope that the problem is reparable and that the decryption keys and data are still there...

That's a good find. Please keep us updated if you do fix this.