Leaderboard

Unpackers tools - source code C# My source code: https://gitlab.com/CodeCracker https://github.com/CodeCrackerSND https://bitbucket.org/CodeCrackerSND/ I will NOT share (anymore) the rest of my tools!

Hi everyone, Maybe some of you heard it already, but Sigma and I are working on an x32/x64 debugger for Windows for a few months now... The debugger currently has the following features: variables, currently command-based only basic calculations, can be used in the goto window and in the register edit window. Example: var*@401000+(.45^4A) software breakpoints (INT3, LONG INT3, UD2), currently command-only (just type 'bp addr') hardware breakpoints (access, write, execute), also command-only stepping (over, into, out, n instructions), can be done with buttons/shortcuts memory allocation/deallocation inside the debuggee quickly access API adresses (bp GetProcAddress) syntax highlighting, currently not customizable simple memory map (just addr+size+module+protection basically) The debugger has an easy GUI, for which we looked a lot at Olly Debug engine is TitanEngine, disassembler BeaEngine, icons are from various sources (see About dialog). We use QT for the GUI part. If you have a suggestion, a bug report, need more info, want to contribute, just post here or send me a private message. The latest public build + source can always be found on http://x64dbg.com (click 'Source'->'bin_public') to download the latest build. For now, you can also download the first 'alpha' here We would love to hear from you! Greetings, Mr. eXoDia & Sigma

hi, this mainly is a bug fix release, as I currently don't have enough time pushing stuff... v0.8 -new: 'pack and execute' button in after-patch-created-dialog -fix: exceptions while creating patch into 'visible' folder (desktop or any other folder opended in explorer.exe) -fix: crashes after applying file drop -fix: offset patch dialog file comparison with huge amount of diffs slow/deadlocks -fix: slow comparison of original and patched files in 'offset patch' dialog -fix: packer console output not shown Here we go => uPPP.v0.8.7z ps: keep on posting suggestions and bug reports! greets

Hi! This is my first post on tuts4 you I hope that this is the right section, if not, please delete this post! Ok so... Few months ago I have made public my internal project called REDasm on GitHub. Basically it's a cross platform disassembler with an interactive listing (but it's still far, if compared to IDA's one) and it can be extended with its API in order to support new formats, assemblers and analyzers. Currently it supports: Portable Executable VB5/6 decompilation . It can detect Delphi executables, a decompiler is WIP. .NET support is WIP. Debug symbols are displayed, if available. ELF Executables Debug symbols are displayd, if available. DEX Executables Debug symbols are displayed, if available. x86 and x86_64 is supported. MIPS is supported and partially emulated. ARM support is implemented but still WIP. Dalvik assembler is supported. Most common assemblers are implemented by using Capstone library, Dalvik assembler is written manually and even the upcoming MSIL/CIL assembler will be implemented manually. The entire project is written in C++ and its UI is implemented with Qt5, internally, the disassembler is separated in two parts: LibREDasm and UI. LibREDasm doesn't contains any UI related dependencies, it's just pure C++, one day I will split it in two separate projects. Some links with source code, nightlies and wiki: Source Code: https://github.com/REDasmOrg/REDasm Nightly Builds (for Windows and Linux): https://github.com/REDasmOrg/REDasm-Builds Wiki: https://github.com/REDasmOrg/REDasm/wiki And some screenshots:

awesome_msil_Out.exe Approach: 1. Necrobit is a jit protection, so we use Simple MSIL Decryptor by CodeCracker , and it shall be ran on NetBox 2. Code virtualization is a relatively new feature of .net reactor, added in version 6.2.0.0. Here is the approach i took (i did this about 6 months ago so my memory is kinda rusty ) : (Click spoiler to see hidden contents)

Not going to create a new thread for this, here's present for everyone: Modded de4dot, which supports latest .NET Reactor 4.9.7.0. de4dot-mod-reactor_4.9.zip

Overview:TitanHide is a driver intended to hide debuggers from certain processes.The driver hooks various Nt* kernel functions (using inline hooks at themoment) and modifies the return values of the original functions.To hide a process, you must pass a simple structure with a ProcessID andthe hiding option(s) to enable to the driver. The internal API isdesigned to add hooks with little effort, which means adding featuresis really easy.Features:- ProcessDebugFlags (NtQueryInformationProcess)- ProcessDebugPort (NtQueryInformationProcess)- ProcessDebugObjectHandle (NtQueryInformationProcess)- DebugObject (NtQueryObject)- SystemKernelDebuggerInformation (NtQuerySystemInformation)- NtClose (STATUS_INVALID_HANDLE exception)- ThreadHideFromDebugger (NtSetInformationThread)Test environments:- Windows 7 x64 (SP1)- Windows XP x86 (SP3)- Windows XP x64 (SP1)Installation:1) Copy TitanHide.sys to %systemroot%\system32\drivers2) Start 'loader.exe' (available on the download page)3) Delete the old service (when present)4) Install a new service5) Start driver6) Use 'TitanHideGUI.exe' to set hide optionsNOTE: When on x64, you have to disable PatchGuard and driver signature enforcement yourself. Google is your friend Repository:https://bitbucket.org/mrexodia/titanhide/ Downloads: https://bitbucket.org/mrexodia/titanhide/downloads Feel free to report bugs and/or request features. Greetings, Mr. eXoDia TitanHide_0001.rar loader.rar

The KeygenMe or more appropriately a CrackMe (since it accepts just a single key) is protected with virtualization based obfuscation. This mini writeup describes a way to obtain the correct key without devirtualization. I - First Steps There are two files - main.py & LicenseChecker.py of which the latter is additionally minified. To improve readability we can run the file through a beautifier like black to get the following code. https://gist.github.com/extremecoders-re/35cb06674676afdcf85bd19d0793d6cc II - Overview The list variable C holds the bytecode for the VM. C=[82,26,95,26,95,26,105, .... snip.... ,571,84,572,84,393,129,3,101,84,103,84,573,76,1,134] The dictionary variable W near the end contains the mappings from the instruction opcode to the corresponding handlers. There are 70 handlers which imply there are the same number of instructions. W = { 10: A0, 179: f, 36: AT, 168: g, # ... snip ... 162: A9, 113: A6, 197: c, 215: AI, } The while loop at the end is the VM fetch-decode-execute loop. while B.a < L(C): try: W[C[B.a]]() except Z as X: A = [X] if not G: raise X P, Ag = G.pop() while F: Ah, Ai, Aj = F and F[-1] or (0, 0, 0) if Ah <= P: break F.pop() B.a = P + Ag B.a += 1 There is a similar loop in one of the handlers AW which implies this must be implementing function calls. III - Simplifying the VM The VM supports 70 instructions but not all of them are used. Hence we can remove the unused handlers to simplify the code. This can be done manually in a trial and error way or we can also automate it by logging which handler executes and remove the others. Eventually we are left with 18 handlers which after renaming are as follows. W = { 2: h2, 19: h19, 26: h26, 33: h33, 41: h41, 76: h76, 82: h82, 84: h84, 88: h88, 101: h101, 109: h109, 112: h112, 113: h113, 117: h117, 129: h129, 131: h131, 134: h134, 139: h139, } Full simplified code: https://gist.github.com/extremecoders-re/8962f5faefcd714ce5336461fe670c06 IV - Tracing the VMCALL instruction With 18 handlers left we can now trace the VM. An important thing to note is the obfuscator must have a way to call non-obfuscated external functions such as those from the standard library. If we log the external function it calls, the logic of the crackme would be clear. The instruction with opcode 76 implements the VMCALL instruction. def h76(): vmctx.pc += 1 E = G.copy() D = bc[vmctx.pc] F = A.pop() if D & 1 else () H = A.pop() if D & 2 else {} I = A.pop()(*(F), **H) J = G.copy() E == J and A.append(I) We can introduce a logging statement just before the call as shown. below. def h76(): vmctx.pc += 1 E = G.copy() D = bc[vmctx.pc] F = A.pop() if D & 1 else () H = A.pop() if D & 2 else {} # Logging the external function name and arguments print(A[-1].__name__, F, H) I = A.pop()(*(F), **H) J = G.copy() E == J and A.append(I) V - Retrieving the correct key Running with the serial and the VMCALL logging in place verify("ABCDE-FGHIJ-KLMNO-PQRST-UVWXY") we get a trace, of which the important parts are shown below. getitem (['ABCDE', 'FGHIJ', 'KLMNO', 'PQRST', 'UVWXY'], 0) {} getattr ('ABCDE', 'encode') {} encode () {} getattr (<module 'hashlib' from '/usr/lib/python3.10/hashlib.py'>, 'md5') {} openssl_md5 (b'ABCDE',) {} getattr (<md5 _hashlib.HASH object @ 0x7f335f0850f0>, 'digest') {} digest () {} list ((253, 101, 190, 39, 10, 139, 237, 181, 248, 22, 251, 138, 86, 113, 116, 52),) {} bytes ([253, 101, 190, 39, 10, 139, 237, 181, 248, 22, 251, 138, 86, 113, 116, 52],) {} eq (b'.\xcd\xde9Y\x05\x1d\x91?a\xb1Ey\xea\x13m', b"\xfde\xbe'\n\x8b\xed\xb5\xf8\x16\xfb\x8aVqt4") {} not_ (False,) {} It calculates the md5 of the first word -> openssl_md5("ABCDE") which is then compared to b"\xfde\xbe'\n\x8b\xed\xb5\xf8\x16\xfb\x8aVqt4". This can be converted to hex representation. >>> print(b"\xfde\xbe'\n\x8b\xed\xb5\xf8\x16\xfb\x8aVqt4".hex()) fd65be270a8bedb5f816fb8a56717434 The MD5 hash can be reversed with any online tool such as https://hashes.com/en/decrypt/hash & https://crackstation.net/ The first word is thus CONGR. Re-running with the following key we get another trace. verify("CONGR-FGHIJ-KLMNO-PQRST-UVWXY") getitem (['CONGR', 'FGHIJ', 'KLMNO', 'PQRST', 'UVWXY'], 1) {} getitem ('FGHIJ', 1) {} eq ('G', 'T') {} Here we see it taking the second word in the key viz FGHIJ and comparing the second character in the word G with T. Thus the correct character at that place is T. Since it stops comparing further letters as soon as a mismatch is found we can only recover the key character by character. However there is a quicker way. We can override the result of the comparison to true such that all the checks are revealed at once. This can be done by a slight modification to the logging logic. def h76(): vmctx.pc += 1 E = G.copy() D = bc[vmctx.pc] F = A.pop() if D & 1 else () H = A.pop() if D & 2 else {} # Logging the external function name and arguments if A[-1].__name__ == "eq": print(A[-1].__name__, F, H) I = True else: I = A.pop()(*(F), **H) J = G.copy() E == J and A.append(I) Running once more with the same key as last time we get the full trace as below. eq (29, 29) {} eq (5, 5) {} eq (5, 5) {} eq (5, 5) {} eq (5, 5) {} eq (5, 5) {} eq (5, 5) {} eq (b"\xfde\xbe'\n\x8b\xed\xb5\xf8\x16\xfb\x8aVqt4", b"\xfde\xbe'\n\x8b\xed\xb5\xf8\x16\xfb\x8aVqt4") {} eq ('G', 'T') {} eq ('O', 'S') {} eq ('Q', 'O') {} eq ('J', 'A') {} eq ('H', 'U') {} eq ('R', 'H') {} eq ('K', 'T') {} eq ('S', 'F') {} eq ('F', 'A') {} eq ('L', 'I') {} eq ('T', 'A') {} eq ('M', 'O') {} eq ('I', 'L') {} eq ('N', 'N') {} eq ('P', 'Q') {} eq ('UYXWV', 'BHZQB') {} From the equality checks we can retrieve the 2nd, 3rd and 4th words in the key. The 1st word has already been retrieved before from the MD5 reversing. CONGR-ATULA-TIONS-QOHFA-UVWXY The fifth word is however checked in a different way. The fifth word in the entered key was UVWXY. However it is checking UYXWV with BHZQB. U -> B Y -> H X -> Z W -> Q V -> B UYXWV is a permutation of the original letters UVWXY. Thus we can simply undo the above mapping in the proper order to get the correct word as shown below. U -> B V -> B W -> Q X -> Z Y -> H The correct last word is BBQZH and thus the complete key: CONGR-ATULA-TIONS-QOHFA-BBQZH

A small blog post I wrote. Hope it's interesting! http://x64dbg.com/blog/2017/06/08/kernel-driver-unpacking.html

PEP - Private exe protector is closed commercial project but i decided to share it's source code ( I purchased it about 2300 USD long time ago ) Add star to repo if you like https://github.com/NIKJOO/PEP

Hi, I made a tool that interprets a vmp rsi-stream, it records the handlers (or vm instructions) and connects them via their data dependencies. This is how a JCC looks like The edges in this graph represent data dependencies. Sequences of nodes with one input and one output are collapsed into blocks. Green nodes are constant nodes. They do not depend on external values (such as CPU registers), unlike red nodes. The hex number left of a node is a step number, the right number is its result. Only const nodes (green) can have a result. The graph contains all nodes that directly or indirectly contribute to the lower right "loadcc" instruction. CMP/JCC in VMP works by executing an obfuscated version of the original CMP which also results in either zero or one. VMP then pushes 2 adresses to its stack (step 121f and 1209) and computes an address that points to either one, depending on zero/one result of the corresponding CMP (step 1265). It then simply loads from that computed address and uses its value for a JMP. The load that loads either address is represented by the "loadcc" node in the graph. Even though all puzzle pieces are here, it is still hard to figure out what the original CMP was, but luckily we have LLVM and luckily it isn't hard to lower the graph to LLVM IR: Godbolt Left is the graph as LLVM IR, middle is output of the optimizer, right is the optimized LLVM IR lowered to x64. The attachment contains the original x64 input, the complete vmp program as LLVM (not just the loadcc part), the optimized x64 (-O3) and an unoptimized version (-O0). The unopt version is interesting because it shows how vmp looks like after removing the junk but still leaving the handlers intact (RSI access is removed, RBP-stack is pre-baked to make it easier for the optimizer passes) I thought it was pretty impressive how LLVM's optimizer plows through the crap and produces such a beautiful result. That is all. Thanks for reading. testproc.zip

ILSpy mod by Medsft: NET assembly browser and decompiler, debugger, High and Low level Editor Project renamed. ILSpy NEXT. NET assembly browser and decompiler, debugger, High and Low level Editor Description: ILSpy (latest ILSpy public version 2.2.0.1737) -add debugger from the SharpDeveloper studio -add CopyFullyQualifiedTypeName.Plugin -add OpCodeTableForm -add to treeview contextmenu: - strong name utility - rename class utility - Jump to EntryPoint - string viewer utility (search enable) - extension exeecute utility (reservation work enable) - hexeditor methodbody utility (runtime compilation enable, - search any text in decompileTextView - find method call - Analyze. Reference calls positioning and highlight ("IL Code" view) two technologies save the result(High Level:recompile assembly and Low Level:Binary Patch(See results and work in Patch_table))) add to decompiletextview contextmenu: - replace instruction (High Level,need recompile to save assembly) - nop instruction (High Level,need recompile to save assembly) - reverse branch (High Level,need recompile to save assembly) - nop instruction (Low Level, no need recompile binary patch see Patch Table) - reverse branch (Low Level, no need recompile binary patch see Patch Table) - class or method injector (High level) - "Undo" operation Mono.Cecil -ignore null type (Read TypeDefinition) -ignore invalid parameter(Read MethodDefinition) -ignore invalid generic argument() -ignore invalid attribute (if (attribute.Constructor == null) continue;) -ignore invalid signature(GetSecurityDeclarationSignature) -fix handle null value in obfuscated assembly -add ToString for CustomAttributeArgument -add ToString for CustomAttributeNamedArgument -ignore null element(MemberDefinition) -avoid recursive declaringtype of some obfuscated assemblies,currently only one level checking -add AllMemberReferences(IEnumerable<MemberReference> GetMemberReferences) -add ElementTypeIntValue(ElementTypeIntValue) -add support to read/write directly from bytes(FromBytes) -Read reloc section, Contributed by Khiem Nguyen -add alternative "Save" technology modified assembly (support obfuscated assembly) Pack "ALL in One" The latest releases of ILSpy.NEXT on http://il4re.ml// [t]We are opened! Welcome, guys.[/t] Last build: 12_08_2016 Sorry for my bad English and WPF

Hello, I'm new here I guess. I was originally planning on just posting a keygenme solution, but for some reason I'm not allowed/able to reply to threads in that section. Maybe if I make a few posts elsewhere it will let me post? If so, I guess I'll start by sharing a few of my projects (related to reverse engineering, of course): eazdevirt - a devirtualizer for Eazfuscator.NET. Not guaranteed to work on recent releases unfortunately (at least not yet). pyinst_tools - a toolkit for working with and modifying executables generated with PyInstaller. Pretty much ExtremeCoder's pyinstxtractor with some extra stuff. dnlib-examples - some extra examples for dnlib which I made mostly for my own learning purposes. There are a few others, perhaps I'll update this thread when I make some more progress on them.

Easy method to unpack .NET Reactor last version: Step 1. Check the file. If not native, go to step 3. Step 2. Dump with Megadumper. After dump if file crashes, just add a resource type of RC_DATA named "__" with CFF Explorer Step 3. Check <Module>.cctor. If it not exists go to step 6. Step 4. Dump methods with ManagedJitter Step 5. Go to <Module>.cctor. Double click on method call (there's only one) Point on your mouse cursor on method list to get method token: Convert it to decimal. In this case 06000033 --> 33 in decimal is 51. Open CFF Explorer, go to methods table and find method with your number. In this case, it is 51. Copy RVA address of this method and go to Address Converter. Type in your RVA and click Enter. Edit bytes 1B 30 to 06 2A (return). Save file. Step 6. Clean file with Simple Assembly Explorer Deobfuscator (All Options).

I will be adding more courses https://pan.huang1111.cn/s/v8XwSE Pass:revteam.re

Hello community, I know you all do expect the paper that I announced about Enigma 2.x unpacking but I don't know when or if I will ever finish it. Because I don't want this project I spent so much time on to die, I decided to publish the source code of it now and seperate from the paper so that everyone can prepare it for future Enigma versions. Also LCF-AT found a bug that I couldn't fix so quickly so I hope someone who is more advanced in c++ than me can fix it. See http://forum.tuts4you.com/topic/26896-the-enigma-protector-2xx-unpacking-devirtualizer-by-dizzy-d/page__st__20#entry135147 for details. Just compile the source with MSVC++2010 and everything should work. Enigma DeVirtualizer.rar

Hello, so I keep getting asked what’s the best obfuscators around so I am posting this so I don’t keep repeating it. I have decided to give my opinion on all obfuscators if I am missing any let me know If you are a developer of any of these obfuscators don’t take what I say as an insult use it to improve DNGuard - an obfuscator I used to say was Chinese crap however I’ve recently spent some time analysing this and can say that the HVM technology is very strong and makes unpacking a lot harder. However when not using the HVM setting it makes unpacking extremely simple with jit dumping and can use codecrackers unpacker for this. Compatibility on this obfuscator is its biggest flaw (along with price) which can be a big NO for a lot of people as this protector can cause files to not run on certain .NET frameworks if they fixed this issue and improved compatibility across systems it would make this obfuscator much better. Price is extremely high but I suppose has worked in its favour with not many files around and extremely hard to get test files to test features. Eazfuscator - a .NET VM that has been around for a while now with the last unpacker for version 4.8 I think from saneki on GitHub. Since then Eazfuscator has improved a lot however the concept stays the same and sanekis unpacker is still a brilliant base to start from. Meaning that an unpacker for this isn’t extremely difficult. The compatibility and performance of this obfuscator is actually fairly good for a VM and tells the user not to overuse the VM and only apply on secret methods as to save performance. The problem with Eazfuscator is that any protection method apart from the VM isn’t good, de4dot handles the control flow perfectly and the strings can be easily decrypted by either updating de4dot code which isn’t too hard or simply invoke. So if you’re app is sensitive on performance then maybe avoid this one as for all VMs performance is hurt no matter how efficient it is. In conclusion I do think this obfuscator is one of the top of its game as even with the old unpackers it’s still a lot of work to update ILProtector - An obfuscator I really do like the concept of keeping performance and security balanced, however in recent times with the release of dynamic unpackers it has kind of died as it seems the developer is applying small patches instead of fixing this properly so each unpacker only requires a few changes. In terms of static unpacking they have this down well, it’s actually a very hard job to statically unpack this protector so if they were to patch the dynamic flaws it would quickly appear back at the top but it’s credibility has been stumped due to the release of unpackers that I think may still work on the latest version (something I haven’t checked). Compatibility and performance on this obfuscator are good but one flaw of this obfuscator is that if the dynamic method is decrypted the original ilcode is there, they apply no MSIL mangling which in my eyes they should do both. Agile.Net another .NET VM however I haven’t analysed this myself that much but a few things I have noticed is that updating de4dot to support the latest version is not all that challenging however it is time consuming, a few modifications to de4dot can make it supply all the data you need to update it for the VM. the method encryption can be removed by jit dumpers from codecracker, from what I’ve seen in de4dot the obfuscator isn’t to hard to completely unpack but we have to thank 0xd4d for all he has done on this obfuscator he has done all the hard work for us so it’s just a matter of taking his code and updating, yes this takes a very long time to do Netguard - Now this is one I’m very familiar with, as most people know netguard is a modified confuserex however a fairly heavy modification. Now the actual protection isn’t that strong however for its price it’s very good, the base of netguard is still the same concept as confuserex and many of its protections can be defeated in the exact same way, the only real changes are the native stub and mutations. However once you remove these protections like control flow and constants can be removed in the same theory as I use in my confuserex unpacker2. This obfuscator like I said is the best for its price however if you’re looking for something better there are other options if you’re willing to pay, now compatibility and performance on netguard are something that it’s known for and not in a good way, it has improved a lot recently however they still add lots of junk that adds no real benefit and just slows down code. Appfuscator - now I don’t know why people don’t use this obfuscator anymore. In my eyes it’s still extremely powerful, codecrackers tools are not stable and if you’re tool is larger than a crackme then it will fail, appfuscator uses opaque predicates and CFG to generate its control flow both of which have no public solvers for so is an extremely powerful obfuscator especially if you mix it with something custom. Performance wise this is actually negligible effect so still to this day one of the higher rated obfuscators. Babel.Net - this is similar to ilprotector in the way it makes dynamic methods however in a different approach. The good thing about this obfuscator is that it provides you with more options than just encrypt msil where you have cflow constants and other expected protections making it not as simply as dumping the dynamic method. The dynamic methods itself are not tricky to solve dynamically similar to ilprotector, invoke the correct method and you have the dynamic method ready to read with dnlib. Statically it gets slightly more complex however a few hours debugging with dnspy and some static analysis will reveal its secrets of how it decrypts the encrypted bodies. Performance and compatibility wise I don’t really know enough about it but I’ve not really seen many complaints about it ArmDot - a relatively new .NET VM which I’m fairly interested in. At its current stage it needs polishing, they currently put the whole vm into each method it’s encrypted making it extremely slow. I explained to the developer that it holds no real benefit as to devirtualize it follows the same concept as all vms which is find the instruction handlers and convert back as most are 1:1 with CIL it makes this step relatively easy once you have detected all handlers however if this obfuscator works on your file and performs well I do recommend it especially as its new and being actively worked on and the developer is always interested in seeing ways to improve which is a good thing. KoiVM - another magical creation from yck so do we expect anything other than greatness. Now this was something he sold to customers until he left the scene and trusted XenoCodeRCE with and gave it him to improve and use. Xeno decided that he would sell this to others and ended up causing it to be leaked on GitHub however let’s ignore that. KoiVM is absolutely insane and different to all other VMS we talked about so far. This doesn’t relate 1:1 with CIL and actually converts it to a form of ASM meaning if you manage to get all the code back you then need to translate ASM to CIL which again is no easy task. People think because it’s opensource it makes it not worth it. Remember confuser/ex was open source and undefeated for a long time. KoiVM is on another level compared to those. Compatibility and performance does take a hit and has limitations which you can read on koivm website now if you’re app works fine and you’re happy with performance then I would strongly suggest sticking with it. You can even make modifications to confuserex and use it with that as after all it’s a confuserex plugin. These are just my thoughts and personal opinions on these obfuscators. I do not mean any disrespect to the developers apart from what I think is good and bad. If you would like further explanation on anything let me know or any specific obfuscator that I haven’t covered as I most likely have some sort of opinion on it feel free to ask Regards Cawk

Answer The password is "gamer vision". All of the following addresses are based on the modulebase 0x00007FF644840000. The possible OEP at: 00007FF644841DF8 | 48:895C24 20 | mov qword ptr [rsp+20],rbx 00007FF644841DFD | 55 | push rbp 00007FF644841DFE | 48:8BEC | mov rbp,rsp 00007FF644841E01 | 48:83EC 20 | sub rsp,20 ... Then the second hit in code section at: 00007FF6448416FC | 48:895C24 08 | mov qword ptr [rsp+8],rbx 00007FF644841701 | 48:897424 10 | mov qword ptr [rsp+10],rsi 00007FF644841706 | 57 | push rdi 00007FF644841707 | 48:83EC 30 | sub rsp,30 ... After prompted "enter password.", the input routine at: 00007FF644841400 | 48:8BC4 | mov rax,rsp 00007FF644841403 | 57 | push rdi 00007FF644841404 | 41:54 | push r12 00007FF644841406 | 41:55 | push r13 00007FF644841408 | 41:56 | push r14 00007FF64484140A | 41:57 | push r15 00007FF64484140C | 48:83EC 50 | sub rsp,50 ... the pointer of local buffer for receiving input text is in rdx(for example, 000000359CC9FA58). When entered some test characters, stack looks like: 000000359CC9FA58: 31 32 33 34 35 36 37 38 39 30 31 32 00 7F 00 00 "123456789012" 000000359CC9FA68: 000000000000000C input size 000000359CC9FA70: 000000000000000F buffer size Whereafter, the process logic virtualized. First of all, the length of input text got checked in a vCmpqr handler: 00007FF644898E0B | 49:39F0 | cmp r8,rsi ; r8=000000000000000C(actual), rsi=000000000000000C(const) The length MUST be 12!, else got "no!". NOTE: the encrypt password has no chance to get decrypted if input length is wrong! The answer String is encrypted(0xC length): 00007FF64484BCB0 8B 75 81 89 86 34 9A 8D 87 8D 83 82 00 00 00 00 decrypt algo: 00007FF6448BF3A6 | 40:8A36 | mov sil,byte ptr [rsi] rsi=00007FF64484BCB0, sil=8B 00007FF6448D4125 | 44:30DB | xor bl,r11b bl=8B, r11b=08; ^=08 = 83 00007FF64488E987 | 880A | mov byte ptr [rdx],cl [00007FF64484BCB0] <- 83 00007FF64485748F | 8A09 | mov cl,byte ptr [rcx] [00007FF64484BCB0] -> 83 00007FF64485E6FA | 44:00D7 | add dil,r10b dil=83, r10b=E4; +=E4 = 67 'g' 00007FF64488E987 | 880A | mov byte ptr [rdx],cl [00007FF64484BCB0] <- 67 00007FF64488DA96 | 49:FFC4 | inc r12 ptr++ 00007FF644859691 | 41:FFC9 | dec r9d length-- 00007FF64488743C | 85C8 | test eax,ecx end loop if length zero At the end of loop, the plaintext: 00007FF64484BCB0 67 61 6D 65 72 20 76 69 73 69 6F 6E 00 00 00 00 gamer vision.... The comparison: 00007FF6448424E7 | FF25 330C0000 | jmp qword ptr [<&memcmp>] ret rax=00000000FFFFFFFF/0000000000000000(if matches) rcx=000000359CC9FA58 "123456789012" rdx=00007FF64484BCB0 "gamer vision" r8=000000000000000C Strings Encrypted Structure BYTE bEncrypt // 1 - encrypt, 0 - decrypt DWORD dwLength BYTE UnDefined[0xC] BYTE CipherText[dwLength+1] The related messages as followings, you can find them in the VM Section ".themida" after it got unpacked at the very beginning of the application. 00007FF6448AC79F 01 10 00 00 00 01 00 00 00 80 21 00 40 01 00 00 decrypt algo: ^A0+4F 00007FF6448AC7AF 00 B6 BF 85 B6 83 71 81 B2 84 84 88 80 83 B5 7F "enter password.\n" 00007FF6448AC7BF 1B 00 00007FF64484BC9F 01 0C 00 00 00 72 64 2E 0A 00 00 00 00 00 00 00 decrypt algo: ^08+E4 00007FF64484BCAF 00 8B 75 81 89 86 34 9A 8D 87 8D 83 82 00 "gamer vision" 00007FF644886C7F 01 05 00 00 00 72 20 76 69 73 69 6F 6E 00 00 00 decrypt algo: ^85+10 00007FF644886C8F 00 EC D0 E6 94 7F 00 "yes!\n" 00007FF64489252F 01 04 00 00 00 00 00 00 00 79 65 73 21 0A 00 00 decrypt algo: ^65+C9 00007FF64489253F 00 C0 C3 3D 24 00 "no!\n" 00007FF64484C40F 01 19 00 00 00 0A 00 00 00 6E 6F 21 0A 00 00 00 decrypt algo: ^12+C6 00007FF64484C41F 00 B8 BE 8D BF BF 48 8D BA BC 8D BE 48 BC BB 48 "press enter to continue.\n" 00007FF64484C42F 8F BB BA BC B1 BA BD 8D 7A 56 00

Not much to say. Questions are welcome. Requests will be ignored. The software created to solve this challenge won't be released. I am posting the final file, but it's actually correct to say that @fvrmatteo did the bulk of the work and I helped with the smaller bits. Oh, and by suggesting some music to listen to while working Time taken: circa 7 days. We still don't handle the code flow, but I guess the file speaks for itself as far as "seeing some results" goes as of now. devirtualizeme64_vmp_3.0.9.DeVed.7z

Something interesting is going on with this exe, seems to be a bug in themida. But before I will talk about that, I will talk about the new dolphin vm. After this post I finally finished adding support for this vm. So dolphin is basically (not surprisingly) more of the same, with a little new concept that is different from fish and tiger (splitting basic operations handlers to more handlers) Eagle is just fish virtualized by dolphin (in the same way that puma is tiger virtualized by fish, and shark is fish virtualized by tiger). Now about the wierd bug. In nested vms, usually all the handlers are virtualized by the same vm engine. But this time things were different. Eagle used two engines vritualize the fish handlers - one of them is dolphin that was generated for that, and the other one was the regular dolphin that was generated for the dolphin only (with the corresponding color) Puma used three engines - the fish engine generated for puma, the regular fish handler, and a fish engine virtualized by dolphin (= eagle, it used the same eagle engine instance). So puma in your exe was tiger virtualized by fish/eagle. Shark was even weirder. Shark should be fish virtualized by tiger engine, but again, in addition to the tiger engine, it used the puma engine too (tiger virtualized by fish) And it was the same broken puma engine! Which mean that some of the handlers were fish virtualized by tiger virtualized by fish virtualized by dolphin! This is why the eagle vms in your exe are fast (as expected from about ~20 virtualized opcodes), but puma is slower (3 levels of vms instead 2), and shark is extremely slow - about few minutes for shark black (~20 opcodes virtualized by 4 levels of vms!) I don't know why it happened. Themida generated the right amount of engine, but it seems that it got confused when choosing the engines for the nested vms. Anyway, the fixed exe is attached with all the unneeded sections removed (took my script half an hour to devirtualize all those 18 engines ><) (EDIT: After running it with pypy instead python it took less than 8 minutes)unpackme.unpacked.fixed.exe.zip

Many years ago I wrote a software protector called MyAppSecured. Somewhere in the middle of porting it from Delphi to C++ I lost my interest in this project. Just found it on my HDD so I thought it might be helpful for someone. In short, the GUI of this protector is written in C++ and the protection stub in written in MASM. The C++ code loads a target in memory and adds 2 PE sections to it. One for the TLS callback code and one for the main code. The MASM stub will be written to those 2 sections. This protector has just 2 protection features: Analyze Immunity (anti-debug) and Memory Shield (anti debug-tools, OEP relocation). Note this is not a download-and-use-right-away protector. The code is written years ago so it's not very well written and also for some unknown reason the MASM stub could not be written into the 2 created sections. It did work very well years ago but I don't have the time to investigate why it doesn't work now. To be clear, the compiled exe file you will find in the package should run nicely but once you try to secure a exe file, that exe file is gonna be corrupted. This project is free for personal and commercial purposes. If you have any questions please ask, but keep in mind I abandoned this project and removed it from my HDD right after posting it here. Even if you are not gonna use this project it might be interesting to check the code. Some interesting stuff you might find there for your own project, such as emulating the CreateThreadW function in pure MASM, adding PE sections & relocation of OEP. MyAppSecured v1.00 Beta source.zip

And here's my promised solution. As you'll notice, it's a totally different approach than that of ExtremeCoders.. It will be published on my blog (https://lifeinhex.com/solving-0x777hs-crackme/) once I take care of all formatting issues. ---- The crackme is an x64 binary that uses a custom protector. Password checking code is protected using a code virtualization feature. In the tutorial I'll show how the protection works and steps I took to defeat it. This is not a full and comprehensive analysis of the protector code or the code virtualization feature. When solving crackmes, I prefer to choose the simplest solution that gets the job done. This is also reason why I did not use ready-made tools like VMAttack (https://github.com/anatolikalysch/VMAttack), Detours, FRIDA and the like... Quickly about code virtualization. Code virtualizers are generally considered one of the hardest software protection methods to defeat. Why is that? Let's see what features a common code virtualization solution offers: Packer. Original program code is packed/encrypted and decoded on runtime. Anti-debug protection. Most protectors use some sort of anti-debugging protection in their code. Code obfuscation. Most protectors add junk code, some use control-flow flattening, constant obfuscation and other techniques. And finally, the actual virtual machine with custom instruction set. If you have just a single feature, like junk code, it's actually quite easy to reverse. The difficulty comes from the combination of all protector features and also how well they are combined. There are several ways to defeat code virtualization: completely devirtualize the code. This is the ultimate success, you have recovered the original x86/x64 code, or a close approximation of it; make a disassembler for the particular VM, disassemble PCode and understand how the algorithm works; trace the VM execution, and use trace data to understand how the algorithm works; patch VM handlers and/or PCode; If you want to learn more about code virtualization in general, I can wholeheartedly recommend Tim Blazytko's blog (https://synthesis.to/2021/10/21/vm_based_obfuscation.html), as well as his Software Deobfuscation training. They are awesome! With that in mind, let's look at our crackme and see what protections it contains. Crackme overview. Encrypted code. If you open crackme.exe in your favorite hex editor, you'll notice that .code section appears to be encrypted. OK, maybe you will not notice that. Just check the entropy of each PE section with a tool like DiE: So, our first step would be to unpack the file. Anti-debug protection. When you try to run the file under x64dbg, you'll notice that it throws some breakpoint exception and terminates: I spent some time trying different ScyllaHide options but without any success. Debugging the startup code allowed me to note some of the features: It uses a lot of Nt* functions; It manually maps ntdll.dll in memory and (probably) extracts syscall ids; The rest of the protection uses syscalls directly; And the protection code is mostly virtualized! At this point I decided to try something else. Let's run the crackme without the debugger, dump process memory and try to attack it using static analysis! Note: if Scylla fails to dump the process, use Process Hacker -> Select crackme.exe process -> Properties -> Memory -> select crackme.exe sections -> Save... and then rebuild PE header. Junk code. Dumped file is surprisingly readable in IDA. We can soon find a suspicious part in .code section: Following the jump, we see a combination of push constant+call followed by data which is very typical for a VM startup: Following that, we see some code that looks like an obfuscated spaghetti code: So, it looks like we have located our VM but the code is obfuscated. We'll need to take care of that first. Deobfuscating junk code. After spending some time cleaning the junk code, you'll notice it uses several specific patterns for obfuscation. jmp+junk The simplest of patterns - it's a short jump and few junk bytes. We can use hex editor and simple regex to replace this with 5 nops. clc+jnb and stc+jb First, a carry flag is set to a know value using clc or stc instruction. Then a conditional jump is used to confuse IDA's analysis. Jump distance is usually very short - 2,3 or 4 bytes. Just like before, we can use regex to replace replace clc+jump+junk code with nops. Big obfuscated do-nothing Once the simple jumps are replaced, you'll notice a much larger obfuscation pattern: The pattern begins with pushfq, followed by call and 2 jumps and ends with the popfq. This example uses RAX, but it can be also RDX or some other register. It's easy to find the end of the pattern just by looking for next popfq instruction. Even larger do-nothing And finally, there's a more complicated pattern. It's so large that I had to use graphic editor to stitch it all together for you. Notice that all nops, jumps and junk code are removed from the image! As with the previous pattern, it's easy to find the end of it, just look for combination of pop rcx, pop eax and popfq. And we're done with code obfuscation! We've identified obfuscation patterns and found a way to deal with them. Analyzing VM dispatcher Now we're able to see what is happening on VM startup. First flags and registers are saved: .code:00007FF70A36CF38 pushfq .code:00007FF70A36CF66 push r15 .code:00007FF70A36D00C push r14 .code:00007FF70A36D0BD push r13 .code:00007FF70A36D15C push r12 ... more pushes ... Then the VM state is prepared and VM dispatcher is reached: .code:00007FF70A36E6B0 xor rdx, rdx .code:00007FF70A36E6E0 mov dl, [rsi] ; fetch next opcode And finally next handler is executed: .code:00007FF70A36E068 mov rax, rsp .code:00007FF70A36E11C add rax, 0F8h .code:00007FF70A36E13C mov rax, [rax] ; table of handler addresses .code:00007FF70A36E13F xor rbx, rbx ; .code:00007FF70A36E169 mov ebx, [rax+rdx*4] ; RDX contains the next opcode .code:00007FF70A36E199 sub rax, rbx .code:00007FF70A36E1C3 jmp rax ; ---> next handler is executed Writing VM tracer For last few years I've written most of my tools in C#. Now I need to hook x64 code and C# is not really suitable for that. So, I dusted off my trusted old copy of Delphi XE2. Also I needed some injector that would inject my DLL into running crackme.exe process. I randomly chose one the first results from Google search: https://github.com/danielkrupinski/Inflame I chose to hook VM dispatcher between "add rax, 0F8h" and "mov eax,[eax]" instructions. Since I didn't have any decent x64 hooking library for Delphi XE2, I made my own "hooking" code. It's ugly and you definitely shouldn't do that in production code. But for the crackme it's fine! hookAddress := imageBase + $2E123; returnAddress := imageBase + $2E13B; d := PDword(hookAddress)^; if (d = $000004E8) then begin // check whether the hooked address contains correct bytes Writeln(Format('Hooking address %x',[hookAddress])); VirtualProtect(pointer(hookAddress), $100, PAGE_EXECUTE_READWRITE, @oldProtection); PWord(hookAddress)^ := $BB48; // mov rbx, const PUInt64(hookAddress + 2)^ := UInt64(@MyHook); PWord(hookAddress + $A)^ := $E3FF; //jmp rbx VirtualProtect(pointer(hookAddress), $100, oldProtection, @oldProtection); end; And this is the code responsible for logging VM context. Nothing fancy, just get values from memory and log them to console. opcode := (savedRDX and $FF); actualRSP := savedRAX - $F8; rax := PUInt64(actualRSP+$70)^; rbx := PUInt64(actualRSP+$78)^; rcx := PUInt64(actualRSP+$80)^; rdx := PUInt64(actualRSP+$88)^; rsi := PUInt64(actualRSP+$90)^; rdi := PUInt64(actualRSP+$98)^; rxx := PUInt64(actualRSP+$A0)^; ryy := PUInt64(actualRSP+$A8)^; r8 := PUInt64(actualRSP+$B0)^; r9 := PUInt64(actualRSP+$B8)^; r10 := PUInt64(actualRSP+$C0)^; r11 := PUInt64(actualRSP+$C8)^; r12 := PUInt64(actualRSP+$D0)^; r13 := PUInt64(actualRSP+$D8)^; r14 := PUInt64(actualRSP+$E0)^; r15 := PUInt64(actualRSP+$E8)^; eflags := PUInt64(actualRSP+$F0)^; Writeln(Format('PC=%.08x/%.08x opcode=%.02x RAX=%.08x RBX=%.08x RCX=%.08x RDX=%.08x RSI=%.08x RDI=%.08x RXX=%.08x RYY=%.08x R8=%.08x R9=%.08x R10=%.08x R11=%.08x R12=%.08x R13=%.08x R14=%.08x R15=%.08x EFL=%.02x',[savedRSI, savedRSI - UInt64(CrackmeImageBase), opcode, rax, rbx, rcx, rdx, rsi, rdi, rxx, ryy, r8,r9,r10,r11,r12,r13,r14,r15,eflags])); Analyzing tracer output Now, let's run the crackme, inject tracing dll and enter some random serial. We'll get output similar to this: PC=7FF66C736ECC/00046ECC opcode=0C RAX=59652FF960 RBX=20CE5537D10 RCX=FFFFFFFF RDX=7FF66C70F040 RSI=00000000 RDI=59652FF9C4 RXX=59652FF8E0 RYY=00000000 R8=7FF66C710520 R9=7FF66C6F0000 R10=00000050 R11=7FF66C710520 R12=00000000 R13=00000000 R14=00000000 R15=00000000 EFL=202 PC=7FF66C736ED0/00046ED0 opcode=0C RAX=59652FF960 RBX=20CE5537D10 RCX=FFFFFFFF RDX=7FF66C70F040 RSI=00000000 RDI=59652FF9C4 RXX=59652FF8E0 RYY=00000000 R8=7FF66C710520 R9=7FF66C6F0000 R10=00000050 R11=7FF66C710520 R12=00000000 R13=00000000 R14=00000000 R15=00000000 EFL=202 PC=7FF66C736EDB/00046EDB opcode=0A RAX=59652FF960 RBX=20CE5537D10 RCX=FFFFFFFF RDX=7FF66C70F040 RSI=00000000 RDI=59652FF9C4 RXX=59652FF8E0 RYY=00000000 R8=7FF66C710520 R9=7FF66C6F0000 R10=00000050 R11=7FF66C710520 R12=00000000 R13=00000000 R14=00000000 R15=00000000 EFL=202 PC=7FF66C736EDF/00046EDF opcode=0C RAX=59652FF960 RBX=20CE5537D10 RCX=FFFFFFFF RDX=7FF66C70F040 RSI=00000000 RDI=59652FF9C4 RXX=59652FF8E0 RYY=00000000 R8=7FF66C710520 R9=7FF66C6F0000 R10=00000050 R11=7FF66C710520 R12=00000000 R13=00000000 R14=00000000 R15=00000000 EFL=206 .... PC=7FF66C736F9C/00046F9C opcode=0C RAX=59652FF960 RBX=20CE5537D10 RCX=00000000 RDX=7FF66C70F040 RSI=00000000 RDI=59652FF9C4 RXX=59652FF8E0 RYY=00000000 R8=7FF66C710520 R9=7FF66C6F0000 R10=00000050 R11=7FF66C710520 R12=00000000 R13=00000000 R14=00000000 R15=00000000 EFL=202 PC=7FF66C736FA0/00046FA0 opcode=13 RAX=59652FF960 RBX=20CE5537D10 RCX=00000000 RDX=7FF66C70F040 RSI=00000000 RDI=59652FF9C4 RXX=59652FF8E0 RYY=00000000 R8=7FF66C710520 R9=7FF66C6F0000 R10=00000050 R11=7FF66C710520 R12=00000000 R13=00000000 R14=00000000 R15=00000000 EFL=202 PC=7FF66C736F20/00046F20 opcode=0C RAX=59652FF960 RBX=20CE5537D10 RCX=00000000 RDX=7FF66C70F040 RSI=00000000 RDI=59652FF9C4 RXX=59652FF8E0 RYY=00000000 R8=7FF66C710520 R9=7FF66C6F0000 R10=00000050 R11=7FF66C710520 R12=00000000 R13=00000000 R14=00000000 R15=00000000 EFL=202 PC=7FF66C736F2B/00046F2B opcode=08 RAX=59652FF960 RBX=20CE5537D10 RCX=00000000 RDX=7FF66C70F040 RSI=00000000 RDI=59652FF9C4 RXX=59652FF8E0 RYY=00000000 R8=7FF66C710520 R9=7FF66C6F0000 R10=00000050 R11=7FF66C710520 R12=00000000 R13=00000000 R14=00000000 R15=00000000 EFL=202 So far it doesn't look like much, does it? But by examining the instruction pointer PC values, we can see that opcode 0x13 can change PC significantly. So opcode 0x13 is probably a (conditional) jump instruction. Let's modify our code and log only jumps. Log file is much shorter, and the final few lines are the most interesting. PC=7FF66C737713/00047713 opcode=13 RAX=00000000 RBX=2AEC5977B90 RCX=00000008 RDX=7FF66C70F040 RSI=00000000 RDI=BB03B3F734 RXX=BB03B3F650 RYY=00000000 R8=7FF66C710520 R9=7FF66C6F0000 R10=00000054 R11=7FF66C710520 R12=00000000 R13=00000000 R14=00000000 R15=00000000 EFL=283 PC=7FF66C7377E4/000477E4 opcode=13 RAX=00000031 RBX=2AEC5977B90 RCX=00000043 RDX=000000F0 RSI=00000000 RDI=BB03B3F734 RXX=BB03B3F650 RYY=00000000 R8=7FF66C710520 R9=7FF66C6F0000 R10=00000054 R11=7FF66C710520 R12=00000000 R13=00000000 R14=00000000 R15=00000000 EFL=297 PC=7FF66C7377F2/000477F2 opcode=13 RAX=00000031 RBX=2AEC5977B90 RCX=00000043 RDX=000000F0 RSI=00000000 RDI=BB03B3F734 RXX=BB03B3F650 RYY=00000000 R8=7FF66C710520 R9=7FF66C6F0000 R10=00000054 R11=7FF66C710520 R12=00000000 R13=00000000 R14=00000000 R15=00000000 EFL=297 PC=7FF66C737844/00047844 opcode=13 RAX=00000000 RBX=2AEC5977B90 RCX=00000043 RDX=000000F0 RSI=00000000 RDI=BB03B3F734 RXX=BB03B3F650 RYY=00000000 R8=7FF66C710520 R9=7FF66C6F0000 R10=00000054 R11=7FF66C710520 R12=00000000 R13=00000000 R14=00000000 R15=00000000 EFL=283 Specifically, on 2nd line we can see RAX=31. That's ASCII code of "1", the first character of fake serial that I entered. In RCX we see value 0x43. Could it be the correct first character of serial and this is "goodboy/badboy" jump? Patching VM context and obtaining the correct serial Let's modify our logger one more time - on our suspected goodboy jump it will set VM flags to a default value, so that the jump is always taken. if savedRSI - UInt64(CrackmeImageBase) = $477E4 then begin PUInt64(actualRSP+$F0)^ := $246; end; We run crackme again, enter a fake serial, and get a good boy message! PC=7FF66C7377E4/000477E4 opcode=13 RAX=00000031 RBX=20BB70A78C0 RCX=00000043 PC=7FF66C7377E4/000477E4 opcode=13 RAX=00000032 RBX=20BB70A78C0 RCX=00000038 PC=7FF66C7377E4/000477E4 opcode=13 RAX=00000033 RBX=20BB70A78C0 RCX=00000036 PC=7FF66C7377E4/000477E4 opcode=13 RAX=00000034 RBX=20BB70A78C0 RCX=00000043 PC=7FF66C7377E4/000477E4 opcode=13 RAX=00000035 RBX=20BB70A78C0 RCX=00000030 PC=7FF66C7377E4/000477E4 opcode=13 RAX=00000036 RBX=20BB70A78C0 RCX=00000030 PC=7FF66C7377E4/000477E4 opcode=13 RAX=00000037 RBX=20BB70A78C0 RCX=00000043 PC=7FF66C7377E4/000477E4 opcode=13 RAX=00000038 RBX=20BB70A78C0 RCX=00000032 PC=7FF66C7377E4/000477E4 opcode=13 RAX=00000000 RBX=20BB70A78C0 RCX=00000031 PC=7FF66C7377E4/000477E4 opcode=13 RAX=00000000 RBX=20BB70A78C0 RCX=00000036 PC=7FF66C7377E4/000477E4 opcode=13 RAX=00000000 RBX=20BB70A78C0 RCX=00000031 PC=7FF66C7377E4/000477E4 opcode=13 RAX=00000000 RBX=20BB70A78C0 RCX=00000038 PC=7FF66C7377E4/000477E4 opcode=13 RAX=00000000 RBX=20BB70A78C0 RCX=00000034 PC=7FF66C7377E4/000477E4 opcode=13 RAX=00000000 RBX=20BB70A78C0 RCX=00000037 PC=7FF66C7377E4/000477E4 opcode=13 RAX=00000000 RBX=20BB70A78C0 RCX=00000030 PC=7FF66C7377E4/000477E4 opcode=13 RAX=00000000 RBX=20BB70A78C0 RCX=00000042 PC=7FF66C7377E4/000477E4 opcode=13 RAX=00000000 RBX=20BB70A78C0 RCX=00000039 PC=7FF66C7377E4/000477E4 opcode=13 RAX=00000000 RBX=20BB70A78C0 RCX=00000043 PC=7FF66C7377E4/000477E4 opcode=13 RAX=00000000 RBX=20BB70A78C0 RCX=00000036 PC=7FF66C7377E4/000477E4 opcode=13 RAX=00000000 RBX=20BB70A78C0 RCX=00000045 PC=7FF66C7377E4/000477E4 opcode=13 RAX=00000000 RBX=20BB70A78C0 RCX=00000042 PC=7FF66C7377E4/000477E4 opcode=13 RAX=00000000 RBX=20BB70A78C0 RCX=00000035 PC=7FF66C7377E4/000477E4 opcode=13 RAX=00000000 RBX=20BB70A78C0 RCX=00000045 PC=7FF66C7377E4/000477E4 opcode=13 RAX=00000000 RBX=20BB70A78C0 RCX=00000033 PC=7FF66C7377E4/000477E4 opcode=13 RAX=00000000 RBX=20BB70A78C0 RCX=00000043 PC=7FF66C7377E4/000477E4 opcode=13 RAX=00000000 RBX=20BB70A78C0 RCX=00000041 PC=7FF66C7377E4/000477E4 opcode=13 RAX=00000000 RBX=20BB70A78C0 RCX=00000032 PC=7FF66C7377E4/000477E4 opcode=13 RAX=00000000 RBX=20BB70A78C0 RCX=00000041 PC=7FF66C7377E4/000477E4 opcode=13 RAX=00000000 RBX=20BB70A78C0 RCX=00000036 PC=7FF66C7377E4/000477E4 opcode=13 RAX=00000000 RBX=20BB70A78C0 RCX=00000044 PC=7FF66C7377E4/000477E4 opcode=13 RAX=00000000 RBX=20BB70A78C0 RCX=00000035 PC=7FF66C7377E4/000477E4 opcode=13 RAX=00000000 RBX=20BB70A78C0 RCX=00000031 Now we can take all logged values from RCX and obtain a correct serial: TL;DR version This is how the crackme was defeated: Dumped process memory and use it for static analysis in IDA; Avoids all anti-debug tricks; Used simple regex replaces to defeat "junk code"; We'll probably break some things but it doesn't matter, as we won't run the broken code; Analyzed VM startup and VM dispatcher; Used DLL injection to get my code running in the crackme process; My code hooks VM dispatcher and dumps VM state before each instruction; Analysis of executed operations allows us to locate goodboy/badboy jump; My hook code patches flags to always take goodboy jump; We can see correct password in VM registers; Attached is a Delphi source code for my VM logger. vm_logger.zip

@ramjane I'm sharing my private script to reach OEP on all 5.xx (and maybe 4.xx). First it tries to find static OEP address in Enigma VM section. If failed, it tries to dynamically reach OEP. lc log "Enigma 5.xx OEP Finder by PC-RET v 1.1 started" bc dbh bphwc gmi eip, MODULEBASE MOV IMAGEBASE, $RESULT //gmi eip, CODEBASE //MOV CODEBASE, $RESULT //gmi eip, CODESIZE //MOV CODESIZE, $RESULT pusha mov eax, IMAGEBASE mov edi, eax add eax, 3C mov eax, edi+[eax] mov SECTIONS, [eax+06], 02 mov esi, eax+0F8 mov edi, 28 mov ebp, SECTIONS mov ecx, edi mul edi, 1 // second section add edi, esi sub edi, 28 mov CODEBASE, [edi+0C] add CODEBASE, IMAGEBASE mov CODESIZE, [edi+08] popa GPA "VirtualAlloc", "kernel32.dll" mov VirtualAlloc, $RESULT GPA "VirtualProtect", "kernel32.dll" mov VirtualProtect, $RESULT GPA "VirtualQuery", "kernel32.dll" mov VirtualQuery, $RESULT bphws VirtualAlloc run rtr esti bphwc VirtualAlloc gmemi eip, MEMORYBASE mov ENIGMA_SECTION, $RESULT mov startsearch, ENIGMA_SECTION find startsearch, #8945F8EB0C8BCF8BD68B45FCE8????????F6C304740B8B55F88B45FC# // structure cmp $RESULT, 0 je dynamic_find static_find: bp $RESULT esto gmemi esi, MEMORYBASE mov startsearch, $RESULT gmemi esi, MEMORYSIZE mov searchend, $RESULT add searchend, startsearch alloc 100 mov eval_section, $RESULT mov [eval_section], #609CB8AAAAAAAABBBBBBBBBBB9CCCCCCCCBADDDDDDDD3BC20F831F0000003918740D813800004000740583C004EBE73948100F840800000083C004EBD99D61908B70F803F39D6190# mov [eval_section+3], startsearch mov [eval_section+8], IMAGEBASE mov [eval_section+D], CODESIZE mov [eval_section+12], searchend bp eval_section+3f bp eval_section+45 bp eval_section+47 mov bakeip, eip mov eip, eval_section esto cmp eip, eval_section+3f je notfound_static cmp eip, eval_section+45 je found_static jmp error found_static: ///////////////////////You can stop here and see OEP in ESI register/////////////////////// mov oep, esi esto mov eip, bakeip bc free eval_section gmemi oep, MEMORYBASE cmp $RESULT, 0 jne not_invalid_oep eval "Invalid OEP found: {oep}. Now script will try another method." msg $RESULT jmp dynamic_find not_invalid_oep: mov oepbytes, [oep], 2 cmp oepbytes, 25ff je risc_oep cmp $RESULT, CODEBASE je good_oep eval "Some weird OEP found: {oep}. Do you want to continue or try using another method? \r\n\r\n\r\nContinue: NO\r\nAnother method: YES" msgyn $RESULT cmp $RESULT, 01 je dynamic_find good_oep: bphws oep esto msg "OEP found!" bphwc ret risc_oep: eval "It seems that OEP: {oep} is RISC-protected. Continuing in another mode." msg $RESULT jmp dynamic_find notfound_static: mov eip, bakeip bc free eval_section dynamic_find: bphws VirtualProtect esto bphwc VirtualProtect bphws VirtualQuery mov hits, 0 VirtualQueryloop: esto cmp [esp+4], IMAGEBASE je checkhits jmp VirtualQueryloop checkhits: inc hits cmp hits, 2 jne VirtualQueryloop bc bphwc bprm CODEBASE, CODESIZE run bpmc msg "Possible OEP(near OEP) found." ret error: msg "Fatal error occured." ret

Hi SnD, This is a small tool I wrote while reversing some malwares. It performs a bunch of nowadays malwares tricks and the goal is to see if you stay under the radar. That could be useful if: You are making an anti-debug plugin and you want to check its effectiveness. You want to ensure that your sandbox solution is hidden enough.. You want to write behavior rules to detect any attempt to use these tricks. Please, if you encounter any of the anti-analysis tricks which you have seen in a malware, don't hesitate to contribute. List of features supported: Anti-debugging attacks IsDebuggerPresent CheckRemoteDebuggerPresent Process Environement Block (BeingDebugged) Process Environement Block (NtGlobalFlag) ProcessHeap (Flags) ProcessHeap (ForceFlags) NtQueryInformationProcess (ProcessDebugPort) NtQueryInformationProcess (ProcessDebugFlags) NtQueryInformationProcess (ProcessDebugObject) NtSetInformationThread (HideThreadFromDebugger) NtQueryObject (ObjectTypeInformation) NtQueryObject (ObjectAllTypesInformation) CloseHanlde (NtClose) Invalide Handle SetHandleInformation (Protected Handle) UnhandledExceptionFilter OutputDebugString (GetLastError()) Hardware Breakpoints (SEH / GetThreadContext) Software Breakpoints (INT3 / 0xCC) Memory Breakpoints (PAGE_GUARD) Interrupt 0x2d Interrupt 1 Parent Process (Explorer.exe) SeDebugPrivilege (Csrss.exe) NtYieldExecution / SwitchToThread Anti-Dumping Erase PE header from memory SizeOfImage Timing Attacks [Anti-Sandbox] Sleep -> SleepEx -> NtDelayExecution Sleep (in a loop a small delay) SetTimer (Standard Windows Timers) timeSetEvent (Multimedia Timers) WaitForSingleObject -> WaitForSingleObjectEx -> NtWaitForSingleObject Human Interaction / Generic [Anti-Sandbox] Mouse movement Total Physical memory (GlobalMemoryStatusEx) Disk size using DeviceIoControl (IOCTL_DISK_GET_LENGTH_INFO) Count of processors (Win32/Tinba - Win32/Dyre) Anti-Virtualization / Full-System Emulation Registry key value artifacts HARDWARE\DEVICEMAP\Scsi\Scsi Port 0\Scsi Bus 0\Target Id 0\Logical Unit Id 0 (Identifier) (VBOX) HARDWARE\DEVICEMAP\Scsi\Scsi Port 0\Scsi Bus 0\Target Id 0\Logical Unit Id 0 (Identifier) (QEMU) HARDWARE\Description\System (SystemBiosVersion) (VBOX) HARDWARE\Description\System (SystemBiosVersion) (QEMU) HARDWARE\Description\System (VideoBiosVersion) (VIRTUALBOX) HARDWARE\Description\System (SystemBiosDate) (06/23/99) HARDWARE\DEVICEMAP\Scsi\Scsi Port 0\Scsi Bus 0\Target Id 0\Logical Unit Id 0 (Identifier) (VMWARE) HARDWARE\DEVICEMAP\Scsi\Scsi Port 1\Scsi Bus 0\Target Id 0\Logical Unit Id 0 (Identifier) (VMWARE) HARDWARE\DEVICEMAP\Scsi\Scsi Port 2\Scsi Bus 0\Target Id 0\Logical Unit Id 0 (Identifier) (VMWARE) Registry Keys artifacts "HARDWARE\ACPI\DSDT\VBOX__" "HARDWARE\ACPI\FADT\VBOX__" "HARDWARE\ACPI\RSDT\VBOX__" "SOFTWARE\Oracle\VirtualBox Guest Additions" "SYSTEM\ControlSet001\Services\VBoxGuest" "SYSTEM\ControlSet001\Services\VBoxMouse" "SYSTEM\ControlSet001\Services\VBoxService" "SYSTEM\ControlSet001\Services\VBoxSF" "SYSTEM\ControlSet001\Services\VBoxVideo" SOFTWARE\VMware, Inc.\VMware Tools SOFTWARE\Wine File system artifacts "system32\drivers\VBoxMouse.sys" "system32\drivers\VBoxGuest.sys" "system32\drivers\VBoxSF.sys" "system32\drivers\VBoxVideo.sys" "system32\vboxdisp.dll" "system32\vboxhook.dll" "system32\vboxmrxnp.dll" "system32\vboxogl.dll" "system32\vboxoglarrayspu.dll" "system32\vboxoglcrutil.dll" "system32\vboxoglerrorspu.dll" "system32\vboxoglfeedbackspu.dll" "system32\vboxoglpackspu.dll" "system32\vboxoglpassthroughspu.dll" "system32\vboxservice.exe" "system32\vboxtray.exe" "system32\VBoxControl.exe" "system32\drivers\vmmouse.sys" "system32\drivers\vmhgfs.sys" Directories artifacts "%PROGRAMFILES%\oracle\virtualbox guest additions\" "%PROGRAMFILES%\VMWare\" Memory artifacts - Interupt Descriptor Table (IDT) location - Local Descriptor Table (LDT) location - Global Descriptor Table (GDT) location - Task state segment trick with STR MAC Address "\x08\x00\x27" (VBOX) "\x00\x05\x69" (VMWARE) "\x00\x0C\x29" (VMWARE) "\x00\x1C\x14" (VMWARE) "\x00\x50\x56" (VMWARE) Virtual devices "\\.\VBoxMiniRdrDN" "\\.\VBoxGuest" "\\.\pipe\VBoxMiniRdDN" "\\.\VBoxTrayIPC" "\\.\pipe\VBoxTrayIPC") "\\.\HGFS" "\\.\vmci" Hardware Device information SetupAPI SetupDiEnumDeviceInfo (GUID_DEVCLASS_DISKDRIVE) QEMU VMWare VBOX VIRTUAL HD Adapter name VMWare Windows Class VBoxTrayToolWndClass VBoxTrayToolWnd Network shares VirtualBox Shared Folders Processes vboxservice.exe (VBOX) vboxtray.exe (VBOX) vmtoolsd.exe (VMWARE) vmwaretray.exe (VMWARE) vmwareuser (VMWARE) vmsrvc.exe (VirtualPC) vmusrvc.exe (VirtualPC) prl_cc.exe (Parallels) prl_tools.exe (Parallels) xenservice.exe (Citrix Xen) WMI SELECT * FROM Win32_Bios (SerialNumber) (VMWARE) SELECT * FROM Win32_PnPEntity (DeviceId) (VBOX) SELECT * FROM Win32_NetworkAdapterConfiguration (MACAddress) (VBOX) SELECT * FROM Win32_NTEventlogFile (VBOX) SELECT * FROM Win32_Processor (NumberOfCores) (GENERIC) SELECT * FROM Win32_LogicalDisk (Size) (GENERIC) DLL Exports and Loaded DLLs kernel32.dll!wine_get_unix_file_nameWine (Wine) sbiedll.dll (Sandboxie) dbghelp.dll (MS debugging support routines) api_log.dll (iDefense Labs) dir_watch.dll (iDefense Labs) pstorec.dll (SunBelt Sandbox) vmcheck.dll (Virtual PC) wpespy.dll (WPE Pro) Anti-Analysis Processes OllyDBG / ImmunityDebugger / WinDbg / IDA Pro SysInternals Suite Tools (Process Explorer / Process Monitor / Regmon / Filemon, TCPView, Autoruns) Wireshark / Dumpcap ProcessHacker / SysAnalyzer / HookExplorer / SysInspector ImportREC / PETools / LordPE JoeBox Sandbox Code/DLL Injections techniques CreateRemoteThread SetWindowsHooksEx NtCreateThreadEx RtlCreateUserThread APC (QueueUserAPC / NtQueueApcThread) RunPE (GetThreadContext / SetThreadContext) Contributors mrexodia: Main developer of x64dbg References An Anti-Reverse Engineering Guide By Josh Jackson. Anti-Unpacker Tricks By Peter Ferrie. The Art Of Unpacking By Mark Vincent Yason. Walied Assar's blog http://waleedassar.blogspot.de/ Pafish tool: https://github.com/a0rtega/pafish source: https://github.com/LordNoteworthy/al-khaser

Tutorial: 1. MegaDumper, get ResourceAssembly.dll (assembly than contains resources) 2. Use ConfuserDelegateKiller to remove delegates from UnpackMe.exe (google it) 3. de4dot with parameters (-p un --strtyp delegate --strtok 06000043) 4. CryptoObfuscator constant fixer by me (pm if you need) 4. Remove all instructions from <Module>.cctor 5. Attach resources with ResourceManager (use file from step 1) 6. Clean from junk classes and delegates

Some steps to get the real file, deobfuscating it will be up to you though: Finding The Embedded Resource Name Open the crackme in your favorite PE browser.View the file resources.Locate RCDATA and find the main resource. In this case it is "__"Dumping The "Real" ExecutableOpen the crackme in OllyDbg.Find all string references and look for the resource name we just found. In this case: Cra'ckMe.0041B280 ; UNICODE "___"Follow the reference into the code.Scroll down and locate the calls to 'SafeArrayCreate' and 'SafeArrayAccessData'. These are the important calls we want to find.We want to set a breakpoint on the call after SafeArrayAccessData. (See code below)Once the break is hit, step over the call.Follow EAX in the dump window. This is the executable decrypted from the "__" resource.Save the memory region, do any fixes needed based on how you save the region etc.You should now have the real executable.004022D9 |. 8D8C24 8800000>LEA ECX,DWORD PTR SS:[ESP+0x88]004022E0 |. 51 PUSH ECX004022E1 |. 6A 01 PUSH 0x1004022E3 |. 83C5 F2 ADD EBP,-0xE004022E6 |. 6A 11 PUSH 0x11004022E8 |. 89AC24 9400000>MOV DWORD PTR SS:[ESP+0x94],EBP004022EF |. 899C24 9800000>MOV DWORD PTR SS:[ESP+0x98],EBX004022F6 |. FF15 54B14100 CALL DWORD PTR DS:[<&OLEAUT32.#15>] ; OLEAUT32.SafeArrayCreate004022FC |. 8D5424 48 LEA EDX,DWORD PTR SS:[ESP+0x48]00402300 |. 8BF0 MOV ESI,EAX00402302 |. 52 PUSH EDX00402303 |. 56 PUSH ESI00402304 |. 895C24 50 MOV DWORD PTR SS:[ESP+0x50],EBX00402308 |. FF15 58B14100 CALL DWORD PTR DS:[<&OLEAUT32.#23>] ; OLEAUT32.SafeArrayAccessData0040230E |. 8B4424 48 MOV EAX,DWORD PTR SS:[ESP+0x48]00402312 |. 55 PUSH EBP00402313 |. 57 PUSH EDI00402314 |. 50 PUSH EAX00402315 |. E8 36900000 CALL Cra'ckMe.0040B350 <=========== SET BREAKPOINT HERE0040231A |. 83C4 0C ADD ESP,0xC0040231D |. 56 PUSH ESI0040231E |. FF15 5CB14100 CALL DWORD PTR DS:[<&OLEAUT32.#24>] ; OLEAUT32.SafeArrayUnaccessDataDumping The "Real" Real ExecutableOpen the new file you dumped in a .NET disassembler such as ILSpy.View the files managed resources and save the resource '_' in this case, to disk as a new executable.This new file is the real obfuscated crackme file fully removed from the loaders.After this point I stopped, the file does a lot of suspicious things so I didn't bother continuing.

Looks like the rumors of leaked VMProtect sources were true. Now they are available for everyone. It was leaked on certain Chinese sites, so use your brain and caution and don't run random files outside of VM... EDIT1: Please note that "intel.cc" and "processor.cc" are missing, so the native code virtualization part is most likely non-working. Thanks to @boot and @lawl3ss and Twitter wisdom for the info! EDIT2: Link changed to anonfiles.

You should not include actual key in case of Crackme here as It defeats the whole mean of Crackme - Let's come to unpacking : 1. File is protected with Native Layer. 2. Unpack .NET Reactor. 3. Devirtualize VM in order to get the clean code. 4. Manual Instructions about DNR VM : DNR VM is pretty much 1:1 5. More Links to study about DNR : Unpacked : Crackme_BH.exe

Hello, I unpacked the file completely (including VM). Here is how I did it (simplified a bit): 1. After a bit of analysis we can notice that Agile.NET hooks into the Just In Time compiler in order to restore the method code. This can be undone by hooking into the JIT before Agile.NET. 2. Update de4dot to be able to remove simple protections like string encryption, control flow, and reference proxy. This just requires you to update some detections. 3. Spend some time analyzing Agile.NET VM, we find out that it's VM is somewhat different to others as it creates "combined" handlers for multiple opcodes. In order to remove the VM we can utilize de4dot devirtualizer. In order to add support we have to track down the original runtime dll that's shipped with the protector to extract the non-merged handler information. After some manual cleanup the result is the following, unpacked file attached. UnpackMe-unpacked.exe

.NET Reactor v6.2.0.0 changed a few things. First, they added code virtualization which is not that hard because it's more straightforward than rest of code virtualization implementations that are in the market. You forgot to protect your code with this feature. Secondly, you can now hide your external and internal calls with their new "Hide calling" feature. You can use de4dot standard ProxyCallFixer1 to fix those delegates. Of course firstly you need to read them from initialization method but reading method is already implemented in the base version of de4dot (which is used for resources, strings etc). Thirdly, AntiDebug feature which is basically just a simple check of IsAttached, just nop these instructions. There are few more changes to necrobit feature, for example they hide PInvoke methods to break old de4dot implementation - pretty easy fix. Overall these changes are not that major to completely rewrite de4dot from scratch. Here is unpacked version of your file unpackme -cleaned.exe

Hi Guys and here is my solution for 32bit one. devirtualizeme32_vmp_3.0.9_v1_deVM_Raham.zip PS: my decompiler is in progress state, so tell me if you found mistake in X86 instructions. Kind Regards

Every once in a while someone is asking about working in RE-related field - what it's like, how to start, what to study, etc. I personally think this is a good summary: https://medium.com/@laparisa/so-you-want-to-work-in-security-bc6c10157d23

X86 Shellcode Obfuscation https://breakdev.org/x86-shellcode-obfuscation-part-1/ https://breakdev.org/x86-shellcode-obfuscation-part-2/ Ted.

LoaderCSharp: Loader C# source code, It will search in memory for hex string and will replace with another hex string. Maybe somebody will find it usefull. LoaderCSharp.zip

First of all, there's no easy way to devirtualize Eazfuscator VMed methods. So keygenning this is pretty hard task. But you can guess methods that are executing by breaking on System.Reflection.RuntimeMethodInfo.Invoke. Another way is to decrypt resource in which Eazfuscator store all VM logic. There will be visible names of methods that are executing. But in this way we will not know the order of execution. So the best way is just to use WinDbg and break on invoke. We need to dump main assembly. Just use MegaDumper to do that. Assembly will not start if there are no giv.txt and Ionic.Zip.dll in the same folder as keygenme. But you can launch original keygenme without that files because they are virtualized using Enigma Protector container. So let's create those two files. In dumped assembly you can also find a timer which checks if some forbidden processes are running, such as IDA, LordPE etc. The token of the method is 0x0600001a. It is recommended to "nop" it using CFF Explorer or WinHEX. Then we place breakpoint on method token 0x0600001b. This method is button1.Click. We also place a breakpoint on System.Reflection.RuntimeMethodInfo.Invoke. We are not going to devirtualize Eazfuscator VM so let's think what method executes firstly after you click an OK button. The first thought that comes to mind - it must be reading text from that Edit1. bBut firstly it again checks that two files (giv.txt and Ionic.Zip.dll). But if on Form.Load it checked just a presence of that files, now it also checks the contents of giv.txt. It must be base64 string of "reversing.ro" (without the quotes). In Ionic.Zip.dll can be anything. It can even not be an assembly. So just breaking on invoke call can reveal methods that are executing. And the most important part - we can see all values in stack and registers! So finally after long "F5-button-clicking-and-checking-method-info" we break on string compare method. And now we can see correct key for our username. My valid pair of name and key: SHADOW 98999697102103 Also I'm attaching dumped assembly and two needed files. Dump_.rar

Tuts 4 You has migrated to a new server. Apologies for the longer than anticipated downtime. I wanted to ensure all files, databases and propagations and server settings were all good before going back online so as not to risk losing information/ files. If you come across any issues whilst using the site please let me know so I can check and resolve... Ted.

Let's solve this Challenge : Preface : Note: If you have a valid key for your system, it is just a matter of seconds to work, i.e., dump (exe & dll) and then unpack. Therefore, this methodology should not be used for real-life applications, as, of course, if an attacker purchases a valid license, you won't be able to stop them (even an intermediate one). Also, VM checks are ineffective. You can run in a real PC, or there are many GitHub repositories to hide the VM, such as https://github.com/hzqst/VmwareHardenedLoader A Step-by-Step Guide : 1. Patch HWID Checks of Executable : 2. Registering and Launching the Executable : 3. Dumping the Executable from Memory: 4. Extracting the Native DLL : 5. Patch HWID Checks of DLL : By this stage, we've effectively navigated through the complexities of the Enigma Protector and completed the native reverse engineering tasks. We now possess the dumped .NET executable and a native DLL that has been patched to bypass the HWID check, both of which were initially secured by Enigma Protector. 6. Dynamic Unpacking of ILProtector : Comment : I've included the source code for this executable, along with the unprotected executable, a dumped version of the executable, and the Protected DLL (as I said in my previous comment, It is very easy to do ). You'll find the rest of the necessary information in this discussion thread or elsewhere on this forum. Calculator_dumped.exe (.NET) - Original Sample file dumped from memory with .NET code. Calculator_unpacked.exe (.NET) - Unprotected File. Calculator_src.zip (.NET) - Source Code. Protect_original.dll (.NET) - shipped along with protected ILP file by the Protector itself. Runtime32_original.dll (C++) - ILP generated dll protected with Enigma Protector 7.40 (dumped carefully). version.dll (C++) - Proxy DLL created by @lengyue to Patch HWID. (Use the Key given in this challenge after putting this dll into the same directory where you placed the exe) Protect_original.dll Runtime32_original.dll Calculator_dumped.exe version.dll Calculator_unpacked.exe Calculator_src.zip

Few Questions in my mind regarding the @solutions getting posted and even getting approved. How did you patch It? How did you unpack or crack It? What kind of debugging settings used by You? Have you used already available public tools or coded something private? (If you made something privately then how does It work?) How did you trace and reach to specific point for patching? (Anti debug bypass or CRC check for patch) What was the logic behind that? Do you guys know what a good @solution is? See this - What is the logic of all these videos posted in threads (mostly related to Themida) ? are these Useful? No absolutely not. you all are just acting like an attention seeker by showing off that you can unpack or patch by making a 13-15 sec video with no info. in such videos, there is a loader and you launch and it works. BOOM ! If all the videos are like this then better not to post and increase burden on the site because in my point of view these kind of video proofs are pointless and senseless. We are here to read and increase the knowledge. If you don't wanna share, simply keep it up to you. No need to show off and even If you do, I have no problem with you when you show-off but It should not be marked as a Solution. P.S. - I am not asking you to share the source code or a complete private stuff but at least you can share steps in a descriptive manner.

The password which solves this challenge is the same as the one posted by kao. Here is my quick write-up for the same. Reposted on https://github.com/extremecoders-re/tuts4you_users_desktop_crackme_writeup with proper markdown formatting. I : Bypassing anti-debug First of all, to make the addresses not vary in between the runs we can disable ASLR for the binary by patching the Dll can move flag in PE Optional header. This is not strictly required but makes it easy to follow along. The binary implements lots of anti-debug, specially playing with HANDLES which makes it a little bit tough to debug right out of the box. Also trying to the attach to the application would make it quit immediately. In Process Hacker we can check that the application is multi-threaded. In fact, the protection logic is implemented on the secondary thread which has a higher CPU usage (1.32 in the image). At this point we can suspend the thread. Once that is done we can simply attach to the process with x64dbg without any issue. II : Finding a suitable point to start We are already attached to the crackme process. At this point it is still waiting for our input on the main thread. We need to find a suitable place to set a breakpoint on such that we can trace the password checking logic with minimal overhead. A nice place to set a breakpoint is in kernelbase.dll!ReadFile just after the call to NtReadFile as shown. With the breakpoint in place we can enter any password say 123456789ABCDEF and hit enter. The breakpoints immediately hits. From here we can continue single stepping until we exit the fgets function and enter the VM region identified by the presence of obfuscated code. The ret instruction at 0x140004B51 should likely be the end of fgets. Stepping once from here we can see obfuscated code signifying the start of VM. III - Tracing the VM At this point on the stack we can see our entered password. We can set a hardware breakpoint on read at 0x14FE60, the address where the password is stored in memory and resume execution. When the breakpoints hits, set another standard breakpoint on MessageBoxW function. The crackme displays the success or failure using this API. Now using x64dbg "Run trace" we can log all instructions until it hits MessageBoxW. This will take quite some time. Make sure to set a large enough value for "Maximum Trace Count" as shown. IV - Filtering the trace When the breakpoint at MessageBoxW hits we can stop tracing and export the trace log to a csv. The objective is to remove all non xor instructions from the trace. Also other xor instructions like xor eax, eax, xor ebx, ebx which are irrelevant towards our goal can be removed. This can be accomplished using a decent text editor like Notepad++. After removing all irrelevant instructions, we are left with just two xor instructions in the csv trace log. 07B77,000000014004602B,33C3,"xor eax,ebx",rax: B3-> 43,,"ebx:&""C:\\crackme.exe""" 448EB,000000014004602B,33C3,"xor eax,ebx",rax: 36-> 0,,"ebx:&""C:\\crackme.exe""" After the first xor, eax holds 0x43 = 'C' which is the first character of our password. The second xor is comparing the null terminator. There are no more xor's as the crackme stops comparing further characters as soon as a mismatch is found. V - Recovering the password We can set a breakpoint on the instruction xor eax, ebx at 0x140004602B. The value in eax after the xor is the correct corresponding password character. Here, eax = 0x43 = 'C' which should be the first character of the password. To get other characters of the password we cannot resume yet. Note that the application exits as soon as a mismatch is found. Hence we can overwrite the value in eax to 0x31 = '1' instead which is the first character of our entered password (`123456789ABCDEF`). We can automate these steps using a Frida script. The script sets a interceptor at the instruction at 0x14004602B => xor eax, ebx . When using the script we have to input a large string of 1's (like 1111111111111111111111111111111111) as the password. The script will overwrite the registers such that after the xor, rax contains '1' (=0x31) making the crackme believe the check succeeded. Finally, we print the complete password when we have got the null terminator. The correct password is printed at the end. Note that we need to inject the frida script after suspending the protection thread in the same way we were attaching the debugger.

How to Unpack this VMProtect 3.5 Challenge - 2022/01/10 by @BlackHat Tutorial : Video Tutorial : Best Regards BlackHat awesome.vmp35_BH_unp.exe

So you want to download some releases from snd? alright let's see at snd.webscene.ir, the distribution section menu contain a link pointing at hxtps://keygens.pro/ Super, looks like there a lot of cracks over here! and the site is virus free, right? So let's pick something, i don't know, maybe 7-Data.Card.Recovery.1.1.keygen-SND hxtps://keygens.pro/crack/729775/ lol @ description on the page, didn't know reagan was from snd and born in russia Anyway we got redirected on a download page after clicking 'Download only Keygen' button, we have to fill a captcha and agree to the conditions The archive is password protected and contain only one file "setup_pass-123.exe" If we try to download some other random files from the keygens.pro collection, sometime we have variations. e.g: Any.video.converter.Ultimate.keygen-URET hxtps://keygens.pro/crack/733508/ who contain a 'readme.txt' but we still have our suspicious setup_pass-123.exe inside. antiviruses aren't really happy about the file when sent to virustotal, but hey, it's kind of normal it's a crack afterall. The file in question is identified massively as 'remcos' (avira, kaspersky, f-secure,..) remcos is a know trojan, and this time they have right. I've sent the file to my capev2 (like cuckoo sandbox but with python3) who also identified it as remcos, and even exactly version 2.7.0 Pro. The process tree: path-pass-123.exe 1204 powershell.exe 764 powershell -w 1 -e cwB0AGEAcgB0AC0A [REDACTED] mc.exe 588 mc.exe 2816 trading_bot.exe 2776 services.exe 484 C:\Windows\system32\services.exe lsass.exe 2992 C:\Windows\system32\lsass.exe mc.exe do a NtOpenMutant with mutex name 'Remcos_Mutex_Inj' fews deletefile() DeletedFile: C:\Users\PC\AppData\Local\Temp\g23cbt11.tv1.ps1 DeletedFile: C:\Users\PC\AppData\Local\Temp\rgmxlij1.zlj.psm1 DeletedFile: C:\Users\PC\AppData\Local\Microsoft\Windows\PowerShell\CommandAnalysis\PowerShell_AnalysisCacheEntry_a5a4f0c9-7658-465a-89b7-50210e17552a DeletedFile: C:\Users\PC\AppData\Local\Microsoft\Windows\PowerShell\CommandAnalysis\PowerShell_AnalysisCacheEntry_aa1cabc1-b688-4c89-bf51-d9e59fc195d8 DeletedFile: C:\Users\PC\AppData\Local\Microsoft\Windows\PowerShell\CommandAnalysis\PowerShell_AnalysisCacheEntry_33715418-423c-4ee6-9bfb-e19632c208c1 DeletedFile: C:\Users\PC\AppData\Local\Microsoft\Windows\PowerShell\CommandAnalysis\PowerShell_AnalysisCacheEntry_d9fccf31-e642-45c3-b729-86cbf5ec234c DeletedFile: C:\Users\PC\AppData\Local\Microsoft\Windows\PowerShell\CommandAnalysis\PowerShell_AnalysisCacheEntry_99c3bc19-136a-483f-a231-8276ab84ee13 DeletedFile: C:\Users\PC\AppData\Roaming\Microsoft\mc.exe DeletedFile: C:\Users\PC\AppData\Local\Temp\webcam.png DeletedFile: C:\Users\PC\AppData\Local\Temp\screenshot.jpg DeletedFile: C:\Users\PC\AppData\Roaming\Mozilla\Firefox\Profiles\fuv0sisu.default-release\cookies.sqlite24628718 DeletedFile: C:\Users\PC\AppData\Roaming\Mozilla\Firefox\Profiles\fuv0sisu.default-release\formhistory.sqlite24628875 About the dropped files, it write a file 'logs.dat' into \AppData\Roaming\temp\, in my case: [2020/10/15 05:31:33 Offline Keylogger Started] [ Program Manager ] [Following text has been copied to clipboard:] h [End of clipboard text] { User has been idle for 400 minutes } And what's was the 'screenshot.png' he created and then deleted? this: one of my capev2 vm, the malware have a bit oversized the screenshot tought. The file sniff keystrokes, harvest/steal private information from browsers and messenger clients, take screenshots from pc and webcam if connected, and installs itself for autorun at startup, yep that not really what we where looking for. Alright... let's search for another site then.. We type "download crack" on google and we are now on keygenninja.com (former KeygenGuru) according to them. site is in second result in google main page, the authors of the sites play on search engine rankings, .. and are extremely well positioned (they pay Google for that) Let's try to download something, idk, maybe 'Panopticum IcePattern v1.2 for Adobe Photoshop' hxtps://keygenninja.com/serial/panopticum_icepattern_v1_2_for_adobe_photoshop.html We click the 'Download Keygen' button and get redirected on another site hxtps://cracknet.net/d/a95b2bff8a272ss9p.html Now we are on a page with 2 big 'download' buttons, the text indicate also that the archive password is 12345 When you click on the button the download is launched, but from another external site: hxtps://get.ziplink.xyz/ I've found also another site: serialms.com, this is just another 'showcase site'. All the cracks point to the same address (cracknet.net). they also have the same db as keygenninja.com Well, we have 3 files in the archive, one executable, and unless keygens.pro, this time we have the info files (nfo and diz file), apparently a release from team inferno (a cracking group who disbanded in 2006) The nfo says it was released in may 2020 and the files timestamp seem from 2020, is inferno back ? When extracting the executable from the archive, we got a suspicious 'rar sfx archive' icon, if we look for executable properties, windows will confirm it's a self-extracting archive. Meaning we can also rename the file to .rar and open it with winrar to see what's going on. btw that archive inside the archive [insert xzibit yo dawg meme here] is also password protected with '12345' According to virustotal only 10 on 70 engines detect it as hostile. Suspicious again huh? let's send this file to capev2 too. When sending a password protected sfx archive, you need to fill the option field with: 'arguments=-p 12345' in capev2, so it will be able to run it with the password. And.. here is the process tree.. yep a big one too, the sfx archive contain a sfx archive, who contain severals other sfx archives [insert again xzibit meme here] and execute everything, resulting a lot of new processes. Panopticum.IcePatter.exe 172 -p12345 cmd.exe 2696 C:\Windows\system32\cmd.exe /c ""C:\Users\PC\AppData\Local\Temp\RarSFX0\keygen.bat" " intro.exe 816 intro.exe 1O5ZF keygen-step-1.exe 3916 keygen-step-1.exe keygen-pr.exe 3892 keygen-pr.exe -p83fsase3Ge key.exe 1280 keygen-step-3.exe 3524 keygen-step-3.exe cmd.exe 3804 cmd.exe /C ping 1.1.1.1 -n 1 -w 3000 > Nul & Del /f /q "C:\Users\PC\AppData\Local\Temp\RarSFX0\keygen-step-3.exe" PING.EXE 2572 ping 1.1.1.1 -n 1 -w 3000 keygen-step-4.exe 2624 keygen-step-4.exe file.exe 3896 002.exe 4548 Setup.exe 4152 slic.exe 4148 1 984D0A19445AA8C5.exe 1552 0011 installp1 984D0A19445AA8C5.exe 1144 200 installp1 cmd.exe 3280 cmd.exe /c taskkill /f /im chrome.exe msiexec.exe 2880 msiexec.exe /i "C:\Users\PC\AppData\Local\Temp\gdiview.msi" services.exe 472 C:\Windows\system32\services.exe svchost.exe 592 C:\Windows\system32\svchost.exe -k DcomLaunch dllhost.exe 3832 C:\Windows\system32\DllHost.exe /Processid:{F9717507-6651-4EDB-BFF7-AE615179BCCF} dllhost.exe 2064 C:\Windows\system32\DllHost.exe /Processid:{F9717507-6651-4EDB-BFF7-AE615179BCCF} svchost.exe 3224 C:\Windows\system32\svchost.exe -k netsvcs VSSVC.exe 3648 C:\Windows\system32\vssvc.exe One file lead to many files So what's going on? well, a lot of things. This isn't remcos RAT like in keygens.pro, i don't know what exactly is all of this, my capev2 seem to detect it as Azorult (a know password stealer) I thinks it's a false positive for 'azorult' malware familly but this one is also harvesting credentials from browsers, bitcoin wallets clients, FTP clients, email clients... BTRSetp.exe seem packed with 'Eshelon revolution protector', it have also a mention to lenin. // Module  [module: SuppressIldasm] [module: Glory_to_the_Great_Lenin_and_the_October_Revolution!!!("Eshelon Revolution Protector ")] [module: EF58C16E8C("Discord Link : v1.0.0-custom")] The batch file keygen.bat unpack keygen-step-4.exe with password 83fsase3Ge This archive contain key.exe and JOzWR.dat, when key.exe is executed it will look in the same folder for the file JOzWR.dat, who is later decoded by key.exe and loaded in memory a 'lzma decoder' screenshot here in memory 1060×847 png 60,4 kB dumped JOzWR.dat is detected by 13 engines. ASCII "-txt -scanlocal -file:potato.dat" potato.dat is a file that will be later created in %TEMP% and who contain harvested serial numbers from your applications, including windows license key. exemple of what contain the file in my capev2: Computer: PC-PC - Main scan Microsoft Office Professional Plus 2010 - License Key - REDACTED-REDACTED-REDACTED-REDACTED-REDACTED Microsoft Office Professional Plus 2010 - Product ID - REDACTED-REDACTED-REDACTED-REDACTED Microsoft Office Professional Plus 2010 - License Key - REDACTED-REDACTED-REDACTED-REDACTED-REDACTED Windows 7 Ultimate - Extra info - Full product name: Windows 7 Ultimate Service Pack 1 Product ID match to CD Key data Product Part No.: REDACTED Installed from 'Full Packaged Product' media. Is OEM: No Windows 7 Ultimate - License Key - REDACTED-REDACTED-REDACTED-REDACTED-REDACTED Windows 7 Ultimate - Product ID - REDACTED-REDACTED-REDACTED-REDACTED Windows 7 Ultimate - User - PC Computer: PC-PC - Deep scan The guy who want free serials get his serials harvested, isn't that a paradox? In conclusion: never open or visit crack sites if you don't have the knowledge to avoid infections, use common sense as some will even try to trick you with fake nfo/fake releases. Maybe buy your softwares (or crack them yourself) to avoid that, and don't trust crack sites at all, even if they was 'legitimate' like keygens.pro, they can go rogue anytime.

@whoknows: why would I lie? And my answer was there 1 hour before CodeCracker's answer.. Short tutorial: 1. Olly + ScyllaHide takes care of all anti-debug. So I didn't have to worry about that; 2. Load ggggg.exe in DNSpy and look around. You'll see what methods are there, their arguments and so on. Interesting parts are: internal static extern bool StrongNameSignatureVerificationEx([MarshalAs(UnmanagedType.LPWStr)] string wszFilePath, bool fForceVerification, ref bool pfWasVerified); This is obviously anti-debug measure. It's good that we have a method that's called via P/Invoke because it's easy to put a breakpoint on it.. private delegate void proStatusCallback(double val, string fl, string flSize); This tells us that some things will (probably) be asynchronous. Hardware breakpoints are different for each thread, you can't use those! Use memory breakpoints instead. private void <Module>(object sender, EventArgs e) Method with those parameters is usually control_onClick.. So, most likely called when you click "Validate" button. Not that it matters.. 3. Load ggggg.exe in Olly. Put breakpoint on StrongNameSignatureVerificationEx. 4. Enter whatever serial and click Validate. Olly will break. 5. Step out of Windows API and CLR methods until you arrive at JIT'ed code. 6. Now the hard work begins. Debug the code and make comments what each JIT'ed method does. Eventually you'll arrive here (addresses and the exact code will be different, depending on OS/.NET Framework version/etc.): 005411AD 8BF1 MOV ESI,ECX 005411AF 8BFA MOV EDI,EDX 005411B6 817D 08 7A040000 CMP DWORD PTR SS:[EBP+8],47A 005411BD 75 13 JNZ SHORT 005411D2 005411BF FF75 0C PUSH DWORD PTR SS:[EBP+C] 005411C2 8BCE MOV ECX,ESI 005411C4 8BD7 MOV EDX,EDI 005411C6 FF15 888C4F00 CALL DWORD PTR DS:[4F8C88] 005411CC 5E POP ESI 005411CD 5F POP EDI 005411CE 5D POP EBP 005411CF C2 0800 RETN 8 There's a check for constant 0x47A. Depending on the entered serial , value at [EBP+8] changes. So it's some sort of checksum. 7. Figure out a serial which passes this check. I found "9999999k" 8. Now you can go further.. Call at address 5411C6 has one argument on stack - entered serial number. So, this must a be a very interesting method. 9. Put memory breakpoint on the argument in stack, run and breakpoint will hit inside mscorlib. Step out until JIT'ed code and you'll be somewhere here: 003C1377 8BC8 MOV ECX,EAX 003C1379 8BD6 MOV EDX,ESI 003C137B 8B01 MOV EAX,DWORD PTR DS:[ECX] 003C137D 8B40 34 MOV EAX,DWORD PTR DS:[EAX+34] 003C1380 FF50 04 CALL DWORD PTR DS:[EAX+4] <--- this converts unicode string to byte array. Memory breakpoint triggered inside it. 003C1383 8BCF MOV ECX,EDI 003C1385 8BD0 MOV EDX,EAX 003C1387 3909 CMP DWORD PTR DS:[ECX],ECX 003C1389 E8 82BAB771 CALL mscorlib.71F3CE10 003C138E 8945 EC MOV DWORD PTR SS:[EBP-14],EAX 003C1391 B9 34380072 MOV ECX,72003834 10. Next call (at 003C1389) returns array of 0x10 bytes.. 025849E8 48 44 00 72 10 00 00 00 38 D0 8E 21 6C D5 23 66 HD.r...8ÐŽ!lÕ#f 025849F8 70 56 45 B9 5A 99 41 7F pVE¹Z™A Could it be that "38D08E216CD52366705645B95A99417F" == MD5("9999999k")? Quick google search confirms that. 11. Breakpoint on byte array, run. See byte array converted to hex string. Breakpoint on string, run.. See 2 strings being compared. 12. Google for the 2nd string. It's MD5("tarkus"). Problem solved.

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

Today I wrote a small class that assists with patching .NET binaries. using System; using System.IO; using dnlib.DotNet; using dnlib.DotNet.Emit; namespace MyNamespace { class Patcher { public delegate bool PatchStrategy(AssemblyDef asm); private static bool patchMethodReturnBool(AssemblyDef asm, string classPath, string methodName, bool returnValue, int numArguments = 0) { var method = findMethod(asm, classPath, methodName); if (method != null && method.Parameters.Count == numArguments) { //patch instructions var instructions = method.Body.Instructions; if (returnValue) instructions.Insert(0, OpCodes.Ldc_I4_1.ToInstruction()); //true else instructions.Insert(0, OpCodes.Ldc_I4_0.ToInstruction()); //false instructions.Insert(1, OpCodes.Ret.ToInstruction()); return true; } return false; } private static MethodDef findMethod(TypeDef type, string methodName) { if (type != null) { foreach (var method in type.Methods) { if (method.Name == methodName) return method; } } return null; } private static MethodDef findMethod(AssemblyDef asm, string classPath, string methodName) { return findMethod(findType(asm, classPath), methodName); } private static TypeDef findType(AssemblyDef asm, string classPath) { foreach (var module in asm.Modules) { foreach (var type in module.Types) { if (type.FullName == classPath) return type; } } return null; } public static bool PatchAssembly(string path, ref string error, PatchStrategy patcher) { var bakpath = path + ".bak"; try { //handle backup if (!File.Exists(bakpath)) File.Copy(path, bakpath); else File.Copy(bakpath, path, true); } catch (Exception x) { error = x.ToString(); return false; } try { DateTime creationTime = File.GetCreationTime(path); //load module var module = ModuleDefMD.Load(File.ReadAllBytes(path)); //execute patching strategy if (!patcher(module.Assembly)) return false; //write assembly if (module.IsILOnly) module.Write(path); else module.NativeWrite(path); //restore file date File.SetLastWriteTime(path, creationTime); File.SetCreationTime(path, creationTime); return true; } catch (Exception x) { File.Copy(bakpath, path, true); error = x.ToString(); } return false; } } } For every patch you write a strategy like this: public static bool PatchRegistrationCheck(AssemblyDef asm) { string classPath = "MyNamespace.MyClass"; /* * public bool IsRegistered(RegistrationData rd) * { * return true; * } */ if (!patchMethodReturnBool(asm, classPath, "IsRegistered", true, 2)) //2 parameters (this + rd) throw new Exception("MyClass.IsRegistered not patched!"); return true; } Then you call it like this: Patcher.PatchAssembly(filePath, Patcher.PatchRegistrationCheck); Hope it will be useful for some of you. Greetings

This document is a small write up demonstrating tools and techniques that can be used while reversing java code. The malware used for this purpose is the AlienSpy RAT (Remote Access Trojan) which has also been attached to this post. The password of the file malware sample.rar is infected. This is live malware. Secure your system before tinkering with it. Additionally, the decompiled source code of the malware has also been provided for study. Reversing an obfuscated java malware.pdf malware sample.rar decompiled malware source.rar

Hello everyone, Here is a small SDK example for TitanEngine Community Edition. It covers far from all features, but enough to get you started. This is the code: #include <windows.h>#include <stdio.h>#include <psapi.h>#include "TitanEngine\TitanEngine.h"PROCESS_INFORMATION* fdProcessInfo;LPVOID lpBaseOfImage;char szDumpName[MAX_PATH]="";static void log(const char* format, ...){ va_list args; va_start(args, format); char msg[1024]=""; vsprintf(msg, format, args); puts(msg);}static void cbOep(){ long long rip=GetContextData(UE_RIP); log("> OEP 0x%llX reached!", rip); log("> Dumping..."); DeleteFileA(szDumpName); //Dump the process (notice that szDumpName need to be a full path) if(!DumpProcess(fdProcessInfo->hProcess, lpBaseOfImage, szDumpName, rip)) { log("> DumpProcess failed..."); StopDebug(); return; } log("> Dumping done!"); log("> Fixing imports..."); ULONG_PTR iatStart=0; ULONG_PTR iatSize=0; //Search for IAT (Search start is 'OEP' in Scylla) ImporterAutoSearchIAT(fdProcessInfo->dwProcessId, szDumpName, rip, &iatStart, &iatSize); if(!iatStart || !iatSize) { log("> IAT not found..."); StopDebug(); return; } log("> IAT Start: 0x%llX, IAT Size: 0x%llX", iatStart, iatSize); char szSectionName[]=".unp64"; //Auto fix the file (append a section & fix IAT) if(!ImporterExportIATEx(szDumpName, szDumpName, szSectionName)) { log("> ImporterExportIATEx failed..."); StopDebug(); return; } log("> Imports fixed!"); //Stop debugging StopDebug();}static void cbNearOep(){ log("> Near OEP!"); //Step using the trap flag StepInto((void*)cbOep);}static void cbPeSpin(){ //Set a hardware breakpoint at RSP with size 8 on read/write SetHardwareBreakPoint(GetContextData(UE_RSP), UE_DR0, UE_HARDWARE_READWRITE, 8, (void*)cbNearOep);}static void cbEntry(){ //Get RIP register long long rip=GetContextData(UE_RIP); log("> Entry point 0x%llX reached!", rip); //Search for MPRESS pattern unsigned char pattern[4]= {0x5D, 0x5B, 0xC3,0xE9}; BYTE wildcard=0; long long found=Find((void*)rip, 0x1000, pattern, 4, &wildcard); if(!found) { //Search for PESpin pattern unsigned char pespin[4]= {0xFF, 0x64, 0x24, 0xF8}; long long found=Find((void*)rip, 0x1000, pespin, 4, &wildcard); if(!found) { log("> MPRESS/PESpin pattern NOT found..."); StopDebug(); return; } log("> PESpin pattern found on 0x%llX!", found); //Step over StepOver((void*)cbPeSpin); return; } //Set a simple INT3 breakpoint SetBPX(found+3, UE_BREAKPOINT, (void*)cbNearOep); log("> MPRESS pattern found on 0x%llX!", found);}static void cbCreateProcess(CREATE_PROCESS_DEBUG_INFO* CreateProcessInfo){ //Get the loaded base lpBaseOfImage=CreateProcessInfo->lpBaseOfImage; log("> Process created on 0x%llX!", lpBaseOfImage);}static bool DevicePathToPath(const char* devicepath, char* path, size_t path_size){ if(!devicepath || !path) return false; char curDrive[3]=" :"; char curDevice[MAX_PATH]=""; for(char drive='C'; drive<='Z'; drive++) { *curDrive=drive; if(!QueryDosDeviceA(curDrive, curDevice, MAX_PATH)) continue; size_t curDevice_len=strlen(curDevice); if(!_strnicmp(devicepath, curDevice, curDevice_len)) //we match the device { if(strlen(devicepath)-curDevice_len>=path_size) return false; sprintf(path, "%s%s", curDrive, devicepath+curDevice_len); return true; } } return false;}static bool GetFileNameFromHandle(HANDLE hFile, char* szFileName){ if(!GetFileSize(hFile, 0)) return false; HANDLE hFileMap=CreateFileMappingA(hFile, 0, PAGE_READONLY, 0, 1, 0); if(!hFileMap) return false; void* pFileMap=MapViewOfFile(hFileMap, FILE_MAP_READ, 0, 0, 1); if(!pFileMap) { CloseHandle(hFileMap); return false; } char szMappedName[MAX_PATH]=""; if(GetMappedFileNameA(GetCurrentProcess(), pFileMap, szMappedName, MAX_PATH)) { DevicePathToPath(szMappedName, szFileName, MAX_PATH); UnmapViewOfFile(pFileMap); CloseHandle(hFileMap); return true; } UnmapViewOfFile(pFileMap); CloseHandle(hFileMap); return false;}static void unpack(char* szFileName){ //Set an engine variable (hide console window of created process) SetEngineVariable(UE_ENGINE_NO_CONSOLE_WINDOW, true); //Get full file path HANDLE hFile=CreateFileA(szFileName, GENERIC_READ, FILE_SHARE_READ, 0, OPEN_EXISTING, 0, 0); if(hFile==INVALID_HANDLE_VALUE) { log("> File \"%s\" doesn't exist...", szFileName); return; } GetFileNameFromHandle(hFile, szDumpName); CloseHandle(hFile); log("> Unpack of file \"%s\" started...", szFileName); FILE_STATUS_INFO inFileStatus= {}; if(IsPE32FileValidEx(szFileName, UE_DEPTH_DEEP, &inFileStatus) && inFileStatus.FileIs64Bit && !inFileStatus.FileIsDLL) { log("> 64-bit PE file detected!"); //Make name of dumped file int len=strlen(szDumpName); while(szDumpName[len]!='.' && len) len--; if(!len) len=strlen(szDumpName); strcpy(szDumpName+len, "_unp64.exe"); //Start the process fdProcessInfo=(PROCESS_INFORMATION*)InitDebugEx(szFileName, 0, 0, (void*)cbEntry); if(fdProcessInfo) { log("> InitDebug OK!"); //Set a custom handler SetCustomHandler(UE_CH_CREATEPROCESS, (void*)cbCreateProcess); //Start debug loop DebugLoop(); } else log("> InitDebug failed..."); } else { log("> Invalid/x86/DLL file..."); } log("> Unpack ended");}int main(int argc, char* argv[]){ puts("unp64 v0.1\n\nSupported packers:\nMPRESS v2.19\nPESpin v1.22 (Packer only)\n"); if(argc<2) puts("usage: unp64 [file.exe]"); else unpack(argv[1]); Sleep(2500); return 0;}Example output:unp64 v0.1Supported packers:MPRESS v2.19PESpin v1.22 (Packer only)> Unpack of file "mpress.exe" started...> 64-bit PE file detected!> InitDebug OK!> Process created on 0x140000000!> Entry point 0x14000F0F3 reached!> MPRESS pattern found on 0x14000FBD7!> Near OEP!> OEP 0x140005DC8 reached!> Dumping...> Dumping done!> Fixing imports...> IAT Start: 0x14000F048, IAT Size: 0x38> Imports fixed!> Unpack endedProject files + Binaries attached.Greetings, Mr. eXoDia unp64.rar

lo folks, here's a new version. I've added and changed too much these days, so that there might be new bugs.I'm too lazy to sort it out what has changed since the last beta version.. please checkout the whole changelog again: v0.6 -new: 'Win64' option for all patch types (disables Wow64 redirections on 64 bit systems) to allow proper patching of x64 targets -new: grouping of patch entries via try-next-on-failure functionality.. some examples: a) multiple (future) versions of a target: add multiple search and replace patterns. as soon as 1 pattern hits, the rest of the group gets skipped. multiple bit versions of a target: one registry patch for the x64 version of a target, and one for the x86 version. the correct one gets automatically applied -new: randomized encryption of patch data (in resources) -new: support reg file version 5.00 -new: 'vista-awareness' via manifest (requestedExecutionLevel: level="requireAdministrator") -new: chiptune players bassmod, titchysid, V2M (v1.5!): .xm, .mod, .it, .s3m, .mtm, .umx, .sid, .v2m, .fc NOTE: as the v2m player comes as v1.5, use "conv2m.exe" from farbrausch to convert old tunes into the new format -new: change scroller behavior at runtime via control chars (speedup, pause, resume,...) -new: additional scroller text editor (load/save text, open in SkinHelper) -new: variables %APP% and %DATE% in scroller text get replaced with application name and release date -new: 3 custom skins for uPPP GUI (choose in options dialog) -new: SkinHelper updated with new chiptune players and from now on shipped together with main package -new: included some out-of-the-box-****: 1 neutral patcher skin (Blue Skull) and 1 packer (Upack) -new: open current template in SkinHelper via double click with right mouse button on preview window -new: whole package is more portable now (sub paths of settings are kept relative in INI file) -new: Messagebox "The target is running ! Close it, then hit OK." -new: button for faster checking of s+r pattern occurrencies -new: Cut/Copy/Paste/Delete contextmenu in pattern boxes -new: Context>Paste in pattern boxes allows multiline patterns (like given from Olly) -fix: filedrop only changed fileattributes of existing files when using confirmation dialog -fix: dropped and executed files returning bad exit code means patch failure -fix: after creating patch.exe and pressing "Execute", execute it with directory of last used target as working directory -fix: don't overwrite already existing backup files (when patching) -fix: reloading project with reg patch followed by other patches caused exceptions -fix: loosing custom drop path when reopening file drop entry -fix: patching failed, when s+r/userinput patch was followed by other s+r patches -fix: exceptions when changing template -fix: keep space chars in front of scroll text on shutdown/restart (for delayed scrollers) Here we go => uPPP.v0.6.Retail.7z And just for the completeness a package with example patches again. Mostly the top-of-the-art ones by Ecliptic: Skin_Examples.7z greets