Jump to content

Most Liked Content

#63 WriteBytes Protected?

Posted by Prodian on 14 November 2013 - 08:24 PM



Keep getting an error saying these are inaccessible.


Binarysharp.MemoryManagement.MemorySharp.ReadBytes(System.IntPtr, int, [bool])

Binarysharp.MemoryManagement.MemorySharp.WriteBytes(System.IntPtr, byte[], [bool])


In the Object Browser they are showing as "Protected" access.



protected void WriteBytes(System.IntPtr address, byte[] byteArray, [bool isRelative = true])

    Member of Binarysharp.MemoryManagement.MemorySharp
Write an array of bytes in the remote process.
address: The address where the array is written.
byteArray: The array of bytes to write.
isRelative: [Optional] State if the address is relative to the main module.


Any idea?


Thanks for the help.

  • #61 Bugs report

    Posted by CreateAndInject on 30 October 2013 - 01:02 PM

    I report here, https://github.com/Z...ySharp/issues/1, but no reply.



    1.window.Mouse.MoveTo(0, 0);
    If the "window" is a child control, mouse can not move correctly!

    2.If an application has 2+ top level windows, WindowFactory.RemoteWindows can not collect all!
    Maybe should support "TopLevelWindows" property, and "MainWindow" is just the first visible one in collections.

    3.Why don't support a "Parent" property in RemoteWindow?

    public string ReadString(IntPtr address, Encoding encoding, bool isRelative = true, int maxLength = 0x200)
    string str = encoding.GetString(this.ReadBytes(address, maxLength, isRelative));
    int index = str.IndexOf('\0');
    return str.Substring(0, index);


    return index==-1?str:str.Substring(0,index);//If don't find "\0" in maxLength, just return it.

    var sharp = new MemorySharp(Process.GetCurrentProcess());
    sharp["kernel32"]["MessageBoxW"].Execute(0, "Hey", "Title", 0);
    this code contains so many errors
    (1) kernel32 => user32
    (2)sharp["user32"]["MessageBoxW"].Execute(0, "Hey", "Title", 0);
    will throw an exception.
    should: sharp["user32"]["MessageBoxW"].Execute(CallingConventions.Stdcall,0, "Hey", "Title", 0);
    (3)MessageBoxW can not work normally, MessageBoxA can.
    (4)sharp["user32"]["MessageBoxA"].Execute(CallingConventions.Stdcall,0, "汉字", "Title", 0);
    If the string contains non-latin character, such as Chinese, this code can not work correctly.
    I must do it like this:

    //my process
    (1).sharp["user32"]["MessageBoxA"].Execute(CallingConventions.Stdcall, 0, Marshal.StringToHGlobalAnsi("汉字"), "Title", 0);
    (2).sharp["user32"]["MessageBoxW"].Execute(CallingConventions.Stdcall, 0, Marshal.StringToHGlobalUni("汉字"), Marshal.StringToHGlobalUni("Title"), 0);

    //remote process
    var bytes = Encoding.GetEncoding("gb2312").GetBytes("汉字");
    Array.Resize(ref bytes, bytes.Length + 1);
    RemoteAllocation ra = ms.Memory.Allocate(bytes.Length);
    sharp["user32"]["MessageBoxA"].Execute(CallingConventions.Stdcall, 0, ra.BaseAddress, "Title", 1);

    I think MemorySharp should support:
    RemoteAllocation/Inptr Write/WriteString (data)
    not need pass in address as paramter and the method will alloc proper size and return the address.(like Marshal.StringToHGlobalAnsi)

  • #5214 Всем привет

    Posted by FloydZed on 04 June 2017 - 07:01 AM

    Привет, смотрели такую статью http://b2blogger.com...oom/202552.html ? Кто, что думает по этому поводу?

  • #90 MemorySharp is now free !

    Posted by YSharp on 29 December 2013 - 11:00 AM

    A fantastic work you've done here. Can't wait to start learning more and using the lib.

  • #59 DLL Error

    Posted by Abystus on 23 October 2013 - 08:45 PM

    Thanks for your report. You are right, RivalFr reported the issue you are encountering.


    I'm taking at heart the optimisation of the performance of my libraries. This is why I'm currently developing BenchShark, a library to benchmark functions in .NET applications. I firstly chose to make it to improve MemorySharp speed, but it can be used with any other applications.


    I will publish an official news when the library will be ready.  :)







    Very nice.  Hopefully that will be able to pinpoint the issues we are experiencing.   I'll have to try that app out on some of my other code to see if things can be optimized.  Thanks for sharing, and can't wait to see the updated library.

  • #58 DLL Error

    Posted by ZenLulz on 23 October 2013 - 06:20 PM

    Thanks for your report. You are right, RivalFr reported the issue you are encountering.


    I'm taking at heart the optimisation of the performance of my libraries. This is why I'm currently developing BenchShark, a library to benchmark functions in .NET applications. I firstly chose to make it to improve MemorySharp speed, but it can be used with any other applications.


    I will publish an official news when the library will be ready.  :)




  • #5611 What Up Coming Games...!!!

    Posted by Williamhawk on 10 October 2017 - 08:22 AM



         I would kill for a Legend of Dragoon sequel or remake with modern graphics and updated stuff. That is the only game I have ever played so much. I must have put a year into it with over 100 restarts once beating it. As far as looking forward to anything come out....I'm planning to get Dragon's Dogma Dark Arisen that released earlier this month. Played it when it first came out and find it so darn fun especially when you could use the followers of other players to help you out. Also wanting to get a PS4 Pro to FINALLY play Horizon Zero Dawn. I've avoided anything related to that game since it came out so I can enjoy it when the time comes.



    Please help.
    I didn't find the right solution from the Internet.


  • #5576 Logitech Craft?

    Posted by Williamhawk on 04 October 2017 - 06:49 AM



         At this year's IFA fair in Berlin, Logitech introduced a very interesting CRAFT keyboard designed for content creators, which brings with it a fairly intelligent system of contextual adaptation to a particular situation, or rather the application where the creator of the content is located. In order to make this the best use of the way, the new Input mechanism, which Logitech calls - Crown!


    Please help.
    I didn't find the right solution from the Internet.


    Posted by Williamhawk on 28 September 2017 - 07:39 AM



        This is why I'd never play HC. I've DC'd a few times due to my router suddenly going NOPE and had a gfx driver crash once too because I pushed an overclock a little too high, both of these things would've cost me a character and countless hours, I'll take my softcore experience instead,  Leader boards also a great place to see what other players of the same class are wearing when they cleared that GR level. Doing up to say GR 70 can be done by all sets, but depends on paragon level and skills. Some sets easier than others. The nice thing for DH is that 3 of the 4 sets really easy to play up to around GR 70 in solo. Natalays might be ok for older players but I personally hate the set and find it the hardest DH set to play. But unhallowed essence, Marauders, and shadow all have strong builds with it that make doing higher level solo clears fairly easy once you have all the gear you need.


    Please help.
    I didn't find the right solution from the Internet.

  • #5530 How to make memory sharp?

    Posted by Williamhawk on 20 September 2017 - 02:07 PM

    I m not able to remember the things and i cannot recall them after some times so can someone give me tip to make my memory sharp so that will also help me
    thank you in advance it will be much helpful.
    I didn't find the right solution from the Internet.

  • #54 DLL Error

    Posted by Abystus on 21 October 2013 - 03:36 AM

    Not sure if there is some way to prevent this in code on my end.  I get a "The handle is not valid" error from the DLL when not being logged into a character, or entering (and remaining in) an instance (World of Warcraft), which I did not get using my old ReadProcessMemory/WriteProcessMemory functions.  Some pics:






    I have yet to identify where in code it is occurring as I do not receive any sort of break in code, but only the error that shows is from the dll.  Do you happen to know the cause, and possibly how it can be prevented?




    I found the origin of the error in my code (durp forgot to click "Break when this exception type is thrown"), and basically boils down to an invalid address being passed (seems this should be handled in the dll for invalid addresses on all reads/writes)?


    Error in code is on this write:




    This forces me to check each address as a precaution like the following to resolve the issue (if it occurs):



    Could you make it just return defaults for each type of invalid read (this could be an optional flag, something like bool IgnoreErrors), and possibly just move on with no error if a write failed (invalid address) within the dll (maybe make your write methods return a boolean for success and suppress the error, again flag based)?  I would have to create a wrapper around your code for Read/Write that first checks the address (to prevent having to check it everywhere), and returns defaults for each type otherwise (I know, I know.. I should find out why the address is taking a dump to begin with, but it would be a nice feature to add on your end imo).  Any help is appreciated.

  • #53 Getting Started (Porting)

    Posted by Abystus on 19 October 2013 - 08:49 PM

    Thanks for the example and break down. I think this should work well enough for me (still shorter than my original code that didn't use your library):


            public static IntPtr FindAddress(IntPtr StaticPointer, int[] Offsets)
                    IntPtr Address = MemSharp.Modules.MainModule.BaseAddress + (int)StaticPointer; //Working base address from MemSharp + Static Address
                    foreach (int Offset in Offsets)
                        Address = MemSharp.Read<IntPtr>(Address, false) + Offset; //Read address and add each offset trailing
                    return Address; //Return final address
                catch (Exception ex) { return IntPtr.Zero; }


    Thanks for your quick responses and insight. I hope to see lots of updates for this very well laid out library. Keep up the great work!

  • #5131 Call to codecave not correct

    Posted by Hatschi on 27 June 2016 - 02:10 PM

    The following code should write a call to codecave at a specific address. It does write a call but the call points to somewhere else instead of my codecave address.

    Dim allocMem As Binarysharp.MemoryManagement.Memory.RemoteAllocation = MSharp.Memory.Allocate(1024, Binarysharp.MemoryManagement.Native.Enums.MemoryProtectionFlags.ExecuteReadWrite, True)
    Dim callStr As String = $"use32 & {vbnewline} call {allocMem.BaseAddress}"
    MSharp.Assembly.Inject(callStr, scriptInjectionAddress)

  • #5130 .NET 4.0 Build

    Posted by Cyrem on 23 June 2016 - 04:48 AM



    I have a problem where I need to build my memory editor launcher under .NET 4.0 to be compatible with XP, however I can't build it as MemorySharp relies on FASM which was built against 4.5.


    Is there any chance the framework could be lowered to 4.0 and still function as normal?



  • #5108 Pattern Scanning?

    Posted by Cyrem on 14 January 2015 - 07:19 AM



    Well thats great to hear and I look forward to when it arrives. :)

  • #5 Welcome to Binarysharp

    Posted by ZenLulz on 28 July 2013 - 06:03 PM

    Welcome on Binarysharp's website dedicated to ZenLulz production.

    For several years, I'm making software development and I finally decided to publish my applications/libraries on the Web. This website will be mainly dedicated to .NET development (C++/CLI, C#) and Memory Editing (reverse engineering). Also, I set up a community area where you can speak with each other about Binarysharp’s products, development or reverse engineering. Feel free to download software available, create an account to participate to the community or simply subscribe to the RSS.

    See you there.

    Click here to view the article

  • #44 Features forecast

    Posted by ZenLulz on 15 October 2013 - 05:32 PM

    Dear Community,


    I decided to list the features that can/will be shipped within MemorySharp on the long run in order to make the development of the library clearer.

    Here are the planned features of the library :

    • [Working] 64-bit support
    • [Pending] PE format analysis
    • [Pending] Executor mechanism
    • [Pending] Hook mechanism
    • [Pending] Pattern searcher mechanism
    • [Pending] Patching mechanism

    Here are the features proposed by the members that can be great to implement :

    • Inject .NET assemblies within a native process


    The features are ordered by status/alphabetical order and does not by order of implementation.

    Feel free to post your suggestions in the dedicated forum.




  • #15 RemoteModule and Structures.

    Posted by master131 on 22 September 2013 - 04:54 PM

    I'm glad I could help. Also, just a tip, in your IsWoW64Process function, you should check that the function exists before calling it using GetProcAddress as suggested on MSDN, otherwise it'll throw an exception.



  • #132 Thanks thread

    Posted by ExVault on 24 September 2014 - 04:41 AM

    I can't find an appropriate place for this, so I post it here.


    I just want to thanks ZenLulz for creating such a great library. I wish you good luck in all your future projects. Good job man!

  • #13 RemoteModule and Structures.

    Posted by master131 on 22 September 2013 - 04:04 AM

    I came across BinarySharp today and its VERY impressive. It's like an all-in-one library for memory/process related operations and I'm amazed at how extensive it is.


    I was interested in how the addresses of remote functions were being found and it seems that it attempts to call LoadLibrary on the target module instead of manually reading it remotely from the Portable Executable structure in memory. I did notice that you said that you were currently working on a "PE Format Analysis" feature which will probably allow this to happen without having to load the module but its just a suggestion if you didn't think of it.


    I have written my own extensive portable executable class but I didn't add any abstraction for it to work with memory (only works with images on disk) so it'd be nice to see someone else's approach on it.


    The following only applies when you decide to add both 32-bit and 64-bit support to your library (as far as I know it's 32-bit only right now).


    Also, I've had a look at the ManagedTeb and ManagedPeb classes and it seems they're using Enums to obtain the field offsets. Due to the varying in sizes of the pointer type in 32-bit and 64-bit applications, wouldn't those offsets break? From looking at your enums, it seems like you've assumed that all pointer types are 4 bytes long. Also, in the TebStructure enum, you've called one of the fields "WoW64Reserved" when the correct name is actually "Wow32Reserved".


    Another thing is that in WoW64 processes, there are actually 2 PEBs and 2 TEBs. One is the 32-bit version and the other one is the 64-bit version. The 64-bit TEB and PEB structure actually vary, that being the pointer sizes are different. Also, in the 64-bit PEB, the GdiHandleBuffer field only has 30 values as opposed to 34. If you require a detailed reference, you can look here.


    Also, obtaining the PEB/TEB of another process is abit troublesome too. If you are a 64-bit process and wish to obtain the 32-bit PEB of a Wow64 process (which is the default one if you were that Wow64 process), you need to use ProcessWow64Information with NtQueryInformationProcess instead of ProcessBasicInformation otherwise it'll return the 64-bit PEB (use IsWow64Process along with a GetProcAddress check to determine if a process is running under WoW64). When using NtQueryInformationProcess with ProcessWow64Information, it takes a reference to a pointer-sized integer (aka, IntPtr) instead of a PROCESS_BASIC_INFORMATION structure and puts the address of the PEB in this pointer-sized integer.

    [DllImport("ntdll.dll", SetLastError=true)]
    public static extern int NtQueryInformationProcess(IntPtr hProcess, PROCESSINFOCLASS pic, ref IntPtr pbi, int cb, out int pSize);


    If you are a 64-bit process and wish to obtain the 32-bit TEB of a Wow64 process, you use the same usual method of obtaining the TEB using NtQueryInformationThread (which in this case will return the 64-bit TEB) and then add 0x2000 because the 64-bit TEB always preceeds the 32-bit TEB by 2 pages (reference: here, check Side Notes, you can see the offset is hardcoded in Wow64cpu!CpuThreadInit).


    Once you've made all the necessary fixes for 32-bit/64-bit TEB/PEB structures, you could easily add a feature that allows you to unlink/hide a module from the PEB. (example: here)


    Another thing is the .NET Process suffers from a problem where if you are running as a 64-bit process and are trying to list the modules of a Wow64 process, it will only list the 64-bit modules (the target's main module, ntdll.dll, wow64.dll, wow64win.dll and wow64cpu.dll). The workaround is to use EnumProcessModulesEx with the LIST_MODULES_ALL filter flag (note that this function only exists in Vista and higher). Then you have you use the populated module handle array with the corresponding functions to obtain the module name, path, size, etc (GetModuleBaseName, GetModuleFileNameEx and GetModuleInformation respectively). The only problem with this is that you cannot create an instance of the ProcessModule class unless you use some hackery with Reflection and populate the internal ModuleInfo class and call the ProcessModule internal constructor.


    Hope this helps. If you require me to explain me to explain anything, then let me know. :)