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

21–30 of 64 posts

Re: A Gentle Primer on Reverse Engineering

#21

Post by farmdve »

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…

Regarding your last sentence. Reverse Engineering is a complex task, and obfuscation is but one of the many challenges a reverse engineer faces, granted malloc/free or stack variable and the example binary not being one of them.

Re: A Gentle Primer on Reverse Engineering

#22

Post by sdevlin »

zrail wrote: post #13
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…

The author addresses this in footnote #2. They're simplifying the C code to get to the point of the article faster.

I don't really buy that this is a simplification. This code isn't even guaranteed to work on correct input.

A really simple fix would be just to use a character array.

Re: A Gentle Primer on Reverse Engineering

#23

Post by zrail »

AlexeyBrin wrote: post #20
zrail wrote: post #18

Earlier quoted context omitted.

Let's look at the source of stdbool.h: #define true 1 #define false 0 http://clang.llvm.org/doxygen/stdbool_8h_source.html

I know that sdtbool actually contains macros for defining true and false, but _Bool is a new type in C99 ... But it is in the standard, implemented by all major compilers, so it should be used for the sake of clarity. IMHO this: bool is_valid(char* password); is more clear than this: int is_valid(char* password);

But here's the thing: in the assembly (the very essence of the essay), booleans are still represented as integers. Using a standard macro would obfuscate the path to getting to the payoff of being able to switch a single byte from 0 to 1 and crack the program, because the author would then have to explain macros and delve into a bunch of ancillary stuff.

Re: A Gentle Primer on Reverse Engineering

#24

Post by farmdve »

zrail wrote: post #23
AlexeyBrin wrote: post #20

Earlier quoted context omitted.

I know that sdtbool actually contains macros for defining true and false, but _Bool is a new type in C99 ... But it is in the standard, implemented by all major compilers, so it should be used for the sake of clarity. IMHO this: bool is_valid(char* password); is more clear than this: int is_valid(char* password);

But here's the thing: in the assembly (the very essence of the essay), booleans are still represented as integers . Using a standard macro would obfuscate the path to getting to the payoff of being able to switch a single byte from 0 to 1 and crack the program, because the author would then have to explain macros and delve into a bunch of ancillary stuff.

Starting to work with Reverse Engineering assumes prior knowledge of programming and/or some basic information about assembly for the specific platform.

Furthermore as the examples are given in C, it is implied that the reader needs to be familiar with the language, and as a consequence, knowing about macros, should be if not a given, then at least required.

Re: A Gentle Primer on Reverse Engineering

#25

Post by zrail »

farmdve wrote: post #21
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…

Regarding your last sentence. Reverse Engineering is a complex task, and obfuscation is but one of the many challenges a reverse engineer faces, granted malloc/free or stack variable and the example binary not being one of them.

The title of the essay starts with "A Gentle Primer". Think less "this is a complex and deep thing that is hard to understand" and more "check out this neat thing you can do with computers! computers are awesome!"

Re: A Gentle Primer on Reverse Engineering

#26

Post by zrail »

farmdve wrote: post #24
zrail wrote: post #23

Earlier quoted context omitted.

But here's the thing: in the assembly (the very essence of the essay), booleans are still represented as integers . Using a standard macro would obfuscate the path to getting to the payoff of being able to switch a single byte from 0 to 1 and crack the program, because the author would then have to explain macros and delve into a bunch of ancillary stuff.

Starting to work with Reverse Engineering assumes prior knowledge of programming and/or some basic information about assembly for the specific platform. Furthermore as the examples are given in C, it is implied that the reader needs to be familiar with the language, and as a consequence, knowing about macros, should be if not a given, then at least required.

The original audience of this content (i.e. not HN) is a broad interest group so you can't really assume that kind of knowledge. Again, think "hey this is neat!" vs "this is absolutely technically correct in all ways."

Re: A Gentle Primer on Reverse Engineering

#27

Post by EpicEng »

zrail wrote: post #13
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…

The author addresses this in footnote #2. They're simplifying the C code to get to the point of the article faster.

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.

Re: A Gentle Primer on Reverse Engineering

#28

Post by zrail »

EpicEng wrote: post #27
zrail wrote: post #13

Earlier quoted context omitted.

The author addresses this in footnote #2. They're simplifying the C code to get to the point of the article faster.

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.

Re: A Gentle Primer on Reverse Engineering

#29

Post by caipre »

seanp2k2 wrote: post #10
jkubicek wrote: post #5

Earlier quoted context omitted.

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

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

Re: A Gentle Primer on Reverse Engineering

#30

Post by userbinator »

zrail wrote: post #18
AlexeyBrin wrote: post #17

C lacks a boolean type This is false, as of C99 we have booleans in C, just include stdbool.h in your code, e.g.: #include ... bool test = true; ...

Let's look at the source of stdbool.h: #define true 1 #define false 0 http://clang.llvm.org/doxygen/stdbool_8h_source.html

Given that more than half of that file is a copyright comment, and the other half basically has to follow a standard exactly, it almost makes me wonder if it meets the minimum threshold of creativity to be copyrightable.
Post reply on HN