Re: [Mingw-w64-public] Lock in support in the crt for ARMNT

2015-12-15 Thread Martell Malone 
Please ignore patch 003 which adds __initenv to msvcrt
This is not available on arm.
Please review this along with the NtCurrentTeb patch.

Apologies for the noise

Kind Regards
Martell

On Tue, Dec 15, 2015 at 10:37 PM, Martell Malone 
wrote:

> Forgot: Please Review. :)
>
> On Tue, Dec 15, 2015 at 10:37 PM, Martell Malone 
> wrote:
>
>> Add the final 2 functions need to run are executables via mingw-w64.
>>
>
>
From 73f31eabfba4d9adcfd3c8999bb97f3585ea8ee1 Mon Sep 17 00:00:00 2001
From: Martell Malone 
Date: Tue, 15 Dec 2015 23:03:05 -0800
Subject: [PATCH] crt: armv7 does not have __initenv in libmsvcrt


diff --git a/mingw-w64-crt/crt/crtexe.c b/mingw-w64-crt/crt/crtexe.c
index 6a2e2c7..ae37e0f 100644
--- a/mingw-w64-crt/crt/crtexe.c
+++ b/mingw-w64-crt/crt/crtexe.c
@@ -26,7 +26,7 @@ extern wchar_t *** __MINGW_IMP_SYMBOL(__winitenv);
 #define __winitenv (* __MINGW_IMP_SYMBOL(__winitenv))
 #endif
 
-#ifndef __initenv
+#if !defined(__initenv) && !defined(__arm__)
 extern char *** __MINGW_IMP_SYMBOL(__initenv);
 #define __initenv (* __MINGW_IMP_SYMBOL(__initenv))
 #endif
@@ -328,7 +328,9 @@ __tmainCRTStartup (void)
gcc inserts this call automatically for a function called main, but not 
for wmain.  */
 mainret = wmain (argc, argv, envp);
 #else
+#ifndef __arm__
 __initenv = envp;
+#endif
 mainret = main (argc, argv, envp);
 #endif
 if (!managedapp)
diff --git a/mingw-w64-crt/include/internal.h b/mingw-w64-crt/include/internal.h
index c6cc796..03fe1c1 100644
--- a/mingw-w64-crt/include/internal.h
+++ b/mingw-w64-crt/include/internal.h
@@ -114,7 +114,7 @@ extern wchar_t *** __MINGW_IMP_SYMBOL(__winitenv);
 #define __winitenv (* __MINGW_IMP_SYMBOL(__winitenv))
 #endif
 
-#ifndef __initenv
+#if !defined(__initenv) && !defined(__arm__)
 extern char *** __MINGW_IMP_SYMBOL(__initenv);
 #define __initenv (* __MINGW_IMP_SYMBOL(__initenv))
 #endif
-- 
2.6.3

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Lock in support in the crt for ARMNT

2015-12-15 Thread Martell Malone 
Add the final 2 functions need to run are executables via mingw-w64.
From 5288e84f375a5abdca6276586fe581872a88bfe8 Mon Sep 17 00:00:00 2001
From: Martell Malone 
Date: Tue, 15 Dec 2015 20:57:52 -0800
Subject: [PATCH 2/2] Add support for NTCurrentTeb for ARMNT


diff --git a/mingw-w64-headers/include/winnt.h 
b/mingw-w64-headers/include/winnt.h
index ef1f440..3fec543 100644
--- a/mingw-w64-headers/include/winnt.h
+++ b/mingw-w64-headers/include/winnt.h
@@ -8367,6 +8367,10 @@ typedef DWORD (WINAPI 
*PRTL_RUN_ONCE_INIT_FN)(PRTL_RUN_ONCE, PVOID, PVOID *);
 struct _TEB *NtCurrentTeb (VOID);
 PVOID GetCurrentFiber (VOID);
 PVOID GetFiberData (VOID);
+FORCEINLINE struct _TEB *NtCurrentTeb(VOID) { struct _TEB *teb;
+__asm ("mrc p15, 0, %0, c13, c0, 2" : "=r" (teb));
+return teb; }
+FORCEINLINE PVOID GetCurrentFiber(VOID) { return 
(PVOID)(((PNT_TIB)NtCurrentTeb())->FiberData); }
 FORCEINLINE PVOID GetFiberData (VOID) { return *(PVOID *)GetCurrentFiber 
(); }
 #endif /* arm */
 
-- 
2.6.3

From 93903df62733bcb701a9be39f9da68b63f6d8f9f Mon Sep 17 00:00:00 2001
From: Martell Malone 
Date: Tue, 15 Dec 2015 18:01:40 -0800
Subject: [PATCH 1/2] Add __initenv to arm32 msvcrt


diff --git a/mingw-w64-crt/libarm32/msvcrt.def 
b/mingw-w64-crt/libarm32/msvcrt.def
index 2533d5a..fc4c49e 100644
--- a/mingw-w64-crt/libarm32/msvcrt.def
+++ b/mingw-w64-crt/libarm32/msvcrt.def
@@ -129,6 +129,7 @@ __doserrno
 __dstbias
 __fpecode
 __getmainargs
+__initenv DATA
 __iob_func
 __isascii
 __iscsym
-- 
2.6.3

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Lock in support in the crt for ARMNT

2015-12-15 Thread Martell Malone 
Forgot: Please Review. :)

On Tue, Dec 15, 2015 at 10:37 PM, Martell Malone 
wrote:

> Add the final 2 functions need to run are executables via mingw-w64.
>
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] patching IAT and _strdup() and malloc() functions

2015-12-15 Thread Vincent Torri 
On Tue, Dec 15, 2015 at 12:05 PM, Jacek Caban  wrote:
> Hi Vincent,
>
> On 12/15/15 7:20 AM, Vincent Torri wrote:
>> Hello
>>
>> I am still working on Examine, my small valgrind-like memory leak
>> detector (http://vtorri.github.io/examine/) and I have 2 questions.
>>
>> First, I recall that it works by doing DLL injection with
>> CreateRemoteThread, and API hooking by patching the IAT.
>>
>> So Examine is working well, now, but I have 2 questions, about
>> _strdup() and malloc() :
>>
>> 1) If I call malloc() in a program, it is detected by Examine. If I
>> call _strdup(), malloc is not detected at all, while MSDN says that
>> _strdup() "calls malloc to allocate storage space" (see
>> https://msdn.microsoft.com/en-us/library/y471khhc.aspx). Does someone
>> have an idea why malloc() is  not catched ?
>
> Both malloc and _strdup live in the same DLL (like msvcrt.dll or any
> other msvcr*.dll version), so calls from _strdup to malloc don't use
> import table, it's a direct call. You could have more luck by hot
> patching malloc function itself, but I don't think it's the right solution.
>
> You may have more luck patching HeapAlloc (or even RtlAllocateHeap)
> instead. At least in Wine, malloc ends up calling it.

I've already patched HeapAlloc(), but malloc is already patched. I'll
try to remove malloc() hook.

Vincent

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] patching IAT and _strdup() and malloc() functions

2015-12-15 Thread LRN 
On 15.12.2015 14:05, Jacek Caban wrote:
> Hi Vincent,
> 
> On 12/15/15 7:20 AM, Vincent Torri wrote:
>> Hello
>>
>> I am still working on Examine, my small valgrind-like memory leak
>> detector (http://vtorri.github.io/examine/) and I have 2 questions.
>>
>> First, I recall that it works by doing DLL injection with
>> CreateRemoteThread, and API hooking by patching the IAT.
>>
>> So Examine is working well, now, but I have 2 questions, about
>> _strdup() and malloc() :
>>
>> 1) If I call malloc() in a program, it is detected by Examine. If I
>> call _strdup(), malloc is not detected at all, while MSDN says that
>> _strdup() "calls malloc to allocate storage space" (see
>> https://msdn.microsoft.com/en-us/library/y471khhc.aspx). Does someone
>> have an idea why malloc() is  not catched ?
> 
> You could have more luck by hot
> patching malloc function itself, but I don't think it's the right solution.

AFAIK, gcc sanitizer does exactly that. Except that it was not ported to
W32/gcc (it works only on POSIX/gcc or W32/MSVC).

-- 
O< ascii ribbon - stop html email! - www.asciiribbon.org



signature.asc
Description: OpenPGP digital signature
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] patching IAT and _strdup() and malloc() functions

2015-12-15 Thread Jacek Caban 
Hi Vincent,

On 12/15/15 7:20 AM, Vincent Torri wrote:
> Hello
>
> I am still working on Examine, my small valgrind-like memory leak
> detector (http://vtorri.github.io/examine/) and I have 2 questions.
>
> First, I recall that it works by doing DLL injection with
> CreateRemoteThread, and API hooking by patching the IAT.
>
> So Examine is working well, now, but I have 2 questions, about
> _strdup() and malloc() :
>
> 1) If I call malloc() in a program, it is detected by Examine. If I
> call _strdup(), malloc is not detected at all, while MSDN says that
> _strdup() "calls malloc to allocate storage space" (see
> https://msdn.microsoft.com/en-us/library/y471khhc.aspx). Does someone
> have an idea why malloc() is  not catched ?

Both malloc and _strdup live in the same DLL (like msvcrt.dll or any 
other msvcr*.dll version), so calls from _strdup to malloc don't use 
import table, it's a direct call. You could have more luck by hot 
patching malloc function itself, but I don't think it's the right solution.

You may have more luck patching HeapAlloc (or even RtlAllocateHeap) 
instead. At least in Wine, malloc ends up calling it.

Cheers,
Jacek

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public