How should the emulator be restored?

[aellul27]

I've tried to use the branch supplied by TrungNguyen1909 and had no luck.
Are you using a patched version of the current idevicerestore?

[whitebelyash]

qemu-t8030 idevicerestore fork requires one small change to build, then it works for master branch of QEMUAppleSilicon.
I've succesfully restored iOS 14b1 using t8030 wiki.

For some reason, sep emu branch fails with SEP ROM panic for me even though I use a decrypted T8030 SEPFW/SEPROM.

[VisualEhrmanntraut]

For some reason, sep emu branch fails with SEP ROM panic for me even though I use a decrypted T8030 SEPFW/SEPROM.

did you wrap it back into an img4? it should be obvious it needs to be in this format when the original is an img4

[whitebelyash]

did you wrap it back into an img4? it should be obvious it needs to be in this format when the original is an img4

Actually thought of this, might retry again.
UPD. yep, it's now accepting 14.7.1 SEP firmware.

[Krylx7]

How would one go about acquiring the SEPROM/SEPFW? Are the files from [REDACTED] sufficient?

[Arbifoxx]

For some reason, sep emu branch fails with SEP ROM panic for me even though I use a decrypted T8030 SEPFW/SEPROM.

did you wrap it back into an img4? it should be obvious it needs to be in this format when the original is an img4

Sorry to add onto this, but how would you wrap the sepfw into an img4? I've successfully decrypted and extracted mine but from there I'm not sure what to do. Also, should the seprom be an img4 as well?

[VisualEhrmanntraut]

and - you can always just let us do our work in peace and patiently wait for the release of the instructions. :)

[chris-pcguy]

With 2048 bytes, ...

Just NO, NOT for both!

I do not understand this, nor will I try to understand this. I could also be entirely wrong. I will leave this until I have more information to try out.

So you're saying that you're not even trying to give it the least amount of effort and that you're purposefully distributing wrong information, so other people will potentially have an even harder time understanding this than you?

Some background:
SSC was introduced with t8020, it didn't exist with t8015. So with <= t8015, all the data were in the sep_nvram. But with >= t8020, everything that didn't needed to be in nvram was moved to the ssc/lynx/ocelot.

maybe you would understand a tire size analogy better:
<= t8015, a unicycle
>= t8020, NOT a regular bicycle, BUT a penny-farthing bicycle, like they once rode on jackass. with the bigger wheel standing for the ssc.

[Arbifoxx]

So you're saying that you're not even trying to give it the least amount of effort and that you're purposefully distributing wrong information, so other people will potentially have an even harder time understanding this than you?

I am sorry, I worded that wrong, that is not what I meant. I did not want to speculate on what the error might have been because it would have most likely been wrong. I am not trying to give zero effort, but I don't want to share what I think it could be as I have no foundation to guess. It seems that my speculations are what brought us to this situation, so I think it is best for me to step away from this project. It is clearly above my pay-grade and I seem to only be doing harm. I was only saying what I thought was working, hence why I made it a point to emphasize that I could be entirely wrong. I never stated that the steps I tried were the correct steps. I apologize for your time, and for my ignorance, and I look forward to the progression of this project.

[VisualEhrmanntraut]

Relax waterdragon. Just follow the man's gist..

[Arbifoxx]

I was actually able to get it to boot using the gist and it restored all the way up to

entering update_sep

libMobileGestalt MobileGestalt.c:711: RestoreLog: Client Query: Image4CryptoHashMethod

2025-05-20 22:07:39.033384+0000 restored_external[7:431] RestoreLog: Client Query: Image4CryptoHashMethod

libMobileGestalt MobileGestalt.c:743: RestoreLog: Client Response: Image4CryptoHashMethod : sha2-384

2025-05-20 22:07:39.036473+0000 restored_external[7:431] RestoreLog: Client Response: Image4CryptoHashMethod : sha2-384

ramrod_copy_manifest_digest_data_from_img4: failed to parse img4Data as Img4

[22:07:39.0051-GMT]{1>4} CHECKPOINT NOTICE: Post-engines NVRAM variable: restore-outcome=initial_engine_no_return

Tue May 20 22:07:39 2025 localhost com.apple.xpc.launchd[1] <Error>: Host-level exception raised: pid = 7, thread = 0x933, exception type = 0xd, codes = { 8589934603 }, states = { 0 }

[22:07:39.0089-GMT]{1>4} CHECKPOINT PROGRESS: NO_REBOOT_RETRY (initial_monitor_no_return) -> (recovery_mode)

Is this a normal error? I've been using the "sep-firmware.n104.RELEASE.im4p.out.new.img4" sepfw that the create_sep.sh made as that's what the launch script uses. I noticed that chris-pcguy stated to not repack the firmware without the proper manifest, does the ipsw have to be modified in some way?

[chris-pcguy]

Is this a normal error?

... no?

Are you sure that you use the SEPFW of t8030 v14.7.1?
Also make sure that you're using the sep ticket for repacking, not the ap ticket.

[Arbifoxx]

That was the only patch I could find and it was on gist, but I decided to edit it out since it did seem quite old and I wasn't truly sure if that was the correct patch. I will try the updated patch/build script.

[Arbifoxx]

The restore completes! It reboots but hangs on messages similar to tx_flush:1075: disk0s1 xid 231 tx stats: # 160 finish 163 enter 1072 wait 7 6653us close 295us flush 7899us that continue to display every minute or so with the bar very close to being full. Is this what's to be expected at the emulator's current state?

[VisualEhrmanntraut]

correct, this is the expected result without the filesystem patches

[Arbifoxx]

How would I go about those?

[VisualEhrmanntraut]

wait until release or figure it out yourself

[aellul27]

Now that localhost usb has been implemented, how can we restore the emulator over that?

[VisualEhrmanntraut]

add to "-M" argument usb-conn-type=ipv4,usb-conn-addr=127.0.0.1,usb-conn-port=8030 and then to companion "-device usb-tcp-remote" one conn-type=ipv4,conn-addr=127.0.0.1,conn-port=8030