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

Cannot handle empty <integer /> #49

Open
blacktop opened this issue Dec 25, 2019 · 3 comments
Open

Cannot handle empty <integer /> #49

blacktop opened this issue Dec 25, 2019 · 3 comments
Labels
Milestone

Comments

@blacktop
Copy link

I'm trying to parse the __PRELINK_INFO.__info section on an iOS kernelcache and the embedded plist gives the above error.

Here is a snippet.

<key>UIDeviceFamily</key>
<array>
    <integer IDREF="2"/>
</array>

I know this isn't valid plist/xml, but Apple seems to think it is?

Is there anything I/we can do?

Thanks!!

@blacktop
Copy link
Author

@blacktop blacktop changed the title Cannot handle empty <integer> Cannot handle empty <integer /> Dec 25, 2019
@DHowett
Copy link
Owner

DHowett commented Dec 26, 2019

So, this is a really curious case. Apple has a number of different XML property list parsers, and cases like this really show off their differences.

I think the kernel one is closer to an actual XML parser. The CoreFoundation one, however, is not. That is most evident here:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
    <integer IDREF="2" />
</plist>
Error Domain=NSCocoaErrorDomain Code=3840 "Encountered empty <integer> on line
4" UserInfo={NSDebugDescription=Encountered empty <integer> on line 4,
kCFPropertyListOldStyleParsingError=Error Domain=NSCocoaErrorDomain Code=3840
"Malformed data byte group at line 1; invalid hex"
UserInfo={NSDebugDescription=Malformed data byte group at line 1; invalid hex}}

Unfortunately, they haven't really specified the format quite well enough for us to make a determination about what is correct.

Is the prelink property list using a different DOCTYPE declaration than a standard XML property list?

@blacktop
Copy link
Author

blacktop commented Dec 27, 2019

The plist embedded in the binary starts with a <dict> tag with no header. I fixed it in my fork here, but it is a total hack and probably not a good solution: blacktop@a935e2e#diff-b46f388ecac749399ab6e09b6c0f1121L89

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

No branches or pull requests

2 participants