Leaderboard

If you are familiar with the Armadillo program, you will remember that this software had a very interesting feature called "Nanomits", which was created to prevent dumps from being taken from protected processes. The source code below is actually a re-engineered version of the original product's behavior that is available to everyone https://github.com/NIKJOO/Nanomits Give repo a star if you find it useful.

@Noob boy Hi again! I spent some time unpacking this WinLicense v3.2.2 x64 target. unpacked_x64.zip

Found how to solve it. Put bp on ntdll.dll and it lands to ntdll.dll:$52DD6 #521D6 <RtlAllocateHeap>. But there are many calls like this. The question is can this be done by script or every call have to be solved manually?

Hi X0rby, tried to solve this unpackme, thank you for the afford. I have a question. For example: 00409F46 | E8 D2F55100 | call asmtomachinecode.vmp_dump_scy.92951D | 00409F4B | CE | into | 00409F4C | 5E | pop esi | 00409F4D | C3 | ret | you solve it as: 00409F46 | FF15 E8E00A02 | call dword ptr ds:[<HeapAlloc>] | 00409F4C | 5E | pop esi | esi:"U‰еjяhP@A" 00409F4D | C3 | ret | How to do it if you don't have the original non packed file?

not so much , in modern CPUs you feel nothing

I don't think it can be done without the Dongle, or Dongle emulation.

Nice src... 😃 What about armadillo Debug-Blocker source code?

O. M. G !!!!!!!!!!! https://github.com/github/dmca/blob/master/2025/05/2025-05-13-vmprotect.md

guys, its 11 years old post.... calm donw

share dongle data

Minimum supported clientWindows 2000. OK! sounds better

https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-ntqueryobject

OK, 2nd function OK but IMHO it's risky to use it, here is why: NtQueryObject: - This function may be changed or removed from Windows without further notice. - This function has no associated header file or import library. You must use the LoadLibrary or GetProcAddress function to dynamically link to Ntdll.dll. - not clear what Windows versions supports it (no info in MSDN) - if you try the ObjectTypeInformation type you'll get error 0xc000004

thanks, I see updated algo above, I'll give it a try today

bool CheckCreateThreadHandleCount() { PUBLIC_OBJECT_BASIC_INFORMATION objInfo = {}; HANDLE hThread = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)dummy, NULL, 0, NULL); if (hThread == NULL) { return false; } NTSTATUS status = NtQueryObject(hThread, ObjectBasicInformation, &objInfo, sizeof(objInfo), NULL); if (!NT_SUCCESS(status)) { CloseHandle(hThread); return false; } DWORD HandleCount = objInfo.HandleCount; Sleep(0x32); objInfo = {}; status = NtQueryObject(hThread, ObjectBasicInformation, &objInfo, sizeof(objInfo), NULL); if (!NT_SUCCESS(status)) { CloseHandle(hThread); return false; } std::cout << "Handle Count: " << objInfo.HandleCount << std::endl; if (objInfo.HandleCount != HandleCount) { CloseHandle(hThread); return true; } CloseHandle(hThread); return false; }

@Noob boy This is a sample of my unpacking this WinLicense v3.2.2 x86 target. For x64 cases, the method is similar. unpacked_x86.zip

for my research i built (a lot of headache though) it and im enjoying debugging it. if you still need help, say it.

smth is wrong with your code I tried sample consle app and it prints 2 when being ran without debugger and 4 when unde4 MS VS... are you sure this is reliable new anti-debug way?

@bootHi~ Expert, can Lengyue's WinLicense v3.2.2 be bypassed? If not, can you try my default encryption version?

If we would have this class: public class CentroidCluster<TCollection, TData, TCentroid, TCluster> : Cluster<TCollection, TData, TCluster> where TCollection : IMulticlassScoreClassifier<TData, int>, ICentroidClusterCollection<TData, TCentroid, TCluster> where TCluster : CentroidCluster<TCollection, TData, TCentroid, TCluster>, new() { } I would just do this: public class DerivTCollection : IMulticlassScoreClassifier<int, int>, ICentroidClusterCollection<int, int, CentroidClusterDeriv> { } public class CentroidClusterDeriv : CentroidCluster<DerivTCollection, int, int, CentroidClusterDeriv> { } we successfully derived class CentroidCluster but now the problem: how we could do with reflection since those classes uses each other https://learn.microsoft.com/en-us/dotnet/api/system.reflection.emit.typebuilder?view=net-9.0 TypeBuilder final Type value is calculated with Type t = tb.CreateType(); but the problem is that class is not yet finished; Any solution?

I think this is a framework limitation and can't be done. I would rather spend time on realizable things.

var assembly = AppDomain.CurrentDomain.DefineDynamicAssembly(new AssemblyName("Test"), AssemblyBuilderAccess.Run); var module = assembly.DefineDynamicModule("Test"); var typeOne = module.DefineType("TypeOne", TypeAttributes.Public); var typeTwo = module.DefineType("TypeTwo", TypeAttributes.Public); TypeConflictResolver resolver = new TypeConflictResolver(); resolver.Bind(AppDomain.CurrentDomain); resolver.AddTypeBuilder(typeOne); resolver.AddTypeBuilder(typeTwo); Type GenericI2 = typeof(Interface<,>).MakeGenericType(new Type[]{typeof(int), typeOne}); typeTwo.AddInterfaceImplementation(GenericI2); Type[] tbCentroidCluster11X = new Type[] {typeTwo, typeof(int), typeof(int), typeOne}; Type tCentroidCluster11X = typeof(CentroidClusterSimplified<,,,>).MakeGenericType(tbCentroidCluster11X); typeOne.SetParent(tCentroidCluster11X); typeOne.CreateType(); typeTwo.CreateType(); I can't see nothing wrong with the above code; but it throws exception System.TypeLoadException: Could not load type 'TypeOne' from assembly 'Test, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. at System.Reflection.Emit.TypeBuilder.TermCreateClass(RuntimeModule module, Int32 tk, ObjectHandleOnStack type) at System.Reflection.Emit.TypeBuilder.CreateTypeNoLock() at System.Reflection.Emit.TypeBuilder.CreateType()

More examples: https://stackoverflow.com/questions/21035470/using-reflection-emit-to-implement-generic-interface If I left as TypeBuilder throws the above error; no Domain_TypeResolve is called. it will works only if I create the Type using CreateType of TypeBuilder like this: if (rtypes[0] is System.Reflection.Emit.TypeBuilder) rtypes[0] = ((System.Reflection.Emit.TypeBuilder)rtypes[0]).CreateType(); interesting is that types created multiple times are equal: Type type1 = typeUseItself.CreateType(); Type type2 = typeUseItself.CreateType(); if (type1.Equals(type2)) { Console.WriteLine("Cool!"); }

@hitech444 if your original question was intended to mean, "can this PureBasic "keygen" be used to activate the full version of SpiderBasic", then I misunderstood you and wasted my time updating the PB code. This is an example keygen template written in PureBasic, it is not a real keygen and, cannot be used to activate either PureBasic or SpiderBasic. The free versions of these cannot be activated using a serial number, there is a full version download and installer - accessible to paid customers. You could theoretically remove the code line limit in the free version/s. If your question was, "can I run this PureBasic "keygen" code in SpiderBasic", then yes. A few, quick and rough, modifications to the original PureBasic code will make it work... Ted.

https://stackoverflow.com/questions/6735274/why-am-i-getting-this-exception-when-emitting-classes-that-reference-each-other but not working in my case; System.ArgumentException: Type must be a type provided by the runtime. at System.Activator.CreateInstance(Type type, Boolean nonPublic) at System.Activator.CreateInstance(Type type) at BabelDeobfuscator.Protections.MethodEncryption.VMDecryptor.GetGenericInstance(Type gtype, Assembly asm) in d:\Projects2021-2024\NET\Babel-Deobfuscator\Babel-Deobfuscator\MethodEncryption\VMDecryptor.cs:line 835 at BabelDeobfuscator.Protections.MethodEncryption.VMDecryptor.Testing(Assembly asm) in d:\Projects2021-2024\NET\Babel-Deobfuscator\Babel-Deobfuscator\MethodEncryption\VMDecryptor.cs:line 1141 at BabelDeobfuscator.Protections.MethodEncryption.VMDecryptor.run(ModuleDefMD module, Assembly asm) in d:\Projects2021-2024\NET\Babel-Deobfuscator\Babel-Deobfuscator\MethodEncryption\VMDecryptor.cs:line 53 at BabelDeobfuscator.Program.Main(String[] args) in d:\Projects2021-2024\NET\Babel-Deobfuscator\Babel-Deobfuscator\Program.cs:line 289

Well, thanks a lot for the fixed keygen but I can't see the relevance... we need to modify the SB exe inside to make it work for much more code lines.... Am I missing something here??? I would expect to advice me to search for 800 and change it to something much, much bigger.....

Have you checked the limitations? I downloaded both SB and PB demos and checked for you... I have not tried SB however, in PB demo I was able to build (with some fixes) and compile an executable using @tim619 code. Check out the attached .zip file. keygen_fixed.zip To get it working in PB6.x I had to replace the legacy "module" commands to "music". In the process I noticed a number of other problems (threading, declarations, command order and event window) and spent a few minutes doing some quick fixes for you. I have not checked the "keygen" code, left it as is... Ted.

time to add new anti-dbg trick into ScyllaHide plugin !?!?

Among the anti-debug techniques, there's an interesting one worth noting. A dummy thread is created and then it calls Sleep(0x32). (The goal is for the created thread to be detected by tools like x64dbg.) Then, it calls NtQueryObject with the ObjectBasicInformation class using the thread handle. If the returned HandleCount is greater than 1, it determines that debugging is in progress. void dummy() { Sleep(8000); } bool CheckCreateThreadHandleCount() { HANDLE hThread = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)dummy, NULL, 0, NULL); if (hThread == NULL) { return false; } Sleep(0x32); PUBLIC_OBJECT_BASIC_INFORMATION objInfo; NTSTATUS status = NtQueryObject(hThread, ObjectBasicInformation, &objInfo, sizeof(objInfo), NULL); if (!NT_SUCCESS(status)) { CloseHandle(hThread); return false; } std::cout << "Handle Count: " << objInfo.HandleCount << std::endl; if (objInfo.HandleCount > 1) { CloseHandle(hThread); return true; } CloseHandle(hThread); return false; }

WinLicense 3.2.2 x64.zipWinLicense 3.2.2 x86Dome.rar Winlicense 3.2.2 has updated the verification method. The old method cannot be bypassed. So how can the new method bypass it

@X0rby bro please share the method instead of sharing unpacked files. Regards.

Hi, I want to present two different methods one can use to change the text which appears on the button. 1. Debugging using dnSpy - This method does not require any unpacking. Steps: Eazfuscator always encrypts strings before applying the virtualization. This means that the text in the button is encrypted. Since we know the string is encrypted by Eazfuscator, we find the string decrypter method. In order to find the string decrypter, first we navigate to entrypoint (dnSpy has a handy context menu action for this). Entrypoint looks a bit like this: Then we navigate to the method highlighted in the image. This class should contain the following code: Then finally we navigate to the class highlighted in the image and find a method which looks similar to this: This is the string decrypter. After we located this method we can go to the next step In order to hijack and modify the result we need to place breakpoints strategically. In this case i set a breakpoint on the last occurrence of "return text;` located at the end of the method. Now that we have set breakpoints, we can move forward to actually debugging the application. To do that we press F5 on the keyboard to start debugging and click OK on the dialog prompt. A breakpoint is hit, in the Locals window we see that our return variable "text" has a value of what looks like some cryptic string. We hit F5 to continue the debugging process. Our breakpoint was hit again, this time the string is ".ctor". We continue to debug using the F5 key. Continue to debug until the value of "text" is "CHANGE MY MESSAGE". Now we can get to changing the value. Let's right click the "text" local and select "Edit Value". The context menu disappears and we can now edit the value. We type in out new value, And press enter. Success! the value is now changed! We continue to debug the application until the main window appears. We have successfully modified the message without modifying the file at all. Using the same method we can press the button and modify the text displayed in the message box. 2. Deobfuscate and devirtualize the file - This is much much harder and requires custom tools to be developed. After deobfuscating and renaming the file using a renamer of our choice, we open the file in dnSpy and find the code we need to change. As the virtualization has been removed this is quite trivial. We can right click the string, select "Edit IL Instructions" and modify the operand of the "ldstr" instruction highlighted to our string. We can then save the file by going to File -> Save Module and selecting the location and pressing OK. Running the modified file results in the message being changed to what we wanted. I hope my rather easy to follow guide (for the first method) is beneficial to some people who want to learn other methods besides unpacking which can be used to change the behavior of a application! Fully deobfuscated, devirtualized and renamed file is attached below.EAZ.deobfuscated.exe More on unpacking and devirtualizing Eazfuscator: For the basic protection public code is already available, e.g. EazFixer For devirtualization, no public tools exist. Eazfuscator is pretty much a 1:1 VM so it is not very hard to restore. Only real annoyance is the equality comparison obfuscation and code encryption which Gapotchenko refers to as "homomorphic encryption" when it is really not that. It just encrypts both sides of a comparison and uses the decrypted value as the key of the code following the comparison.

Well, this topic is very interesting indeed.AFAIK, VMProtect usually includes four types of code integrity checks in an application protected with all advanced options enabled.1. File Check As SunBeam said, APIs called: CreateFile, CreateFileMapping, and MapViewOfFile. This happens during the shell code execution, i.e. between the target's entry point and the OEP. For this InlineMe, the followings are checked. Address Length Hash ------- ------ ----#00000001 003D0170 00010E78 D2953B20#00000002 003E1018 000061E8 632E395E#00000003 003D012C 0000003C 1EBECA14#00000004 003D0000 00000128 10C6C1DDFile Mapping Address: 003D0000Normally only 4 items in the table, and table itself not Hash checked. 2. Memory Check #1 This is for verifying the file image in memory when the target loaded. If you examined the table records, you'll figure out that it's also a file check! Large part of the records are for .vmp1 section validation, only few for PE Header. Table size varies from different version or target. There is a hash check for table itself, and the valid Hash stored at some place, which can be easily patched. 3. Memory Check #2 This is the memory check in a real sense, and applies mainly for the application. If the application was compressed, it happens after the user code, data and resource got unpacked. Table size is more bigger than the previous one, and the worse thing is that the table's Hash is hardcode in PCODE! In contrast with the Memory Check #1, records in the table not all meaningful. There is a End Flag, after that all the data is garbage. These three checks above are performed at the shell code execution stage. The record in table can be defined as: typedef struct { long EncryptOffsetRVA; long EncryptLength; long EncryptHash;} VMP_HashCheck_Record;The check procedure: a) decrypting OffsetRVA, +Modulebase, +Reloc. Factor; decrypting Length; c) call getHash handler to calculate Hash; d) encrypting the Hash; e) comparing it with the one in record.4. Random Memory Check No this kind of check in SunBeam's unsophisticated InlineMe. If the "Check the integrity of VM objects" option enabled, and a piece of the application code was virtualized, it will have an opportunity to show up. A check table does exist also, in which only the offset RVA are encrypted, and each length is one byte long for better execution performance. This silently check could be done many times in a virtualized code portion, but only one record is picked up randomly by the vRdtsc handler. According to VMProtect's help document, "A silent check means that the protected program will not show any messages in case the integrity of VM objects is broken, but it will cause the virtualized code to function incorrectly, which will lead to critical errors and, therefore, to the complete crash of the protected program." Okay, what the hell is going on within the SDK API VMProtectIsValidImageCRC? It's just the Memory Check #1 & #2!As Conquest mentioned previously, the getHash handler here is very very important! It's the critical clue for inline patching, even repacking a VMP target IMHO.If you logged the getHash handler(entry: 0041847A for vmp1) from the target's entry(00414699) to OEP(00401224), you'll find out that all the three checks are performed even this target not packed! Which means the VMProtectIsValidImageCRC function has been called once by the shell code in .vmp1 section. After read the log of the second getHash handler(entry: 0040CC9D for vmp0) between two Timer function CheckMemory(00401000) calls, it can be proved that only Memory Check #1 & #2 been done!Before continuing, let's discuss a little about foregoing approaches.White's solution is to patch the VMProtectIsValidImageCRC's result, it's simple and excellent only for this target! But, it's not the good approach because the patch point is within vRet handler, which is not generally applicable and dangerous in other case! First, the return value gets crap when went back to normal code from some virtualized user function or other SDK API in an application protected. Second, if the "Encrypt registers at VM output" option enabled, the return values at this point must be decrypted by another routines in different places.The ultimate aim is to prevent these checks or altering the content of tables. The more professional way is to patch the PCODE, that is difficult and needs advanced skill! The easy way is to hook the getHash handler, and patch the returns, somewhat as JohnWho did.The attached script is my method which just for demonstrating how to patch getHash handler and Memory Check #2 table, it's proper and enough for this scenario, I think.Followings are some references for this InlineMe. Modulebase: 00400000Imagebase: 00400000Memory Check #1 Table=====================Address: 00412180, Size: 00000210(0000002C Items), Table Hash: 84268688Item eOffset eLength eHash Decrypting dOffset dLength cHash ceHash----- ------- ------- ----- ------- ------- ----- ------#00000001: 99F316C6 43B06508 5BDB89EE => 00411000 0000111F 43C5CF7B 5BDB89EE#00000002: 99F6FCF6 43B075DF 056F5F20 => 00419CF9 000000CA ED58A5AD 056F5F20...#0000002B: 99F5875A 43B07219 B182023B => 0041359C 0000000C 996C48C8 B182023B#0000002C: 99F5375A 43B07219 B05176BB => 00413588 0000000C 983BBC48 B05176BBAlgorithm--------- OffsetRVA decrypting: +6A08E97A, Shld E, ++, bswap Length decrypting: Shrd 18, ++, Shld 18, ~, ^E347219D, +301E1D57, ~, ^77D93621 Hash encrypting: --, --, ~, bswap, +8B45E9E9, --, ~, bswapMemory Check #2 Table=====================Address: 0040D164, Size: 000021CC(000002D1 Items), Table Hash: C8A37D66Item eOffset eLength eHash Decrypting dOffset dLength cHash ceHash----- ------- ------- ----- ------- ------- ----- ------#00000001: BA3B965B 99C2CE3A AB72BDF6 => 00403768 00000007 EEA5E87A AB72BDF6#00000002: BA3B62F3 9CC2CE3A 55DA3F26 => 00406AD0 00000004 01200000 55DA3F26...#00000231: BA3B9899 8DC2CE3A 0552AC2B => 0040352A 00000013 3A5489D0 0552AC2B#00000232: BA3BB96E 9AC2CE3A 9502AE76 => 00401455 00000006 71567840 9502AE76#00000233: BA3BCDC4 61346F34 11058009 => FFFFFFFF <= *** Table End Flag found!Algorithm--------- OffsetRVA decrypting: +45C4323A, ~, --, -- Length decrypting: -A1C2CE3B, bswap, ++, ~ Hash encrypting: ^6153D6ED, -86B3B143, bswap, ~Note: cHash - Hash calculated by getHash handler; ceHash - Encrypted cHash; should == eHash if everythig is fine, else patches or software breakpoints detected.Script: /* Note: run this script at the target entry: 00414699 !!! MistHill at tuts4you.com, 2015/05/25*/ history 0 lclr bphwc bpmc bc var pWinMain var vGetHash var dwModuleBase var pMemoryCheckTable var bufTemp mov pWinMain, 0000102F ; all RVA mov vGetHash, 0000CC9D mov pMemoryCheckTable, 0000D164 gmi eip, MODULEBASE mov dwModuleBase, $RESULT add pWinMain, dwModuleBase add vGetHash, dwModuleBase add pMemoryCheckTable, dwModuleBase bphws pWinMain erun bphwc pWinMain cmp eip, pWinMain jne L_Exit mov [vGetHash-914], #49E8ED0D0000894500# mov [pMemoryCheckTable+18], #59518BD18D89D50D00003B4DFC7507B8667DA3C8EB108D92D973FFFF3B55FC7505B87AE8A5EEC3# mov bufTemp, [pMemoryCheckTable+1A58], 0C mov [pMemoryCheckTable+0C], bufTemp, 0CL_Exit: ret

The pipe doesn't work like UDP style packets when it comes to receiving the full buffer. You will receive the full thing. But yes, you need to read the pipe in a loop to handle incoming data and such. If you are worried about speed and such you could also use MMFs with a custom queue system. I can assure you that MMFs work great for this (and are more reliable then pipes). A project I have done for work involved pipes at first and after a few issues due to the speed and rate we needed to transfer data, we moved into a custom queued MMF system I wrote that is a ton faster and handled the data much more efficiently. The file created that is used with pipes is created on physical memory which are "mounted" to the named pipe file system. Inside your DLL you can create a thread using CreateThread to monitor the pipe like this: DWORD __stdcall YourThreadName() { HANDLE hPipe = INVALID_HANDLE_VALUE; unsigned char btData[ MAX_PIPE_SIZE ]; DWORD dwBytesRead; while( true ) { hPipe = CreateNamedPipe( lpPipeName, PIPE_ACCESS_INBOUND, PIPE_TYPE_BYTE|PIPE_WAIT, PIPE_UNLIMITED_INSTANCES, MAX_PIPE_SIZE, MAX_PIPE_SIZE, STDTIMEOUT, 0 ); if( hPipe != INVALID_HANDLE_VALUE ) { if( ConnectNamedPipe( hPipe, 0 ) ? TRUE : ( GetLastError() == ERROR_PIPE_CONNECTED ) ) { if( ReadFile( hPipe, btData, MAX_PIPE_SIZE, &dwBytesRead, 0 ) ) { if( dwBytesRead > 0 ) { // // Do what you want with the data inside of btData here. // } FlushFileBuffers( hPipe ); DisconnectNamedPipe( hPipe ); } } }else{ Sleep( 10 ); } } if( hPipe ) { CloseHandle( hPipe ); hPipe = 0; } return 0;} I cannot gaurantee this is the best method suitable for using pipes, but it is the method I used when myself and another developer wrote the hook we did for work. I suggest you look into MMFs as well. They are very easy to work with, however they do not have a blocked writing/reading system like pipes so you need to create a queue method to handle reading and writing to the MMF. It is really not hard to do. You should setup a structure at the start of the MMF to handle validation and such, something like: struct _MMF_HEADER { DWORD dwCount; // Should be big enough if not use a custom datatype such as unsigned char [size] unsigned char bHandled; // Boolean check to determine if the current data has been read and handled. DWORD dwDataSize; // Size of the data inside the MMF (should include the header as part of its size.) }; This is just an example of something you could do. With this, you can confirm the count by incrementing it by one each time it is handled and comparing it to the last count recorded. Also with this, your hook can create a queue by checking the bHandled byte in the header to ensure that the current data was handled already or not. If not, it can be pushed into a vector or something an stored to be added later. This is the route I took when writing an IPC method that was fast and reliable. I can assure you that the MMF method can handle a lot more data faster then the pipes can if you need to do things at a very high rate. When I wrote my queue handler, I wrote a test application to test the speed and such of the queue system, and it was 1:1 when it came to handling the data. The method we used to test was setting the max MMF size to 10k bytes and writing random data to it every 10 miliseconds. ( Sleep(10) ) The C# program was able to keep up reading from the MMF that the queue never got over 2. The nice part is you can handle losted connections as well. When the C# application disconnected the queue rapidly grew in size as the MMF was not read/handled. But as soon as the C# application reconnected, the queue instantly dropped back to 0/1/2 in size after pushing the queue to the MMF to be handled. If you need any help, I would be glad to help you out. Just ask.