Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incomplete and duplicated DLLs #187

Open
brian6932 opened this issue Apr 19, 2024 · 11 comments
Open

Incomplete and duplicated DLLs #187

brian6932 opened this issue Apr 19, 2024 · 11 comments
Assignees

Comments

@brian6932
Copy link

brian6932 commented Apr 19, 2024

Describe the bug
https://i.alienpls.org/AppleMobileDeviceSupport64.msi

The following DLLs are required, for the service to run (these are the expected sizes, from an msi install)

  Length Name
  ------ ----
  235872 AppleMobileDeviceService_main.dll
  103776 AppleMobileDeviceService.exe
   28984 AppleVersions.dll
   80696 ASL.dll
 1861408 CFNetwork.dll
 2230584 CoreFoundation.dll
27159352 icudt62.dll
   45880 libcache.dll
  104760 libdispatch.dll
 2457912 libicuin.dll
 1579320 libicuuc.dll
 1320224 libxml2.dll
 3888480 MobileDevice.dll
  237368 objc.dll
   95544 pthreadVC2.dll
  991008 SQLite3.dll

Out of those, from just looking at byte lengths, (these are broken, extracted by lessmsi)

 Length Name
 ------ ----
  37688 libcache.dll
2117944 libicuin.dll
1042208 libxml2.dll
3183456 MobileDevice.dll
  72504 pthreadVC2.dll

To Reproduce

lessmsi.exe x AppleMobileDeviceSupport64.msi

Expected behavior
Should work.

Desktop:

  • OS: Windows 10
brian6932 added a commit to brian6932/dank-scoop that referenced this issue Apr 21, 2024
Waiting on activescott/lessmsi#187

todo:
    Reverse engineer service with sc.exe/Registry
    Deduplicate and symlink shared DLLs between MDS and AAS
@activescott
Copy link
Owner

@brian6932 I suspect this is because there are two of these files in that msi. After extracting them I ran the following commands to see the files:

C:\Users\scott\Downloads>dir /s AppleMobileDeviceSupport64\SourceDir | findstr libcache.dll
11/08/2023  04:37 PM            37,688 libcache.dll
11/08/2023  04:31 PM            45,880 libcache.dll.duplicate1

That .duplicate1 extension is added by lessmsi when it detects it is extracting a file into athe same place. Just guessing, but maybe they have x32 x64 versions in there and the lessmsi logic extracts only one based on the target OS.

You can also open that msi up in the GUI and do a Ctrl+F fr libcache.dll and you'll see both of them there too:

Screenshot 2024-04-23 at 16 40 40

I'm closing this issue with the assumption that gets you straightened out, but if not, feel free to re-open or open another issue.

@brian6932
Copy link
Author

brian6932 commented Apr 24, 2024

You're right about the duplicates being the right sizes, but msiexec doesn't do this. I'd wager there's some way you can tell which dll is for which platform, or some flag should be added to choose the largest duplicate, storing a bunch of sizes in a table isn't a modular approach to this, and it doesn't make a ton of sense to extract 2x the data I actually need.

@activescott
Copy link
Owner

Well I don't think those bits are being mangled, but I suspect there is some heuristic that could be used to fix the paths. When I was looking at this yesterday I noticed they were linked to two different install directories with a 64 or 32 in the names. Looking at the Directory table closer now I see these two files ultimately resolve to a directory named CommonFiles64Folder and CommonFilesFolder that have the same default value of Common Files. Which is where it gets put and one overwrites the other.

I suppose we could implement some logic in lessmsi to detect at least those root-level duplicate directory names (root level == TARGETDIR per https://learn.microsoft.com/en-us/windows/win32/msi/directory-table#remarks) and differentiate them somehow like Common Files-CommonFiles64Folder and Common Files-CommonFilesFolder or something.

Would that meet your needs?

P.S. Some of this is a bit of a note to myself :)

msi Directory table 01 INSTALLDIR msi Directory table 02 MobileDeviceFolder msi Directory table 03 AppleFolder msi Directory Table 04 CommonFiles msi Directory table 05 TARGETDIR

@activescott activescott reopened this Apr 24, 2024
@brian6932
Copy link
Author

brian6932 commented Apr 24, 2024

Yea SGTM

@mega5800
Copy link
Contributor

Hello @activescott @brian6932

I found a way to differentiate between 32 bit and 64 bit dll files, regardless of their name or file path.

@brian6932 what would be the best outcome for you?

Would you like LessMSI CLI to extract only the files relevant to your system?
I.e. ignoring any 32bit files where your system is 64 bit and vice versa.

Or would you like to preserve the ability to extract all the files using a designated flag?

Thank you.

@brian6932
Copy link
Author

brian6932 commented Jul 17, 2024

Would you like LessMSI CLI to extract only the files relevant to your system?
I.e. ignoring any 32bit files where your system is 64 bit and vice versa.

Imo, yes when a duplicate filename exists as the default behavior, but there should be flags to alter it, and maybe one to ignore altogether (e.g. -a <arch>, --architecture <arch>, --ignore-architectre).

@activescott
Copy link
Owner

Great, what is the way to differentiate? Will it work with all msi's?

Agree with the flag.

What if someone wants both versions? Would they do the extraction twice (which is probably fine)?

@mega5800
Copy link
Contributor

@activescott, using the PEHeader Magic property I can easily check if a PE file (dll, exe and so on) is 32 or 64 bit.

IMO x command should yield both versions, as there are scripts using LessMSI which expect this kind of behaviour.
If the user would like to get the 64 bit files, they can run the next command:

lessmsi.exe x path/to/msi -a=64

And so on for the 32 bit.
Thoughts?

@activescott
Copy link
Owner

Sounds good. Let's try it!

@mega5800
Copy link
Contributor

@activescott Can you please assign this ticket to me?

I think this ticket and the overwrite ticket are related and can be solved together by one update.

@activescott
Copy link
Owner

Assigned to you. I was thinking that it is possible the original issue that I described above will still need solved in addition to doing the architecture flag - as some files might turn out to be duplicates that are not DLLs. I'm not positive that would happen but it seems plausible.
Anyway, I think the architecture flag is still a great idea though so we should start there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants