DSM-G600, DNS-3xx and NSA-220 Hack Forum

fonz wrote:

ntohs, ntohl, htons, htonl work fine here. Note that short means 16 bits, and long 32 bits.

Thanks for the information.  To be more specific here is what I saw in libmp4v2:

Here is the original function that did not work:

inline u_int32_t STRTOINT32(const char* s) {
  return ntohl(*(uint32_t *)s);
}

You would expect something returned like 0x66726565 returned (ascii "free") and you'd actually get 0x66000000.  It looks to me like the 4 bytes were read starting from the pointer address reading in the negative direction instead of the positive direction.

I changed the function to this and it works correctly:

inline u_int32_t STRTOINT32(const char* s) {

     u_int32_t D0 = s[0] << 24;
     u_int32_t D1 = s[1] << 16;
     u_int32_t D2 = s[2] << 8;
     u_int32_t D3 = s[3];
     u_int32_t s2 = D0 + D1 + D2 + D3;
     return s2;
}

I am a beginner with linux programming (I am a Windows developer in my real life).  Any insight?  I'm just trying to understand this.

boilerjt wrote:

You would expect something returned like 0x66726565 returned (ascii "free") and you'd actually get 0x66000000.  It looks to me like the 4 bytes were read starting from the pointer address reading in the negative direction instead of the positive direction.

Found it. It's a bug in your program. You cannot use ntohl on unaligned addresses (i.e. address  of the string must be a multiple of 4). Your replacement function works on unaligned values, too. Add -Wcast-align to the CFLAGS to see it:

root@bob:/tmp# cat test2.c
#include <stdio.h>
#include <stdint.h>

inline uint32_t STRTOINT32(const char* s) {
  return ntohl(*(uint32_t *)s);
}

int main(int argc, char **argv)
{
        char *str = "free";
        char *str2 = "0free";
                
        printf("str %s\n", str);
        printf("f(str) %lx\n", STRTOINT32(str));
        printf("f(str2+1) %lx\n", STRTOINT32(str2+1));

        return 0;
}



root@bob:/tmp# gcc -o test2 -Wcast-align test2.c
test2.c: In function 'STRTOINT32':
test2.c:5: warning: cast increases required alignment of target type


root@bob:/tmp# ./test2
str free
f(str) 66726565
f(str2+1) 66726530

boilerjt wrote:

Does i386 automatically align the address?

The question is a different one: On ARM (and a number of other architectures), you can read 4-byte values only from addresses that are multiples of 4. Afaict, there's no such restriction on x86.