Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Gentle Primer on Reverse Engineering

emily.st

Post reply on HN
Print view View original

31–40 of 64 posts

Re: A Gentle Primer on Reverse Engineering

#31

Post by busterarm »

jkubicek wrote: post #5
Kenji wrote: post #2

This is slightly offtopic but I find the vulgar example passwords amusing. I used to use a lot of vulgar language in my code but when you have to commit it and other people (e.g. your supervisor) read it, you have to be more careful.

I find it especially amusing because "poop" and "butts" are my default "I need to enter some text here" strings.

Same here except I go much more vulgar.

It's such a hard habit to break. Also, if I can name a character in a videogame, it's almost always Dickbutt.

Re: A Gentle Primer on Reverse Engineering

#33

Post by sokoloff »

zrail wrote: post #19
farmdve wrote: post #16

Earlier quoted context omitted.

The footnote was very difficult to spot. Furthermore, I am not sure why not write out the complete code, even if the author knew the code was not correct, even when pointed out, it would have been very trivial to initialize the variable.

Because the author made a stylistic choice to publish slightly incomplete code to get to the point faster (and pointed that out in a footnote, which was just as easy to spot as the "bug"). The point of the essay is not a perfectly executed C program, it's to demonstrate code disassembly and reverse engineering. More attention on perfect C code means less attention (reader attention and author attention alike) on the…

The gist accompanying the article of the full source code contains the same bug. I'm not convinced it was a stylistic choice in the blog for a clearer explanation.

I would expect the full code to be correct/complete. This type of bug goes well beyond "I also make some assumptions in string handling that are considered gravely unsafe to use in a modern program, so please do not use this code in the real world." IMO.

Re: A Gentle Primer on Reverse Engineering

#35

Post by zrail »

sokoloff wrote: post #33
zrail wrote: post #19

Earlier quoted context omitted.

Because the author made a stylistic choice to publish slightly incomplete code to get to the point faster (and pointed that out in a footnote, which was just as easy to spot as the "bug"). The point of the essay is not a perfectly executed C program, it's to demonstrate code disassembly and reverse engineering. More attention on perfect C code means less attention (reader attention and author attention alike) on the…

The gist accompanying the article of the full source code contains the same bug. I'm not convinced it was a stylistic choice in the blog for a clearer explanation. I would expect the full code to be correct/complete. This type of bug goes well beyond "I also make some assumptions in string handling that are considered gravely unsafe to use in a modern program, so please do not use this code in the real world." IMO.

The C code is literally the least interesting part of this essay. This bug, such as it is, does not matter. It is entirely and completely beside the point.

Re: A Gentle Primer on Reverse Engineering

#36

Post by juliangregorian »

caipre wrote: post #29
seanp2k2 wrote: post #10

Earlier quoted context omitted.

This is why we have [foo, bar, baz, quux] and example.com though: https://www.iana.org/domains/reserved

I recently had to expand my list and came up with: foo bar baz buz qux pip pop tut rof art uff dex dom zed

Except there's already foo, bar, baz, qux, quux, garply, waldo, fred, plugh, xyzzy, thud.

http://www.catb.org/~esr/jargon/html/F/foo.html

Re: A Gentle Primer on Reverse Engineering

#37

Post by digler990 »

zrail wrote: post #35
sokoloff wrote: post #33

Earlier quoted context omitted.

The gist accompanying the article of the full source code contains the same bug. I'm not convinced it was a stylistic choice in the blog for a clearer explanation. I would expect the full code to be correct/complete. This type of bug goes well beyond "I also make some assumptions in string handling that are considered gravely unsafe to use in a modern program, so please do not use this code in the real world." IMO.

The C code is literally the least interesting part of this essay. This bug, such as it is, does not matter . It is entirely and completely beside the point.

This isn't art class. facts fucking matter. unless you proffer incompetence.

Re: A Gentle Primer on Reverse Engineering

#38

Post by fezz »

sdevlin wrote: post #11

First: great article. One nit, though. There's a subtle error in the main function: char* input; printf("Please input a word: "); scanf("%s", input); Local variables are not automatically initialized in C, and we never assign input to point to any particular block of memory. This means it's probably pointing off to some random location - basically whatever address happened to be sitting on the stack when main was cal…

Um, nice example of mansplaining.

Re: A Gentle Primer on Reverse Engineering

#40

Post by EpicEng »

zrail wrote: post #28
EpicEng wrote: post #27

Earlier quoted context omitted.

Simplifying does not mean incorrect. Initializing the variable would not add appreciable complexity to the code. It's a snippet and should be fixed lest it make the author appear incompetent.

I'm not 100% confident, but I'm pretty sure the author does not care if you think they're incompetent. The author's skill and apparent interest is in explaining an inherently difficult concept (reverse engineering a complied executable) in a way that won't cause their audience ( not you ) to tune out and/or go running for the hills. Could they adjust the snippet? Sure. Will it add anything to the essay to do so? Nope…

Eh... I'm not really buying it. I think it was an honest mistake. C'mon; this makes that snippet harder to read?

    char input[SIZE];
I really don't think so. I'm all for simplifying example code to get the core concept across, but I wouldn't go as far as to invoke undefined behavior. I also don't understand the use of scanf. At all. A seasoned, competent C user would never consider using scanf.

Anyway, I didn't mean to derail things too much here. It's really a nitpick and has little to do with the article itself.

Post reply on HN