Someone asked for a mac version of fasmg, so I did pretty much the same thing that was done for fasm:

I also wrote a completely automated script for Travis CI.

Thank you for your help! I still plan to write the Mach-O macros for fasmg, then we could be able to skip the OBJCONV step, or even GCC altogether.

The latest versions of fasmg package include a native port of fasmg to MacOS, based on the macros I wrote for the creation of Mach-O executables and objects.

I would be grateful for some tests and hopefully confirmation that this port works correctly on actual MacOS machines. If anyone has access to such computers, preferably with various versions of MacOS, please give it a try.

Works fine on osx10.11 in Travis CI, and all my ez80 tests pass.

Tried on macOS 10.12.5, works with no issues.
I was able to assemble successfully fasmg.asm using fasmg binary provided (renamed it first)
And with the new binary, compiled successfully the source again.
4 passes, 9.2 seconds, 57678 bytes

Should I give it a specific extension when packaging?

I don't think so. it worked just fine out of the box.
MacOs of course protested saying that the app was not by a signed developer bla bla bla xD (quit common) After giving the permision to be executed it worked just fine.

I renamed it before assembling just so that the new binary generated from fasmg.asm wouldn't override the original one.
For the new one generated I did have to chown executable permissions but I suspect its standard procedure.

ps: I used the binary located in fasmg/source/macos/fasmg and the source in the same folder.

Also confirmed to self compile to an identical file and pass ez80 tests by someone else in 10.13.

The latest macOS 10.15 (Catalina) has removed support for 32-bit executables. So, using the same techniques that were used for adapting the linux port to 64 bits, I adapted the macos port to 64-bits. The executable version has been tested to self-compile correctly and generate the same working executable. However, the object file doesn't work due to header and relocation issues in the 64-bit macho format output.

Some empirical testing shows that even with ASLR, malloc consistently returns 32-bit addresses as much as it can. However, fopen seems to be returning a pointer into a library and so I had to create a table to map 32-bit "file handles" to the 64-bit file pointers.

More detail about the object file issues: it seems that at least the latest ld 512.4 doesn't like the CPU_SUBTYPE_LIB64 (which might be for 64-bit libraries themselves or something, not sure). Also, it didn't like X86_64_RELOC_SIGNED_4 in code sections and wanted X86_64_RELOC_BRANCH instead, but my attempts to replace this caused it to think it was linking to an offset outside of the 32-bit range.

This was tested against flat assembler version g.iphqh.

Thank you! If you permit, I would love include the working version in the official package (perhaps with a note about your contribution?). The object version is not really that much important to have, so we could skip it for now. The X86_64_RELOC_BRANCH relocations probably use a different formula, this would need a bit of an investigation and testing.

Indeed, anyone may use that code however they wish. Anyway, most of it is just slightly modified from other files, so I wouldn't want to claim too much credit, but any credit would be appreciated nonetheless.

You did a really great job of making all modifications in the same style I used to write fasmg. Therefore, since you have this exact version tested and working, I'm inclined to just include it in the official package without any changes.

Hi,

Bumping this topic because I've encountered an issue with mach-o binaries made with fasmg (in my case, fasmg itself): they can't be codesigned as there isn't enough space for the new load command in the header:


A quick PoC (by @jacobly above) reserving a page after the commands (rb 4096) makes codesigning work, though.
Could this be fixed/implemented officially?

https://lief.quarkslab.com/doc/latest/tutorials/11_macho_modification.html seems to be a good resource.

Thanks.

Could you share the patch that you tested? It would be great to have a point of reference that is already known to work. Also, would a size smaller than 4096 be enough? (Note that normally the header size is not aligned, so adding a round number of bytes for padding probably does nothing for the alignment either and you could use any other number just as well.)

I believe the best way to do it in the official package would be to introduce a HeaderPad option in MachO.Settings, analogous to the linker option mentioned in the error message, and then set it up with a large enough default value:

Yep, that is exactly where I put the padding (I put the rb on the line following that db). I dumped the exe before and after and the SizeOfLoadCommands increased by 16 bytes, so that might be enough. I'll have @Adriweb confirm that it still works with 16.

I confirmed that codesigning worked on the test binary provided by jacobly.

Thank you! I'm making 16 the new default.