Send MinGW-Notify mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.osdn.me/mailman/listinfo/mingw-notify
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of MinGW-Notify digest..."
Please do not reply to this notification; the sender address is unable to
accept incoming e-mail. If you wish to unsubscribe you can do so at
https://lists.osdn.me/mailman/listinfo/mingw-notify.
Today's Topics:
1. [mingw] #40446: Obscure issue compiling/linking Windows
binaries from Linux using mingw (MinGW Notification List)
2. [mingw] #40438: Bug in libmingwex-5.3.1 dll
(MinGW Notification List)
3. [mingw] #40438: Bug in libmingwex-5.3.1 dll
(MinGW Notification List)
----------------------------------------------------------------------
Message: 1
Date: Tue, 26 May 2020 18:55:58 +0900
From: MinGW Notification List <[email protected]>
To: OSDN Ticket System <[email protected]>
Subject: [MinGW-Notify] [mingw] #40446: Obscure issue
compiling/linking Windows binaries from Linux using mingw
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
#40446: Obscure issue compiling/linking Windows binaries from Linux using mingw
Open Date: 2020-05-26 15:19
Last Update: 2020-05-26 18:55
URL for this Ticket:
https://osdn.net//projects/mingw/ticket/40446
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=40446
---------------------------------------------------------------------
Last Changes/Comment on this Ticket:
2020-05-26 18:55 Updated by: thecolonial
Comment:
Dammit! :) I actually pondered this as soon as I pulled the trigger on the
issue. Based on the name I did think there was an affiliation.
Sorry for the noise. I shall close and move on!
---------------------------------------------------------------------
Ticket Status:
Reporter: thecolonial
Owner: (None)
Type: Issues
Status: Closed
Priority: 3
MileStone: (None)
Component: (None)
Severity: 5 - Medium
Resolution: Invalid
---------------------------------------------------------------------
Ticket details:
Hi,
I've recently been working on providing support to build Windows Meterpreter
binaries using mingw via CMake on Linux. The project source can be found here:
https://github.com/OJ/metasploit-payloads/tree/cross-compile-linux/c/
meterpreter
I think it's fair to say that the kind of stuff Meterpreter does is a little
"non standard" compared to most C/C++ projects and so I expected to come up
against some edge case issues.For the most part it has gone very well, but I
stumbled on something yesterday that has taken me a solid day of debugging to
get to the bottom of. I'll do my best to describe in detail and provide links
to the relevant things so that the mingw developers can get themselves to the
point that I was to reproduce the issue.
Meterpreter is made up of a number of components. A core component called
metsrv is what's loaded first, and from there a number of other components
(extensions) can be loaded on the fly. One of the extensions is called kiwi,
which is made up of functionality pulled from a project called Mimikatz by Ben
Delpy, the source if which can be found here: https://github.com/gentilkiwi/
mimikatz
The kiwi extension makes some modifications to this project allowing it be
loaded using Reflective DLL Injection. This technique was developer by Stephen
Fewer, the source can be found here: https://github.com/stephenfewer/
ReflectiveDLLInjection
So metsrv is loaded via RDI, it can then load kiwi via RDI. Nothing too complex
so far.
The kiwi source is definitely complex. Mimikatz does crazy things with the
internals of Windows via obscure APIs. In order to support various versions of
Windows it has to include a few custom made libraries that are shipped with the
project in the lib subfolder.
Prior to undertaking this task, we were able to build all the components of the
project cleanly with VS 2013/2017/2019 and the binaries would work as expected.
I was having the same experience porting things to mingw on Linux until I
reached the kiwi extension, which resulted in the issue that I thought I'd log
here.
Invocation of the features of the binary would result in the program crashing.
After debugging, I realised that all IAT function pointers that should have
been imported from advapi32.dll were set to NULL. This seemed a little strange,
because all other IAT entries looked fine. Then after many hours of digging, I
noticed that there was something odd going on with the Import descriptors.
Please refer to the following image:
https://i.imgur.com/zXynXJp.png
This image is a screenshot from PE-Bear, a PE analysis tool, and it shows the
imports for the resulting ext_server_kiwi.x64.dll binary that is generated from
mingw. Things to note:
• Only 6 functions are imported from WINSTA.dll, though PE Bear reports that
it has 105.
• The list of functions that are imported contain references to functions
loaded from advapi32.dll.
• The RVA of the first thunk for advapi32.dll appears in the list of
functions for winsta.dll.
Ultimately, the root of the issue is that the import descriptor for winsta.dll
is not terminted with a NULL entry. So what happens at runtime is that the DLL
loader iterates through all the winsta.dll functions first, correcty resolves
them using LoadLibrary and GetProcAddress, and stores the pointers in the IAT.
As soon as it hits the first entry for advapi32.dll (in this case A_SHAFinal)
it attempts to call GetProcAddress with an invalid module base (because it's
reusing WINSTA.dll's base) and hence the call will result in NULL. The net
result is that all of the advapi32.dll import entries are set to NULL.
I modified the reflective DLL injection code so that it doesn't assume that a
NULL terminator is present. It will also look at the next set of import
characteristics and make sure that it doesn't go past the first thunk. This
change resulted in everything working fine.
This problem isn't present in the VS compilers/linkers I've used and hence I
think it might be an issue specific to mingw. I do have a working solution, but
I think there could be something that may impact other people if we don't get
to the bottom of it. Hopefully it's specific to my project alone, however I
don't think it is. Maybe it's an edge case that mingw doesn't yet cover.
I think this is a linker issue rather than a compiler issue, but that's
obviously up to people with more knowledge than me to determine. I wouldn't
consider this the highest priority, given that it's rather edge case and you
probably haven't seen it before despite the long history of the mingw project.
If you need any more clarification on the issue, or links to sources etc,
please let me know. I can provide binaries if required.
Many thanks for your time and for the great work you folks do this project.
Best regards
OJ / @TheColonial
--
Ticket information of MinGW - Minimalist GNU for Windows project
MinGW - Minimalist GNU for Windows Project is hosted on OSDN
Project URL: https://osdn.net/projects/mingw/
OSDN: https://osdn.net
URL for this Ticket:
https://osdn.net/projects/mingw/ticket/40446
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=40446
------------------------------
Message: 2
Date: Tue, 26 May 2020 20:43:11 +0100
From: MinGW Notification List <[email protected]>
To: OSDN Ticket System <[email protected]>
Subject: [MinGW-Notify] [mingw] #40438: Bug in libmingwex-5.3.1 dll
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
#40438: Bug in libmingwex-5.3.1 dll
Open Date: 2020-05-23 10:07
Last Update: 2020-05-26 20:43
URL for this Ticket:
https://osdn.net//projects/mingw/ticket/40438
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=40438
---------------------------------------------------------------------
Last Changes/Comment on this Ticket:
2020-05-26 20:43 Updated by: keith
Comment:
So, you thought you would piss me off some more, by posting two more improperly
marked-up comments? The "preview" button is there for a reason ... please use
it, before you submit incorrectly marked-up garbage.
By the way, I downloaded source of 'mingw-org-wsl', but did not find there
any strings matching '__emutls_get_address'
You will not find it, because it is a libgcc helper, implied when variables are
declared with the __thread attribute, (as arising in the new mbrscan.c and
wcharmap.c translation units).
---------------------------------------------------------------------
Ticket Status:
Reporter: rosasmje
Owner: keith
Type: Issues
Status: Open [Owner assigned]
Priority: 2
MileStone: (None)
Component: (None)
Severity: 5 - Medium
Resolution: None
---------------------------------------------------------------------
Ticket details:
libmingwex-5.3.1 is BUGGY! it imports from self procedure
"__emutls_get_address", while not exporting it. thus any linked app would not
start. changed to --static also submitted this as review. also tested Version
5.2.2, it is good; it has not any "__emutls_get_address" inside;
--
Ticket information of MinGW - Minimalist GNU for Windows project
MinGW - Minimalist GNU for Windows Project is hosted on OSDN
Project URL: https://osdn.net/projects/mingw/
OSDN: https://osdn.net
URL for this Ticket:
https://osdn.net/projects/mingw/ticket/40438
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=40438
------------------------------
Message: 3
Date: Tue, 26 May 2020 21:56:11 +0100
From: MinGW Notification List <[email protected]>
To: OSDN Ticket System <[email protected]>
Subject: [MinGW-Notify] [mingw] #40438: Bug in libmingwex-5.3.1 dll
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
#40438: Bug in libmingwex-5.3.1 dll
Open Date: 2020-05-23 10:07
Last Update: 2020-05-26 21:56
URL for this Ticket:
https://osdn.net//projects/mingw/ticket/40438
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=40438
---------------------------------------------------------------------
Last Changes/Comment on this Ticket:
2020-05-26 21:56 Updated by: keith
Comment:
So, you thought you would piss me off some more, by posting two more improperly
marked-up comments? The "preview" button is there for a reason ... please use
it, before you submit incorrectly marked-up garbage.
By the way, I downloaded source of 'mingw-org-wsl', but did not find there
any strings matching '__emutls_get_address'
You will not find it, because it is a libgcc helper, implied when variables are
declared with the __thread attribute, (as arising in the new mbrscan.c and
wcharmap.c translation units).
you can use any PE-tools analyzers to view this 'libmingwex-2.dll' & see
reported mistake: '__emutls_get_address' import is linked again to
'libmingwex-2.dll'
I don't know of any such tools, other than objdump, which I can run on GNU/
Linux, (and objdump doesn't really help much here). However, the point is that
libmingwex-2.dll is linked with -static-libgcc, which supplies
__emutls_get_address(), so that should be embedded within libmingwex-2.dll,
without requiring it to be exported.
Windows10 (& for sure olders) will always refuse to load this DLL
It is strange that Wine can do so; thus it seems apparent that the procedure
body is appropriately embedded ... otherwise, where is Wine finding it?
However, I have managed to resurrect an old WinXP virtual machine, on which I
can see the effect you describe; (seems to me, to be yet another Windows
deficiency, and thus, another reason to kick it into touch, once and for all
time). I can work around this Windows deficiency, in either of two ways:
• Do not link libmingwex-2.dll with -static-libgcc, thus introducing an
implicit dynamic dependency on libgcc_s_dw2-1.dll, (and thus, incurring the
licensing restrictions on redistribution, which are inherent in this
dependency).
• Move the mbrscan.o and wcharmap.o modules out of libmingwex-2.dll, (thus
necessitating an interface version bump to libmingwex-3.dll), and into
libmingw32.a, (which will always be statically linked); this also implies
that libmingwex-3.dll must be deployed in conjunction with updated
libmingw32.a, libmingwex.a, and libmingwex.dll.a.
Of these two, I prefer the latter, (since it doesn't enforce the licensing
restriction, for those users who may wish to distribute libmingwex-3.dll
dependent applications); I will proceed on this latter basis.
---------------------------------------------------------------------
Ticket Status:
Reporter: rosasmje
Owner: keith
Type: Issues
Status: Open [Owner assigned]
Priority: 2
MileStone: (None)
Component: (None)
Severity: 5 - Medium
Resolution: None
---------------------------------------------------------------------
Ticket details:
libmingwex-5.3.1 is BUGGY! it imports from self procedure
"__emutls_get_address", while not exporting it. thus any linked app would not
start. changed to --static also submitted this as review. also tested Version
5.2.2, it is good; it has not any "__emutls_get_address" inside;
--
Ticket information of MinGW - Minimalist GNU for Windows project
MinGW - Minimalist GNU for Windows Project is hosted on OSDN
Project URL: https://osdn.net/projects/mingw/
OSDN: https://osdn.net
URL for this Ticket:
https://osdn.net/projects/mingw/ticket/40438
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=40438
------------------------------
Subject: Digest Footer
_______________________________________________
MinGW-Notify mailing list
[email protected]
https://lists.osdn.me/mailman/listinfo/mingw-notify
------------------------------
End of MinGW-Notify Digest, Vol 32, Issue 8
*******************************************
