Who knows, especially now that we are working on RAM Keygen again. Try uninstalling it then reinstalling, AV likely deleted it.
to chandu_ycm I recomend you before instaling the loader disable your antivirus and firewall. Then install the toolkit. After that search an option in your antivirus to exclude files, folder, etc, so the antivirus don't delete the loader. At the end enable your antivirus and firewall again. I did these and it works fine. I hope this help you a little.
ok i'll try again after uninstalling office 2010 completely. i've installed and uninstalled 2 times on my OS, is this may create any problem? i am using MSDN's professional plus trail version.
Hi Cody, I was wondering if there has been a fix for the "check available rearms" button deactivating Office 2010 under certain circumstances? The changelog doesn't seem to suggest so. If not, are you still working on it? (I'm on 2.1.4)
Installed 2.1.6 and available button deactivate office 10 pro plus and go to 30 days. I just have 1 single rearm. I uninstall and reinstall EZ activator and again is ok
Check your topic. It can get all keys, but you cannot rely on the keys in the registry being actually installed. See the post there for more info. I posted modded source from the toolkit.
Think I might have gotten the first method I ever saw to run in RAM working, in C#. A file called CMemoryExecute.cs was the first thing I tried and it never worked. Two things are at fault. One is that you cannot inject into a 64 Bit process, the other is me compiling the toolkit as "Any CPU" breaks it from ever working. Good to see Krakatoa's AutoIT post up, as it could be useful, but the code I plan to use if I get this working the way I want won't require it. I injected KMSEmulator into vbc.exe, which is running is a CMD window it popups and title says vbc.exe, but it is KMSEmulator. I just need to inject into a process that won't popup a window and I'm good.
"won't popup a window" in autoit script: DllStructSetData($tSTARTUPINFO, "Flags", BitOR(0x00000001, 0x00000100)) DllStructSetData($tSTARTUPINFO, "ShowWindow", 0) Modify in c#? All example code (Create new process): Code: ; STARTUPINFO structure (actually all that really matters is allocated space) Local $tSTARTUPINFO = DllStructCreate("dword cbSize;" & _ "ptr Reserved;" & _ "ptr Desktop;" & _ "ptr Title;" & _ "dword X;" & _ "dword Y;" & _ "dword XSize;" & _ "dword YSize;" & _ "dword XCountChars;" & _ "dword YCountChars;" & _ "dword FillAttribute;" & _ "dword Flags;" & _ "word ShowWindow;" & _ "word Reserved2;" & _ "ptr Reserved2;" & _ "ptr hStdInput;" & _ "ptr hStdOutput;" & _ "ptr hStdError") DllStructSetData($tSTARTUPINFO, "Flags", BitOR(0x00000001, 0x00000100)) DllStructSetData($tSTARTUPINFO, "ShowWindow", 0) ; This is much important. This structure will hold very some important data. Local $tPROCESS_INFORMATION = DllStructCreate("ptr Process;" & _ "ptr Thread;" & _ "dword ProcessId;" & _ "dword ThreadId") ; Create new process Local $aCall = DllCall("kernel32.dll", "bool", "CreateProcessW", _ "wstr", $sExeModule, _ "wstr", $sCommandLine, _ "ptr", 0, _ "ptr", 0, _ "int", 0, _ "dword", 4, _ ; CREATE_SUSPENDED ; <- this is essential "ptr", 0, _ "ptr", 0, _ "ptr", DllStructGetPtr($tSTARTUPINFO), _ "ptr", DllStructGetPtr($tPROCESS_INFORMATION))
Thing is the C# code doesn't have structs, but I'm trying to mod. The code I'm using is totally independent of the autoit, but I'm comparing to see if I can make it hide.
Given that this would wipe out writing the file to disk, I need to find a way to patch the port in the byte array. I added port change/set to 2.1.7 (not BETA 1), but this must be set before KMS Keygen runs. Basically I have to get it as a variable then edit it then inject it.
RAM Execution has been perfected, Port, PID and all. One more issue preventing a 2.1.7 release. It is related to the key checker. EDIT: More problems than I thought. Having to compile for x86 to do RAM Execution has screwed up Backup/Restore/Repair because of the crappy registry redirection.
Nope, just solved the issue with a simple trick. The redirection occurs because it is 32 bit under 64 and starts 32 bit cmd. I simply rigged our "ExecuteCommand" process to figure out if the OS is 64 bit, and access the 64 bit cmd.exe by using "sysnative", another name for system32. Means normally sys32 gets redirected, now it won't, calling the 64 bit cmd on 64 bit os and bypassing the redirection.
Unfortunately I still need Microsoft.Win32 class calls to access the registry to work and they are screwed. Can't repair because the redirection screws up the read. .NET 4 has expanded the class we use to help us, I may have to go .NET 4 as opposed to totally rewriting everything and having to use DLLImports everywhere.