Kas Ob.

Looks like it doesn't support older Delphi versions (up to Seattle it doesn't) , so sorry for this not so sure comments. AES don't rat ass to the any values being fed, but it is all about the length of the data, here comes the problems with padding. for more information about this you can read https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Padding This base64 have the length of 64 chars meaning it will decode to 48 byte, so in theory the IV would be 16 out of these and the rest will be the encrypted text. I really recommend to refrain from using the _MAX_ everywhere, and either fix the lengths as you know the algorithm/scheme is used, or use other OpenSSL function to get the right lengths, it will spare you troubles down the road. Now if EVP_DecryptFinal_ex failed then this should mean one thing and one only, EVP_DecryptUpdate received data and still waiting for more to be compliant with the parameters from EVP_DecryptInit_ex and the used padding scheme. With some searching, found this https://stackoverflow.com/questions/53394102/openssl-decryption-evp-decryptfinal-ex-fails Hope it helps.

Now I have a theory, See, that RtlFreeHeap, this one since i saw it and it lingered in my brain, it makes less sense every time i think of scenario for it, RtlxxHeap functions belongs to Windows Driver realm (WDK), and they have very specific usage to communicate and share memory with drivers, so why is LibCrypto is freeing such a heap ? and what could have went wrong? The Answer for these might be simple, your OpenSSL library used a hardware token or loaded a certificate from some hardware most likely a USB devices, this device was either a malfunctioned driver, a conflict with more than one driver, or simply it was unplugged ( also here comes some interference from other factors, like i have a rare problem, when i have my mobile doing heavy wifi traffic and i put it close to the monitor some times the monitor will flash to black in this second i notice that my back lighted keyboard also flash to black like it was unplugged and re-plugged) this will cause the driver to stop and restart. Also a fact everyone should know, almost all Windows drivers will not upload form memory, they will stay there disabled and removed, they will linger there, taking resources by design as performance wise, next windows restart they will not be loaded. So if you didn't restart your PC for long time, also you have changed or switched or updated your drivers, then as silly as it might sound a restart might fix this for good. Try to remember what did happen with your hardware and reproduce that exception, are you using hardware certificate storage? did you unplugged it while you application was running ?..... Also it is unlikely to be an OpenSSL bug, because it might be something you configured it or copied some settings from the net, if you are not using hardware storage then make sure OpenSSL is not looking for one. Hope that help, and good luck.

I can't answer that, sorry. This is really nice catch !, and it will be useful for everyone if you share with us, how you did it and what setting EurekaLog did you have. This should not be important, i mean if the connection was broken or not or who initialized the closing. My thought on this based on the screenshot: 1) ResetSSL is the last call from Delphi application the rest was in OpenSSL, while freeing a memory allocation. 2) The hang was caused by WER (Windows Error Reporting), ZwWaitForMutipleObjects is waiting for WerReportExceptionWorker. 3) The application is Windows Service which means it is not allowed to have GUI elements, so the system in theory should have froze the service then WER kicked in and asked for allowing to report (to upload to Microsoft), of course WER generated a dump log somewhere, but may be WER was configured to automatically upload the report. So in my opinion, you should check your WER setting, (there is many resources on this, simple search will help), the most important is was WER generating the dump and it took very long time?, or it was generated and was uploading it without you interaction ?, or it was blocked from by firewall from uploading?..... That on one hand, on the other hand EurekaLog can capture (raised by 3rdparty/system libraries), the exception raised by a DLL, and the system stepped instead of handling this differently by returning the execution to the application (to the last try-except), the Windows kernel decided that exception is critical and in need to be reported, so if you can produce that specific exception, then i suggest to train on it, have fun capturing it with EurekaLog before WER interfere, you will gain experience with EL and system exotic exceptions. Another thought, i see that you are using timers, so what is the probability of that Send (in your code) being called while another thread is releasing the socket or OpenSSL resources, is there a chance that your application somehow calling ResetSSL on already freed/released context ?, in other words is there a threads race to reset/close/free that socket ? Hope that helps.

How about such solution ?

The last Delphi IDE I have is Seattle, and these are unknown to both of us (me and the IDE) No, it was just researching for live video long time ago, and was completely sure that WMF is worthless as it, CPU usage was unacceptable high for ASF video while the quality was good, also synching the audio with video was big problem as i needed to use my own jitter to fast play the audio when a delay in traffic over wire were introduced, the result was no for it. The whole API give you the sense it was built for specific Microsoft software, unlike Windows libraries. Well i don't think you need help you are doing great job, please feel free to share any question to brain storm it together.

Some problems !, one might call WMF the mother of all problems that can encode and decode. I remember trying use the encoder in real time for live video chat, and dropped it later and never looked back. Anyway, i can't compile and run TBitmapEncoderWMF, but i looked at the source and found this the following line This to my experience with the whole Windows Media Foundation that approach is a problem, and most likely a core problem in your encoder. The problem in such calculation with that your are not using audio sample rate and the ability to divide the audio sample right, so my suggestion is to to round that fSampleDuration to what audio sample allow you and will be acceptable to the encoder and of course to the decoder in later stage. To understand the problem and forgive my English and inconsistent phrases, you have to know why the standard of the audio sample rate for many many years was 44100 hz, why this number and from where it came, please read this https://en.wikipedia.org/wiki/44%2C100_Hz and see its there for compatibility with PAL at 50 fps and NTSC at 60 fps, so to make it right in your encoder you should choose fSampleDuration according to acceptable/right audio sample rate, that will add to exact (real exact like 44100) audio sample rate per second. Also you should make sure that audio sample rate and the sample rate buffer have the right channels, you can't have audio sample rate with 2 channels and feed the encoder an odd number of samples !, same goes for 5.1 channels or 7.1, just food for thoughts, if and most likely you are doing 2 channels (Strereo) then the audio sample per frame should always be even number. By the way, it is beautiful code what you did there !

In fact that is bad practice, it is allowed and will work though, unless proxies and cache managers on the road interfere. CloudFlare and Firewalls also might suspect such payload in header and remove them.

Well, if you insist on going this then i suggest to just hash the X509 certificate file in whole and check the hash, and call it done, this will be identical to the thumbprint but with different value.

@sfrazor You are defeating the whole purpose of using X509 certificates with SSL/TLS by comparing the certificate elements. X509 infrastructure is there to establish a chain of trust, means you don't need to ..... really long story....!!! I will try to simplify the process in few steps to utilize X509 certificates the right way. 1) Create self signed certificate and lets call it root, you must not disclose its private key to anyone or anything, means even your client and server must not have its private key, but the client must have it, the certificate its self. 2) Put that root certificate in place to accessed by the client, either install it in Windows store or even better use the ICS bundle store. 3) Create Another certificate and lets call it SC ( server certificate) and sign it by the root !, this one should be with your server with its private key. 4) That is it, we are done preparing, the client on handshaking will verify the server certificate (SC) against his included trusted root ! also you can add middle certificates between the Root and the SC , and those called CA , these can be included with client bundle or sent with the SC as a reply for the Client establishing a handshake. Please try searching and researching this process more in detail, and if you need better or easier way to generate certificates then try this https://hohnstaedt.de/xca/ Also you can use as a safe place for your certificates and their keys.

It handle a translated version without colors, while browsers handle this more elegantly and translate it back to the 4 bytes version, to my knowledge Windows started to support the emoji Unicode in full with WIndows 10 version 2H(something!!) and Windows 11 does it too, but older versions all does some translate to an equivalent Unicode versions, browsers does the opposite and translate to the the newer, also all languages are supported from decades ago, but a newer versions also exist. Take this PizzaSlice on this browser it does appear like this 🍕 , colorful as in this image , in Delphi EditText you can try and input from Windows directly by opening the emoji keyboards with WinKey+. Now in Delphi it will appear like this Delphi can handle this as two bytes WideChar perfectly and Windows will take the short one just fine, and any browser on paste will translate it back to the color one, Lets try something different to capture the real bytes for this, open an empty text file then write that emoji, on my Windows 10 ver 1803 it does appear black, and lets save that file with UTF8 and with Unicode, here are the files PizzaSlice_UTF8.txt PizzaSlice_Unicode.txt And in hex their content ( bytes) PizzaSlice_UTF8 contains this EF BB BF F0 9F 8D 95 , EF BB BF is the UTF8 header PizzaSlice_Unicode contains this FF FE 3C D8 55 DF , FF FE is the Unicode header These bytes are the correct content for this emoji without any translation and can be confirmed by visiting this page and paste the pizza slice and look for the hex out put https://onlinetools.com/unicode/convert-unicode-to-hex PizzaSlice_UTF8.txt

I have no idea what you want to say here. Sorry i missed a word "the answer is :", i was answering my own question the one you answered above, and yes this is wasn't problem. Yes it is exactly what you said, as long that char fits in 2 bytes UTF16 or a widechar with 2 bytes, then it will fits in 3 bytes UTF8, no debate there. This is not a problem as long the input from Delphi or from a system like Windows OS which traditionally couldn't and didn't in the past support these UCS-4 aka UTF32, but now windows does support them like Android, and this makes a problem. Take an example this pizza slice emoji 🍕, in the past there wasn't away to input from keyboard but now windows does support it, this pizza slice is 3 bytes in Unicode, but it is 4 bytes in UTF8 and UTF16, and Delphi with its String or WideString will not be able to handle it, but again since long time ago Delphi RTL switched to delegate all these operation to WideCharToMultiByte and MultiByteToWideChar. This is not the case with Delphi 7, and away from that emoji char, the OP did say he didn't have exotic chars in the traffic, can be the data received and handled by OpenSSL contain 4 bytes char, just because he is using HTTP request does imply the probability. I was saying exactly what you did say, and expanded on the fact when using traffic from internet we can't expect it to fit in Delphi 2 bytes per char strings. Anyway, i sounded my opinion about such GDI leak from AlphaSkin based on my point of view, and still see the cause by overflowing buffers or overwriting memory, to me the logical and easiest way to explain such behavior based on what OP said all happen with introducing ICS with OpenSSL and threading, and the fact if this overflowing was having anything else than zero's AlphaSkin code should generated hell of exceptions, threading problem can't be so consistent with zeroing memory, this leads me to deduct the only place that could make this happen with Delphi 7 and it outdated way to handle strings with different encoding coming from OpenSSL input and output, that is it.

@PizzaProgram Good luck ! Not only for that 😎, also for a slice of pizza 🍕

OK, i don't want this to as debate, but few things here should be pointed, True, but, UTF16 is either one or 2 of 16bit units ( it is called unit in Wikipedia), so it is either 2 bytes or 4 bytes, why this wasn't ever a problem with all versions of Delphi ?, The is : simply because all the input and output where either internally generated data or by the OS ( mostly Windows), Windows API always refer to them as Wide, anyway this shouldn't a problem as long as the input and output is from Delphi application or the Windows, but in this very case the data are coming from remote place over the wire who knows the origin, also being handled by OpenSSL, so assuming it is will be 2 bytes UTF8 or even 2 bytes UTF16 is at least doubtful. I really looked and looked then looked again, i just don't see failing point in both functions Utf8Encode and UnicodeToUtf8, this UnicodeToUtf8 though does trim but never fail, will return 0 if the input is an empty string other than that it will trim the result according to supplied buffer if it is shorter than needed, but will not fail. It would be very helpful if someone paste the code of these functions here, of course if that not violating some license.

How is this not wrong if this function assumes a UTF8 char can be only 3 bytes max instead of 4 ? What else is wrong with that conversion function, have you seen these two calls in one line of code, are we juggling strings left and right through many types from WideString, AnsiString then UTF8String with wrong max length and expect it to not be wrong, because it does work sometimes ?

I think you are following the wrong thing here, even if this problem caused by loading and unloading OpenSSL which i doubt, but yet you can just log the loading and unloading operations with their result to a file and be sure. If my hunch is right and it is caused by the intense allocating and reallocating operation done by both AlphaSkin and ICS with OpenSSL, then minimizing these operation by caching objects and reusing will only minimize the effect and delay the inevitable, this bug is just like ticking bomb and you were unlucky enough that is not crashing sooner. I don't have My Delphi 7 at hand so checked an old projects and looked at the code without even running it, and here saw this gem In Utf8Encode there is this Length * 3, which assuming the size of UTF8 char would be 3 bytes at max, among this pasta with a call to WStrToPChar, which is mindboggling in the middle of converting a string to convert it first then convert it again, it seems Delphi 7 may be wrong in handling UTF8, it is +20 after all, and the fact UTF8String is used as RawByteString, raise even more questions. Now assuming ICS (with dropped Delphi 7 support) is right and not missing with such conversion, i suggest you try the following 1) Use UnicodeToUtf8 and Utf8ToUnicode directly instead of Utf8Encode and Utf8Decode. 2) Use more aggressive memory manager to detect corruption, really you should try EurekaLog, it is the best ability to all sort of memory malpractices along with leaks resources like GDI handles. 3) Log all the strings in raw format to a file, write them to a a memorysteam separated with some chars then flush that stream to the disk, se for yourself the result. Hope that help.

+1

Yes. Using remote Delphi debugger or using different debugger to get these addresses will be way more accurate and easier. This one is the best out there https://x64dbg.com/

Also was there a UTF8String in Delphi 7 ? and how it being handled in , what did Length() return, length in bytes or in chars ? I have no idea.

May be, ! I might be wrong here but there is bug with string copying somewhere.

No ! The thing is : the bug might be not in this code you pasted and could be in other places even may be in ICS , Delphi 7 is not supported and things might be missed, also your suggestion of this "-1" explain that you need to research the difference between string (default) with WideString and AnsiString and UTF8String .. Here if UTF8 is 2 bytes per char then it should be or to make it safer when you are in doubt then, hard to me to advice this but but as i said the problem might be not only here (i mean these 2 lines), you have to research and understand these strings and their size then adjust your code accordingly. While i can't be sure 100% it is the problem but with high confidence it is the culprit but overflowing memory write.

I think screenshot would helped earlier, so others here could spot the problem for you, look at these is that what do you see ? The first one is an new project while the second has this So i think you are following the wrong thing, as many tools are build for Windows binaries with PDB debug information, in this case it could find a suitable address (previous with an export or known from the debug info) so it grabbed the closest before the address and resolved it as entry point. Find the culprit address by calculating the address of TMethodImplementationIntercept +xxxxxx then follow it in you debugger, or attach a debugger or... may be try Andres PDB debug info tool see if that works with your watching tool, or find another tool that does show an address instead of a relative address ... Hope that helps, and good luck.

This AlphaSkin is innocent here, though these leaks is definitely GUI objects, they are not freed and most likely with not closed handles. How this happen is easy to explain (i think), your introduced code most likely copied and pasted form ICS demos (assuming) but in all cases you are missing the part of converting and adjusting the read size for those strings, hence you are overflowing buffers and writing in places you should not, and because FastMM allocate memory once and reuse its parts will allow such overflow, also both AlphaSkin and ICs( the way you are doing it by not caching and reusing components) have very memory intensive operation, the code keeps overflowing and destroying GUI handles and may be other things, and that making AlphaSkin after each failed operation to respawn/recreate these handles and allocate memory on them. ps: many of the OpenSSL objects have zeros in its contexts or will be zeroed for security reason, so the overflow is writing 0's which make AlphaSkin think it is not allocated objects and not throw an exception.