returning pointer to SSL structure from SSL function

[mabdelouahab]

    sub rsp, 20h
    call OPENSSL_init_ssl
    sub rsp, 20h
    call TLS_client_method
    mov SSL_METHOD, rax
    mov rcx, SSL_METHOD
    sub rsp, 20h
    call SSL_CTX_new
    mov SSL_CTX, rax
One is enough
Or at least add every time:add rsp, 20h

[NoCforMe]

There are errors in this definition. In 64-bit C(++) for Windows, an "int" is still 32-bit, and, IIRC, a long as well ( to define a 64-bit integer, one has to use "long long" or "__int64 int" ).

Thanks. As I've been saying all along, my ignorance of things 64-bit is showing ...
Strange, though, that ints are still 32 bit, isn't it? I wouldn't have thought that.

[cyrus]

    sub rsp, 20h
    call OPENSSL_init_ssl
    sub rsp, 20h
    call TLS_client_method
    mov SSL_METHOD, rax
    mov rcx, SSL_METHOD
    sub rsp, 20h
    call SSL_CTX_new
    mov SSL_CTX, rax
One is enough
Or at least add every time:add rsp, 20h

I've been only doing the add if I am in a loop. Should I be doing this add regardless? I've never seen it done but it makes sense to do it for each function.

[cyrus]

I wanted to update the post and mention I decided to not use the OpenSSL libraries at all. I mean, they are really just a front-end for all the hardcore backend stuff they don't write themselves like encryption and TLS. They just make it work on platforms, which I am grateful for of course.

So how will you get to work, you ask? Well I'm just ripping through the code basically lol. Right now I just finished writing the padding portion to doing encryption/decryption with the assembly function directly using aesni_cbc_encrypt calling it from C with no OpenSSL libraries at all so now I am just converting the C portion to asm.

I did something similar for key derivation last year and it was not easy but extremely rewarding. It was the most intense thing I've done. I did encryption and decryption in the frikkin linux kernel (kernel c) on specific blocks of the disk without using an initial ramdisk! I got all the functions I needed for key derivation, then I just called the kernel functions with the DER. I basically went through a couple thousand lines of code easily and it boiled down to just a couple C functions, 3 assembly functions, then I implemented it all in the kernel directly. It was for an embedded platform so I couldn't use any of the libraries. Similarly, it wouldn't make sense to write an asm program if I have to include all of their extremely bloated libraries. A non-shared binary is over 4mb!

[jj2007]

Congrats, you seem to have lots of fun

My experience is that often you end up with a few lines of beautiful assembly code for what took loads of badly documented C/C++ gibberish before. As you write, it's rewarding to see the result.

[cyrus]

Congrats, you seem to have lots of fun

My experience is that often you end up with a few lines of beautiful assembly code for what took loads of badly documented C/C++ gibberish before. As you write, it's rewarding to see the result.

Yes they are just ridiculous in how they write their code, with all these fancy objects and ctx's thinking people won't be able to analyze it. i had asked one of the main developers what is the ultimate function that does encryption and he simply replies it with telling me to subscribe to a mailing list and ask it there. it isn't like they wrote that function either! they don't own the protocol. and last i checked, SSL is deprecated lol so they should change the name to OpenENC or something. i did post, however, no answer. nobody knows but the devs themselves and they won't even tell me. had to figure it out on my own but im fine with that, just makes me more of an expert and boosts my skills even more.

[mabdelouahab]

I'm just using OpenSSL. It does the same thing for SSL in Windows as well. In fact I am programming for a windows machine using masm64. The same SSL functions that work in Linux are the same ones in Windows. Using the same source code, I configured it in linux and in windows. In fact I first wrote the program in c on linux first, then converted it to cpp on windows, and now converting that to asm on windows.

Do you mean that you are running your program in Linux?
If this code is in the Linux system, then you are wrong, because the Linux system uses System V AMD64 ABI, function arguments of type integer/pointers are passed to the callee function in the following way:
- Arguments 1-6 are passed via registers RDI, RSI, RDX, RCX, R8, R9 respectively
- Arguments 7 and above are pushed on to the stack

    mov RDI, SSL_METHOD
    call SSL_CTX_new
    mov SSL_CTX, rax

[cyrus]

I'm just using OpenSSL. It does the same thing for SSL in Windows as well. In fact I am programming for a windows machine using masm64. The same SSL functions that work in Linux are the same ones in Windows. Using the same source code, I configured it in linux and in windows. In fact I first wrote the program in c on linux first, then converted it to cpp on windows, and now converting that to asm on windows.

Do you mean that you are running your program in Linux?
If this code is in the Linux system, then you are wrong, because the Linux system uses System V AMD64 ABI, function arguments of type integer/pointers are passed to the callee function in the following way:
- Arguments 1-6 are passed via registers RDI, RSI, RDX, RCX, R8, R9 respectively
- Arguments 7 and above are pushed on to the stack

    mov RDI, SSL_METHOD
    call SSL_CTX_new
    mov SSL_CTX, rax

I'm running on windows. I am aware of the calling convention. I was asking you about adding the stack space back to each call.

[cyrus]

I basically got what I wanted because I ended up just linking the object file for aes from the openssl library. I got the 64-bit running in linux but on windows, I couldn't for 2 straight days figure out why it just wouldn't work until I realized they coded the 64-bit for linux. I don't know how they do the conversion for windows systems, because they build it into the libcrypto.lib anyway so I had an idea. Get the 32-bit version since the code isn't subject to any calling convention. Worked like a charm. But yeah I had to go with GAS, no MASM on that one.

And yeah, NoCForMe, now I know why you don't code in 64-bit. It is so easy and fun, no stack alignment headache! Haven't coded in 32-bit in years. And that was just linux. Well, also, I believe you don't really have to. I did some reading and seems like a lot of code actually is written in 32-bits. It still works on 64-bit so I guess most people just don't bother with the extra headache?

[mabdelouahab]

guess most people just don't bother with the extra headache?

Except me 

This example works well for me and without errors

Code Select Expand

.data
    SSL_METHOD    dq    0
    SSL_CTX       dq    0
.code
    entry_point proc
        sub rsp, 20h
        call OPENSSL_init_ssl
       
        call TLS_client_method
        mov SSL_METHOD, rax

        mov rcx, SSL_METHOD
        call SSL_CTX_new
        mov SSL_CTX, rax

        mov rcx,SSL_CTX
        call SSL_CTX_free

        xor rax,rax
        call ExitProcess
        ret
    entry_point endp
end ;Start


[jj2007]

guess most people just don't bother with the extra headache?

That is an ideologically loaded question, my friend

I've coded a library in 64-bit (search the forum for JBasic), and it was fun but I certainly prefer 32-bit code.

Between 16- and 32-bit code, there is a factor 6-8 in terms of speed gain.
Between 32- and 64-bit code, there is a difference around 0-5%, in both directions. It depends on factors such as cache misses, the length of pointers, etc. Sometimes 64-bit code is faster because modern 64-bit compilers make more use of SIMD instructions than older (32-bit) ones; which is not true for Assembly: we always used SIMD instructions in 32-bit land.
64-bit code can address more than 2GB, which is occasionally an advantage.
64-bit code has more registers, which is occasionally an advantage (but I very rarely run out of registers in 32-bit code).

[cyrus]

guess most people just don't bother with the extra headache?

That is an ideologically loaded question, my friend

I've coded a library in 64-bit (search the forum for JBasic), and it was fun but I certainly prefer 32-bit code.

Between 16- and 32-bit code, there is a factor 6-8 in terms of speed gain.
Between 32- and 64-bit code, there is a difference around 0-5%, in both directions. It depends on factors such as cache misses, the length of pointers, etc. Sometimes 64-bit code is faster because modern 64-bit compilers make more use of SIMD instructions than older (32-bit) ones; which is not true for Assembly: we always used SIMD instructions in 32-bit land.
64-bit code can address more than 2GB, which is occasionally an advantage.
64-bit code has more registers, which is occasionally an advantage (but I very rarely run out of registers in 32-bit code).

Yeah I mean I'm always up for a challenge but I figure maybe most just want to get their projects completed. Good to know about the difference. Glad we have the option to go either way for now

[daydreamer]

In 64 bit you can kinda SIMD of " and,or,xor,not" with 64 bit gp registers instead of searching for xmm,ymm,zmm mnemonics for use those boolean functions