Jump to content
Tuts 4 You

[DevirtualizeMe] VMProtect 2.13.5


Recommended Posts

Posted (edited)

Hi.

I created an unpackme using VMProtect 2.13.5. The only task is to devirtualize the blocks of code that are virtualized.

There are 7 short functions. Each will execute when keyboard numbers 1-7 are pressed.

The functions are virtualized as follows:

1 - Only mutation with no additional options
2 - Virtualization with no additional options
3 - Virtualization with the VM integrity check option
4 - Virtualization with the register scrambling on VM exit option
5 - Virtualization with the hide constants option
6 - Virtualization with all 3 extra options
7 - Ultra mode (which means mutation + virtualization) with all 3 extra options

The purpose is more educational in the form of seeing how the different options affect the codeflow and to understand the VMP virtual machine in general. This means that most of the virtualized blocks of code are quite similar with each other. This is not meant to be an extra hard challenge. No additional tricks used.

The functions are short, ~20 asm instructions. The unpackme is coded in MASM.

devirtualizeme_vmp_2.13.5.rar

 

Edited by HellSpider
New forum layout fix.
  • Like 5
Posted

Thanks!will look tomorrow at this is there any possibility of making same concept unpackme but just with 


Themida,Enigma,Obisidium,SafeEngine?or some other VM support protector


Posted

Thanks!will look tomorrow at this is there any possibility of making same concept unpackme but just with 

Themida,Enigma,Obisidium,SafeEngine?or some other VM support protector

 

Absolutely. The only problem is that I do not have recent full versions any other VM protector than VMProtect.

 

As regarding to Oreans products, demo versions should be fine (correct me if I'm mistaken), but for example Obsidium does not allow usage of the virtual machine in the demo version. If I manage to get some recent versions of the other protectors, I'll post similar devirtualizeme apps.

 

So in case "someone knows something" regarding full versions of the named applications hit me a PM. :secret:

 

P.S. I don't know if you noticed this thread already.

  • Like 1
Posted

Absolutely. The only problem is that I do not have recent full versions any other VM protector than VMProtect.

 

As regarding to Oreans products, demo versions should be fine (correct me if I'm mistaken), but for example Obsidium does not allow usage of the virtual machine in the demo version. If I manage to get some recent versions of the other protectors, I'll post similar devirtualizeme apps.

 

So in case "someone knows something" regarding full versions of the named applications hit me a PM. :secret:

 

P.S. I don't know if you noticed this thread already.

maybe some angels can share their licenses just for his goal - btw im checked and it perfect for documentation and studying :)

of course code could been even smaller ^ ^

Posted

maybe some angels can share their licenses just for his goal - btw im checked and it perfect for documentation and studying :)

of course code could been even smaller ^ ^

 

Had to make a compromise between a small VM block and as many different instructions as possible. I like to include a variety of instructions in the VM block instead of just the usual MOV, PUSH and CALL styled code blocks. :)

Posted

Well, certain protector authors do not appreciate Unpackmes and Crackmes being protected by full versions of their products. DNGuard HVM is one such example, I'm sure there are more. ;-)

  • Like 1
  • 1 month later...
Posted (edited)

40c13d|POP_32 R7

40c13b|PUSH_32 3463029938

40c136|ADD N2, N1

40c135|POP_32 R0

40c133|POP_32 R5

40c131|POP_32 R9

40c12f|POP_32 R0

40c12d|POP_32 R4

40c12b|POP_32 R2

40c129|POP_32 R14

40c127|POP_32 R8

40c125|POP_32 R3

40c123|POP_32 R10

40c121|POP_32 R11

40c11f|POP_32 R1

40c11d|POP_32 R13

40c11b|PUSH_32 R11

40c119|PUSH_32 2876904829

40c114|PUSH_32 2876928084

40c10f|PUSH_32 42794868

40c10e|PUSH_32 4294967039

40c10b|PUSH_32 R11

40c109|PUSH_32 42794856

40c108|FETCH32 N1

40c107|NOR_32 N2, N1 ;CF

40c106|POP_32 R6

40c104|NOR_32 N2, N1 ;CF

40c103|POP_32 R6

40c101|POP_32 R1

40c0ff|PUSH_16 4

40c0fd|PUSH_32 R6

40c0fb|PUSH_32 4294967231

40c0f9|NOR_32 N2, N1 ;CF

40c0f8|POP_32 R12

40c0f6|SHR N1, BYTE N2

40c0f5|POP_32 R15

40c0f3|ADD N2, N1

40c0f2|POP_32 R12

40c0f0|FETCH32 N1

40c0ef|POP_32 R12

40c0ed|POP_32 R11

40c0eb|POP_32 R11

40c0e9|PUSH_32 R12

40c0e7|PUSH_32 42794872

40c0e6|FETCH32 N1

40c0e5|POP_32 R1

40c0e3|PUSH_32 42794872

40c0e2|FETCH32 N1

40c0e1|NOR_32 N2, N1 ;CF

40c0e0|POP_32 R11

40c0de|PUSH_32 1422223766

40c0d9|NOR_32 N2, N1 ;CF

40c0d8|POP_32 R11

40c0d6|PUSH_32 2872743529

40c0d1|PUSH_32 R1

40c0cf|NOR_32 N2, N1 ;CF

40c0ce|POP_32 R15

40c0cc|NOR_32 N2, N1 ;CF

40c0cb|POP_32 R15

40c0c9|POP_32 R11

40c0c7|PUSH_32 R0

40c0c5|PUSH_32 R12

40c0c3|PUSH_32 R10

40c0c1|PUSH_32 R8

40c0bf|PUSH_32 R3

40c0bd|PUSH_32 R2

40c0bb|PUSH_32 R12

40c0b9|PUSH_32 R9

40c0b7|PUSH_32 R0

40c0b5|PUSH_32 R14

40c0b3|PUSH_32 R6

40c0b1|PUSH_32 R5

40c0af|PUSH_32 831937358

40c0aa|ADD N2, N1

40c0a9|POP_32 R15

40c0a7|PUSH_32 R7

40c0a5|PUSH_32 R11

40c0a3|JUMP N1+N2

40e63c|POP_32 R1

40e63a|PUSH_32 3463029938

40e635|ADD N2, N1

40e634|POP_32 R3

40e632|POP_32 R4

40e630|POP_32 R2

40e62e|POP_32 R10

40e62c|POP_32 R3

40e62a|POP_32 R11

40e628|PUSH_32 42794848

40e627|FETCH32 N1

40e626|POP_32 R6

40e624|PUSH_32 R6

40e622|NOR_32 N2, N1 ;CF

40e621|POP_32 R14

40e61f|PUSH_32 1422223766

40e61a|NOR_32 N2, N1 ;CF

40e619|POP_32 R0

40e617|PUSH_32 R6

40e615|PUSH_32 2872743529

40e610|NOR_32 N2, N1 ;CF

40e60f|POP_32 R15

40e60d|NOR_32 N2, N1 ;CF

40e60c|POP_32 R5

40e60a|POP_32 R0

40e608|POP_32 R9

40e606|POP_32 R12

40e604|POP_32 R14

40e602|POP_32 R13

40e600|POP_32 R7

40e5fe|POP_32 R7

40e5fc|POP_32 R5

40e5fa|PUSH_32 R5

40e5f8|PUSH_32 R5

40e5f6|NOR_32 N2, N1 ;CF

40e5f5|POP_32 R8

40e5f3|PUSH_32 2303

40e5f0|NOR_32 N2, N1 ;CF

40e5ef|POP_32 R15

40e5ed|ADD STACK, 4

40e5ec|PUSH_32 R11

40e5ea|PUSH_32 42794876

40e5e9|POP_32 R8

40e5e7|PUSH_32 R10

40e5e5|PUSH_32 R12

40e5e3|PUSH_32 R13

40e5e1|PUSH_32 R9

40e5df|PUSH_32 42794860

40e5de|PUSH_32 16

40e5dc|ADD N2, N1

40e5db|POP_32 R11

40e5d9|PUSH_32 R8

40e5d7|PUSH_32 R3

40e5d5|PUSH_32 R14

40e5d3|PUSH_32 R5

40e5d1|PUSH_32 256

40e5ce|PUSH_32 8

40e5cc|PUSH_32 42794832

40e5cb|ADD N2, N1

40e5ca|POP_32 R7

40e5c8|PUSH_32 12

40e5c6|PUSH_32 42794828

40e5c5|ADD N2, N1

40e5c4|POP_32 R7

40e5c2|NOR_32 N2, N1 ;CF

40e5c1|POP_32 R11

40e5bf|ADD N2, N1

40e5be|POP_32 R11

40e5bc|PUSH_32 42794836

40e5bb|FETCH32 N1

40e5ba|NOR_32 N2, N1 ;CF

40e5b9|POP_32 R11

40e5b7|MOV STACK, N1

40e5b6|PUSH_32 9

40e5b4|POP_32 R11

40e5b2|PUSH_32 1638

40e5af|POP_32 R7

40e5ad|PUSH_32 R13

40e5ab|PUSH_32 42794580

40e5aa|FETCH32 N1

40e5a9|NOR_32 N2, N1 ;CF

40e5a8|POP_32 R9

40e5a6|PUSH_32 R13

40e5a4|PUSH_32 42794576

40e5a3|FETCH32 N1

40e5a2|NOR_32 N2, N1 ;CF

40e5a1|POP_32 R10

40e59f|NOR_32 N2, N1 ;CF

40e59e|POP_32 R9

40e59c|PUSH_32 R13

40e59a|PUSH_32 42794576

40e599|FETCH32 N1

40e598|NOR_32 N2, N1 ;CF

40e597|POP_32 R9

40e595|NOR_32 N2, N1 ;CF

40e594|POP_32 R10

40e592|POP_32 R9

40e590|PUSH_32 R9

40e58e|PUSH_32 42794580

40e58d|FETCH32 N1

40e58c|NOR_32 N2, N1 ;CF

40e58b|POP_32 R10

40e589|PUSH_32 R12

40e587|PUSH_32 42794576

40e586|FETCH32 N1

40e585|NOR_32 N2, N1 ;CF

40e584|POP_32 R2

40e582|NOR_32 N2, N1 ;CF

40e581|POP_32 R2

40e57f|POP_32 R2

40e57d|PUSH_32 R11

40e57b|PUSH_32 R7

40e579|PUSH_32 R9

40e577|IDIV N3

40e576|POP_32 R15

40e574|POP_32 R13

40e572|POP_32 R5

40e570|PUSH_32 4294962538

40e56b|PUSH_32 R15

40e569|PUSH_32 R5

40e567|PUSH_32 R13

40e565|PUSH_32 R15

40e563|PUSH_32 R8

40e561|PUSH_32 R0

40e55f|PUSH_32 42794556

40e55e|FETCH32 N1

40e55d|POP_32 R9

40e55b|PUSH_32 R9

40e559|NOR_32 N2, N1 ;CF

40e558|POP_32 R10

40e556|PUSH_32 434729460

40e551|NOR_32 N2, N1 ;CF

40e550|POP_32 R10

40e54e|PUSH_32 R9

40e54c|PUSH_32 3860237835

40e547|NOR_32 N2, N1 ;CF

40e546|POP_32 R12

40e544|NOR_32 N2, N1 ;CF

40e543|POP_32 R7

40e541|PUSH_32 R11

40e53f|PUSH_32 R14

40e53d|PUSH_32 R3

40e53b|PUSH_32 R2

40e539|PUSH_32 831937358

40e534|PUSH_32 R4

40e532|ADD N2, N1

40e531|POP_32 R12

40e52f|PUSH_32 R1

40e52d|POP_32 R10

40e52b|PUSH_32 3463029938

40e526|ADD N2, N1

40e525|POP_32 R7

40e523|POP_32 R6

40e521|POP_32 R1

40e51f|POP_32 R12

40e51d|POP_32 R2

40e51b|POP_32 R7

40e519|PUSH_32 42794556

40e518|FETCH32 N1

40e517|POP_32 R4

40e515|PUSH_32 42794556

40e514|FETCH32 N1

40e513|NOR_32 N2, N1 ;CF

40e512|POP_32 R14

40e510|PUSH_32 434729460

40e50b|NOR_32 N2, N1 ;CF

40e50a|POP_32 R3

40e508|PUSH_32 3860237835

40e503|PUSH_32 R4

40e501|NOR_32 N2, N1 ;CF

40e500|POP_32 R9

40e4fe|NOR_32 N2, N1 ;CF

40e4fd|POP_32 R9

40e4fb|POP_32 R14

40e4f9|POP_32 R11

40e4f7|POP_32 R0

40e4f5|POP_32 R15

40e4f3|POP_32 R9

40e4f1|POP_32 R5

40e4ef|POP_32 R5

40e4ed|PUSH_32 2108543307

40e4e8|PUSH_32 2108527337

40e4e3|PUSH_32 R15

40e4e1|PUSH_32 R15

40e4df|NOR_32 N2, N1 ;CF

40e4de|POP_32 R13

40e4dc|PUSH_32 R15

40e4da|PUSH_32 42794568

40e4d9|FETCH32 N1

40e4d8|NOR_32 N2, N1 ;CF

40e4d7|POP_32 R5

40e4d5|NOR_32 N2, N1 ;CF

40e4d4|POP_32 R3

40e4d2|POP_32 R5

40e4d0|PUSH_32 42794576

40e4cf|PUSH_16 4

40e4cd|PUSH_32 R3

40e4cb|PUSH_32 R3

40e4c9|NOR_32 N2, N1 ;CF

40e4c8|POP_32 R13

40e4c6|PUSH_32 4294967231

40e4c4|NOR_32 N2, N1 ;CF

40e4c3|POP_32 R8

40e4c1|SHR N1, BYTE N2

40e4c0|POP_32 R8

40e4be|ADD N2, N1

40e4bd|POP_32 R0

40e4bb|FETCH32 N1

40e4ba|POP_32 R5

40e4b8|POP_32 R4

40e4b6|POP_32 R0

40e4b4|PUSH_32 R5

40e4b2|PUSH_32 42794580

40e4b1|FETCH32 N1

40e4b0|POP_32 R13

40e4ae|PUSH_32 R13

40e4ac|NOR_32 N2, N1 ;CF

40e4ab|POP_32 R8

40e4a9|PUSH_32 2182268610

40e4a4|NOR_32 N2, N1 ;CF

40e4a3|POP_32 R0

40e4a1|PUSH_32 R13

40e49f|PUSH_32 2112698685

40e49a|NOR_32 N2, N1 ;CF

40e499|POP_32 R5

40e497|NOR_32 N2, N1 ;CF

40e496|POP_32 R0

40e494|POP_32 R0

40e492|PUSH_32 R11

40e490|PUSH_32 R1

40e48e|PUSH_32 R11

40e48c|PUSH_32 R12

40e48a|PUSH_32 R9

40e488|PUSH_32 R7

40e486|PUSH_32 R2

40e484|PUSH_32 R15

40e482|PUSH_32 R1

40e480|PUSH_32 R3

40e47e|PUSH_32 R3

40e47c|PUSH_32 831937358

40e477|PUSH_32 R6

40e475|ADD N2, N1

40e474|POP_32 R5

40e472|PUSH_32 R10

40e470|PUSH_32 R0

40e46e|JUMP N1+N2

40e875|POP_32 R7

40e873|PUSH_32 3463029938

40e86e|ADD N2, N1

40e86d|POP_32 R4

40e86b|POP_32 R11

40e869|PUSH_32 42794540

40e868|FETCH32 N1

40e867|POP_32 R5

40e865|PUSH_32 R5

40e863|NOR_32 N2, N1 ;CF

40e862|POP_32 R1

40e860|PUSH_32 2182268610

40e85b|NOR_32 N2, N1 ;CF

40e85a|POP_32 R2

40e858|PUSH_32 R5

40e856|PUSH_32 2112698685

40e851|NOR_32 N2, N1 ;CF

40e850|POP_32 R10

40e84e|NOR_32 N2, N1 ;CF

40e84d|POP_32 R1

40e84b|POP_32 R2

40e849|POP_32 R6

40e847|POP_32 R0

40e845|POP_32 R10

40e843|POP_32 R1

40e841|POP_32 R13

40e83f|POP_32 R3

40e83d|POP_32 R15

40e83b|POP_32 R9

40e839|POP_32 R4

40e837|POP_32 R4

40e835|PUSH_32 R6

40e833|PUSH_32 R6

40e831|NOR_32 N2, N1 ;CF

40e830|POP_32 R8

40e82e|PUSH_32 1

40e82c|NOR_32 N2, N1 ;CF

40e82b|POP_32 R4

40e829|POP_32 R12

40e827|PUSH_32 10258

40e824|PUSH_32 R13

40e822|PUSH_32 R12

40e820|PUSH_32 42794572

40e81f|FETCH32 N1

40e81e|NOR_32 N2, N1 ;CF

40e81d|POP_32 R6

40e81b|PUSH_32 1024

40e818|NOR_32 N2, N1 ;CF

40e817|POP_32 R6

40e815|POP_32 R4

40e813|PUSH_32 R4

40e811|PUSH_32 42794572

40e810|FETCH32 N1

40e80f|NOR_32 N2, N1 ;CF

40e80e|POP_32 R6

40e80c|PUSH_32 2303

40e809|NOR_32 N2, N1 ;CF

40e808|POP_32 R12

40e806|ADD STACK, 4

40e805|NOR_32 N2, N1 ;CF

40e804|POP_32 R14

40e802|PUSH_32 42794580

40e801|FETCH32 N1

40e800|NOR_32 N2, N1 ;CF

40e7ff|POP_32 R14

40e7fd|POP_32 R4

40e7fb|PUSH_16 3

40e7f9|PUSH_32 R4

40e7f7|PUSH_32 42794578

40e7f6|FETCH32 N1

40e7f5|SHR_64 <N1,N2>, BYTE N3

40e7f4|POP_32 R13

40e7f2|POP_32 R12

40e7f0|PUSH_16 186

40e7ee|PUSH_16 3

40e7ec|PUSH_16 3

40e7ea|NOR_16 ;CF

40e7e9|POP_32 R8

40e7e7|NOR_16 ;CF

40e7e6|POP_32 R6

40e7e4|PUSH_16 69

40e7e2|PUSH_16 3

40e7e0|NOR_16 ;CF

40e7df|POP_32 R4

40e7dd|NOR_16 ;CF

40e7dc|POP_32 R6

40e7da|POP_8 r12

40e7d8|PUSH_16 0

40e7d6|PUSH_16 1350

40e7d4|POP_32 R6

40e7d2|PUSH_16 16

40e7d0|PUSH_32 R6

40e7ce|SHL N1, BYTE N2

40e7cd|POP_32 R13

40e7cb|POP_32 R4

40e7c9|PUSH_16 65

40e7c7|PUSH_16 110

40e7c5|POP_8 r4

40e7c3|POP_8 r4

40e7c1|PUSH_32 42794584

40e7c0|POP_32 R0

40e7be|PUSH_32 R4

40e7bc|PUSH_32 4202824

40e7b7|PUSH_32 R0

40e7b5|PUSH_32 4238292

40e7b0|PUSH_32 4199958

40e7ab|PUSH_32 R13

40e7a9|PUSH_32 R10

40e7a7|PUSH_32 R4

40e7a5|PUSH_32 R1

40e7a3|PUSH_32 R3

40e7a1|PUSH_32 R0

40e79f|PUSH_32 R2

40e79d|PUSH_32 R15

40e79b|PUSH_32 R9

40e799|PUSH_32 R7

40e797|PUSH_32 R0

40e795|VM_OUTSIDE

409d38|POP_32 R14

409d36|PUSH_32 3463029938

409d31|ADD N2, N1

409d30|POP_32 R1

409d2e|POP_32 R4

409d2c|POP_32 R7

409d2a|POP_32 R13

409d28|POP_32 R11

409d26|POP_32 R6

409d24|POP_32 R3

409d22|POP_32 R0

409d20|POP_32 R1

409d1e|POP_32 R15

409d1c|POP_32 R9

409d1a|POP_32 R5

409d18|POP_32 R5

409d16|PUSH_32 12

409d14|PUSH_32 42794568

409d13|PUSH_32 4

409d11|ADD N2, N1

409d10|POP_32 R10

409d0e|ADD N2, N1

409d0d|POP_32 R12

409d0b|MOV STACK, N1

409d0a|PUSH_32 64

409d08|PUSH_32 4202588

409d03|PUSH_32 R6

409d01|PUSH_32 8

409cff|PUSH_32 R7

409cfd|ADD N2, N1

409cfc|POP_32 R2

409cfa|FETCH32 N1

409cf9|PUSH_32 4220393

409cf4|PUSH_32 4199988

409cef|PUSH_32 R12

409ced|PUSH_32 R15

409ceb|PUSH_32 R1

409ce9|PUSH_32 R0

409ce7|PUSH_32 R3

409ce5|PUSH_32 R6

409ce3|PUSH_32 R11

409ce1|PUSH_32 R13

409cdf|PUSH_32 R7

409cdd|PUSH_32 R6

409cdb|PUSH_32 R1

409cd9|VM_OUTSIDE

406724|POP_32 R4

406722|PUSH_32 3463029938

40671d|ADD N2, N1

40671c|POP_32 R7

40671a|POP_32 R14

406718|POP_32 R3

406716|POP_32 R6

406714|POP_32 R8

406712|POP_32 R0

406710|POP_32 R5

40670e|POP_32 R9

40670c|POP_32 R15

40670a|POP_32 R11

406708|POP_32 R1

406706|POP_32 R12

406704|POP_32 R2

406702|PUSH_32 256

4066ff|PUSH_32 8

4066fd|PUSH_32 42794576

4066fc|ADD N2, N1

4066fb|POP_32 R13

4066f9|ADD N2, N1

4066f8|POP_32 R13

4066f6|MOV STACK, N1

4066f5|POP_32 R10

4066f3|PUSH_32 R10

4066f1|PUSH_32 42794840

4066f0|FETCH32 N1

4066ef|NOR_32 N2, N1 ;CF

4066ee|POP_32 R12

4066ec|PUSH_32 2303

4066e9|NOR_32 N2, N1 ;CF

4066e8|POP_32 R13

4066e6|ADD STACK, 4

4066e5|POP_32 R1

4066e3|POP_32 R7

4066e1|POP_32 R13

4066df|POP_32 R9

4066dd|POP_32 R9

4066db|POP_32 R3

4066d9|POP_32 R2

4066d7|POP_32 R15

4066d5|PUSH_32 R13

4066d3|MOV STACK, N1

4066d2|POP_32 R0

4066d0|PUSH_32 42794880

4066cf|FETCH32 N1

4066ce|PUSH_32 42794876

4066cd|PUSH_32 8

4066cb|ADD N2, N1

4066ca|POP_32 R13

4066c8|MOV [N1], N2 //destroy both

4066c7|POP_32 R13

4066c5|PUSH_32 R10

4066c3|PUSH_32 R3

4066c1|PUSH_32 R2

4066bf|PUSH_32 R1

4066bd|PUSH_32 R15

4066bb|PUSH_32 R9

4066b9|PUSH_32 R8

4066b7|PUSH_32 R7

4066b5|PUSH_32 R0

4066b3|PUSH_32 R1

4066b1|PUSH_32 R5

4066af|vm_quit

Surprisingly enough my decompiler seems to be working even for this version of vmp! I will code a decent garbage cleaner and a gui too!

 

^function two!

Edited by xSRTsect
  • Like 3
  • 3 months later...
Posted

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     00408927

You 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    0x4

It 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 = 0546416E

This 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=0D619F21

At 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         = 0D619F21

The 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 Hash

Checking 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 Handler

Noted 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, +B6B2EBF7

Thereafter, 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
 

  • Like 7
  • Thanks 1
  • 4 weeks later...
Posted

Very impressive post, MistHill. :)

Nice to see some attempts on my VM challenges.

 

I'm posting the MASM source code for the first 3 functions below.

 

VK_1

Function_01            PROC argHandle:DWORD

pushad
pushfdsub esp,100hmov ebx,6h
push 2E1h
pop eax
xor edx,edx
and ecx,edx
idiv ebx
cmp edx,3h
jb @f
clc
add edx,3h
@@:
cld
xchg eax,edx
xor eax,edx
sub edx,edx
imul eax,0B00B5hmov ebx,esp
invoke wsprintf,ebx,addr lpFunc01Msg, eaxinvoke MessageBox,argHandle,ebx,addr lpAppName,MB_ICONINFORMATIONadd esp,100hpopfd
popadretFunction_01            ENDP

 

VK_2

Function_02            PROC argHandle:DWORD

pushad
pushfdsub esp,100hmov ebx,9h
push 666h
pop eax
xor edx,edx
and ecx,edx
idiv ebx
@@:
test edx,edx
je @f
add ebx,eax
dec edx
jmp @b
@@:
clc
cld
or ebx,2812h
ror ebx,3h
xor bl,45h
movzx ecx,bx
shl ecx,10h
mov ch,41h
mov cl,6ehmov ebx,esp
invoke wsprintf,ebx,addr lpFunc02Msg, ecxinvoke MessageBox,argHandle,ebx,addr lpAppName,MB_ICONINFORMATIONadd esp,100hpopfd
popadretFunction_02            ENDP

 

VK_3

Function_03            PROC argHandle:DWORD

pushad
pushfdsub esp,100hmov ebx,7h
push 668h
pop eax
xor edx,edx
and ecx,edx
idiv ebx
@@:
test edx,edx
je @f
add ebx,eax
dec edx
jmp @b
@@:
clc
cld
or ebx,3671h
ror ebx,2h
xor bl,9Fh
movzx edx,bx
shl edx,10h
mov dh,9Fh
mov dl,21hmov ebx,esp
invoke wsprintf,ebx,addr lpFunc03Msg, edxinvoke MessageBox,argHandle,ebx,addr lpAppName,MB_ICONINFORMATIONadd esp,100hpopfd
popadretFunction_03            ENDP
Posted

How do you even start unvirtualizing? How do you get past all that shit-ton of garbage instructions?


Posted

Experience and practise.


Posted

But where to start? When u get a piece of virtualized code, what are u lookin for first?


Posted (edited)

In lack of a automatisation this can be a very very boring job to do even you have the knowledge so is not reliable.

 

Edited by GIV
Posted

But could someone make some tut with any univrtualization, like themida, lookin at deathway's plugin its easy peasy, and such practical example would be soo useful


Posted

Extreme Coders in the other topic already gave you few links to tutorials. What's wrong with them?


Posted (edited)

kao: I've never seen VMProtect applications whose mutated or virtualized code got rebuilt. So, please, spare us the lecture with the links and reading documentation (even posts). It's a good thing there are knowledgeable people out there (like some in this or other related threads), but it only goes as far as that: showcasing that they've went that extra mile to understand the inner works. When it comes to actually putting the theory to practice, most responses are "you were already given links to x, y, z, can't you do it from there?" (when those links depict only the theoretical, not the factual).


 


So, please, do pin-point us to something more practical rather than theoretical. Am not talking about automations or scripts, but a proof of concept, dal capo al fine.


 


BR,


Sun


 


P.S.: MistHill here managed to rebuild mutate code, my bad :)


Edited by SunBeam
  • Like 3
Posted (edited)

Well i went through the links you provided, it was about some basic deobfuscation. But i wonder how MistHill did that thing... cant understand anything in his post, and there are no real examples anywhere... so how can i even start


Edited by Pancake
Posted

Well i went through the links you provided, it was about some basic deobfuscation. But i wonder how MistHill did that thing... cant understand anything in his post, and there are no real examples anywhere... so how can i even start

he deobfuscated the mutated code. vmp mutation is very primitive. check any sample with mutation. 

Posted (edited)

Conquest, you mean he just traced through the entire function and simply deobfuscated it? I actually tried to run trace and it takes forever (i wrote my own dll which traces with trap flag). Oh i need to modify it not to step into dlls, and then i will see how many steps will it take

 

Indeed the first trace was very simple :) Goin to try another

 

In second VM im gettin crash, because one return returns to invalid address. When ran legally, the return at address 405925 is executed 2 times - first to call messagebox and second to return to the code. When tracing, the flow before the return looks like that: there are the "ret call call call" sequences with same addresses, and suddenly there is wrong address and program crashes. is it some anti trace or im doin smth wrong?

 

 

Return from 405583 to 4061C2
Call from 406169 to 4013CE
Call from 40604A to 4048F1
Call from 404917 to 405571

Return from 405583 to 4061C2
Call from 406169 to 4013CE
Call from 40604A to 4048F1
Call from 404917 to 405571

Return from 405583 to 4061C2
Call from 406169 to 4013CE
Call from 40604A to 4048F1
Call from 404917 to 405571

Return from 405583 to 4061C2
Call from 406169 to 4013CE
Call from 40604A to 4048F1
Call from 404917 to 405571

Return from 405583 to 4061C2
Call from 406169 to 4013CE
Call from 40604A to 4048F1
Call from 404917 to 405571

Return from 405583 to 4052AB
Return from 405925 to D17C848B < crash

 

Thanks in advance

Edit: it seems like the sequence:

 

Return from 405583 to 4061C2
Call from 406169 to 4013CE
Call from 40604A to 4048F1
Call from 404917 to 405571

 

resolves the VMhandler address [EAX*4+0x404AB5] , XOR with 0x32F56883, and the return 405583 returns to that address. But still cant figure out why it does the Return from 405925 to D17C848B which crashes - any help is appreciated :) Im tryin my best to understand VMs indepth

Edited by Pancake
Posted (edited)

I know the pushfd / pushss or rep anti-step tricks. i did not patch them in my tracer, goin to do it asap and try it then.


 


So the patch will be: when i step on pushfd i execute that command and on next command i patch the dword pointed by esp with NOT 0x100.


 


Well i did it but still gettin same crash. Did anyone successfuly trace through 2nd?


Edited by Pancake
Posted

@Pancake we have a pathetic game called mooplstory. there the devs have some kind of morbid fascination about obfuscating critical routines to hinder reversers from actually making localhost of their poorly coded game. Unfortunately , this doesnt stop the reversers from doing that. We routinely restore the critical functions and send functions from the mutated codes to restore back the original functions. good thing is that unlike themida, vmp's vm is very premature and once you know the original routine in gist, you can grab the constants out of the vm either by manual emulation or by fishing.  As you can see , using vms to hide your code is probably the lamest excuse to hide the fact that you cannot do a proper job.
you might be thinking what kind of tool we use, we dont even use any tool . simple scripts to log values solves the problem for us. I was reversing themida a few months ago and i can tell you one thing, deathway's job was way tougher than creating a vmp unvmer. 

Posted

I just wrote that my own tracing dll (which i coded just for me), the VM makes that weird return, and all i want to know is why, because i simply cant figure it out. And i also stated that im completly new to VMs and im not lookin for ready tools and i never will be, so i compeltly dont understand your post. Im tryin this and that, not knowing if it will work or fail, and im just asking for some guidance...


Posted

I just wrote that my own tracing dll (which i coded just for me), the VM makes that weird return, and all i want to know is why, because i simply cant figure it out. And i also stated that im completly new to VMs and im not lookin for ready tools and i never will be, so i compeltly dont understand your post. Im tryin this and that, not knowing if it will work or fail, and im just asking for some guidance...

VMP has quite some definite reports written about it . some of them are available on the forum. most importantly the ones written by rolles . The description is still valid(though i saw a few posts on vmp forum about restructuring the vm on v3 onwards) . You can study the available unvming tools for other apps, most prominently, the one by dizzyd . deathway released the source of his tool in its early days (no exactly complete tool source but the parsers and lexical analyser). also look at the gcc and llvm source code for deobfuscating hints and .net source codes for details on their implementation of stack based vm for x86. 

 

currently i havent associated myself with hacking in about past 3 months due to issues in real life so i couldnt remember all the details. if possible i will add more as i will come by them .

Posted (edited)

Thats a hell of a list. Thanks

 

Today i spent a lot of time on it and i must say i picked up a lot about that VM software. Unvirtualized and deobfuscated handler responsible for call instruction, overwrote handler addresses and indeed it worked :) I can say that I see general patterns here. I created the sniffer in DLL (inline hook in main VM handler).

 

I want to go forward, so thats a little question to all the great people here :)

 

Now i must somehow undertand the PCode pointed by ESI.

There are 0x100 entries in the handlers table. As far as i understand, each is responsible for handling particural instruction, like in my case handlers[0x1D] was responsible for CALL sprintf, CALL MessageBoxA and "VM EXIT" (maybe its jut RET and not CALL i guess?). At the entry point of the 0x1D handler the call address is already on the stack, so most probably handler before prepared the call address. There are a lof ot 0x20 handlers. I add a small log of the handlers id and pcode (licznik = counter in my lang). Thanks everyone again for such quick answers! Day ago i was terrified when i saw a VM :D Now im... a boss :D

So now im goin back to work :)

I think i will check the handlers before invoking the msgbox.

I also wonder where he stores the context (registers, flags), that will be my second task.

 

Licznik 1020 Handler address 405E50 Handler ID 15 PCode 47
Licznik 1021 Handler address 404A4D Handler ID 6E PCode F4
Licznik 1022 Handler address 4061C2 Handler ID BF PCode 97
Licznik 1023 Handler address 405E50 Handler ID 15 PCode 19
Licznik 1024 Handler address 4061C2 Handler ID BF PCode 67
Licznik 1025 Handler address 404EB5 Handler ID 17 PCode 23
Licznik 1026 Handler address 404430 Handler ID 47 PCode CD
Licznik 1027 Handler address 40134E Handler ID 61 PCode 9C
Licznik 1028 Handler address 404A4D Handler ID 5E PCode 1C
Licznik 1029 Handler address 404A4D Handler ID 5E PCode D5
Licznik 1030 Handler address 4061C2 Handler ID BF PCode A6
Licznik 1031 Handler address 4061C2 Handler ID EA PCode 34
Licznik 1032 Handler address 4061C2 Handler ID 20 PCode 60
Licznik 1033 Handler address 4061C2 Handler ID 20 PCode 70
Licznik 1034 Handler address 4061C2 Handler ID 20 PCode A4
Licznik 1035 Handler address 4061C2 Handler ID 20 PCode 7C
Licznik 1036 Handler address 4061C2 Handler ID 20 PCode A0
Licznik 1037 Handler address 4061C2 Handler ID 20 PCode 5C
Licznik 1038 Handler address 4061C2 Handler ID BF PCode 0F
Licznik 1039 Handler address 4061C2 Handler ID 20 PCode 07
Licznik 1040 Handler address 4061C2 Handler ID 20 PCode 43
Licznik 1041 Handler address 4052AB Handler ID 1D PCode C9 <-- calls MessageBoxA

Edited by Pancake
  • Thanks 1

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...