Freitag, 26. September 2014

[Tools] VirtualWin: Virtual desktops for Windows

Edit from 2017: With Windows 10 VirtualWin isnt needed anymore :)

Hey there,
to fill the time between the c# memory manipulation tutorials I convinced myself to post about free software / services which I use to enhance my daily pc experience.

One awesome software I use since many years is the open source program VirtualWin (http://virtuawin.sourceforge.net/)

Like the name already implies it enhance windows with the possibility to work on several virtual desktops:


Even more awesome: Its easy as hell
Launch it
Define shortcuts for each desktop and enjoy a better arranged workstation.

Atleast I cant work with a full taskbar: Spotify, Skype, VisualStudio, WoW, IRC, Pidgin, different browser window etc.
With the help of this tiny little tool I can split the tools I use over several desktops and focus much better on the things I am doing right now instead of being distracted every moment (and its also awesome to hide Warcraft 3 and other games from teachers in school :p)

Dienstag, 23. September 2014

[WoW v1.12.1 / C#] aaaaand more basics: Manipulating other process memory (without a library)

Hello,
as I previously stated I use BlackMagic by Shynd to interact with other processes. When I started with the whole topic I used it without even knowing what this great dll was doing in detail (which is bad in my opinion).

In this post I want to take a step back and write the current tickcount into LastHardwareAction without any kind of tool.

What is required?

  • WoW v1.12.1
  • Cheat Engine (to control if we do our job good)
  • Basic C#

Lets go!

1. First of all: LastHardwareAction address is 0x00CF0BC8

2. Attach Cheat Engine to your WoW instance and add the address manually by Add Address Manually. The type is 4 byte (UInt / Int -> 4 byte)

3. To modify memory of another process we need WriteProcessMemory which is provided by Kernel32.dll. We follow the suggestion of pinvoke (http://www.pinvoke.net/default.aspx/kernel32.writeprocessmemory) and define our prototype like this:

 [DllImport("kernel32.dll", SetLastError = true)]  
     static extern bool WriteProcessMemory(  
       IntPtr hProcess,  
       IntPtr lpBaseAddress,  
       IntPtr lpBuffer,  
       int nSize,  
       out IntPtr lpNumberOfBytesWritten);  


4. To verify our MemoryWrite we also want to read the memory. Once again we define another prototype for ReadProcessMemory:

 [DllImport("kernel32.dll", SetLastError = true)]  
     static extern bool ReadProcessMemory(  
       IntPtr hProcess,  
       IntPtr lpBaseAddress,  
       [Out] byte[] lpBuffer,  
       int dwSize,  
       out IntPtr lpNumberOfBytesRead);  

5. Now that we got Read and WriteProcessMemory defined we need a simple UInt which we will convertert into a byte array and write to memory later

 uint exTickCount = 1;  
 byte[] bCurTickCount = BitConverter.GetBytes(exTickCount);  

6.  Lets break up this little snippet:

 Process WoW = Process.GetProcessesByName("WoW")[0];  
 IntPtr bytesWritten = IntPtr.Zero;  
 IntPtr lpBuffer = Marshal.AllocHGlobal(Marshal.SizeOf(bCurTickCount[0]) * 4);  
 Marshal.Copy(bCurTickCount, 0, lpBuffer, bCurTickCount.Length);  
 WriteProcessMemory(WoW.Handle, (IntPtr)0x00CF0BC8, lpBuffer, bCurTickCount.Length, out bytesWritten);  

We obtain all Processes with the name WoW and pick the first one (Since this is just an example ... who gives a fuck)
We initialise bytesWritten with IntPtr.Zero

We use Marshal.AllochGlobal to allocate the needed size of bytes in the unmanaged address space of our program (http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.marshal.allochglobal(v=vs.100).aspx)
With Marshal.SizeOf we get the size of bytes a managed object has unmanaged:
You can use this method when you do not have a structure. The layout must be sequential or explicit.
The size returned is the size of the unmanaged type. The unmanaged and managed sizes of an object can differ. For character types, the size is affected by the CharSet value applied to that class. (source)

Since all elements of our array are from the same type we just multiple the value we get from Marshal.SizeOf with our count of elements and get the value of bytes we need to allocate.

Next step is about copying our managed byte array in unmanaged memory with the help of Marshal.Copy:
1. parameter -> Our byte array
2. parameter -> The element where we begin to copy
3. parameter -> Pointer to the beginning of our previously allocated unmanaged space
4. parameter -> The length of bytes to copy into unmanaged memory

Finally we call WriteProcessMemory:
1. parameter -> Handle to our process
2. Parameter -> Address of LastHardwareAction
3. parameter -> Pointer to our previously allocated unmanaged bytes now storing the byte array
4. parameter -> The length of bytes to write
5. parameter -> Will hold the values of bytes we successfully wrote into the address space of WoW

Want to know more about unmanaged and managed memory? I found a great post on stackoverflow explaining this topic (stackoverflow).

6. Everything worked? Great! Lets view LastHardwareAction in Cheat Engine (this time as: Array of byte (size 4))
Following this tutorial you will most likely see the result I saw:




Windows stores bytes in little endian which means that the little end (our last element) is stored first.
Short version: Bytes are reversed (if you calculate the value you start of with the first left byte instead of the first right)

Reading from memory is pretty much the same game. Create an empty array with the size of bytes you want to read. Pass handle, address, aswell the empty array to ReadProcessMemory and enjoy the results.

The full source code can be viewed here: https://github.com/Zz9uk3/MemWriteTest (a pre-compiled binary is also included)

If you have problems, questions or suggestions for further posts I would be glad to have a chat over skype (cmwts9) or IRC (#FeenixED on quakenet).

Moreover I want to point to an OwnedCore-thread collecting links to all kind of memory manipulation librarys:
http://www.ownedcore.com/forums/world-of-warcraft/world-of-warcraft-bots-programs/wow-memory-editing/331363-memory-hacking-library-list.html



Sonntag, 21. September 2014

[WoW v1.12.1 / C#] The first memory manipulation

If you havnt read my last tutorial I would advice you to read it:
http://zzuks.blogspot.ch/2014/09/a-basic-window-mover.html

Today we want to write a simple anti-Afk tool for the WoW version 1.12.1. Like in the previous post the whole source will be attached to the end of the post.

What is required?

  • Basic C#
  • WoW v1.12.1
  • Cheat Engine
What we should know?
Every state and change in the game is also a change in the memory.
Environment.TickCount holds the value in milliseconds the PC is running since last start (http://msdn.microsoft.com/en-us/library/system.environment.tickcount(v=vs.110).aspx)
Everytime we press a key or do something with our mouse the "LastHardwareAction" is set to our current TickCount
When the TickCount stored in "LastHardwareAction" is older than 5 minutes we are flagged as AFK

How we find the Address for "LastHardwareAction"?
First of all we launch WoW and attach Cheat Engine to it.
Since we know that an int / uint has the size of 4 byte we will scan for 4 byte values.
Every time we move our mouse in the boundaries of the WoW window the TickCount in LastHardwareAction is also updated.
The solution is scanning for changed / unchanged / increased values

Lets go then

  1. We get our current TickCount with help of Environment.TickCount
  2. After obtaining it we make the LastHardwareAction in WoW update by moving our mouse inside the window boundaries
  3. Since the TickCount in LastHardwareAction is bigger than the TickCount we previously copied we do a first Scan with the Scan Type: "Bigger than ..." and the value of our copied TickCount.
  4. After the first scan we will stil have a lot of address.
  5. To reduce those we do the following: Do a Next Scan with the Scan Type: Unchanged value if you havnt changed the LastHardwareAction for the moment (No keypress or mouse move inside the WoW boundaries)
  6. If you have changed the LastHardwareAction we do a Next Scan with the Scan Type: Increased value

After reducing the found addresses to a good minimum we will find many values storing the TickCount of the players last hardware action however we will stick to this one: 0x00CF0BC8

Since we found the address we need a way to update its value from another process. Usually one would use WriteProcessMemory (http://msdn.microsoft.com/en-us/library/windows/desktop/ms681674(v=vs.85).aspx) and ReadProcessMemory (http://msdn.microsoft.com/en-us/library/windows/desktop/ms680553(v=vs.85).aspx) however I will stick to a library called BlackMagic.

In my sample project I do the following:
  1. Get all processes with the Name "WoW"
  2. Iterate over the process list
  3. Check if the current WoW process is version 1.12.1
  4. If it is write our current TickCount (obtained using Environment.TickCount) into LastHardwareAction
The procedure will be repeated every 10 seconds. Every open WoW 1.12.1 is prevented from flagging us as AFK now.


The full source code can be viewed here: https://github.com/Zz9uk3/AfkPreventer (a pre-compiled binary is also included)

If you have problems, questions or suggestions for further posts I would be glad to have a chat over skype (cmwts9) or IRC (#FeenixED on quakenet).

When I am at home again I will prolly extend this a bit and also upload the source of BlackMagic (credits to Shynd obviously)



Samstag, 20. September 2014

[WoW v1.12.1 / C#] A basic window mover

Hello fellow readers,
instead of beginning with the bot tutorial I will first of all explain and post some easier and more tiny tools. That way I try to progress slowly towards our goal instead of just going for the big fish.

Today we will program a window mover in C# for World of Warcraft (or any other game). This tiny tool was always a nice help when i had to deal with multiple WoW windows:


1: Gather all processes relevant to the windows you want to move

 List<Process> WoW = new List<Process>();  
 foreach (Process p in Process.GetProcessesByName("WoW"))  
 {  
      WoW.Add(p);  
 }  

2: Obtain the window handles from the process.
What is a handle?
A HANDLE in Win32 programming is a token that represents a resource that is managed by the Windows kernel. A handle can be to a window, a file, etc.
Handles are simply a way of identifying a particulate resource that you want to work with using the Win32 APIs.

Conclusion: We need the handles pointing to our WoW windows.
 IntPtr[] Handle = new IntPtr[WoW.Count];  
 for (int i = 0; i < WoW.Count; i++)  
 {  
      Handle[i] = WoW[i].MainWindowHandle;  
      WoW[i].PriorityClass = ProcessPriorityClass.Normal;  
 }  

3: After obtaining the handles to our WoW windows we need to obtain the following:
Screenwidth aswell screenheight.
 int GlobalHeight = SystemInformation.VirtualScreen.Height;  
 int GlobalWidth = SystemInformation.VirtualScreen.Width;  

Before we continue we need to realise the following
The coordinate system for a window is based on the coordinate system of the display device. The basic unit of measure is the device unit (typically, the pixel). Points on the screen are described by x- and y-coordinate pairs. The x-coordinates increase to the right; y-coordinates increase from top to bottom. The origin (0,0) for the system depends on the type of coordinates being used.

The system and applications specify the position of a window on the screen in screen coordinates. For screen coordinates, the origin is the upper-left corner of the screen. The full position of a window is often described by a RECT structure containing the screen coordinates of two points that define the upper-left and lower-right corners of the window.

Short version: The point (0/0) is the top left corner of our monitor.

4: Before we can move the window we need to learn about dllimportant:
With dllimport we can call functions provided by a dll that is written in unmanaged code (C++, C etc.). Windows is providing a lot of functions to interact with the system and the processes running on it. To call those we need to define a prototype of a function and "assign" it to a function of an unmanaged dll.
The whole topic a bit better explained: http://msdn.microsoft.com/en-us/library/aa984739(v=vs.71).aspx

To move another process window we need the function "SetWindowPos" provided by the "user32.dll". With the help of PInvoke we can get pretty good infos about all WinAPI functions and how we are supposed to call them in any .net language: http://www.pinvoke.net/default.aspx/user32.setwindowpos

 [DllImport("user32.dll")]  
 private static extern bool SetWindowPos(IntPtr hWnd, IntPtr hWndInsertAfter,  
      int x, int y, int width, int height, uint uFlags);  

After defining the prototype of SetWindowPos and creating the handle list of windows we can go on with step 5.

5: Before we learned that the very top left point of our screen is 0/0. If we move our point to the right the X-coordinate increases. If we move our point towards the bottom our Y-coordinate increases.

Since we want to start repositioning our windows at the top right of the screen we will start with the following set of coordinates:
(GlobalWidth - x / 0)
In this case x is representing the width of our wow window since it would otherwise be moved outside the screen boundaries.

 int Schieber = 0;  
 int Row = 1;  
 foreach (IntPtr p in Handle)  
 {  
      // 310 241  
      SetWindowPos(p, IntPtr.Zero, GlobalWidth - (x * Row), 0 + (y * Schieber), x, y, SHOWWINDOW);  
      Schieber++;  
      if (Schieber > 2)  
      {  
           Row++;  
           Schieber = 0;  
      }  
 }  

As you can see we iterate over our array of handles repositioning and resizing each of them. After each repositioned window the Y-coordinate will be increased to move the next window in line below the previous window.
If there are are 3 windows placed over each other it will move one window width to the left and start the next column.


The full source code can be viewed here: https://github.com/Zz9uk3/WoWMover (a pre-compiled binary is also included)

If you have problems, questions or suggestions for further posts I would be glad to have a chat over skype (cmwts9) or IRC (#FeenixED on quakenet).