Leaderboard

The software performs network time verification by connecting to the internet. It retrieves the time from www.baidu.com and contains no malicious code. Please rest assured. I have no interest in embedding Trojan viruses or backdoors in the software.

I do not release the decoder but the code optimizer (not immediately), this is not specific to the oream vm, it is only far more effective than others. What do you say about angr or miasm or optimice or codedoctor ?? do we eliminate them all the tools for binary code analysis ?? I do not issue the decoder code because my hobby is a hobby and I do not want to give anybody a damn but reversing is sharing (I unfortunately belong to the old old reverser school). If I spoke good English I would probably share a lot more info and would not like others who just write for self-celebration. Do you know Scherzo or Softworm ?? I'm an old man who now deals with reversing and my only good luck is that the day they will all program in python or javascript I will not be there anymore..hahahahaha

Hi, I'm beginning not to ask for the program because I will not make it public, I do not want to harm anybody. Instead I will release the source code of the deobfuscator as soon as I have time to fix some points. @miraculix The deobfuser completely rebuilds the CFG (remove fake Jcc, Opaque Predicates etc .. etc ..) apply PeepHole (pattern recognition) remove DeadCode and Constant Folding and call analyzer and more. Thanks to the suggestions of @fvrmatteo I could try different peepHole solutions than the pattern recognition but the result was never as efficient as the use of pattern recognition so I use this solution at the moment (I reverse, not a conference at MIT code needs to work well .. hahahaha). I only use Pascal. As a disassembler engine use Capstone and as Emulator (for small portions of code) use Unicorn Engine.Not use Virtual Machines Symbolic Execution Phyton script etc .. etc .. Place a small video to give an idea. deob.rar

First you say Themida is trashtier, then you pick a far inferior packer and state that it is better..? People need to start realizing, that if you have no clue what you're talking about, you should either start your sentence with "I assume" or you shouldn't say anything at all. Silence is bliss. VMProtect is actually rather bad, as the virtual machine in VMProtect is really easy to crack. If you have to choose between Themida and VMProtect, you should always pick Themida. Why? Because Themidas virtual machines are much more advanced and much harder to crack than VMProtect. Themida was initially known for their CISC VM which was (at the time) very strong. It has since been defeated (by Deathway) and is now considered weak (since it's actually rather simple once you start to understand it). VMProtect's virtual machine is almost an exact replica of the Themida CISC VM featuring stronger obfuscation, and as such it works in the exact same way, which makes it (almost) equally weak. Since then, Themida developed the RISC machine (RISC64 and RISC128), which was against defeated by Deathway. They then proceeded to develop the FISH and TIGER machines, which features very new tricks such as complex combined handlers (FISH) doing multiple operations each instead of a handler for each operation like CISC had, and also internal (yet simple) cryptography. The TIGER VM is very similar to the FISH VM (since it is built on the same engine), but doesn't utilize the cryptographic internal registers, etc. Themida also features hybrid virtual machines, such as SHARK, which is FISH virtualized by TIGER, or PUMA, which is TIGER virtualized by FISH. The newest machine(s) from Themida is the DOLPHIN machine, which is yet another layer of complexity upon the newer FISH/TIGER engine, while also supplying a hybrid VM called EAGLE, which is FISH virtualized by DOLPHIN (if memory serves right). If you want to compare the complexity of the newer Themida VMs (e.g. EAGLE) vs. VMProtect's VM, you're probably looking at a complexity scale saying 15:1 or something like that. TL;DR Don't listen to the guys above, as they are completely clueless on the topic. Pick Themida if you have to choose between the two of them.

Haven't touched this project for a long time. So I worked this weekend on updating the script and catching up with all the changes that they did in the last 1-2 years. Everything works right now except for TIGER. They added a new weird "push" handler, which is very different from any other TIGER handler. (the offset for the push isn't from a parameter, but from a call to another function that return an internal state value, usually that internal state value is used with a parameter to get the wanted real value, but this time it is used just with a constant number... in your binary for example one such handler is at 0x0562AC9). Nothing too bad, but I ran out of time for this weekend. I will do it during this week and update this comment with the devirtualized tiger when it is done. Except for that most of the changes were small. Some of them are fixing bugged handlers, other are adding some small protection templates to the handlers. One change that they did was not reseting the state when re-entering the vm after external instruction execution. (instructions that they don't virtualize). Another change was changing the start of the vm. Until now the start of the vm was something like that: (They push all the registers to the stack before they enter the vm) pop VM_REG_1 pop VM_REG_2 pop VM_REG_3 .. They changed it to: (in a random order) mov VM_REG_1, [esp] mov VM_REG_2, [esp+4] mov VM_REG_3, [esp+8] ... add esp, ... Another change is obfuscating the ending of some of the FISH and TIGER handlers. The FISH(32/64) BLACK is probably the most annoying vm. since the handlers are heavily obfuscated, with fake conditional jumps and all of that shit. One big handler can be 100000+ instructions. So even a small bug when handling it can fornication up everything. It is probably the safest vm because of that but also really really slow. oh, and in 64-bit my compiled devirtualized code isn't the same size as the original code, I am not sure why is that, which of the compiled opcodes take more space than the original . But I still had enough space for the devirtualized code in the original address because of the surrounding macros. devirtualizeme_tmd_2.4.6.0_fish32.devirtualize.clean.exe.7z devirtualizeme_tmd_2.4.6.0_fish64.devirtualize.clean.exe.7z

Chances are that first packet, because your on a TCP/IP network is a broadcast for the MAC address if its not already been found and cached? But you should be able to confirm this by pinging the device and sniffing the packets... Ted.

Well, you found the line where it crashes but the problem is much deeper. It's caused by pointers and memory reallocation. Something like this: Line 117: if FileToBytes(szFilePath, bFile) then // allocates a memory for TByteArray Line 134: IID := @bFile[dwIATPos]; // IID is a pointer into current TByteArray Line 145: SetLength(bFile, Length(bFile) + dwSize); // resizes TByteArray, memory is not reallocated yet Line 148: CopyMemory(@bFile[dwPos], @Imports.szLibName[1], Length(Imports.szLibName)); // first write into resized array, Delphi memory manager reallocates memory. IID is a pointer into garbage now. Line 149: IID.Name := OffsetToRVA(dwPos, ISH.VirtualAddress, ISH.PointerToRawData); // crash! Your code is quite a mess, so it's hard to give a suggestion how to fix it properly. I'd try avoid using pointers into bFile at all costs. Cheers, kao.