.NET Reactor v6.5.0.0

[whoknows]

View File

.NET Reactor v6.5.0.0

---

Try to unpack or alternatively provide a serial.

Protections used:

• Necrobit
• Antitampering
• Antidebug
• Obfuscation
• Code Virtualization

+ Shield with SNK

Whats new in .NET Reactor [6.5.0.0] 12-Nov-2020

• Fixed 'Code Virtualization' issue
• New 'Anti Tampering' approach
• and more..

---

• Submitter
  whoknows
• Submitted
  11/29/2020
• Category
  UnPackMe (.NET)

 

[Rift]

Serial: TGlmZSBpcyBCZWF1dGlmdWw4MWEzNzBjOS03MzU2LTQzNWEtODhlNi1mY2VhNDJjMzQ2MGQ

In short:

var str = String.Concat("Life is Beautiful","81a370c9-7356-435a-88e6-fcea42c3460d");

var b = Encoding.GetBytes(str);

var b64 = ToBase64String(b);

var serial = b64.Replace("=","");

 

Thank you, whoknows!

- Rift

[whoknows]

for the history. 13 lines of code and these settings :

w/o the success picture

the pure app :

the secure pure w/o the success picture :

-----------------------------------------------------------------------------

w/ success picture

the pure app :

the secured app w/ success picture :

 

 

 

 

[whoknows]

View File

.NET Reactor v6.5.0.0 (v2)

---

Try to unpack or alternatively provide a serial.

Protections used:

• Necrobit
• Antitampering
• Antidebug
• Obfuscation
• Code Virtualization

+ Shield with SNK

--

whats new on v2

• Obfuscation (turn on to Public Types  + All method parameters)
• Hide internal/external method calls (produces delegates)

---

• Submitter
  whoknows
• Submitted
  12/02/2020
• Category
  UnPackMe (.NET)

 

Edited December 6, 2020 by Teddy Rogers

[Rift]

Nice.

However, pretty much the same (concerning the protection).

There are four possible serials. I'll provide one of them, in case others want to try the challenge out.

Valid serials are xored by 0x03 and the resulting string is compared against the user input.

Valid Serial (2nd in the list)

Zlv#wtl#kbg#b#ajd#ejdkw#obpw#mjdkw/#gjgm$w#zlv<TjmgltpElqnpBssoj`bwjlm72

 

I admit that a technique for statically devirtualize the methods would be really useful. There are .NET malware that use .NET Reactor to obfuscate the code.

Thanks whoknows!

Edited December 2, 2020 by Rift

[Sh4DoVV]

10 hours ago, Rift said:

Nice.

However, pretty much the same (concerning the protection).

There are four possible serials. I'll provide one of them, in case others want to try the challenge out.

Valid serials are xored by 0x03 and the resulting string is compared against the user input.

Valid Serial (2nd in the list)

Zlv#wtl#kbg#b#ajd#ejdkw#obpw#mjdkw/#gjgm$w#zlv<TjmgltpElqnpBssoj`bwjlm72

 

I admit that a technique for statically devirtualize the methods would be really useful. There are .NET malware that use .NET Reactor to obfuscate the code.

Thanks whoknows!

Hi

May you explain about devirtualize and unpacking of this ?

[whoknows]

I will come back with v3

[Taitor]

23 hours ago, Rift said:

Valid serials are xored by 0x03 and the resulting string is compared against the user input.

Valid Serial (2nd in the list)

Please post technique used for reversing it. Mods, this was discussed in the past, no? Solutions without technique should not be approved in this section?

[Rextor]

for stable crack you need come back to 20 years ago... yes, exactly 2000

then if you change the file name to anything else, your serial will be stable code,

but only 4 valid serial available, for example:

Quote

Kf#wkqft#vs#jm#wkf#wqbpk#`bm\"ffaf`;f4.0:6;.76e6.a6fb.`36b;42a4g:f

also, if you don't want travel in the time, you need make your valid serial based on 'EXE' file name

if you using "WindowsFormsApplication41" your valid serial can be:

Quote

Kf#wkqft#vs#jm#wkf#wqbpk#`bm"TjmgltpElqnpBssoj`bwjlm72

if you want generate more by yourself you can devirtualize file by yourself

if not, just write a keygen by this picture:

Quote

enjoy

[whoknows]

excellent @Rextor

[whoknows]

View File

.NET Reactor v6.5.0.0 (v3)

---

Try to unpack or alternatively provide a serial.

Protections used:

• Necrobit
• Antitampering
• Antidebug
• Obfuscation
• Code Virtualization

+ Shield with SNK

+ Helper DLL

---

• Submitter
  whoknows
• Submitted
  12/05/2020
• Category
  UnPackMe (.NET)

 

Edited December 6, 2020 by Teddy Rogers

[BataBo]

On 12/5/2020 at 4:12 PM, whoknows said:

View File

.NET Reactor v6.5.0.0 (v3)

---

Try to unpack or alternatively provide a serial.

Protections used:

• Necrobit
• Antitampering
• Antidebug
• Obfuscation
• Code Virtualization

+ Shield with SNK

+ Helper DLL

---

• Submitter
  whoknows
• Submitted
  12/05/2020
• Category
  UnPackMe (.NET)

 

Like v1 and v2 v3 had a 4 serial challenge  for sentences that we start with in this file are:"The chairs made a loud noise when we sat down on them.","Are you cold?","How big an idiot do you think I am?","Do you eat ice cream?", unlike v2 if the year is 2000 it will get the filename without extension and if not it will return "eebec8e7-3958-45f5-b5ea-c05a871b7d9e " then one of those 4 strings are combined with the value returned from the method with DateTime thing and then each character is xored with value 50 now, I'm not sure if this is by design but 4 strings serial challenge is impossible to solve because if space which has value of 32 is xored with value of 50 we will get value of 18 and if we then look into ascii table we can see that character with value of 18 is not printable or in other words you can't type it into the textbox making it impossible to solve.But unlike v2 v3 has another challenge that is solvable, first thing that is done is a method is called it takes 2 parameters a string and an integer the value of the string in this case is "mahone" and the number is 78562 then the program gets first character from the string in this case 'm' and does the following:

((number from argument)*(length of string from argument))+(666*(first character)) in this case the result is 543966
(number from argument)*(first character)*123 in this case the result is 1053280734
(6613*(first character)*(length of string from argument))+(number from argument) in this case the result is 4403464
Then these values are concatenated with "-" to make "543966-1053280734-4403464" 
Then "-" are removed and the string is reversed to get value "46430444370823501669345" which is the password

I'd just like to note that I didn't try to crack v1 and v2 and all I know about them is from the posts above.

 

[whoknows]

hi and thanks for your time, all correct^, ^please try to dig on the latest v3 revisionC from the link above as edited @ 

Quote

Edited Sunday at 03:36 PM by Teddy Rogers

 

[BataBo]

1 hour ago, whoknows said:

hi and thanks for your time, all correct^, ^please try to dig on the latest v3 revisionC from the link above as edited @ 

 

Hi, I don't have much free time so I probably won't look into it.The same password for v3 works for v3c so make sure you uploaded the right file 

[whoknows]

Quote

The same password for v3 works for v3c

this is true! but the technic is dff!

[Rift]

On 12/4/2020 at 9:10 PM, Rextor said:

for stable crack you need come back to 20 years ago... yes, exactly 2000

then if you change the file name to anything else, your serial will be stable code,

but only 4 valid serial available, for example:

also, if you don't want travel in the time, you need make your valid serial based on 'EXE' file name

if you using "WindowsFormsApplication41" your valid serial can be:

if you want generate more by yourself you can devirtualize file by yourself

if not, just write a keygen by this picture:

enjoy

I also have to say that i'm impressed by the result. Excellent indeed.

Since there is knowledge and maybe tools, sharing the method or the tools (as @SychicBoy did for his control flow deobfuscator) would be great for the community.

Personally, in solving the challenge, when dealing with this kind of obfuscators, I hook UnsafeInvokeInternal and get the result, This indeed works. In this case the challenge are simple so reversing the logic is also.

However to properly reconstruct the assembly a different approach is obviously needed.

About the Necrobit protection, what maybe is already known, and I found out:

In the Module constructor, a hashtable is built after the resource containing the real MSIL body has been decrypted.

Then each index in the hashtable is passed to another method that natively writes the real MSIL opcodes in memory.

What I tried is using Reflection to dump the hashtable after has been populated. I get an offset (relative to method body offset) and the MSIL bytecode.

However I am stuck in reversing the process, that is parsing the bytecode, get ILCode back and write it successfully to the assembly.

[Inception]

On 12/9/2020 at 1:02 PM, Rift said:

I also have to say that i'm impressed by the result. Excellent indeed.

Since there is knowledge and maybe tools, sharing the method or the tools (as @SychicBoy did for his control flow deobfuscator) would be great for the community.

Personally, in solving the challenge, when dealing with this kind of obfuscators, I hook UnsafeInvokeInternal and get the result, This indeed works. In this case the challenge are simple so reversing the logic is also.

However to properly reconstruct the assembly a different approach is obviously needed.

About the Necrobit protection, what maybe is already known, and I found out:

In the Module constructor, a hashtable is built after the resource containing the real MSIL body has been decrypted.

Then each index in the hashtable is passed to another method that natively writes the real MSIL opcodes in memory.

What I tried is using Reflection to dump the hashtable after has been populated. I get an offset (relative to method body offset) and the MSIL bytecode.

However I am stuck in reversing the process, that is parsing the bytecode, get ILCode back and write it successfully to the assembly.

Hey! I made a blog post about this, if you wanna check out how you can parse and replace the CIL code. https://0xinception.github.io/defeating-reactors-necrobit/

[Cursedzx]

Fully unpacked V3:

 

So I noticed that the dll and the executable are both protected with .NET Reactor. The dll has 5 virtualized methods. The purpose of that is probably to prevent people from cracking the unpackme. 

Since this is not a crackme, I have decided to fully unpack cuz I have a lot of free time to do it.
I just dragged the files to my deobfuscator so I'll just explain the steps of what my deobfuscator did to deobfuscate the contents of the unpackme.

 

1. Get rid of the code flow obfuscation. You can use Hussaryn/NET-Reactor-Cflow-Cleaner-6.7.0.0 since this one is updated. I haven't tested this one though so I am not sure.

2. Detect necrobit and read encrypted method bodies in resources. The method bodies are stored in resources and the decryption routine has a part in the code that has a random generated mutation. The trick to that is using a CIL emulator. I use DNEmulator, but the repository is gone. I think De4dot emulator is good enough for this one.

3. Do step 1 again since it might have control flow obfuscation applied to some methods.

On 8/7/2021 at 5:28 AM, Inception said:

Hey! I made a blog post about this, if you wanna check out how you can parse and replace the CIL code. https://0xinception.github.io/defeating-reactors-necrobit/

You could also read this blog and use reflection to get the decrypted method bodies. It is explained where .NET Reactor stores its decrypted method bodies. But I am not a fan of using reflection, so I don't want that. I guess this should work on most unpackmes but not all since it is lacking something. 

4. Detect obfuscated ldtokens. The obfuscated token is not really obfuscated. It is just stored as an integer and some function resolves the token and returns the runtimetypehandle of that.

5. Detect and devirtualize virtualized functions. I learned a lot from @TobitoFatito's explanation. 

The Instruction Set Architecture of .NET Reactor VM is almost the same as .NET CIL. So it should be easy to understand the VM if you already understand .NET CIL.

6. Do step 1 again since it might have control flow obfuscation applied to some devirtualized methods.

7.  Detect and decrypt string encryption. The decryption routine is similar to necrobit decryption routine and the encrypted string data is stored in resources. Once the resources data is decrypted, you can find the calls that's using the decryption method and get the string data by acquiring the first argument and using that to go to the offset of the decrypted data and read the first 4 bytes and convert it to int32 to get the string length. Then read string data after the string length data.

8. Detect and decrypt resource encryption. The resources has more than 1 decryption mode and it is also compressed. I think the method that de4dot uses for this one still works. Code: ResourceResolver.cs

9. Use de4dot to clean the rest and fix names.

 

Files:
 

WindowsFormsApplication41-Deobfuscated-cleaned.exe WindowsFormsApplication41yippi-Deobfuscated-cleaned.dll

Edited August 8, 2021 by Cursedzx

[BlackHat]

Cleaned all file without touching file manually and I think the restored code looks like very close to original. 

WindowsFormsApplication41yippi-cleaned.dll whoknows6.5_v3-cleaned.exe whoknows6.5_v2-cleaned.exe whoknows6.5_v1-cleaned.exe