The extracted AEA key file is missing one

[ssdswi]

What happened?

There are two *dmg.aea in IPSW file,but only can extract one key by *dmg.aea.pem. The other unextracted key is the key for the most critical dmg file, which is the largest in file size.

How can we reproduce this?

use ‘ipsw extract --fcs-key’

ipsw version

Version: 3.1.544,

Search

• [X] I did search for other open and closed issues before opening this

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

Additional context

No response

[ssdswi]

Oh,i'm sry.I found the fs and the sys fcs key are the same.It's my fault. But i can't open any ios18 decrypted *.dmg file with “Transmac” on Windows. I can open the biggest ios17 and before *.dmg file in IPSWs at “transmac”APP in Windows. That's why I made this mistake. Is there any other way to open it on Windows?

[blacktop]

do you have apfs-fuse installed?

[blacktop]

if so you could try: ipsw mount fs IPSW.ipsw

[ssdswi]

I'm using the apfs-fuse project, which seems to only work in a Linux environment, so I tried to mount the dmg using "ipsw mount" in a Linux environment, but it seems that ipsw doesn't call my compiled apfs-fuse directly even though I've added it to the $PATH.

So I tried extracting the dmg file and then mounting it directly using "apfs-fuse" and it seems to work. So in fact the decrypted dmg file should be correct, but there doesn't seem to be a way to use the file inside the dmg directly on Windows at the moment, but it should work fine on Linux or macos!

So how exactly should I use "ipsw mount" directly within the ipsw project without prompting for the apfs command not found? Or is it possible to fully port this project to Windows?

ps:I'm a novice. Forgive my ignorance,please!

[blacktop]

that is strange, I wonder if you can all apfs-fuse from anywhere (not just in the 'buid' folder to show it really can be found in your PATH?

I'm going to add a PATH lookup to then use the absolute path, let me know if that fixes anything for you too?

[aman77724]

Doss this issue resolved or is there another way to extract that big .dmg.aea file .

[Hamm0udx]

do you have apfs-fuse installed?

Please make a video with the steps. I am a big fan of your work, but I did not understand the method.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 5 days with no activity.

[MicahMartin]

that is strange, I wonder if you can all apfs-fuse from anywhere (not just in the 'buid' folder to show it really can be found in your PATH?

I'm going to add a PATH lookup to then use the absolute path, let me know if that fixes anything for you too?

for some reason ipsw can't find apfs-fuse but I definitely have it installed, and I'm finding it in my little test script :/

[blacktop]

What version of Go are you using? And are you running your test inside of docker?

[MicahMartin]

What version of Go are you using? And are you running your test inside of docker?

go version go1.23.9 linux/amd64 im not running inside dockerk

[blacktop]

ipsw is built with latest 1.24 Go, also I assume this is running on Linux (the failure) and not in Docker?

That makes no sense to me as it's doing that same thing:

https://github.com/blacktop/ipsw/blob/25c2444b16bbc9ea62d43f6750dcdbc60bbce86d/internal/utils/macos.go#L478

[MicahMartin]

ipsw is built with latest 1.24 Go, also I assume this is running on Linux (the failure) and not in Docker?

That makes no sense to me as it's doing that same thing:

ipsw/internal/utils/macos.go

Line 478 in 25c2444

apfsFusePath, err := execabs.LookPath("apfs-fuse")

yeah its really weird.. It must be something on my system? (ubuntu 24.04) I'm pulling down the repo now to see if I can replicate it with a build. I'm currently using the snap version

[blacktop]

Thank you for your help @MicahMartin !

[MicahMartin]

works when built from source!?

here's my snap version - Version: 3.1.605, BuildCommit: 7b938f50cba17c9736e93e2694fb4df65650477a.

I appreciate all the work you put into this repo, ima spend some time & see if I can figure it out and contribute! Its so weird though because it's literally the same code.

I don't see how this could be the issue since fuse is installed to /usr/local/bin.. https://github.com/golang/sys/blob/3d9a6b80792a3911da1fa665c959a5ede3abf476/execabs/execabs.go#L50

[blacktop]

It might be due to the sandboxing that snap is doing?

[blacktop]

maybe we need to change the confinement? https://github.com/blacktop/ipsw/blob/25c2444b16bbc9ea62d43f6750dcdbc60bbce86d/.goreleaser.yml#L718

[MicahMartin]

Im looking into it now, turning my local ipsw into a snap repo & running it locally with strict confinement. and if it is the case, I'll look into using https://snapcraft.io/docs/interfaces - this is just my opinion but if you could avoid having users specify --classic when installing that'd cleaner fair to say?

[blacktop]

That sounds good to me. I'm 💯 🍎 so I don't use any of the linux installers, but like to support ALL the pkg mgrs and make it as easy as possible for people to install run ipsw on their platform of choice. I want to protect their security and privacy in any ways that I can, so I set up the snap pipeline w/ hopefully good defaults. If there are better settings I am open to that.

[MicahMartin]

https://github.com/blacktop/ipsw/pull/723