search

Hitmasu / Jitex

A library to modify MSIL and native code at runtime
MIT License
120 stars 15 forks source link

Any chance for x86? #97

Open EugeneSunrise opened 9 months ago

EugeneSunrise commented 9 months ago

Hello Dear, how many changes do I need make to add x86 .net6/7 support?

Hitmasu commented 9 months ago

Hello,

Probably if you add an x86 trampoline on this method should be enough:

https://github.com/Hitmasu/Jitex/blob/2258f2cd859fe39cfd422dfe65540af1f7115348/src/Jitex/Utils/MemoryHelper.cs#L27-L62

The startIndex represents the index in the array where the address should be written.

It might be necessary to adjust some lines to write a pointer (or 32 bits) into the array:

https://github.com/Hitmasu/Jitex/blob/2258f2cd859fe39cfd422dfe65540af1f7115348/src/Jitex/Utils/MemoryHelper.cs#L22

https://github.com/Hitmasu/Jitex/blob/2258f2cd859fe39cfd422dfe65540af1f7115348/src/Jitex/Utils/MemoryHelper.cs#L137

If it doesn't work, please let me know, and I can assist with the implementation.

EugeneSunrise commented 9 months ago

Tested on windows.

I've changed GetTrampoline(IntPtr methodAddress) method: from var address = BitConverter.GetBytes(methodAddress.ToInt64()); to var address = BitConverter.GetBytes(methodAddress.ToInt32());

Then byte[] Code, int StartIndex) GetTrampoline(): from trampoline = new byte[] { 0x48, 0xB8, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xE0 }; startIndex = 2; to trampoline = new byte[] { 0xB8, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xE0 }; startIndex = 1;

And currently stuck in ManagedJit.CompileMethod(IntPtr thisPtr, IntPtr comp, IntPtr info, uint flags, IntPtr nativeEntry, out int nativeSizeOfCode)

Line MethodInfo methodInfo = new MethodInfo(info); info(Pointer to CORINFO_METHOD_INFO) always -1

Any ideas?

Hitmasu commented 9 months ago

I'll investigate that.

Which version of .NET are you currently testing?

EugeneSunrise commented 9 months ago

I'll i

.net 7 x86

RedDot-3ND7355 commented 9 months ago

Also getting cucked by the same issue. (Error occurs on a x86 Process, but works fine on x64) If it does happen for x86, That'd be fraken awesome. <3

If this helps in any way to find out why it doesn't work.

Description: The process was terminated due to an unhandled exception.
Stack:
   at System.RuntimeMethodHandle.InvokeMethod(System.Object, Void**, System.Signature, Boolean)
   at System.Reflection.MethodInvoker.Invoke(System.Object, IntPtr*, System.Reflection.BindingFlags)
   at System.Reflection.RuntimeMethodInfo.InvokeWithManyArguments(System.Reflection.RuntimeMethodInfo, Int32, System.Object, System.Reflection.BindingFlags, System.Reflection.Binder, System.Object[], System.Globalization.CultureInfo)
   at System.Reflection.RuntimeMethodInfo.Invoke(System.Object, System.Reflection.BindingFlags, System.Reflection.Binder, System.Object[], System.Globalization.CultureInfo)
   at System.Delegate.DynamicInvokeImpl(System.Object[])
   at System.Delegate.DynamicInvoke(System.Object[])
   at Jitex.Utils.RuntimeHelperExtension.PrepareDelegate(System.Delegate, System.Object[])
   at Jitex.JIT.ManagedJit.PrepareHook()
   at Jitex.JIT.ManagedJit..ctor()
   at Jitex.JIT.ManagedJit.GetInstance()
   at Jitex.JitexManager.get_Jit()
   at Jitex.JitexManager.AddMethodResolver(MethodResolverHandler)
   at Jitex.JitexManager.add_MethodResolver(MethodResolverHandler)
   at JitTest.InitializeJit.MyMethodResolver()
   at JitTest.InitializeJit.JitInit()

Followed By...

Faulting module name: coreclr.dll, version: 7.0.1523.57226, time stamp: 0x655ed8ef
Exception code: 0xc0000005
Hitmasu commented 9 months ago

Also getting cucked by the same issue. (Error occurs on a x86 Process, but works fine on x64) If it does happen for x86, That'd be fraken awesome. <3

If this helps in any way to find out why it doesn't work.

Description: The process was terminated due to an unhandled exception.
Stack:
   at System.RuntimeMethodHandle.InvokeMethod(System.Object, Void**, System.Signature, Boolean)
   at System.Reflection.MethodInvoker.Invoke(System.Object, IntPtr*, System.Reflection.BindingFlags)
   at System.Reflection.RuntimeMethodInfo.InvokeWithManyArguments(System.Reflection.RuntimeMethodInfo, Int32, System.Object, System.Reflection.BindingFlags, System.Reflection.Binder, System.Object[], System.Globalization.CultureInfo)
   at System.Reflection.RuntimeMethodInfo.Invoke(System.Object, System.Reflection.BindingFlags, System.Reflection.Binder, System.Object[], System.Globalization.CultureInfo)
   at System.Delegate.DynamicInvokeImpl(System.Object[])
   at System.Delegate.DynamicInvoke(System.Object[])
   at Jitex.Utils.RuntimeHelperExtension.PrepareDelegate(System.Delegate, System.Object[])
   at Jitex.JIT.ManagedJit.PrepareHook()
   at Jitex.JIT.ManagedJit..ctor()
   at Jitex.JIT.ManagedJit.GetInstance()
   at Jitex.JitexManager.get_Jit()
   at Jitex.JitexManager.AddMethodResolver(MethodResolverHandler)
   at Jitex.JitexManager.add_MethodResolver(MethodResolverHandler)
   at JitTest.InitializeJit.MyMethodResolver()
   at JitTest.InitializeJit.JitInit()

Followed By...

Faulting module name: coreclr.dll, version: 7.0.1523.57226, time stamp: 0x655ed8ef
Exception code: 0xc0000005

This occurs because Jitex attempts to insert an x64 trampoline on x86. You can resolve this error by adding an x86 trampoline. However, another error will arise, as Eugene mentioned, due to the fact that on x86, the sizes of certain internal structs in .NET changes.

Probably, by the end of this month, I can release a version with x86 support.

EugeneSunrise commented 9 months ago

Also getting cucked by the same issue. (Error occurs on a x86 Process, but works fine on x64) If it does happen for x86, That'd be fraken awesome. <3

If this helps in any way to find out why it doesn't work.


Description: The process was terminated due to an unhandled exception.

Stack:

   at System.RuntimeMethodHandle.InvokeMethod(System.Object, Void**, System.Signature, Boolean)

   at System.Reflection.MethodInvoker.Invoke(System.Object, IntPtr*, System.Reflection.BindingFlags)

   at System.Reflection.RuntimeMethodInfo.InvokeWithManyArguments(System.Reflection.RuntimeMethodInfo, Int32, System.Object, System.Reflection.BindingFlags, System.Reflection.Binder, System.Object[], System.Globalization.CultureInfo)

   at System.Reflection.RuntimeMethodInfo.Invoke(System.Object, System.Reflection.BindingFlags, System.Reflection.Binder, System.Object[], System.Globalization.CultureInfo)

   at System.Delegate.DynamicInvokeImpl(System.Object[])

   at System.Delegate.DynamicInvoke(System.Object[])

   at Jitex.Utils.RuntimeHelperExtension.PrepareDelegate(System.Delegate, System.Object[])

   at Jitex.JIT.ManagedJit.PrepareHook()

   at Jitex.JIT.ManagedJit..ctor()

   at Jitex.JIT.ManagedJit.GetInstance()

   at Jitex.JitexManager.get_Jit()

   at Jitex.JitexManager.AddMethodResolver(MethodResolverHandler)

   at Jitex.JitexManager.add_MethodResolver(MethodResolverHandler)

   at JitTest.InitializeJit.MyMethodResolver()

   at JitTest.InitializeJit.JitInit()

Followed By...


Faulting module name: coreclr.dll, version: 7.0.1523.57226, time stamp: 0x655ed8ef

Exception code: 0xc0000005

This occurs because Jitex attempts to insert an x64 trampoline on x86. You can resolve this error by adding an x86 trampoline. However, another error will arise, as Eugene mentioned, due to the fact that on x86, the sizes of certain internal structs in .NET changes.

Probably, by the end of this month, I can release a version with x86 support.

Thank you for your support🙏🏼❤️

EugeneSunrise commented 8 months ago

🙏🏼

Hitmasu commented 8 months ago

Apologies for the delay.

I've released a preview version of Jitex (6.7.0-preview) that provides initial support for x86. Please note that this support is currently limited to core functions:

However, the following features are not included in this preview:

Achieving full x86 support is challenging for me due to my use of a macOS environment for development. Setting up a VM running a Windows 10 x86 environment is particularly difficult on mac, and I've encountered challenges in doing so. I eventually opted to install Windows 10 x86 on an old machine that was available to me. Consequently, debugging becomes a significant challenge as I lack the necessary tools, with only a clean Windows setup and Windbg at my disposal.

The primary difficulty in supporting x86 lies in the MethodHelper class, which extensively deals with offsets. Adapting these methods for x86 would require remapping certain methods, involving the removal of 4 bytes from specific offsets. While not an impossible task, it does consume a substantial amount of time, especially when the right tools are not available in my environment.

Considering these challenges, I'll not achieve full x86 support within this year. Any assistance would be greatly appreciated, and I'll provide guidance for those interested in contributing.

This preview version should suffice for most scenarios. If not work for you, let me know.

EugeneSunrise commented 8 months ago

Apologies for the delay.

I've released a preview version of Jitex (6.7.0-preview) that provides initial support for x86. Please note that this support is currently limited to core functions:

  • Resolve Methods.
  • Resolve Tokens.
  • Intercept Methods.

However, the following features are not included in this preview:

  • Some methods from MethodHelper.
  • Resolve DynamicMethod.
  • Occasionally, the source from resolveToken may not be accurate.

Achieving full x86 support is challenging for me due to my use of a macOS environment for development. Setting up a VM running a Windows 10 x86 environment is particularly difficult on mac, and I've encountered challenges in doing so. I eventually opted to install Windows 10 x86 on an old machine that was available to me. Consequently, debugging becomes a significant challenge as I lack the necessary tools, with only a clean Windows setup and Windbg at my disposal.

The primary difficulty in supporting x86 lies in the MethodHelper class, which extensively deals with offsets. Adapting these methods for x86 would require remapping certain methods, involving the removal of 4 bytes from specific offsets. While not an impossible task, it does consume a substantial amount of time, especially when the right tools are not available in my environment.

Considering these challenges, I'll not achieve full x86 support within this year. Any assistance would be greatly appreciated, and I'll provide guidance for those interested in contributing.

This preview version should suffice for most scenarios. If not work for you, let me know.

It works! 🥳 Thank You so much, this project is awesome! I have a macOS(arm parallels) work environment right now too and I understand how hard it is to get work done ❤️. Also if you want i can give you credits in my repo

Hitmasu commented 8 months ago

Apologies for the delay. I've released a preview version of Jitex (6.7.0-preview) that provides initial support for x86. Please note that this support is currently limited to core functions:

  • Resolve Methods.
  • Resolve Tokens.
  • Intercept Methods.

However, the following features are not included in this preview:

  • Some methods from MethodHelper.
  • Resolve DynamicMethod.
  • Occasionally, the source from resolveToken may not be accurate.

Achieving full x86 support is challenging for me due to my use of a macOS environment for development. Setting up a VM running a Windows 10 x86 environment is particularly difficult on mac, and I've encountered challenges in doing so. I eventually opted to install Windows 10 x86 on an old machine that was available to me. Consequently, debugging becomes a significant challenge as I lack the necessary tools, with only a clean Windows setup and Windbg at my disposal. The primary difficulty in supporting x86 lies in the MethodHelper class, which extensively deals with offsets. Adapting these methods for x86 would require remapping certain methods, involving the removal of 4 bytes from specific offsets. While not an impossible task, it does consume a substantial amount of time, especially when the right tools are not available in my environment. Considering these challenges, I'll not achieve full x86 support within this year. Any assistance would be greatly appreciated, and I'll provide guidance for those interested in contributing. This preview version should suffice for most scenarios. If not work for you, let me know.

It works! 🥳 Thank You so much, this project is awesome! I have a macOS(arm parallels) work environment right now too and I understand how hard it is to get work done ❤️. Also if you want i can give you credits in my repo

Great!

I'm planning to incorporate support for .NET 8 and aim to release a stable, non-preview version soon.

It's going to be wonderful! Could you share your project so that I can include a reference to it in Jitex as well?

As this version doesn't offer complete x86 support, I'll keep this issue open with the #help tag.

EugeneSunrise commented 8 months ago

Apologies for the delay. I've released a preview version of Jitex (6.7.0-preview) that provides initial support for x86. Please note that this support is currently limited to core functions:

  • Resolve Methods.
  • Resolve Tokens.
  • Intercept Methods.

However, the following features are not included in this preview:

  • Some methods from MethodHelper.
  • Resolve DynamicMethod.
  • Occasionally, the source from resolveToken may not be accurate.

Achieving full x86 support is challenging for me due to my use of a macOS environment for development. Setting up a VM running a Windows 10 x86 environment is particularly difficult on mac, and I've encountered challenges in doing so. I eventually opted to install Windows 10 x86 on an old machine that was available to me. Consequently, debugging becomes a significant challenge as I lack the necessary tools, with only a clean Windows setup and Windbg at my disposal. The primary difficulty in supporting x86 lies in the MethodHelper class, which extensively deals with offsets. Adapting these methods for x86 would require remapping certain methods, involving the removal of 4 bytes from specific offsets. While not an impossible task, it does consume a substantial amount of time, especially when the right tools are not available in my environment. Considering these challenges, I'll not achieve full x86 support within this year. Any assistance would be greatly appreciated, and I'll provide guidance for those interested in contributing. This preview version should suffice for most scenarios. If not work for you, let me know.

It works! 🥳 Thank You so much, this project is awesome! I have a macOS(arm parallels) work environment right now too and I understand how hard it is to get work done ❤️. Also if you want i can give you credits in my repo

Great!

I'm planning to incorporate support for .NET 8 and aim to release a stable, non-preview version soon.

It's going to be wonderful! Could you share your project so that I can include a reference to it in Jitex as well?

As this version doesn't offer complete x86 support, I'll keep this issue open with the #help tag.

We gave you credits in this repo and this. Actually I don't really know how you feel about these "stuff", but in our case we needed to change code in runtime and jitex handled it 200% well. Let me know if you're not comfortable with these "stuff", we'll clean up our repositories, but I think this is not bad example of using jitex to its full potential😈

Hitmasu commented 8 months ago

We gave you credits in this repo and this. Actually I don't really know how you feel about these "stuff", but in our case we needed to change code in runtime and jitex handled it 200% well. Let me know if you're not comfortable with these "stuff", we'll clean up our repositories, but I think this is not bad example of using jitex to its full potential😈

Thank you for credits!

I don't see any issues in utilizing Jitex for this purpose. Jitex is open-source under the MIT license, and since I'm not responsible for those projects, i don't see any problems.

However, referencing that project in Jitex might pose some laws problems for me. Due to this risk, I'd rather refrain from including references to both projects in the readme.

I hope you understand the cautious approach.