Well I am a bit stumped for a couple days trying to figure out why it fails when calling SSL_CTX_new() and I figure the forum is so dead that I decided to give you guys something to answer by creating this thread :smiley:
In C++, I am basically calling
SSL_library_init();
const SSL_METHOD *meth = TLS_client_method();
SSL_CTX *ctx = SSL_CTX_new (meth);
SSL *ssl = SSL_new (ctx);
Which works and I continue on with the rest of my code but in assembly, the tricky thing here is that the pointer returned isn't going to just be 8 bytes. It's an entire struct.
It is a somewhat complex struct because it has members that are not only int, but some of these are function pointers and some that even return function pointers and some of them even have OTHER structs in there. This is the actual struct itself.
struct ssl_method_st {
int version;
unsigned flags;
unsigned long mask;
SSL *(*ssl_new) (SSL_CTX *ctx);
void (*ssl_free) (SSL *s);
int (*ssl_reset) (SSL *s);
int (*ssl_init) (SSL *s);
int (*ssl_clear) (SSL *s);
void (*ssl_deinit) (SSL *s);
int (*ssl_accept) (SSL *s);
int (*ssl_connect) (SSL *s);
int (*ssl_read) (SSL *s, void *buf, size_t len, size_t *readbytes);
int (*ssl_peek) (SSL *s, void *buf, size_t len, size_t *readbytes);
int (*ssl_write) (SSL *s, const void *buf, size_t len, size_t *written);
int (*ssl_shutdown) (SSL *s);
int (*ssl_renegotiate) (SSL *s);
int (*ssl_renegotiate_check) (SSL *s, int);
int (*ssl_read_bytes) (SSL *s, uint8_t type, uint8_t *recvd_type,
unsigned char *buf, size_t len, int peek,
size_t *readbytes);
int (*ssl_write_bytes) (SSL *s, uint8_t type, const void *buf_, size_t len,
size_t *written);
int (*ssl_dispatch_alert) (SSL *s);
long (*ssl_ctrl) (SSL *s, int cmd, long larg, void *parg);
long (*ssl_ctx_ctrl) (SSL_CTX *ctx, int cmd, long larg, void *parg);
const SSL_CIPHER *(*get_cipher_by_char) (const unsigned char *ptr);
int (*put_cipher_by_char) (const SSL_CIPHER *cipher, WPACKET *pkt,
size_t *len);
size_t (*ssl_pending) (const SSL *s);
int (*num_ciphers) (void);
const SSL_CIPHER *(*get_cipher) (unsigned ncipher);
OSSL_TIME (*get_timeout) (void);
const struct ssl3_enc_method *ssl3_enc; /* Extra SSLv3/TLS stuff */
int (*ssl_version) (void);
long (*ssl_callback_ctrl) (SSL *s, int cb_id, void (*fp) (void));
long (*ssl_ctx_callback_ctrl) (SSL_CTX *s, int cb_id, void (*fp) (void));
};
So to get the size (because I don't know of any other way), I have to look it up in ssl_local.h, copy it but create my own version of this struct otherwise I get an error that the struct is already defined which is true. And then I do a sizeof(my_ssl_method_st). It has things like OSSL_TIME I have to figure out what is, assumming 4 bytes so in the end I get 248 bytes. So then I declare the SSL_METHOD pointer in masm as such:
SSL_METHOD DQ 31 DUP (0)
which is 31 x 8 = 248. So now I can return a pointer to this struct that will get correctly populated. So I now feed that into the next call but it fails. Here is basically a summary of the above C code.
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
In C, these functions succeed but fails with masm. In the debugger, it fails stating STATUS ACCESS VIOLATION. Environment variable not found.
LastError: The system could not find the environment option that was entered.
Hmm; take my comments with a rather large grain of salt, as I'm not a 64-bit guy. But you're both overthinking and wrong-thinking some aspects here, methinks.
No. 1 problem, seems to me, is defining that structure in your (assembly-language) code. So do it. I'll get you started:
C++:
struct ssl_method_st {
int version;
unsigned flags;
unsigned long mask;
...
translates to
my_ssl_method_st STRUC
version DD ?
flags DD ?
mmask DD ?
...
You can handle that, right? Good. (I'm only showing snippets of the whole thing.) I'll leave converting the pointer stuff to you, or someone else here. Also notice that I gave it a unique name in case there's already a structure defined in one of your include files.
Fine. Now that youve got that structure defined, you can immediately get the size of it by simply coding
SIZEOF my_ssl_method_st
and to declare an instance of this structure, instead of faking it with your SSL_METHOD DQ 31 DUP (0), simply declare it by
SSL_METHOD my_ssl_method_st<>
which will make addressing individual members super-easy without any futzing around:
MOV EAX, SSL_METHOD.version
Regarding the function returning this structure, I can't say for sure, but I'm willing to bet that it doesn't "return" the entire structure (i.e., copying it somewhere), but instead returns a pointer to a structure, which is the typical method for functions that return structures. In which case you already know how to deal with that, right?
Let me know if I'm wrong here ...
Yes I understand of course it returns a pointer to a structure. I come from a C background. What's going on here is that in assembly, you can't just return that to some pointer declared as pointer DQ ? because that pointer needs to point to a struct and that struct gets populated when you call TLS_client_method.
I can't just use the included function because there are no header files, just the library which has the struct inside of it. The only way to get that info is looking for it in ssl_local.h. I counted up the bytes for that structure which is 248 bytes so I don't really need to write it out in asm, I just need to declare a pointer of the right size. I do this for the STARTUP INFORMATION struct and PROCESS INFORMATION struct as well when I use CreateProcessA. However, those are small structs. Even if I declare an enormous amount for this struct, it doesn't work. The key here is that rax returns a pointer to a struct but that pointer must have enough size to hold that struct and that's why I declared 248 bytes for it so it isn't that I am faking it, I just have to declare that size initially.
I wanted to mention that I dont need to use any of the data in that struct. In the STARTUP INFORMATION struct for CreateProcessA, I just load it into a register and I know at what position to put data in there. like if i load it in r12, i just use [r12 + 4] and add what data i need there but here i am passing off this entire struct as an argument to SSL_CTX_new. That structure is enormous, over 800 bytes actually. Over 300 lines of code.
Quote from: cyrus on January 23, 2024, 09:24:56 AMI can't just use the included function because there are no header files, just the library which has the struct inside of it.
That's why you need to create your own "header" (include) file with a function description (PROTO) and a structure definition.
QuoteThe only way to get that info is looking for it in ssl_local.h.
Yes. So use that info to translate the structure definition to assembly language. It won't take long and will save you a lot of headaches.
QuoteI counted up the bytes for that structure which is 248 bytes so I don't really need to write it out in asm, I just need to declare a pointer of the right size. I do this for the STARTUP INFORMATION struct and PROCESS INFORMATION struct as well when I use CreateProcessA. However, those are small structs. Even if I declare an enormous amount for this struct, it doesn't work. The key here is that rax returns a pointer to a struct but that pointer must have enough size to hold that struct and that's why I declared 248 bytes for it so it isn't that I am faking it, I just have to declare that size initially.
Correction, and maybe clear up some confusion: the
pointers don't have "different sizes". They're all the same size, the size of a pointer in 64-bit ASM (quadword). What's different is
what they point to. Remember, a pointer is just a piece of data that holds the address of something. (You already know this, just trying to reinforce it.)
So again, if you define the structure, you can declare it and it will be exactly the right size, no need to worry about that. Either declare it on the stack as a LOCAL, or as a global ("static" in C parlance) in your
.data or
.data? section.
Does this help any?
all pointers are 8 bytes yes. when i use the STARTUP INFORMATION struct, I declare it as such:
sinfo DQ 14 DUP(0) ; used for sinfo struct which is 108 bytes but 108/8 = 13.5 so 14 is needed (112) ;
If I just did
sinfo DQ ?
that would never work because a pointer (8 bytes) isn't enough storage to use if i loaded it into a register. i can declare those both like that but it wouldn't make sense to use the pointer. i guess I could hold the address of that sinfo there but then I could just lea my storage anyway.
later down when i call CreateProcessA, i do
lea r12, sinfo
The other way is to push bytes onto the stack which you've seen me do before. I simply would push 112 bytes on the stack in 8 byte pushes 14 times, then just
mov r12, rsp
mov QWORD PTR [r12 + 4], rcx
whatever rcx data i put goes into the 2nd member of that struct
now maybe I'm wrong because my sinfo isn't exactly a pointer, its just storage. a pointer to that isn't necessary unless I just declare another one and point that to my array, but that doesn't seem to benefit me. its possible that maybe i am not 100% on pointers to structs as that seems to be my issue in asm because that is new to me.
I've tried to translate it automagically to MASM syntax, but it's tougher than I thought: the algo that works for most C structures fails miserably for this one. One wonderful thing about C/C++ is that thousands of enthusiastic coders are actively seeking to create new, innovative syntaxes to confuse those freaks who believe in simple standards.
Anyway, it's clear that much more than 248 bytes are there. SIZE_P is 4 bytes in 32-bit and 8 bytes in 64-bit code.
ssl_method_st STRUCT
version SDWORD ?
flags flags; <>
mask DWORD ?
ctx) SIZE_P ?
s) SIZE_P ?
s) SIZE_P ?
s) SIZE_P ?
s) SIZE_P ?
s) SIZE_P ?
s) SIZE_P ?
s) SIZE_P ?
readbytes) SIZE_P ?
readbytes) SIZE_P ?
written) SIZE_P ?
s) SIZE_P ?
s) SIZE_P ?
int) SIZE_P ?
???? SIZE_P ?
???? SIZE_P ?
readbytes) SIZE_P ?
???? SIZE_P ?
written) SIZE_P ?
s) SIZE_P ?
parg) SIZE_P ?
parg) SIZE_P ?
ptr) SIZE_P ?
???? SIZE_P ?
len) SIZE_P ?
s) SIZE_P ?
void) SIZE_P ?
ncipher) SIZE_P ?
void) SIZE_P ?
ssl3_enc SIZE_P ?
void) SIZE_P ?
) SIZE_P ?
) SIZE_P ?
ssl_method_st ENDS Attention, it seems that this structure combines often several pointers in one line, e.g.
int (*ssl_read) (SSL *s, void *buf, size_t len, size_t *readbytes);
So the readbytes SIZE_P translation is most probably wrong.
Quote from: cyrus on January 23, 2024, 10:12:49 AMIf I just did
Code Select Expand
sinfo DQ ?
that would never work because 8 bytes isn't enough storage to use if i loaded it into a register
The registers in 64-bit code (rax, rcx, r12 etc) are 8 bytes wide, so I can't see the problem here. Unless you talk about SSE* registers like xmm0 or ymm0, of course.
You're confusing pointers with data storage areas. Lessee, how can I illustrate this?
OK, your example is sinfo DQ 14 DUP(0), a 112-byte area of storage. Fine. But it's not a pointer. A pointer would be
sinfo DQ 14 DUP(0)
sinfo_ptr DQ sinfo
the 2nd item becomes a pointer which points to sinfo, and that pointer is always going to be the native size of a pointer, in this case a QWORD.
For the structure I wrote about up there, the code would be
SSL_METHOD my_ssl_method_st<> ;in .data, .data? or as a LOCAL
and then you could pass a pointer to this declared structure to your function, which would fill it in. The pointer will always be the same size--8-bytes--only what it points to will change in size. You could create the pointer (in a register) by
LEA R12, SSL_METHOD
or pass it to a function by
ADDR SSL_METHOD
(or OFFSET SSL_METHOD if it's declared in .data or .data?).
Ok so I guess I would have to actually create a skeleton of these structs just to use them? See I thought I could just do what I do with the PROCESS INFORMATION struct in CreateProcessA because that struct actually gets populated, I don't add data. A call populates it, then it is passed off to CreateProcessA. With the SSL functions, a pointer to SSL_METHOD *meth is simply returned from calling TLS_client_method(). But what is it pointing to? That storage has to exist somewhere. That's what I thought declaring it in .data would actually do.
Obviously SSL is an Object, not just an Structure.
SSL_CTX also is an Object.
Yes but isn't an object just a large structure? I've looked at the structs themselves. At the end of the day though, isn't just simply declaring enough storage than passing that off enough to do what I need? What is required for me to get this to work?
Quote from: cyrus on January 23, 2024, 11:11:01 AMYes but isn't an object just a large structure?
No.
Quote from: cyrus on January 23, 2024, 11:11:01 AMWhat is required for me to get this to work?
You need the main part: all the methods.
Can you be specific about the main part? Do I need to create the structs as mentioned by NoCforMe? How does one declare an object in assembly? I guess that is what I am looking for. I can't find much of that online. And to be quite frank, I don't see how an object is any different than just a structure. They seem to label them that way but it's just a struct to me.
Just like their other contexts are just structs. In C, there isn't another data type anyway so there isn't any secret there. I learned C 8 years ago but not saying I am a true expert in it, but I was able to break down the entire PEM_read_PrivateKey_ex() down to about 12 lines of actual code, meaning all the functions needed to decrypt an SSL private key to the DER format with BytesToKey() and assembly routines, etc. And all that code was thousands of lines of it but I followed it all the way through. I mention that because there were tons of contexts they use passing it off to other functions and creating other contexts, basically a bunch of error handling and different conditions that I didn't need. I was able to bypass all they did without any contexts.
Quote from: cyrus on January 23, 2024, 10:32:53 AMI thought I could just do what I do with the PROCESS INFORMATION struct in CreateProcessA because that struct actually gets populated
[out] lpProcessInformation
A pointer to a PROCESS_INFORMATION structure that receives identification
information about the new process.Yes indeed, it gets populated, i.e. you
receive a pointer ("out") to a (filled) structure that was created
by Windows somewhere in memory.
Is that the case for you? You are rather vague about the API you want to use, and which arguments the API call takes.
OK, here's (hopefully) a little more help. I've converted that structure for you. Here it is. It took me all of 10 minutes to do it.
SSL_METHOD STRUCT
version DQ ?
flags DQ ?
mmask DQ ?
Pssl_new DQ ?
Pssl_free DQ ?
Pssl_reset DQ ?
Pssl_init DQ ?
Pssl_clear DQ ?
Pssl_deinit DQ ?
Pssl_accept DQ ?
Pssl_connect DQ ?
Pssl_read DQ ?
Pssl_peek DQ ?
Pssl_write DQ ?
Pssl_shutdown DQ ?
Pssl_renegotiate DQ ?
Pssl_renegotiate_check DQ ?
Pssl_read_bytes DQ ?
Pssl_write_bytes DQ ?
Pssl_dispatch_alert DQ ?
Pssl_ctrl DQ ?
Pssl_ctx_ctrl DQ ?
PPget_cipher_by_char DQ ?
Pput_cipher_by_char DQ ?
Pssl_pending DQ ?
Pnum_ciphers DQ ?
PPget_cipher DQ ?
Pget_timeout DQ ?
Pssl3_enc DQ ?
Pssl_version DQ ?
Pssl_callback_ctrl DQ ?
Pssl_ctx_callback_ctr DQ ?
SSL_METHOD ENDS
Members starting with "P" are pointers; those starting with "PP" are pointers to pointers.
This should at least get you started; I believe if you define this structure (put this code at the top of your program) AND declare and instance of this structure
MySSLmethod SSL_METHOD <>
then at least the function call should succeed.
What the hell to do with the contents of the structure once you get it, I have no idea. You apparently have to use all those pointers to functions (or "methods" to use the fancy-schmancy C++ lingo) to call them, and I have no idea how to do that. Probably something like this, to take one member as an example:
int (*ssl_clear) (SSL *s);
INVOKE Pssl_clear, s ;where "s" is a pointer to an SSL, whatever that is
; or if you don't use INVOKE, use good old "push-push-call":
PUSH s
CALL <struct name>.Pssl_clear
Quote from: jj2007 on January 23, 2024, 12:09:57 PMQuote from: cyrus on January 23, 2024, 10:32:53 AMI thought I could just do what I do with the PROCESS INFORMATION struct in CreateProcessA because that struct actually gets populated
[out] lpProcessInformation
A pointer to a PROCESS_INFORMATION structure that receives identification
information about the new process.
Yes indeed, it gets populated, i.e. you receive a pointer ("out") to a (filled) structure that was created by Windows somewhere in memory.
Is that the case for you? You are rather vague about the API you want to use, and which arguments the API call takes.
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.
Quote from: cyrus on January 23, 2024, 11:39:27 AMHow does one declare an object in assembly?
https://masm32.com/board/index.php?board=43.0 (https://masm32.com/board/index.php?board=43.0)
Quote from: cyrus on January 23, 2024, 12:18:52 PMI'm just using OpenSSL.
Would you be so kind and supply a minimum of documentation? I.e. what kind of arguments does "OpenSSL" expect?
Here is an example of what we need to help you:
BOOL CreateProcessA(
[in, optional] LPCSTR lpApplicationName,
[in, out, optional] LPSTR lpCommandLine,
[in, optional] LPSECURITY_ATTRIBUTES lpProcessAttributes,
[in, optional] LPSECURITY_ATTRIBUTES lpThreadAttributes,
[in] BOOL bInheritHandles,
[in] DWORD dwCreationFlags,
[in, optional] LPVOID lpEnvironment,
[in, optional] LPCSTR lpCurrentDirectory,
[in] LPSTARTUPINFOA lpStartupInfo,
[out] LPPROCESS_INFORMATION lpProcessInformation
);
Quote from: HSE on January 23, 2024, 12:24:05 PMQuote from: cyrus on January 23, 2024, 11:39:27 AMHow does one declare an object in assembly?
https://masm32.com/board/index.php?board=43.0
Not very helpful ...
Quote from: NoCforMe on January 23, 2024, 12:12:19 PMOK, here's (hopefully) a little more help. I've converted that structure for you. Here it is. It took me all of 10 minutes to do it.
SSL_METHOD STRUCT
version DQ ?
flags DQ ?
mmask DQ ?
Pssl_new DQ ?
Pssl_free DQ ?
Pssl_reset DQ ?
Pssl_init DQ ?
Pssl_clear DQ ?
Pssl_deinit DQ ?
Pssl_accept DQ ?
Pssl_connect DQ ?
Pssl_read DQ ?
Pssl_peek DQ ?
Pssl_write DQ ?
Pssl_shutdown DQ ?
Pssl_renegotiate DQ ?
Pssl_renegotiate_check DQ ?
Pssl_read_bytes DQ ?
Pssl_write_bytes DQ ?
Pssl_dispatch_alert DQ ?
Pssl_ctrl DQ ?
Pssl_ctx_ctrl DQ ?
PPget_cipher_by_char DQ ?
Pput_cipher_by_char DQ ?
Pssl_pending DQ ?
Pnum_ciphers DQ ?
PPget_cipher DQ ?
Pget_timeout DQ ?
Pssl3_enc DQ ?
Pssl_version DQ ?
Pssl_callback_ctrl DQ ?
Pssl_ctx_callback_ctr DQ ?
SSL_METHOD ENDS
Members starting with "P" are pointers; those starting with "PP" are pointers to pointers.
This should at least get you started; I believe if you define this structure (put this code at the top of your program) AND declare and instance of this structure
MySSLmethod SSL_METHOD <>
then at least the function call should succeed.
What the hell to do with the contents of the structure once you get it, I have no idea. You apparently have to use all those pointers to functions (or "methods" to use the fancy-schmancy C++ lingo) to call them, and I have no idea how to do that. Probably something like this, to take one member as an example:
int (*ssl_clear) (SSL *s);
INVOKE Pssl_clear, s ;where "s" is a pointer to an SSL, whatever that is
; or if you don't use INVOKE, use good old "push-push-call":
PUSH s
CALL <struct name>.Pssl_clear
Ok thanks a lot for putting that together. Here is what I've done after declaring the struct as you just did. I declared method as a pointer to that struct
method DQ MySSLmethod
Then here is how my code looks:
call TLS_client_method
mov method, rax
mov rcx, qword ptr [method]
sub rsp, 20h
call SSL_CTX_new
mov SSL_CTX, raxIt fails. I also tried
lea rcx, method but fails too. I get the same error.
Sorry, can't help you with that level of detail. Wish I could. But some general questions and observations:
First of all, why are you trying to use assembly language here? Do you want to, or do you have to? Not trying to talk you out of it, just wondering the reason why.
About all this object stuff:
There seems to be a lot of mystery surrounding the whole idea of "objects" and "methods", which may make one believe that they're totally impenetrable concepts that can't be used in assembly language.
My guess©® is that this is just not true. Those "objects" and "methods" ultimately have to be just plain functions and data objects, which can be expressed in an assembly-language program. Of course, you have to know what the functions do, what arguments the functions expect, what results they return, and the format of any structures. And of course you need the functions themselves, either in a static library or a DLL. But if you know all that, I don't see why you can't write an assembly-language program which replicates exactly the C++ equivalent code. And without having to use an "object-oriented assembler".
Not saying it would be easy. But it should be possible.
Let's take one example. In the ssl_method_st structure, let's say you want to invoke the "method" ssl_read (in other words, call that function): this can be accomplished thus, using "push-push-call" (minus any needed stack manipulation, which I'm not familiar with but you seem to be):
; int (*ssl_read) (SSL *s, void *buf, size_t len, size_t *readbytes);
PUSH Preadbytes
PUSH len
PUSH Pbuf
PUSH Ps
CALL MySSLmethod.ssl_read
(This may be wrong, as I don't know the X64 ABI; maybe some of those arguments have to go into registers instead. But you get the idea.)
All those scary-looking members are just pointers to functions. That's all. You set up the parameters and call them.
If anything I'm writing here is wrong, I'd appreciate being corrected. I really don't want to mislead you.
On second thought, may be I can help you. You're trying to call a function of type SSL_CTX, right? But you don't call the type; you call the function itself through its pointer, which is part of that stucture:
; SSL *(*ssl_new) (SSL_CTX *ctx);
MOV RCX, Pctx
SUB RSP, 20h
CALL MySSLmethod.Pssl_new
MOV result, RAX
assuming that Pctx is a pointer to a thing of type SSL_CTX, and result is a thing of type SSL.
Aargh; unless you have to dereference that pointer, since it's a pointer to a pointer (*(*ssl_new)), in which case you'd need something like
MOV RAX, MySSLmethod.Pssl_new
MOV RAX, [RAX]
CALL RAX
...
But this is just a guess on my part. Others may be able to figure this out ...
Maybe try this? Do you see what's going on here?
Quote from: NoCforMe on January 23, 2024, 01:13:22 PMSorry, can't help you with that level of detail. Wish I could. But some general questions and observations:
First of all, why are you trying to use assembly language here? Do you want to, or do you have to? Not trying to talk you out of it, just wondering the reason why.
About all this object stuff:
There seems to be a lot of mystery surrounding the whole idea of "objects" and "methods", which may make one believe that they're totally impenetrable concepts that can't be used in assembly language.
My guess©® is that this is just not true. Those "objects" and "methods" ultimately have to be just plain functions and data objects, which can be expressed in an assembly-language program. Of course, you have to know what the functions do, what arguments the functions expect, what results they return, and the format of any structures. And of course you need the functions themselves, either in a static library or a DLL. But if you know all that, I don't see why you can't write an assembly-language program which replicates exactly the C++ equivalent code. And without having to use an "object-oriented assembler".
Not saying it would be easy. But it should be possible.
Let's take one example. In the ssl_method_st structure, let's say you want to invoke the "method" ssl_read (in other words, call that function): this can be accomplished thus, using "push-push-call" (minus any needed stack manipulation, which I'm not familiar with but you seem to be):
; int (*ssl_read) (SSL *s, void *buf, size_t len, size_t *readbytes);
PUSH Preadbytes
PUSH len
PUSH Pbuf
PUSH Ps
CALL MySSLmethod.ssl_read
(This may be wrong, as I don't know the X64 ABI; maybe some of those arguments have to go into registers instead. But you get the idea.)
All those scary-looking members are just pointers to functions. That's all. You set up the parameters and call them.
If anything I'm writing here is wrong, I'd appreciate being corrected. I really don't want to mislead you.
On second thought, may be I can help you. You're trying to call a function of type SSL_CTX, right? But you don't call the type; you call the function itself through its pointer, which is part of that stucture:
; SSL *(*ssl_new) (SSL_CTX *ctx);
MOV RCX, Pctx
SUB RSP, 20h
CALL MySSLmethod.Pssl_new
MOV result, RAX
assuming that Pctx is a pointer to a thing of type SSL_CTX, and result is a thing of type SSL.
Aargh; unless you have to dereference that pointer, since it's a pointer to a pointer (*(*ssl_new)), in which case you'd need something like
MOV RAX, MySSLmethod.Pssl_new
MOV RAX, [RAX]
CALL RAX
...
But this is just a guess on my part. Others may be able to figure this out ...
Maybe try this? Do you see what's going on here?
I'm writing a simple SSL client basically. Yeah I believe I would have to rip through that entire SSL code and get just the nitty gritty functions that I want to use and rewrite them. Yes it would be difficult because I've done something similar. Took me 3 months to read the all functions needed lol. All their scary looking contexts boiled down to basically a handful of functions that I just re-wrote and 2 of them were actually assembly routines that I ended up including and calling from the kernel itself. It was kind of funny after reading thousands of lines of code, all I ever needed was a couple lines of code.
I do know how those ugly function pointers work lol. The ones with returning a pointer to a struct looks pretty hairy. I remember going through these in 2015 in King's book on C. He explained it very well. Yep definitely know how to call them in assembly too, you are correct. As you stated, though, those objects all boil down to just some function call anyway, nothing special about them.
Regarding that last part I wrote, I think I misread that structure member.
SSL *(*ssl_new) (SSL_CTX *ctx) means that the member is a pointer to a function (*ssl_new) that returns a pointer to an SSL, so no de-referencing needed (it's not a pointer to a pointer).
I think.
Quote from: NoCforMe on January 23, 2024, 03:13:18 PMRegarding that last part I wrote, I think I misread that structure member.
SSL *(*ssl_new) (SSL_CTX *ctx) means that the member is a pointer to a function (*ssl_new) that returns a pointer to an SSL, so no de-referencing needed (it's not a pointer to a pointer).
I think.
lol yes you're right. Actually that function pointer is exactly the final command I listed in my original post.
SSL *ssl = SSL_new (ctx);
SSL_METHOD_ST 128 80h bytes
version +0h 4h
flags +4h 4h
mask +8h 4h
ssl_new +Ch 4h
x64
SSL_METHOD_ST 248 F8h bytes
version +0h 4h
flags +4h 4h
mask +8h 4h
ssl_new +10h 8h
Quote from: TimoVJL on January 23, 2024, 05:06:38 PMx64
SSL_METHOD_ST 248 F8h bytes
Hmm; I counted 36 members, each 8 bytes I'm assuming (X64), for a total of 288 bytes. ?????
OP: Hate to put flies in the ointment, but why is your structure different from this one (https://docs.huihoo.com/doxygen/openssl/1.0.1c/structssl__method__st.html)? This one (and numerous others I found online) doesn't have the flags or mask members.
I just took it from
https://masm32.com/board/index.php?msg=126423 (https://masm32.com/board/index.php?msg=126423)
Another version:
SSL_METHOD 120 78h bytes
version +0h 4h
ssl_new +4h 4h
SSL_METHOD 240 F0h bytes
version +0h 4h
ssl_new +8h 8h
408 /* Used to hold functions for SSLv2 or SSLv3/TLSv1 functions */
409 struct ssl_method_st
410 {
411 int version;
412 int (*ssl_new)(SSL *s);
413 void (*ssl_clear)(SSL *s);
414 void (*ssl_free)(SSL *s);
415 int (*ssl_accept)(SSL *s);
416 int (*ssl_connect)(SSL *s);
417 int (*ssl_read)(SSL *s,void *buf,int len);
418 int (*ssl_peek)(SSL *s,void *buf,int len);
419 int (*ssl_write)(SSL *s,const void *buf,int len);
420 int (*ssl_shutdown)(SSL *s);
421 int (*ssl_renegotiate)(SSL *s);
422 int (*ssl_renegotiate_check)(SSL *s);
423 long (*ssl_get_message)(SSL *s, int st1, int stn, int mt, long
424 max, int *ok);
425 int (*ssl_read_bytes)(SSL *s, int type, unsigned char *buf, int len,
426 int peek);
427 int (*ssl_write_bytes)(SSL *s, int type, const void *buf_, int len);
428 int (*ssl_dispatch_alert)(SSL *s);
429 long (*ssl_ctrl)(SSL *s,int cmd,long larg,void *parg);
430 long (*ssl_ctx_ctrl)(SSL_CTX *ctx,int cmd,long larg,void *parg);
431 const SSL_CIPHER *(*get_cipher_by_char)(const unsigned char *ptr);
432 int (*put_cipher_by_char)(const SSL_CIPHER *cipher,unsigned char *ptr);
433 int (*ssl_pending)(const SSL *s);
434 int (*num_ciphers)(void);
435 const SSL_CIPHER *(*get_cipher)(unsigned ncipher);
436 const struct ssl_method_st *(*get_ssl_method)(int version);
437 long (*get_timeout)(void);
438 struct ssl3_enc_method *ssl3_enc; /* Extra SSLv3/TLS stuff */
439 int (*ssl_version)(void);
440 long (*ssl_callback_ctrl)(SSL *s, int cb_id, void (*fp)(void));
441 long (*ssl_ctx_callback_ctrl)(SSL_CTX *s, int cb_id, void (*fp)(void));
442 };
Yikes. Version hell?
Quote from: NoCforMe on January 23, 2024, 01:13:22 PMThere seems to be a lot of mystery surrounding the whole idea of "objects" and "methods", which may make one believe that they're totally impenetrable concepts that can't be used in assembly language.
Basically,
- you call some InitMyObject(pToObject) API;
- eax signals whether your call was successful (S_OK) or not;
- if successful, pToObject points to n bytes of memory;
- this memory is
structured, i.e. you can access its bytes as
mov esi, pToObject
myObj equ [esi.NAMEOFSTRUCT] ; an equate to avoid [esi.NAMEOFSTRUCT].someMethod
a) mov eax, myObj.colorOfObject
b) push Rgb(255, 128, 0) & call myObj.changeColorMethod
That's all, mystery solved :cool:
Converting C structures to assembly isn't always trivial.
SSL_METHOD STRUCT
version DQ ?
flags DQ ?
mmask DQ ?
Pssl_new DQ ?
Pssl_free DQ ?
Pssl_reset DQ ?
Pssl_init DQ ?
<snip>
Pssl_ctx_callback_ctr DQ ?
SSL_METHOD ENDS
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" ).
So this struct probably should rather look like this:
SSL_METHOD STRUCT 8
version DD ?
flags DD ?
mmask DD ?
Pssl_new DQ ?
Pssl_free DQ ?
Pssl_reset DQ ?
Pssl_init DQ ?
<snip>
Pssl_ctx_callback_ctr DQ ?
SSL_METHOD ENDS
Don't miss the "8" behind "STRUCT" - structure alignment MUST be 8 to ensure that all Qwords start at an "8-byte boundary".
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
Quote from: _japheth on January 23, 2024, 11:44:32 PMThere 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.
Quote from: mabdelouahab on January 24, 2024, 05:32:12 AM 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.
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!
Congrats, you seem to have lots of fun :thumbsup:
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.
Quote from: jj2007 on January 29, 2024, 08:29:22 PMCongrats, you seem to have lots of fun :thumbsup:
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.
Quote from: cyrus on January 23, 2024, 12:18:52 PMI'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
Quote from: mabdelouahab on January 31, 2024, 06:16:55 PMQuote from: cyrus on January 23, 2024, 12:18:52 PMI'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.
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?
Quote from: cyrus on February 02, 2024, 02:26:31 PMguess most people just don't bother with the extra headache?
Except me :biggrin:
This example works well for me and without errors
.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
Quote from: cyrus on February 02, 2024, 02:26:31 PMguess most people just don't bother with the extra headache?
That is an ideologically loaded question, my friend :badgrin:
I've coded a library in 64-bit (search the forum for JBasic), and it was fun but I certainly prefer 32-bit code.
Quote from: jj2007 on February 03, 2022, 10:50:12 AMBetween 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).
Quote from: jj2007 on February 02, 2024, 07:55:42 PMQuote from: cyrus on February 02, 2024, 02:26:31 PMguess most people just don't bother with the extra headache?
That is an ideologically loaded question, my friend :badgrin:
I've coded a library in 64-bit (search the forum for JBasic), and it was fun but I certainly prefer 32-bit code.
Quote from: jj2007 on February 03, 2022, 10:50:12 AMBetween 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
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