Hacker News Reader

Comment by arsome | Hacker News Reader

I've always found this one a bit peculiar - usually debugging is about looking at something on a simpler, lower level than implementation. Rather than looking at a whole set of logic, let's step through it piece by piece, look at each operation. When done slowly with care and understanding of the lower level components in the system, debugging code is simpler than learning and implementing most architectural patterns in all but the most extreme of circumstances (compiler bugs, hardware faults).

Or maybe I just spent too much time in OllyDbg at a young age to notice.

View on HN

> usually debugging is about looking at something on a simpler, lower level than implementation

the lower you go, the less context you have about the author's intent. with too-clever code it's easy to miss the forest for the trees.

e.g. it usually works fine to fix spelling errors at word level, but less well to restructure complex sentances without larger context.

Please tell me “sentances” was intentional.

Waht maeks yuo tihnk twas intantional?

As others have pointed out, while it's easy at a quintessential level, it's not easy if you're dealing with actually complex (and clever) structures.

I don't know if you've ever had that experience in your OllyDbg-using days, but did you ever try to analyse software that was using some form of hashing function, or cryptography (ECDSA, for instance) with OllyDbg, without knowing what it was? The idea is kind of like that. While it's easy to get a concrete idea of what that block of code is doing (feed it an ASCII string and some memory structures, it spits gobledygook out), it's not so easy to look at it and conclude "Ha! This implements AES-CBC!" without some strong intuition or experience.

I will note that it doesn’t actually take all that much reverse engineering experience to be able to recognize most algorithms if you how they work “in code”.

If they're inlined and optimized, it's often hard to tell where they begin and end... and if anything else is interleaved into the beginning or end.

Hard, but not impossible. Usually the really annoying bit is if it ends up being split across multiple functions with stuff in between.

I will usually plop a breakpoint at where the problem is presenting itself (often in a controller or view), scan up the stack to find where I think the problem is actually being caused, then break at that point and walk through the code as you suggest.

If I understand the application really well often I don't need to do the first step, but it can be a handy shortcut.

I think the law could be put more generally: Specifying how to do X using Y tool-set is half as hard as discovering the order corner case where Y tool-set breaks down.

So, yeah, specifying an architecture may be easier than debugging a routine but discovering the "hole" in the architecture can be twice as hard as specifying it.

> Or maybe I just spent too much time in OllyDbg.

Yes. Because if you have to use a debugger to understand a piece of code (your own or someone else's), the author has already failed. Good code can be read and understood without any additional tools.

For complex code you cannot understand it in the debugger. You can understand how it works, but you can't get the design of why it works (or should work if it had been implemented to the design)

Reply on news.ycombinator.com