class dump objc categories class name missed for NSObject/UIView etc.

[Rokey1990]

What happened?

objc code:

@interface NSObject(ExtensionDemo)

- (void)ext_test1;

@end

command:
ipsw cd ReviewToolDemo -a ExtensionDemo

output:

@interface (ExtensionDemo)

/* instance methods */
- (void)ext_test1;

@end

the classVMAddr=0, it seems GetBindName from the macho file not works.

How can we reproduce this?

ReviewToolDemo.zip
ipsw cd ReviewToolDemo -a ExtensionDemo

ipsw version

Version: 3.1.470, BuildCommit: 0f0880bb8ea7688ed5d8afc4254cd5136cfdbd07

Search

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

Code of Conduct

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

Additional context

No response

[blacktop]

@t0rr3sp3dr0 ?

[blacktop]

fixed in blacktop/go-macho@237bf71

[blacktop]

FYI @Rokey1990 in the future that was an issue in the go-macho pkg

Thank you for letting me know!

[blacktop]

@Rokey1990 this should be fixed now

[blacktop]

wait, there might be something weird going on w/ a collision of go-macho versions?

[blacktop]

I think I somehow accidentally created a tag for this before and it got registered w/ the Go pkgs

So I just created another go-macho release to avoid this collision as I don't know how to remove the prev cached tag in the golang pkg servers etc

[blacktop]

Ok @Rokey1990 this should be fixed (for real this time)

[Rokey1990]

It does't works well. this is not a category-specific problem, the same problem exists with other symbols, such as classes.

I think the GetBindName also has a bug too, the "categoryPtr.ClsVMAddr" is always 0 for NSObject or UIView(symbols in other dynamic libraries)，this case, GetBindName will return NSObject only, even the real class name is UIView.

// GetBindName returns the import name for a given dyld chained pointer
func (f *File) GetBindName(pointer uint64) (string, error)

In some documents, they use the address of categoryPtr.ClsVMAddr(ptr + sizeof(uint64)) to get the bind name, Whether we need to do the same?

my debug image:

our implement:

[blacktop]

do you have a specific example in the orig binary you supplied for UIView?

I believe I've fixed the ptr==0 case for category class name lookup

I'll now try and fix it everywhere else it is used

[blacktop]

@Rokey1990 please check latest release

[blacktop]

I believe I've mostly been testing binaries w/ the NEW chained-fixup binds/rebases so didn't properly test the OLD LC_DYLD_INFO_ONLY style as much w/ Objc

Thank you for reporting!

Please keep these issues coming! and make sure to also test out all the Swift parsers as well 👍

[Rokey1990]

@blacktop Thanks! The latest release has been verifield, it works for earlier macho file👍!

But there are still some problems with the fix, as follow：

• Dump objc root class error, superclass ptr=0, GetBindName are still called?
• Dump some swift types error while parseGenericContext(go-macho/swift.go), It may be caused by wrong use of GetBindName or getContextDesc？

You can use the latest macho file to reproduce it ReviewToolDemo.zip

The swift parsers i have tested using ealier version, But just some simple usage！I'll go into more detail later,If any problems are found, I will inform you as soon as possible!

And I have some feature suggestions, hope to implemented, Many thanks!

• class-dump, some objc class name may contains swift demangled string, hope to add a config to demangle it!
• swift-dump, '-o' option seem to not woking, It's a exciting feature for further parsing!

[blacktop]

This should now be fixed in master (i'll push out a new release soon, just waiting on #451)

I also added a --demangle flag to the class-dump cmd, but it just does the same thing as using the -V flag (meaning -V already swift-demangles the class-dump)

[Rokey1990]

Nothing is wrong with master👍! Thank you!