Hacker Newsnew | past | comments | ask | show | jobs | submit | asamy45's commentslogin

Doctype | Software engineer | Stockholm, Sweden | ONSITE, VISA or REMOTE (worldwide) | Full-time | https://www.doctype.se/ We're a small digital agency based in Stockholm, Sweden. Currently around 15 people. We have an office in the heart of Stockholm, but our employees are free to work from wherever they feel most productive. We've built https://lemondogs.com/, https://www.gothiaecup.com/, https://beta.esportal.se/, amongst other websites. Our largest clients are within the eSports segment. We’re currently looking for a software engineer with reverse engineering skills to work with us on client-sided anti-cheat technology. The project you would be working on is a standalone client built in C/C++, Go and x86 Assembly. Our current tech stack is mainly Go, MariaDB and React,

Requirements:

* Good understanding of C and x86-64 assembly

* Good understanding of the Windows NT kernel

* Good grasp of reverse engineering

* Eager to learn

Nice to have:

* Experience with reverse engineering malware/cheats/games, the windows NT kernel

* Experience with binary instrumentation

* Experience with hardware-assisted virtualization (such as VT-x and AMD-V), SLAT (Second Level Address Translation) (e.g. EPT, NPT)

* Understanding cryptography primitives

You’ll be working together with another anti-cheat engineer to combat cheaters in video games. Mail me at: asamy@doctype.se


Doctype | Software engineer | Stockholm, Sweden | ONSITE, VISA or REMOTE (worldwide) | Full-time | https://www.doctype.se/ We're a small digital agency based in Stockholm, Sweden. Currently around 15 people. We have an office in the heart of Stockholm, but our employees are free to work from wherever they feel most productive. We've built https://lemondogs.com/, https://www.gothiaecup.com/, https://beta.esportal.se/, amongst other websites. Our largest clients are within the eSports segment.

We’re currently looking for a software engineer with reverse engineering skills to work with us on client-sided anti-cheat technology. The project you would be working on is a standalone client built in C/C++, Go and x86 Assembly. Our current tech stack is mainly Go, MariaDB and React,

Requirements:

* Good understanding of C and x86-64 assembly

* Good understanding of the Windows NT kernel

* Good grasp of reverse engineering

* Eager to learn

Nice to have:

* Experience with reverse engineering malware/cheats/games, the windows NT kernel

* Experience with binary instrumentation

* Experience with hardware-assisted virtualization (such as VT-x and AMD-V), SLAT (Second Level Address Translation) (e.g. EPT, NPT)

* Understanding cryptography primitives

You’ll be working together with another anti-cheat engineer to combat cheaters in video games. Mail me at: asamy@doctype.se


Doctype | Software engineer | Stockholm, Sweden | ONSITE, VISA or REMOTE (worldwide) | Full-time | https://www.doctype.se/

We're a small digital agency based in Stockholm, Sweden. Currently around 15 people. We have an office in the heart of Stockholm, but our employees are free to work from wherever they feel most productive. We've built https://lemondogs.com/, https://www.gothiaecup.com/, https://beta.esportal.se/, amongst other websites. Our largest clients are within the eSports segment.

We’re currently looking for a software engineer with reverse engineering skills to work with us on client-sided anti-cheat technology. The project you would be working on is a standalone client built in C/C++, Go and x86 Assembly. Our current tech stack is mainly Go, MariaDB and React,

Requirements:

* Good understanding of C and x86-64 assembly

* Good understanding of the Windows NT kernel

* Good grasp of reverse engineering

* Eager to learn

Nice to have:

* Experience with reverse engineering malware/cheats/games, the windows NT kernel

* Experience with binary instrumentation

* Experience with hardware-assisted virtualization (such as VT-x and AMD-V), SLAT (Second Level Address Translation) (e.g. EPT, NPT)

* Understanding cryptography primitives

You’ll be working together with another anti-cheat engineer to combat cheaters in video games. Mail me at: asamy@doctype.se


Hey I know you guys, you're the ones who ran Darkcomet-RAT on players PC's to see if they were cheating. I will be sure to apply as I have lots of DC experience and I imagine you will be upgrading to blackshades soon(I can help with that!).


Doctype | Software engineer with reverse engineering skills / Anti-cheat engineer | Stockholm, Sweden | ONSITE, VISA or REMOTE (worldwide) | Full-time | https://www.doctype.se/

We're a small digital agency based in Stockholm, Sweden. Currently around 15 people. We have an office in the heart of Stockholm, but our employees are free to work from wherever they feel most productive. We've built https://lemondogs.com/, https://www.gothiaecup.com/, https://beta.esportal.se/, amongst other websites. Our largest clients are within the eSports segment.

We’re currently looking for a software engineer with reverse engineering skills to work with us on client-sided anti-cheat technology. The project you would be working on is a standalone client built in C/C++, Go and Assembly. Our current tech stack is mainly Go, MariaDB and React.

Requirements:

* Good understanding of C and x86-64 assembly

* Good understanding of the x86 architecture

* Good understanding of the Windows NT kernel

* Good grasp of reverse engineering

* Eager to learn

Nice to have:

* Experience with reverse engineering malware/cheats/games, the windows NT kernel

* Experience with binary instrumentation

* Experience with hardware-assisted virtualization (such as VT-x and AMD-V), SLAT (Second Level Address Translation) (e.g. EPT, NPT)

* Understanding cryptography primitives

The role we’re looking to fill is full-time. You’ll be working together with another anti-cheat engineer to combat cheaters in video games. We can offer relocation to Sweden and assist with housing. Feel free to mail me at asamy@doctype.se if this sounds interesting to you!


Doctype | Software engineer with reverse engineering skills / Anti-cheat engineer | Stockholm, Sweden | ONSITE, VISA or REMOTE (worldwide) | Full-time | https://www.doctype.se/

We're a small digital agency based in Stockholm, Sweden. Currently around 15 people. We have an office in the heart of Stockholm, but our employees are free to work from wherever they feel most productive. We've built https://lemondogs.com/, https://www.gothiaecup.com/, https://beta.esportal.se/, amongst other websites. Our largest clients are within the eSports segment.

We’re currently looking for a software engineer with reverse engineering skills to work with us on client-sided anti-cheat technology. Our current tech stack is mainly Go, MariaDB and React, but the project you would be working on is a standalone client built in C/C++, Go and Assembly.

Requirements:

* Good understanding of C and x86-64 assembly

* Good understanding of the x86 architecture

* Good understanding of the Windows NT kernel

* Good grasp of reverse engineering

* Eager to learn

Nice to have:

* Experience with reverse engineering malware/cheats/games, the windows NT kernel

* Experience with binary instrumentation

* Experience with hardware-assisted virtualization (such as VT-x and AMD-V), SLAT (Second Level Address Translation) (e.g. EPT, NPT)

* Understanding cryptography primitives

The role we’re looking to fill is full-time. You’ll be working together with another anti-cheat engineer to combat cheaters in video games. We can offer relocation to Sweden and assist with housing. Feel free to mail me at asamy@doctype.se if this sounds interesting to you!


So how does this belong to HN?


The movslq instruction will sign extend the upper 32 bits.


Right you are! Thanks. I tried to check, but didn't realize my test case had produced a zero bit in that position so didn't expose sign extension.


Actually he clearly misunderstands the difference, IA-32 refers to x86, which he then says IA-64, which refers to Itanium, which is sort of a bad comparison then.


There is no cast that happens behind the scene, look at the generated assembly.


Do you mean that the cast in the code gets compiled out?


No. The int to int * truncation does not happen, the cast does not matter. What matters is the `int *p' which is 64-bit on 64-bit systems, so the compiler will just move the returned value in RAX into wherever p is, so no truncation happens, even without the cast. Look at the generated assembly, you'll see what I mean.


Clang is too clever and gives malloc the correct implicit declaration even when you don't have an explicit prototype:

    test.c:10:12: warning: implicitly declaring library function 'malloc' with type 'void *(unsigned long)'
      [-Wimplicit-function-declaration]
I think that having a prototype mismatch with the actual declared function is undefined behavior, so this is a legal way to resolve it, but not every compiler will. Older compilers tended to treat malloc as just another function and wouldn't do this.

I was able to replicate the older behavior by wrapping malloc in my own function. In one file:

    int main()
    {
        int* p;
        p = (int*)wrapped_malloc(sizeof(int));
        *p = 10;
        return 0;
    }
    
And in another file:

    void *wrapped_malloc(int size) {
        return malloc(size);
    }
Compiling them into one program results in a crash. The relevant bit of assembly is:

    0000000100000f4f	movslq	%eax, %rdi
So it is indeed only extracting the lower 32 bits of the returned pointer.

The page looks pretty old (the IA-64 reference sure is dated, anyway) so I'd guess that it was referring to an older compiler that didn't have a special case for malloc like this.


Right, C compilers will automatically known it's part of libc. You didn't need to do the separate file thing, you could just have the wrapper and it will trigger the movslq, or a cltq.


With the wrapper in the same file, clang threw an error because the definition conflicted with the implied prototype.


Doesn't happen for me. Both GCC and Clang compile it fine.


Strange. Here's my erroring code:

    int main()
    {
        int* p;
        p = (int*)wrapped_malloc(sizeof(int));
        *p = 10;
        return 0;
    }
    
    void *wrapped_malloc(int size) {
        return malloc(size);
    }
And the actual error:

    test.c:9:11: error: conflicting types for 'wrapped_malloc'
        void *wrapped_malloc(int size) {
              ^
    test.c:4:19: note: previous implicit declaration is here
            p = (int*)wrapped_malloc(sizeof(int));
Are you doing anything differently?


Try putting wrapped_malloc above main. Or at least declaring it above main.


If it's above main then there's no longer an implicit prototype and you're no longer replicating the problem.


No, I am not sure why this happens.


The question asks about IA-64 (Itanium) and IA-32. You're talking about the RAX register which is x86-64.

If you call malloc without a prototype in scope, bad things can happen. Just because it happens to work out OK with the platform and compiler that you tested doesn't mean that it will work everywhere or that it will keep working in the future.


His scope of talk sounds as if he is referring to x86-64. Many people mistake the IA-64 for x86-64, that's why I assumed he'd be talking about it. Not to mention that IA-32 refers to x86, which he clearly seems to misunderstand.


VC++ pops a CDQE in there. For ``p=(int *)malloc(1000);'', with no prototype for malloc, it generates this:

        mov     ecx, 1000
        call    malloc
        cdqe
        mov     QWORD PTR p$[rsp], rax
I'll have to check if it's still true today, but Windows/the VC++ CRT certainly used not have no qualms about handing out pointers to memory below the 4GByte mark. So if you have a problem like this, it can go undetected for quite some time...

(Don't know about Linux. 64-bit OS X binaries usually start with a 4GByte section at 0, so the bottom 4GBytes simply isn't available.)


Has nothing to do with includes, it has no error. The C compiler will automatically know its imported. He probably thinks that `int *` is 32-bit regardless.


It has everything to do with includes. Just think how implicit declarations are defined.


Just think of the generated assembly.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: