+- Hack Forums (https://hackforums.net)
+-- Forum: Tech (https://hackforums.net/forumdisplay.php?fid=444)
+--- Forum: Coding (https://hackforums.net/forumdisplay.php?fid=151)
+---- Forum: Software Development (https://hackforums.net/forumdisplay.php?fid=118)
+---- Thread: [.NET] .NET Reverse Engineering Tutorial Series - by debug (/showthread.php?tid=5227981)
* - debug - Apr 10, 2016
Thanks for all the feedback guys. Feel free to leave suggestions for the next episodes.
* - $lick - Apr 11, 2016
Debug, teaching children to steal because they are poor since 2002.
Vouch.
* - debug - Apr 11, 2016
(Apr 11, 2016 06:45 AM)Nexus™  Wrote: Debug, teaching children to steal because they are poor since 2002.You know it, bb.
Vouch.
* - VisualSoft - Apr 23, 2016
was fun watching this Videos.
i would request you to post some nice tutorials to Protect App from being Cracked from skid Crackers.
I know you can not make it impossible to get cracked, but can make it hard.
* - 帖子作者 - Apr 23, 2016
You should do an episode 3. :)
* - Corios - Apr 23, 2016
Only watched the first video so far, but one thing I will note:
You shouldn't just nop instructions instead of deleting them. Deleting an operation isn't going to mess with the call stack over noping it, and actually has a higher chance of not messing the source up in the case you're attempting to modify msil at run time, as it has already aligned its boundary. And for compile time modification, I mean it's a very slim chance, but if something is dependent on another thread, you creating a nop sled might dis align these times (which this would be a bad programming practice on the authors part in the first place, but still a possibility).
In general, disregarding the small time a nop instruction takes to hit, it's better to remove than to nop.
(Apr 6, 2016 12:07 AM)Only3 Wrote: patching if else is not really reversing but good to see this kind of threads
no... by definition, it is.
* - DisguiserNET - Apr 24, 2016
(Apr 23, 2016 08:56 PM)Corios Wrote: Only watched the first video so far, but one thing I will note:This is wrong. Nopping an instruction insted of deleting them preserves branches while deleting an instruction might cause problems. And i dont get why this should cause problems with the call stack, since nop actually is "no operation"
You shouldn't just nop instructions instead of deleting them. Deleting an operation isn't going to mess with the call stack over noping it, and actually has a higher chance of not messing the source up in the case you're attempting to modify msil at run time, as it has already aligned its boundary. And for compile time modification, I mean it's a very slim chance, but if something is dependent on another thread, you creating a nop sled might dis align these times (which this would be a bad programming practice on the authors part in the first place, but still a possibility).
In general, disregarding the small time a nop instruction takes to hit, it's better to remove than to nop.
no... by definition, it is.
* - DonD - Apr 24, 2016
Very much appreciate this little starter thread for people ionterested in debugging.
Thanks alot :D
* - Dennamanarjag - Apr 24, 2016
(Apr 23, 2016 08:56 PM)Corios Wrote: In general, disregarding the small time a nop instruction takes to hit, it's better to remove than to nop.
As someone else said, removing instructions may mess with branching offsets which would need to be updated, replacing with NOP does not.
Additionally I think you're all (including OP) confusing the call stack with the evaluation stack. They're two separate things and not really related. You have to be careful with just NOPing instructions willy-nilly. As an example; a conditional branch pops a value off the eval stack and if you simply NOP it it'll most likely fuck the rest of the code up since the object at the top of the stack that's meant to be popped by the branch will linger.
* - Corios - Apr 24, 2016
(Apr 24, 2016 05:27 AM)DisguiserNET Wrote: This is wrong. Nopping an instruction insted of deleting them preserves branches while deleting an instruction might cause problems. And i dont get why this should cause problems with the call stack, since nop actually is "no operation"
(Apr 24, 2016 08:28 AM)Dennamanarjag Wrote: As someone else said, removing instructions may mess with branching offsets which would need to be updated, replacing with NOP does not.
Additionally I think you're all (including OP) confusing the call stack with the evaluation stack. They're two separate things and not really related. You have to be careful with just NOPing instructions willy-nilly. As an example; a conditional branch pops a value off the eval stack and if you simply NOP it it'll most likely fuck the rest of the code up since the object at the top of the stack that's meant to be popped by the branch will linger.
I must not read it the same way you guys did, I was agreeing with the part of "Deleting an operation isn't going to mess with the call stack over noping it". (The OP said it will mess with call stack, I'm stating it won't)
And to address the other part: So you would rather take the chance of a branch falling through than experiencing a compilation error? This is leading to unsafe operations in a safe language. Deleting a line instead of noping it will cause the method to be unable to be written so you can fix the error on the spot, noping it is going to cause undefined behavior especially if a large change is made. You shouldn't nop things.
* - DisguiserNET - Apr 24, 2016
(Apr 24, 2016 11:33 PM)Corios Wrote: And to address the other part: So you would rather take the chance of a branch falling through than experiencing a compilation error? This is leading to unsafe operations in a safe language. Deleting a line instead of noping it will cause the method to be unable to be written so you can fix the error on the spot, noping it is going to cause undefined behavior especially if a large change is made. You shouldn't nop things.
You shouldnt talk about the call stack but the evaluation stack insted. And of course removing an instruction might mess up the stack and exceed the maxstack. You gotta fix that in both possibilities. However, you dont have to care about branches when you nop insted of deleting. And this is the reason why unexperienced reverse engineers should nop :D
Moreover, you can always create unsafe code with .net language and the part with "unable to be written" is just a thing you favourite decompiler will tell you by default, its possible nonetheless
* - Dennamanarjag - Apr 25, 2016
(Apr 24, 2016 11:33 PM)Corios Wrote: And to address the other part: So you would rather take the chance of a branch falling through than experiencing a compilation error? This is leading to unsafe operations in a safe language.
A compilation error? Are you talking about when the JIT compiles it? I don't see how this leads "unsafe operations" any more than removing an instruction.
(Apr 24, 2016 11:33 PM)Corios Wrote: Deleting a line instead of noping it will cause the method to be unable to be written so you can fix the error on the spot
Are we talking about patching built assemblies here? Because removing an operation is definitely not guaranteed to make the assembly unable to be written any more than a NOP would.
(Apr 24, 2016 11:33 PM)Corios Wrote: noping it is going to cause undefined behavior especially if a large change is made.
Implying simply removing a branch won't cause undefined behavior? You talked about creating a NOP sled earlier. Removing a branch instead of NOPing is more likely to cause behavior similar to a NOP sled e.g misaligned relative branches.
Not to mention if the application is distributed in Release mode as it should NOPs won't even be compiled so you get the both of best worlds.
* - Cecilia - Apr 25, 2016
I see no reason to not nop, except the rare chance something will fuck up, which is easy to detect and fix by deletion.
As others have said, there will always be issues with your exception handlers and other branches that rely on those offsets when you delete an instruction.
Modern libraries do adjust for this and will not be a problem in most decompilers/deobfuscators/assembly modification libraries.
I'd rather nop than delete because it is easier, its such a small detail guys, there's no reason to go into a debate about 'nop vs delete' it is just something people do or do not do, depending on the situation.
* - debug - Aug 28, 2016
Thinking about reviving this series if anyone has any interest.
* - baxterbigboy - Aug 29, 2016
I'm very interested @debug