Live data from Hacker News

A Gentle Primer on Reverse Engineering

emily.st

51–60 of 64 posts

Re: A Gentle Primer on Reverse Engineering

#51

Kind of sad that 75% of the comments in this thread are negative or pedantic. I work as a reverse engineer and I thought it was a good "gentle primer".

Whenever I read a comment like this of sufficient age I wish I could see a snapshot of the page at the time. Right now there's only 48 comments in total and I don't really notice much negativity. There's some back and forth nit-picking, do you consider that negative?

Re: A Gentle Primer on Reverse Engineering

#52
post #43
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.

The author was wrong, and then corrected their post. Why get indignant on their behalf?

The wrongness, such as it was, is completely beside the point. The author's audience is a group of people where this has a high probability of this being their first exposure to any C at all. That `malloc` is one more thing for them to get tripped up and distracted by.

I'm indignant because this happens on almost every marginally interesting article that makes the front page and I'm sick of it. I get that the code was wrong and a bug and C must be correct at all times or the world will literally light on fire. It's just exhausting reading comment after comment about the tiniest little nit in an otherwise perfectly wonderful essay.

Re: A Gentle Primer on Reverse Engineering

#53
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);

Of course it should be bool.

I'm glad that the OP at least made it a const char *password though, since that's also a must-have. Always const input pointers. And local temporaries. And everything else that you can const, except scalar arguments pretty much.

Re: A Gentle Primer on Reverse Engineering

#54
Something interesting I found out whilst following these instructions: My version of linux has two different echo commands `echo` and `/bin/echo`.

The basic one cannot accept any flags and when I type `echo "\x01"` it prints `\x01`

The one in bin can accept flags, and requires the -e flag to interpret backslashes.

This changes the echo line of the program to this:

`/bin/echo -e "\x01"`

I found this out because it was changing the byte from 00 to 5C rather than 01, because 5C is the ASCII for \

Re: A Gentle Primer on Reverse Engineering

#55

Something interesting I found out whilst following these instructions: My version of linux has two different echo commands `echo` and `/bin/echo`. The basic one cannot accept any flags and when I type `echo "\x01"` it prints `\x01` The one in bin can accept flags, and requires the -e flag to interpret backslashes. This changes the echo line of the program to this: `/bin/echo -e "\x01"` I found this out because it was…

Interesting. You might be seeing the bash (or other shell) `echo` builtin.

Re: A Gentle Primer on Reverse Engineering

#56
post #55

Something interesting I found out whilst following these instructions: My version of linux has two different echo commands `echo` and `/bin/echo`. The basic one cannot accept any flags and when I type `echo "\x01"` it prints `\x01` The one in bin can accept flags, and requires the -e flag to interpret backslashes. This changes the echo line of the program to this: `/bin/echo -e "\x01"` I found this out because it was…

Interesting. You might be seeing the bash (or other shell) `echo` builtin.

$ which echo

echo: shell built-in command.

Re: A Gentle Primer on Reverse Engineering

#57
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

God, I hate these, especially in API documentation. Come up with a simple example of how I might want to use your API. The relationship between fruit and bananas is much more clear than between foos and bazzes.

Re: A Gentle Primer on Reverse Engineering

#58
post #27
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.

Forget the author appearing competent, this is a primer. Primers should have code you can copy and paste and be correct every time. Most beginner following along running into a weird issue with the program they're using to reverse engineer before even getting to the fun part are just going to give up.

Re: A Gentle Primer on Reverse Engineering

#60
post #18

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

That simply explains the truth behind the words. Re-type-ing basic types into other names gives us the ability to share intent without commentary. A function returning 'bool' is intended to be treated as having two valid return values. A function returning int might be intended to return any of the large rage of values that int can support.
Post reply on HN