Recovering data with Ramdisk and SSH, connection woes

Discussion in 'iOS 6' started by Techshui, Oct 17, 2013.

  1. Techshui macrumors newbie

    Aug 16, 2013
    Currently I'm trying to recover data from my iPod Touch 4G.

    Gecko iPhone Toolkit loads up it's Ramdisk and my iPod displays

    listening port 1999 and running /sbin/sshd
    I try connecting with PuTTY to localhost:2222, doesn't work. I get "Network error: Connection refused".

    Apperently, GIT doesn't usbmux to forward the ports until you run their bruteforce script (which I don't want to do because I'm not trying to crack my passcode, I'm just recovering data).

    So I used itunnelmux.exe --lport 22
    C:\Users\Owner\Downloads\itunnel_mux_rev71>itunnel_mux.exe --lport 22
    [ERROR] locate_AMRecoveryModeDeviceSendFileToDevice: Could not locate function p
    [INFO] Waiting for new TCP connection on port 22
    [INFO] Waiting for device...
    [INFO] Device connected: ramdisk tool Dec  1 2011 14:40:41
    At this point I run PuTTY, pointing it to localhost and port 22, this time it doesn't refuse the conection, but the itunnelmux windows says this:

    [INFO] Info: New connection...
    [ERROR] AMDeviceConnect = -402653083
    [ERROR] Error: Device Connect
    And of course PuTTY just hangs. What can I do :(

    EDIT: What does _AMRecoveryModeDeviceSendFileToDevice refer to? That appears to be the problem?
  2. Techshui thread starter macrumors newbie

    Aug 16, 2013
    OK, I've tried a different approach: Using msftguy's runnable JAR file

    However when I run the jar file, at the stage where it's supposed to send the syringe exploit and load the Ramdisk, it simply kicks it out of DFU mode back into normal.

    So I tried copying the files created in my temp/ssh_rd folder, and manually running
    tetheredboot.exe -i [iBSS dfu file] -k [kernel file] -r [ramdisk]

    This happens:
    Initializing libpois0n
    ERROR: The process "iTunes.exe" not found.
    ERROR: The process "iTunesHelper.exe" not found.
    Waiting for device to enter DFU mode
    Device must be in DFU mode to continue
    Device must be in DFU mode to continue
    Device must be in DFU mode to continue
    Device must be in DFU mode to continue
    Device must be in DFU mode to continue
    And yes, of course it's in DFU mode, but shouldn't tetheredboot be sending the syringe exploit, instead of libpois0n? How do I force it to use the correct exploit?

    Or could there be another reason why it's not communicating with the device?


Share This Page