First of all, i'm trying to learn reverse engineering for testing my codes and that's all and i'm not stupid enough to do illegal things with my knowledge so please don't give me legal advises.

I'm trying to crack an application that is written in C# and what all i wanna do is to find the assembly location of an if statement that checks for a license file which i believe i can bypass the license just but jumping over the if statement but i can't figure out how to do with IDA Pro or X64dbg. i'm not sure if i can do that or not because C# is byte code right? and bypass it through assembly may cause other crashes in the application. i tried dnSpy and ILSpy thanks to the friend in the comments.

i was able to decompile the application and access the codes and i even found the if statement in the decompiled codes with JetBrains dotpeek and Visual Studio

verbose mode: this application first checks for license and then checks for a hardware lock and i believe i can bypass them by jmp and nop in assembly cause after decompiling the application i spotted where the application looks for license and hardware lock and i saw guided hacking did the same using x64dbg. the problem is i don't know the tools to do it for C# application and the codes are like hashed. let me show you in a picture maybe it's not hashed i'm just a newbie: decompiled source screenshot this is the reason i can't compile the code again

| improve this question | | | | |
New contributor
  • For .NET executables I would rather suggest to debug on the bytecode level using tools such as ILSpy or dnSpy instead of looking at the assembly level with x64dbg. – morsisko May 20 at 23:07
  • @morsisko let me try – Ebrahim Karimi May 20 at 23:17
  • ok, so far what i've seen is just decompiling, waht i need is to change the executable, remove and add codes @morsisko – Ebrahim Karimi May 20 at 23:20
  • using dnSpy you can change the code inside the dnSpy application, using ILSpy you can for example export everything to new C# project and then patch the instructions in your IDE. – morsisko May 20 at 23:23
  • dnSpy is amazing cause i can debug from decompiled executable but still can't compile the project because i obfuscated the codes and thats why i decided to do it in assembly level @morsisko – Ebrahim Karimi May 20 at 23:36

reading your question several times and the discussion in the comments i did not understand what you're trying to get/obtain, so i will be answering to parts that i think that are relevant according to the problems you posed. maybe other and more experienced people here would help elaborate and improve:

if you're trying to "reverse" an interpreted code, .net in this case, i think the best way to do so is using dnspy, as it gives you pretty much all that you need to understand the logic, patch and change things accordingly and deal with obfuscation and similar operations.

now you said you're struggling with obfuscation, but obfuscation is just a way to mislead the user doing the reversing. meaning you can, sometimes with great effort, to understand what's going on behind the scenes, change variable names and function names accordingly, to make it more "logical" to you. using a decompiler can also help you see the bigger image, but it's mostly about filling the gaps, bit and bit. what i usually do in situations like that, i try to find the calling functions and trying to understand what they do, the logic behind them, what parameters they use and why, and i go with the simplest path, meaning: sometimes if function contains a lot misleading paths, but it's easier to infer the logic from the variables, you can understand what the function does, name the variables correctly, and then go over to understand the function and its implementation to avoid wasting time on dead paths(though you can check coverage to understand what parts of the code are usually used). sometimes it's just the other way around, going with the function, understanding a bit of it's logic, understanding the parameters, and then fixing the parameters and the function, but it's mostly goes down to experience with similar tasks and going with your gut, but understanding it can be wrong(hard part is knowing when to stop before going too deeply in the wrong path).

in regards to encryption or coding, sometimes going dynamically debugging might help you a lot with understand how it translates and checks your input, or the mechanism behind the encryption. but usually it goes down to many basic encryption/coding algorithms or custom implementation of them, that can be spotted with some experience, and then it's easier. if you coded the application and it's not a malware(though you should have snapshots), then there's nothing wrong if you do "bad things", just to understand which functions the program is calling, how it handles information, common program paths, apis, obfuscation and finally dealing with the encryption scheme you're facing. sometimes you don't need to face the encryption if it's not done correctly, you can, at times, just avoid it.

you said you wanted to crack the application, so i don't understand what you mean by that, i thought you meant like a crackme kind of task. if you really want to "crack" applications, you should know that there are lot of other defensive mechanisms such as checksums, different signatures, sometimes server verification and similar, but it all goes down to understand the logic behind what's happening. though i really don't think "cracking" is not a good path to walk at, i think that you should find better ways to use your skills for good, for instance malware analysis or hardening software/binaries by identifying weak implementations and similar.

anyways, since you did not provide a problem but a general issue, my best answer is to go with your guts, fail, and then learn why you failed to try it again and again until you understand how it works. it will help you understand and develop "hunch". then it's easier to understand how to defeat obfuscation and encryption and similar mechanisms.

bottom line is simple, ask yourself simple question, what does it do? is it obfuscated? is it encrypted? why is it encrypted? how does it encrypt? what does it encrypt? how does it check what is correct/wrong? does it matter if i input the correct information or can i bypass it somehow? but the easiest way is just understanding the goal, and going backwards, and thus tackling only what actually interferes with your progress, and not meaningless things that you solved, but could have avoided.

this answer would introduce some tools for debugging C# application

hope i helped a bit and good luck

| improve this answer | | | | |
New contributor

Your Answer

Ebrahim Karimi is a new contributor. Be nice, and check out our Code of Conduct.

