flat assembler
Message board for the users of flat assembler.

Index > Unix > fasmg on MacOSX

Author
Thread Post new topic Reply to topic
jacobly



Joined: 04 Feb 2016
Posts: 44
jacobly 27 Jul 2017, 02:23
Someone asked for a mac version of fasmg, so I did pretty much the same thing that was done for fasm:
Code:
patch -p0 <macosx.patch
chmod +x ./fasmg
./fasmg source/libc/fasmg.asm fasmg.elf
objconv -fmacho32 -nu fasmg.elf fasmg.o
gcc -m32 -Wl,-no_pie fasmg.o -o fasmg
    

I also wrote a completely automated script for Travis CI.


Description: MacOSX executable and patch
Download
Filename: fasmg-macosx.zip
Filesize: 30.48 KB
Downloaded: 1384 Time(s)

Post 27 Jul 2017, 02:23
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 27 Jul 2017, 09:28
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.
Post 27 Jul 2017, 09:28
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 29 Aug 2017, 12:13
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.
Post 29 Aug 2017, 12:13
View user's profile Send private message Visit poster's website Reply with quote
jacobly



Joined: 04 Feb 2016
Posts: 44
jacobly 02 Oct 2017, 08:07
Works fine on osx10.11 in Travis CI, and all my ez80 tests pass.
Post 02 Oct 2017, 08:07
View user's profile Send private message Reply with quote
Enko



Joined: 03 Apr 2007
Posts: 676
Location: Mar del Plata
Enko 02 Oct 2017, 14:54
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
Post 02 Oct 2017, 14:54
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 02 Oct 2017, 15:01
Enko wrote:
I was able to assemble successfully fasmg.asm using fasmg binary provided (renamed it first)
Should I give it a specific extension when packaging?
Post 02 Oct 2017, 15:01
View user's profile Send private message Visit poster's website Reply with quote
Enko



Joined: 03 Apr 2007
Posts: 676
Location: Mar del Plata
Enko 02 Oct 2017, 15:10
Tomasz Grysztar wrote:
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.
Post 02 Oct 2017, 15:10
View user's profile Send private message Reply with quote
jacobly



Joined: 04 Feb 2016
Posts: 44
jacobly 02 Oct 2017, 18:55
Also confirmed to self compile to an identical file and pass ez80 tests by someone else in 10.13.
Post 02 Oct 2017, 18:55
View user's profile Send private message Reply with quote
jacobly



Joined: 04 Feb 2016
Posts: 44
jacobly 19 Oct 2019, 16:26
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.


Description:
Download
Filename: mac64.zip
Filesize: 86.26 KB
Downloaded: 1071 Time(s)

Post 19 Oct 2019, 16:26
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 19 Oct 2019, 22:24
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.
Post 19 Oct 2019, 22:24
View user's profile Send private message Visit poster's website Reply with quote
jacobly



Joined: 04 Feb 2016
Posts: 44
jacobly 20 Oct 2019, 08:52
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.
Post 20 Oct 2019, 08:52
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 20 Oct 2019, 09:01
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. Smile
Post 20 Oct 2019, 09:01
View user's profile Send private message Visit poster's website Reply with quote
Adriweb



Joined: 19 Oct 2019
Posts: 8
Location: France
Adriweb 26 Dec 2020, 01:23
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:
Quote:
fatal error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate: can't allocate code signature data for: [...]/fasmg (for architecture x86_64) because larger updated load commands do not fit (the program must be relinked using a larger -headerpad value)


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.
Post 26 Dec 2020, 01:23
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 26 Dec 2020, 11:50
Adriweb wrote:
A quick PoC (by @jacobly above) reserving a page after the commands (rb 4096) makes codesigning work, though.
Could this be fixed/implemented officially?
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:
Code:
        if defined Settings.HeaderPad
                HEADER_PAD := Settings.HeaderPad
        else
                HEADER_PAD := 1000h
        end if    
Code:
        commands db SIZE_OF_COMMANDS dup 0, HEADER_PAD dup ?    
Post 26 Dec 2020, 11:50
View user's profile Send private message Visit poster's website Reply with quote
jacobly



Joined: 04 Feb 2016
Posts: 44
jacobly 10 Jan 2021, 00:11
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.
Post 10 Jan 2021, 00:11
View user's profile Send private message Reply with quote
Adriweb



Joined: 19 Oct 2019
Posts: 8
Location: France
Adriweb 10 Jan 2021, 01:05
I confirmed that codesigning worked on the test binary provided by jacobly.
Post 10 Jan 2021, 01:05
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 10 Jan 2021, 12:30
Thank you! I'm making 16 the new default.
Post 10 Jan 2021, 12:30
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.