HN user

adr_

122 karma
Posts2
Comments26
View on HN

For my part, I loved the long form, in-depth post, and I learned a lot. I'll admit breaking it up visually with some diagrams or photos is tempting (maybe a photo of your serial setup?) but I felt the explanations were all clear without it.

Hydrolysis is chemical breakdown via reaction with water. This is electrolysis. But it's a popsci article, so they put that in the subtitle. "Splitting" makes sense to people who don't use terms like hydrolysis and electrolysis frequently.

It is a fun mental exercise. I love this stuff, and that's the motivation.

I once wrote an emulator for a 4 bit microprocessor in Befunge (a 2D esoteric programming language). Then, I was definitely showing off something that really does not matter. 100% useless.

This is a little different. The motivation is the same, but it also proves that you cannot sanitise Javascript by removing letters or words. It's very easy to assume that such sanitisation works, and such an assumption can be a security-critical mistake. I've actually read this article before because I needed to solve such a problem.

Unsigned integer overflow is defined.

I agree that the carry flag shouldn't be exposed directly, but the ability to express "add and check for overflow" would be useful and allow for these optimisations where the architecture supports it.

Edit: But if you want to exploit the processor to its fullest, go with assembly. The compiler is good, but proving optimisations is a hard problem, and complex, single-instruction-specific optimisations aren't going to take off any time soon.

If the NSA is working with Intel, they're not going to bother with an RNG... The processor is the most trusted part of the computer security model - why would you choose bad random numbers as your attack vector?

Relevant talk: Hardware Backdooring is Practical - Jonathan Brossard https://www.youtube.com/watch?v=j9Fw8jwG07g

I wouldn't call it more verbose.

AT&T:

    sub    $0x8,%rbx
    callq  *%rax
    mov    (%rbx),%rax
Intel:
    sub    rbx, 0x8
    call   rax
    mov    rax, [rbx]
Intel can be written with:
    mov    rax, QWORD PTR [rbx]
But it's redundant and assemblers don't expect it. It's only necessary in a handful of places to avoid ambiguity, as opposed to the incessant size suffixes and $/% prefixes, which make AT&T feel more verbose to me. Definitely a matter of familiarity, though.

This is a bad answer, but when I'm on Linux, I use objdump and gdb for most of my reversing. They don't really compare to IDA, though. xxd is fine for hex editing, especially in the context of simple conditional jump changing, although there are much better open source hex editors.

I wrote an actual libc-free "Hello World" program for Linux: http://codepad.org/rUckf7jR

It should work as 32-bit or 64-bit and compile with clang or gcc. It compiles to about 11 assembly instructions.

To produce a fairly small file:

    $ clang -nostdlib -O3 -o helloworld -m32 helloworld.c
    $ strip helloworld
    $ strip -R .note.gnu.build-id ./helloworld
    $ wc -c helloworld
    428 helloworld

I've forgotten when I learned this stuff. Recently, I've been teaching people who have been programming for years how to reverse engineer. It's surprising how much trouble they have grasping trivial operations like "a & a" or "b ^ b", and understanding arithmetic equivalents, like using "a << 2" to multiply by four. Two's complement also seems to challenge a lot of people - I suppose an intuitive understanding comes with time, but I'd expect people to pick that up if they've been writing C for a while.

I do feel that this poll is biased, because people prefer to declare their knowledge than admit their ignorance.

BCD is not a bad idea... It's not great, you can pack arbitrary precision values more tightly, and you rarely need to display them (even when you do, the screen is slower than the maths), but it's useful for a bunch of things and it's nice to think about.

But does it really need an instruction on every modern computer's processor to make it that tiny bit faster?

When was the last time you used a program that used that instruction? I've never run in to it (and I spend a decent amount of time looking at x86 assembly). Nonetheless, it shows up at the top of every instruction reference - you need to implement it if you want to simulate x86 correctly.

But at least I can run some old 8086 code on my computer... Right?

If the salts are different, it will definitely change.

On the other hand, using the same salt twice will change the hash if it's put before the data, but not if it's put after the data.

Given an MD5 collision, you can apply a common suffix and still have a hash collision. Applying a common prefix changes the state the hash process is in when it reaches the colliding data and this breaks the collision.