Jump to content
Tuts 4 You

Leaderboard

  1. kao

    kao

    Full Member+


    • Points

      7

    • Content Count

      2,304


  2. Bartosz Wójcik

    Bartosz Wójcik

    Full Member


    • Points

      4

    • Content Count

      83


  3. Washi

    Washi

    Junior+


    • Points

      4

    • Content Count

      20


  4. 0x1579492959

    0x1579492959

    Full Member


    • Points

      3

    • Content Count

      146



Popular Content

Showing content with the highest reputation since 05/30/2020 in Posts

  1. 2 points
    Personally, I like to use the Scylla plugin of x64dbg, doing it manually by going to the memory map of x64dbg and dump the relevant memory ranges from there, or using WinDbg .writemem or the !savemodule sos extension command, depending on which debugger I am using at the moment. Also, once you're able to open the app in dnSpy, dnSpy can also reconstruct .NET modules from memory, by going to Debug > Windows > Modules and then right clicking the module you want to dump. There are probably also other tools out there that can do the same.
  2. 1 point
    Unpacked! So here's what i did. Removing the antitamper is really difficult if you're going to decrypt the methods by executing the method decrypt call in <module>.cctor. I think this is caused by the function that modifies some parts of metadata. The function is placed before the method decrypt function and after PE section finding part. So what i did was i modified abugger's antitamper remover and it pretty much worked. After antitamper was removed, it somehow created an error when decompressing constant data. Anyways, im too lazy to find out how removing antitamper was causing that. I just executed the original file and grabbed the decompressed byte array value for constant and moved the initializer in <module>.cctor. After that, i resolved the values of mutations. If i remember, there were sizeof, convert.toint32, math.(function) and int/short.parse. After the mutations, all you need to do is to convert the fields to locals, calli to call, resolve the delegates, and resolve and remove the proxy call delegates. You have to make your own approach on removing the proxy call delegates on this one. The values of the delegates are initialized at <module>.cctor. here's the result of what i did. (manually cleaned junk types). Unpackme_cleaned.exe screenshot:
  3. 1 point
    Hi, you dont need to parse the ASCII strings like "MZ" with each other.Just read the hex values and use them to compare it with any other values you did read in hex from any other file etc. You can use CFF Explorer to see whole PE infos at once.Maybe you wanna do or handle it like that too etc. greetz
  4. 1 point
    To clarify - I meant the "e_cblp" field you were asking about. You can put any value in it. "e_magic" of course has to be "MZ".
  5. 1 point
    asking me ? hope @Reza-HNA PM u.
  6. 1 point
    Is this a hidden feature of the protection or does the app just not work?
  7. 1 point
  8. 1 point
    Thought I might create a thread to collect articles/papers that bring machine learning to rce... https://medium.com/@alon.stern206/cnn-for-reverse-engineering-an-approach-for-function-identification-1c6af88bca43
  9. 1 point
    password: "viva la revolution" How the password verified? Here, check my entered password against the correct one, both encrypted. Obviously, the encrypted password at RVA 00011054 is 18 characters long. But, what is the encryption or decryption algorithm? Don't dive into that, instead I assume the algorithm is symmetrical. This time, I entered the right length password "123456789012345678". At entry of the subroutine, Ecx=004FF534, we can find the entered password at allocated buffer 008F0000: Copy and paste with the correct cipher password from RVA 00011054: 008F0000 12 EC C5 CB AC FC 86 96 23 7C 7D 57 46 5C 43 4F 008F0010 56 2D 2A 00 Run to the end of loop at 01323461, we got: 008F0000 12 76 69 76 61 20 6C 61 20 72 65 76 6F 6C 75 74 .viva la revolut 008F0010 69 6F 6E 00 ion.
  10. 1 point
    Can't you repost this challenge but with x64 version of vmp? (If you are struggling finding such a version pm-me)
  11. 1 point
    Perhaps It was about time I should share my tool with you guys. This is a Debugger and Devirtualizer for VMP virtualized code. Notice that When I mean devirtualizer, I mean it shows what machine instructions it executes (not the actual x86 original code). Allows you to debug and place breakpoints. Please try it, and if you like it, please develop it further. Confused? Read the intro.txt file and try to follow the example. VMPDBG_0_1_0_SRC.zip
  12. 1 point
    Frankly speaking, it's a challenging experiment I've never done before. I decided to take a try.On the WM_INITDIALOG message, a thread of which the lpStartAddress is 00401233 was created. The ThreadProc takes care of all the VK_1 ~ VK_7 keystrokes. This thread function itself is a loop, exits if user32.EndDialog flag set. vKey Functions00401259 E8 9F000000 CALL 004012FD ; VK_10040126F E8 E9000000 CALL 0040135D ; VK_200401285 E8 3F010000 CALL 004013C9 ; VK_30040129B E8 95010000 CALL 00401435 ; VK_4004012B1 E8 EB010000 CALL 004014A1 ; VK_5004012C7 E8 41020000 CALL 0040150D ; VK_6004012E0 E8 94020000 CALL 00401579 ; VK_7004012FD E9 24850000 JMP 004098260040135D E9 4F9B0000 JMP 0040AEB1004013C9 E9 2BC30000 JMP 0040D6F900401435 E9 3CD40000 JMP 0040E876004014A1 E9 C26B0000 JMP 004080680040150D E9 CD7E0000 JMP 004093DF00401579 E9 A9730000 JMP 00408927You can see, all jumps go to the ".vmp0" section, which means these functions are mutated or virtualized. Let's dive into several subroutines to look for something fun. As HellSpider stated, "most of the virtualized blocks of code are quite similar with each other." Procedures almost the same, call user32.wsprintfA to get the message and user32.MessageBoxA to display it. We focus mainly on how the "Control value" generated and on different features in the subroutine. ************* 004012FD VK_1 ************* Control Value: 0x04E6509A This part is for mutation demo, relative ease. Lots of branches VMProtect produced. Basically, all forks do identical operation, the result can be reached simply by tracing the main routine only. After demutation, the equivalent asm instructions look like: 004012FD C8 000100 ENTER 0x100, 0x000401301 60 PUSHAD00401302 9C PUSHFD00401303 BB 06000000 MOV EBX, 0x600401308 B8 E1020000 MOV EAX, 0x2E10040130D 33D2 XOR EDX, EDX0040130F F7FB IDIV EBX ; 05:7A00401311 83C2 03 ADD EDX, 0x3 ; 0800401314 92 XCHG EAX, EDX00401315 33C2 XOR EAX, EDX ; 7200401317 33D2 XOR EDX, EDX ; <- this seems useless00401319 69C0 B5000B00 IMUL EAX, EAX, 0xB00B5 ; 04E6509A0040131F 8D5C24 24 LEA EBX, [ESP+0x24]00401323 50 PUSH EAX ; Control value00401324 68 03214000 PUSH 0x402103 ; ASCII "VMProtect Mutation block has been executed!",CR,LF,CR,LF,"Control value: 0x%08X"00401329 53 PUSH EBX ; lpOut0040132A E8 E7020000 CALL 00401616 ; <JMP.&user32.wsprintfA>0040132F 83C4 0C ADD ESP, 0xC00401332 6A 40 PUSH 0x40 ; uType, combination of flags: MB_OK|MB_ICONASTERISK|MB_APPLMODAL00401334 68 5C204000 PUSH 0x40205C ; Title = "DevirtualzeMe"00401339 53 PUSH EBX ; Text: the message to be displayed0040133A FF75 08 PUSH DWORD PTR [EBP+0x8] ; hWnd of owner0040133D E8 F2020000 CALL 00401634 ; <JMP.&user32.MessageBoxA>00401342 9D POPFD00401343 61 POPAD00401344 C9 LEAVE00401345 C2 0400 RETN 0x4It can be considered as a template of the rest subroutines, only the algorithms of Control Value are different from each other. The only doubt here is Control Value algo. What is the mutation? "replacing the source instruction with its analog (or a certain instruction sequence), which gives the same result as the source instruction.", VMProtect officially claimed. So, I'm not very sure whether the control value algo does exist. Maybe the control value just PUSHed out there. It's hard to say, need HellSpider to confirm this.Note: the above patch works only when key '1' pressed, never stroke other number key, it crashes certainly. This area is full of the VM interpreter/handler code. ************* 0040135D VK_2 ************* Control Value: 0x0546416E Algorithm: 0000281B (= 00000009 ^ 00002812)0000281B ROR 3 = 60000503Low Byte 03 ^ 45(IMM) = 4660000546 SHL 10 = 0546000005460000 | 416E = 0546416EThis function is simply virtualized without additional options. Again, similar to mutation, it's also difficult to identify the primitive constants used in a target before getting protected. The only thing I can do is to guess from the hardcode immediates in this portion of virtualized bytecode. This part roughly covers 0x229 virtual machine instructions, not so complicated. ************* 004013C9 VK_3 ************* Control value: 0x0D619F21 Since virtualized with the "VM integrity check option", it's much sophisticated than the above. It's a painful journey, you’re gonna get brain-burned from this stuff!We trace the Control Value first. Here is an excerpt of virtual instructions executed for the Control Value calculation: HIWORD------StepNum. vEIP vOpcode Operand-------- ---- ------- -------000000C1 00407674: vPushImm4 8D175218000000C2 0040766F: vPushImm4 0040849E000000C3 0040766A: vPushImm4 ABD7E33F000000C4 00407665: vPushImm4 0040A816000000C5 00407660: vReadMemDs4 54281CC8 = [0040A816]000000C6 0040765F: vAdd4 54281CC8 + ABD7E33F = 00000007000000C8 0040765C: vPopReg4 vR1 00000007000000C9 0040765A: vReadMemDs4 72E8B450 = [0040849E]000000CA 00407659: vAdd4 72E8B450 + 8D175218 = 00000668000000CC 00407656: vPopReg4 vR14 00000668 dw [0040A816] = 54281CC8 + IMM32 ABD7E33F = 00000007 dw [0040849E] = 72E8B450 + IMM32 8D175218 = 00000668000000EE 0040761E: vIdiv4 00000000 00000668 / 00000007 = Q000000EA R00000002000001A7 004088E2: vAdd4 000000EA + 00000007 = 000000F10000029F 004088E2: vAdd4 000000EA + 000000F1 = 000001DB000003A3 00407FF9: vPushImm1 00000059000003A5 00407FF2: vPushImm4 80F30437000003C0 00407FB5: vReadMemDs4 7F0D323A = [00409269]000003C1 00407FB4: vAdd4 7F0D323A + 80F30437 = 00003671 dw [00409269] = 7F0D323A + IMM32 80F30437 = 00003671000003C4 00407FAF: vNand4 000001DB ~& 00003671 = FFFFC804000003C8 00407FAA: vNand4 FFFFC804 ~& FFFFC804 = 000037FB => 000001DB | 00003671 = 000037FB000003CB 00407FA5: vReadMemDs1 000000A9 = [0040882C]000003CC 00407FA4: vAdd1 000000A9 + 00000059 = 00000002 <- shift count b [0040882C] = A9 + IMM 59 = 02000003D1 00407F9D: vShrd 000037FB 000037FB >> 00000002 = C0000DFE 000037FB shrd 02 = C0000DFE <- *** byte3 0x0D shows up000003D4 00407F98: vPushImm1 00000059 IMM 59000003D5 00407F96: vPushImm4 0040862E000003D6 00407F91: vReadMemDs1 00000046 = [0040862E] b [0040862E] = 46000003D7 00407F90: vPushImm1 0000006F000003D8 00407F8E: vPushImm4 0040ADD1000003D9 00407F89: vReadMemDs1 000000A1 = [0040ADD1] b [0040ADD1] = A1000003DA 00407F88: vPushImm2 00006D8A000003DB 00407F85: vPushImm4 00410569000003DC 00407F80: vPushImm1 00000074 IMM 74000003DD 00407F7E: vPushImm4 0040BFD3000003DE 00407F79: vReadMemDs1 000000EC = [0040BFD3] b [0040BFD3] = EC + IMM8 74 = 60000003DF 00407F78: vAdd1 000000EC + 00000074 = 00000060000003E1 00407F75: vPushReg1 vR13LB 000000FE here vR13=C0000DFE(Step #000003D1)000003E2 00407F73: vPushReg1 vR13LB 000000FE000003E3 00407F71: vNand1 000000FE ~& 000000FE = 00000001000003E4 00407F70: vPopReg4 vR0 00000202000003E5 00407F6E: vNand1 00000001 ~& 00000060 = 0000009E000003E6 00407F6D: vPopReg4 vR0 00000282000003E7 00407F6B: vPushImm1 000000C9000003E8 00407F69: vPushImm4 00407567000003E9 00407F64: vReadMemDs1 000000D6 = [00407567]000003EA 00407F63: vAdd1 000000D6 + 000000C9 = 0000009F b [00407567] = D6 + IMM8 C9 = 9F000003EB 00407F62: vPopReg4 vR10 00000287000003EC 00407F60: vPushReg1 vR13LB 000000FE000003ED 00407F5E: vNand1 000000FE ~& 0000009F = 00000000000003EE 00407F5D: vPopReg4 vR7 00000246000003EF 00407F5B: vNand1 00000000 ~& 0000009E = 00000061 => 9F ^ FE = 61 <- *** byte2000003F0 00407F5A: vPopReg4 vR1 00000202000003F1 00407F58: vPopReg1 vR13LB 00000061 now vR13=C0000D61000003F2 00407F56: vReadMemDs2 00009276 = [00410569]000003F3 00407F55: vAdd2 00009276 + 00006D8A = 00000000000003F4 00407F54: vPopReg4 vR1 00000257000003F5 00407F52: vPushReg2 vR13LW 00000D61000003F6 00407F50: vPopReg4 vR1 00000D61000003F7 00407F4E: vAdd1 000000A1 + 0000006F = 00000010 b [0040ADD1] = A1 + IMM8 6F = 10 <- shift count000003F8 00407F4D: vPopReg4 vR10 00000213000003F9 00407F4B: vPushReg4 vR1 00000D61000003FA 00407F49: vShl4 00000D61 << 00000010 = 0D610000000003FB 00407F48: vPopReg4 vR5 00000206000003FC 00407F46: vPopReg4 vR0 0D610000 <- *** HIWORDLOWORD------000003FD 00407F44: vAdd1 00000046 + 00000059 = 0000009F b [0040862E] = 46 + IMM8 59 = 9F <- *** byte1000003FE 00407F43: vPushImm1 00000098000003FF 00407F41: vPushImm4 0040921D00000400 00407F3C: vReadMemDs1 00000089 = [0040921D] b [0040921D] = 89 + IMM8 98 = 21 <- *** byte000000401 00407F3B: vAdd1 00000089 + 00000098 = 0000002100000402 00407F3A: vPopReg4 vR10 00000A1700000403 00407F38: vPopReg1 vR0LB 00000021 now, vR0=0D61002100000404 00407F36: vPopReg4 vR10 00000A8600000405 00407F34: vPopReg1 vR0HB 0000009F now, vR0=0D619F21At this point we already have 0x405 steps, not yet including the two API calls. The computation process can be summarized and simplified as: 00000668 IDIV 00000007 => Quotient: 000000EA, Remainder: 00000002000000EA * 2 + 00000007 = 000001DB000001DB | 00003671 = 000037FB000037FB ROR 00000002 = C0000DFEC0000DFE ^ 9F = C0000D61C0000D61 SHL 00000010 = 0D6100000D610000 | 9F21 = 0D619F21The very important concept "VM integrity check" in VMProtect appears in the second half of virtualized code. There is an integrity check table. Each record in the table has a size of 9 bytes: DWORD - encrypted checking address RVABYTE - checking lengthDWORD - negative of the Valid HashChecking procedure: 1) generating a random number by vRdtsc handler 2) modulus operating the total records count of the table 3) multiplying it by the record size, got record offset in the table 4) decrypting address RVA in the record 5) computing the Hash by getHash(vCheck) handler 6) the result Hash + Valid Hash(NEG) + return address of vRet HandlerNoted here, the last step is the so-called "Silent Check"! No comparison, just a ADD operation! This implies that, if the integrity check failed, vRet will be lead to some unknown address, finally causing the application crash. Virtual instructions of this block: 00000444 00407EAC: vRdtsc 0000107E:804F0139 only LOWORD used00000451 00407E94: vNand2 32AA ~& FEC6 = 0111 ~32AA & 0139 = 011100000459 00407E83: vNand2 CDF1 ~& 0139 = 32060000045B 00407E80: vNand2 3206 ~& 0111 = CCE800000464 00407E6D: vDiv2 CCE8 / 002D = Q 048D R 001F CCE8 % 2D0000046B 00407E5E: vMul2 001F * 0009 = 00000117 idx * size = record ptr0000047B 00407E3A: vAdd4 0040642A + 00000117 = 00406541 offset in table0000048B 00407E17: vReadMemDs1 000000FA = [00406545] length: FA...000004C9 00407D95: vAdd4 B6B2EBF7 + 494D6A88 = 0000567F Offset RVA000004D0 00407D84: vAdd4 00400000 + 0000567F = 0040567F +Modulebase...000004D5 00407D7C: vCheck offset: 0040567F, length: 000000FA, Hash: A7563B85000004DE 00407D68: vReadMemDs4 58A9C47B = [00406546] NEG Hash stored in table000004DF 00407D67: vAdd4 58A9C47B + A7563B85 = 00000000 SHOULD BE ZERO!!!000004E0 00407D66: vPopReg4 vR3 00000257000004E1 00407D64: vAdd4 00000000 + 00401616 = 00401616 <- *** Silent Check000004E2 00407D63: vPopReg4 vR9 00000202 Address SHOULD BE Call user32.wsprintfA!!!000004E3 00407D61: vPushReg4 vR5 00000206000004E4 00407D5F: vPushReg4 vR0 0D619F21000004E5 00407D5D: vPushReg4 vR8 00000000000004E6 00407D5B: vPushReg4 vR2 00400000000004E7 00407D59: vPushReg4 vR15 000000EA000004E8 00407D57: vPushReg4 vR10 00C2FE84000004E9 00407D55: vPushReg4 vR7 00406541000004EA 00407D53: vPushReg4 vR4 004121F0000004EB 00407D51: vPushReg4 vR11 00C2FFA8000004EC 00407D4F: vPushReg4 vR0 0D619F21000004ED 00407D4D: vPushReg4 vR9 00000202000004EE 00407D4B: vRet 00401616 | <JMP.&user32.wsprintfA> [esp+00]: 0040E362 return address after call [esp+04]: 00C2FE84 out buffer [esp+08]: 004021A2 ASCII "VMProtect Virtualization (+ VM integrity check) block has been executed!",CR,LF,CR,LF,"Control value:..." [esp+0C]: 0D619F21 Control valueRandom Memory Check Table-------------------------Table address: 0040642A, Items: 0000002DItem. Offset <- Decrypt Length Hash Read <- NEG Hash Calc.#00000001: 00401302|BA017BA2 00000057 516DF676|AE92098A 516DF676#00000002: 00401362|BA0D7BA2 00000065 3290E84D|CD6F17B3 3290E84D...#00000020: 0040567F|B3B11BA2 000000FA A7563B85|58A9C47B A7563B85...#0000002C: 00406226|B025FBA2 000000FB 3C31C786|C3CE387A 3C31C786#0000002D: 00406321|B0055BA2 000000F6 A19E32E3|5E61CD1D A19E32E3Decrypt Algo. for Offset RVA: shrd 1F, ~, ++, shld 12, ~, ^6BA308FF, +B6B2EBF7Thereafter, the "VM Integrity Check" performed two times, each just before calling user32.MessageBoxA and vRet to return address of VK_3 subroutine.Have fun, see you.MistHill
  • Newsletter

    Want to keep up to date with all our latest news and information?
    Sign Up
×
×
  • Create New...