devaukz / macho-kit Goto Github PK

Most of Mach-O Kit's testing involves using Mach-O Kit to parse every framework on the current host and comparing the output against o-tool. This approach comes with a number of deficiencies:

• Lack of test coverage against older (or newer, depending on the host) Mach-O binaries.
• Lack of testing coverage against iOS Mach-O binaries
• Lack of testing coverage against malformed or malicious binaries.

A handful of binaries from all of the above categories should be selected for a 'core' test pass that can run in CI.

i read the "__objc_catlist" section data, the i used clsPointer.name, the value is category name, i also want get category cls info.
for example:
// the source code is :

@interface UIImage (AFNetworkingSafeImageLoading)
+ (UIImage *)af_safeImageWithData:(NSData *)data;
@end

static NSLock* imageLock = nil;

@implementation UIImage (AFNetworkingSafeImageLoading)

+ (UIImage *)af_safeImageWithData:(NSData *)data {
    UIImage* image = nil;
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        imageLock = [[NSLock alloc] init];
    });
    
    [imageLock lock];
    image = [UIImage imageWithData:data];
    [imageLock unlock];
    return image;
}

@end

used macho-kit, the result is AFNetworkingSafeImageLoading, but i also want to get the class UIImage, how can i get the info

Looks like context.h should include logging.h to use mk_logger_c at line 50. Right now all works because of current include order.

I added the project to my current xcode project and created a new workspace. I opened the workspace and can build my project. However the first line of the example let memoryMap = try! MKMemoryMap(contentsOfFile: URL(fileURLWithPath: "/System/Library/Frameworks/Foundation.framework/Foundation"))

gives me an error:

ld: warning: Auto-Linking supplied '/Users/andermoran/Desktop/Detective-C/MachOKit.framework/MachOKit', file was built for arm64 which is not the architecture being linked (x86_64): /Users/andermoran/Desktop/Detective-C/MachOKit.framework/MachOKit Undefined symbols for architecture x86_64: "_OBJC_CLASS_$_MKMemoryMap", referenced from: objc-class-ref in ViewController.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation)

could you clarify how this is supposed to be implemented? Also some Objective-C code example would be nice :)

Awesome project 😉

I'm trying to analysis a MachO file like above. But when I want to get the info of String Table , I got an error said Image does not have a __LINKEDIT segment.. Obviously, there is a __LINKEDIT segment on this file.

Investigate adding parsers for Swift metadata (stable ABI).

Looks like here MachOKit/MachOKit/_MKFileMemoryMap.h:28:

#include <MachOKit/macho.h>

should be:

#include <libMachO/macho.h>

Also should be fixed in:
MachOKit/MachOKit/MachOKit.h:34
MachOKit/MachOKit/SharedTypes/MKBackedNode+Pointer.h:28

Looks like line #290 in core.h contains infinite recursion cycle, isn't it? This line produces following warning:

libMachO/libMachO/Core/core.h:290:57: All paths through this function will call itself

core.h:290

uint8_t* swap (uint8_t *input, size_t length) const { return swap(input, length); }

hi I just clone repo in my project, and add framwork in genaral, but when i run, xcode report that can not find MKDataModel+Layout_Internal.h, and it is imported by MKNodeFieldCPUType.m, count you tell me what should i do?
is that because my project is not for app?
error reason:
/Users/bytedance/Desktop/oc/MachO-Kit/MachOKit/Shared/Type/CPUType/MKNodeFieldCPUType.m:31:9: 'MKDataModel+Layout_Internal.h' file not found

MachO binaries built to target the latest betas (iOS 15/macOS 12/etc) – or, if built for arm64e, even some older versions – replace the old fixup format with a new, more compact, "chained" format. The new format is documented in <mach-o/fixup-chains.h>, and there's also a Medium article that summarises it.

This change, in conjunction with our discussion from #13, makes me think that it might be best if MachO-Kit provided an API to query an MKPointer and "resolve" it (either returning the resolved address if found, or otherwise metadata about the symbol) if it has an associated fixup, to abstract the implementation details of the fixups themselves.

Can you provide a short example how to enumerate symbols from export table?

Can't imagine where to get all arguments to mk_string_table_enumerate_strings.

Some problems with the current implementation:

• It is difficult to (re)construct the C structure layout for a node. This is needed when implementing a disassembler, where you want to display structures overlaid on top of the raw binary data.

• Node layouts are re-created with each call to -layout. Layouts should be cached. Many layouts are the same for all instances of a node type and could be defined at the class (vs instance) level.

• The current mechanism for describing bitfields is less than ideal.

• The type of an MKNodeField is attempting to describe both the semantic type of the field as well as the data type. These should be split.

• MKNodeFieldOptions should be removed. It was added to simplify the implementation of Mach-O Explorer, with the justification that other viewer apps built with Mach-O Kit could also use it. But its purpose is too narrow. It does not belong in Mach-O Kit.

Is the __DATA segment's __cfstring section not implemented? Please excuse me if I'm missing something obvious.

I'd like to parse this section's CFString elements.

MachO files built to target the latest release OSes (iOS 14/macOS 11/etc) use a new "small" format for ObjC method lists, which contain relative 32-bit offsets to methods instead of absolute addresses. Implementing the relative pointer format could also help with Swift ABI support, since Swift does something similar. For implementation details, check out RelativePointer, method_t, and method_list_t in objc-runtime-new.mm.

Hi, I've created empty project, loaded MachO-Kit framework in it, and included #import <MachOKit/MachOKit.h> into my .m file.

Everything was fine until I changed extension to .mm.
As I found out, there are some troubles with importing libraries via @import while using C++.
I've been trying a bunch of stuff, e.g. passing flags -fmodules and -fcxx-modules, but nothing helped.

Later, I've found out that the fix is to replace all entries of @import Foundation into #import <Foundation/Foundation.h> in MachO-Kit.
After this changes, everything works fine(it builds and I'm still able to parse MachO files even with .mm extenstion).

Will this change broke something?
If there is no problems with it, could you please apply fix?

The dyld shared cache parser has not been given much attention the past few years. Ensure that it can still parse the modern caches. Modernize the implementations of -layout: for all DSC classes.