Washi

@washi@infosec.exchange
106 Followers
22 Following
26 Posts

#AsmResolver 6.0.0-beta.4 released!

This release addresses many shortcomings found during beta.3, including ARM32 and ARM64 support, auto references importing, and many other DX improvements.

馃憠 Get it on GitHub or NuGet: https://github.com/Washi1337/AsmResolver/releases/tag/v6.0.0-beta.4

#dotnet #pe #reversing

Release 6.0.0-beta.4 路 Washi1337/AsmResolver

It's been a while since the last beta.3 release, and the main reason for this has been that beta.3 saw many more testers actively trying out v6.0.0 and pushing it to its limits. Beta.4 addresses ma...

GitHub

After #flareon11 challenge 7, I got inspired to build tooling for #dotnet Native AOT reverse engineering.

As such, I built a #Ghidra Analyzer that can automatically recover most .NET types, methods and frozen objects (e.g., strings).

馃憠https://blog.washi.dev/posts/recovering-nativeaot-metadata/

Recovering Metadata from .NET Native AOT Binaries

Ever seen a binary that looks like a .NET binary based on its strings, but .NET decompilers are not able to open them?

Washi

#AsmResolver 6.0.0-beta.3 just got pushed to NuGet!

More bugs were found and squashed. We are closing in on a full release with most of the public API being stable.

Get it on GitHub or NuGet 馃憠 https://github.com/Washi1337/AsmResolver/releases/tag/v6.0.0-beta.3

#dotnet #pe #reversing

Release 6.0.0-beta.3 路 Washi1337/AsmResolver

This is a maintenance release. AsmResolver is closing in on a main release with most of the public API being stable. However, similar to 6.0.0-beta.2, this is still a pre-release and some of the pu...

GitHub

#AsmResolver 6.0.0-beta.2 has been released

This is a maintenance release that addresses many regressions introduced by the refactors in 6.0.0-beta.1.

Get it on NuGet or GitHub
馃憠 https://github.com/Washi1337/AsmResolver/releases/tag/v6.0.0-beta.2

Release 6.0.0-beta.2 路 Washi1337/AsmResolver

This is a maintenance release that fixes some shortcomings and addresses various regressions introduced by the refactors in 6.0.0-beta.1. Similar to 6.0.0-beta.1, this is an unstable release and th...

GitHub

I just published my writeups for all challenges of #flareon11:

馃憠 https://blog.washi.dev/posts/flareon11/

馃憠 https://washi1337.github.io/ctf-writeups/writeups/flare-on/2024/

Hope you like them as much as I liked writing them!

Flare-On 11 Write-Ups

Today a short post.

Washi
CrowdStrike Global:Offensive

#AsmResolver 5.5.1 is out!

This is a maintenance release, adding #dotnet 8.0 targets and fixes issues related to type signatures, CIL optimizations, as well as some rare edge cases in .NET metadata directory parsing.

Get it on GitHub/NuGet:
馃憠 https://github.com/Washi1337/AsmResolver/releases/tag/v5.5.1

Release 5.5.1 路 Washi1337/AsmResolver

This is an incremental maintenance release that adds .NET 8.0 as an official target and fixes issues related to type signatures, CIL optimizations, as well as some rare edge cases in .NET metadata ...

GitHub

@cxiao @still Unfortunately, there's not really a golden rule. Different obfuscators encrypt/decrypt CIL in different ways.

My go-to advice would be to always look at the module initializer (<Module>::.cctor) first. If that is readable in e.g., dnSpy but the remainder of the methods isn't, usually it means this cctor is trying to either A) decrypt all other methods or B) set up some kind of JIT hook to decrypt methods on-the-fly as methods are being JIT'ed.

Option A is the easiest to deal with: You can just step over the lines of this .cctor, and just dump the entire module using dnSpy/ExtremeDumper/WinDbg/x64dbg and then open it in your favourite decompiler (after potentially fixing some PE headers). Option B) is harder, you'll have to trigger the JIT for every method and hook into the JIT compiler itself to catch the compiled CIL code. There are JIT dumper tools out there that do this (e.g., https://github.com/Anonym0ose/JitDumper), but obfuscators like DNGuard make that hard to work out-of-the-box. I usually just look at the generated code instead then, whilst having a close look at called BCL methods and the object heap.

As for tools, Harmony is powerful but also has issues from my experience, mainly because it relies on loading the target assembly with Reflection which many obfuscators know how to prevent. dnSpy(Ex) has improved quite a bit though over the years, it can nowadays view the JIT'ed assembly of a method during execution (right click "View Disassembly" during execution). But WinDBG is kind of the tool that always just works^tm, provided that you know how to bend it to your will (which can be a real pain sometimes). Can recommend the series by UbbeLol on some basics of windbg+sos (https://www.youtube.com/watch?v=q-IWHHFQcXg&list=PL4A8A31D0204239A5&index=2), although they are a bit dated by now probably. Mostly the way I learnt to work with it was to "just f*ck around" with my own samples in WinDbg. The good news is that .NET binaries are still executables that eventually run x86 code, so a lot of the standard RE strategies should still work.

There seems to be a bit of a lack of up-to-date content on this to be honest (maybe good ideas for new blog posts :^)). Regardless, I hope this gives some pointers :).

GitHub - Anonym0ose/JitDumper

Contribute to Anonym0ose/JitDumper development by creating an account on GitHub.

GitHub

Did you know you could write entire #csharp programs just by using the "await" keyword?

OK, well not really, but I spent some weekends developing AwaitFuscator: A (dumb) #obfuscator that turns your #dotnet program into nothing but "await" expressions!

馃憠https://blog.washi.dev/posts/awaitfuscator

Awaiting the Awaitables - Building the AwaitFuscator

Here is a scenario you probably have never encountered. Have you ever decompiled a .NET binary that only consists of a bunch of await keywords and nothing else?

Washi

"Noo! Ghidra has such a bad UI! IDA is much better!"

Explain to me: In what world does a hex view need column selection that crosses multiple columns (and beyond) and disappears upon scrolling?

The decompiler may be good but I genuinely don't see how people put up with IDA's UI.