Kas Ob.

So after looking more at the encryption code, i stand with claim above, but .. It could be my old and outdated sources, they either : 1) Should hashed the data along with the randomly generated IV, and leave it out of the encryption, or 2) They should have encrypted the hash along with the data, as this looks like a single mistake (old mistake), it might be changed or fixed, though this will break compatibility between versions, the code to fix this FEncryptor.EncodeBuffer(TValueArr(Result), KEY_GUID_LEN + IV_LEN, CipherLen - HashLen, TValueArr(Result), KEY_GUID_LEN + IV_LEN); // should be FEncryptor.EncodeBuffer(TValueArr(Result), KEY_GUID_LEN + IV_LEN, CipherLen , TValueArr(Result), KEY_GUID_LEN + IV_LEN); Any fix will break compatibility, so in my opinion they should deprecate "ehTagAndHash" and use it only for decryption, and introduce ehTagAndHash2 with either of two suggestions above, but this will break compatibility backward too. Of course any changes of the above suggestion need adjustment in the decryption too.

Yes, (though outdated). Also yes. Your problem is not with the key itself, the key literally as i mentioned above, concatenating SHA1 and MD5 of the password, also the mode is CBC, so less work there. Your problem is in the code in TCREncryptor.Decrypt (and TCREncryptor.EncryptBytes) , these are very nicely done and very secure with authenticated encryption (with TagAndHash enabled), along random IV for each and every encryption operation followed by magic number "$BAADF00D" indicates the length of the data, hence removing the need for padding, it is well done until they missed to include hashing the IV with data (!!) this will leak information about the encrypted data. You are more secure with only "ehTag" in DataHeader property than "ehTagAndHash", no leaked information about the data, preventing any differential analysis, but with this you will lose the authentication. I am sorry that i can't share any source code from a proprietary code licensed to me, as you seem you don't have it, but with the above few lines you can ask them to fix their mistake and answer your support ticket. Hope that helps.

However, also i looked at my UniDAC (also expired but way newer than MyDAC) and there is TUniEncryptor and as the DAC components are shared between all DevArt libraries, i think the algorithm is still that old and with not best practice or standard password-key derivation, as changing it will break compatibility unless it is explicitly had an option to switch to newer one, and i don't see such option, in the online help for the latest ones.

My MyDAC expired long time ago, and i never used their Password2Key algorithm, i always used a key directly with the encryption, but when needed to be password derived i used HMACSHA256, the algorithm to derive the key (in the my TCREncryptor) is outdated and not secure enough to provide 256bit security and may be not even enough for 128bit, the code does concatenate the SHA1 with MD5 of the password. Anyways, you would better contact their support for this question in case you can't recognize the used algorithm, while if you have the source as i do, then it should be in "procedure TCREncryptor.Password2Key;", but again in MyDAC there is no TMyEncryptor, there is only TCREncryptor, which means they did refactor this and may be the algorithm too.

Try this procedure TForm10.Button1Click(Sender: TObject); var MyReg: TRegistry; begin MyReg := TRegistry.Create; try MyReg.RootKey := HKEY_CURRENT_USER; if MyReg.KeyExists('\Control Panel\Cursors') then begin MyReg.Access := KEY_WRITE or KEY_READ or KEY_WOW64_64KEY; // KEY_WRITE or KEY_READ together or we can separate them per operation if MyReg.OpenKey('\Control Panel\Cursors', False) then begin //st := MyReg.ReadString(''); MyReg.WriteString('', 'Windows Black'); end; end; finally MyReg.Free; end; end;

I want to know and solve this, away from Windows Server 2003 and Windows XP rare existence, it is nice to have unified version to support them all, this single API stopped a punch of great and old software and split many repository. I don't see this as stupid or waste of time, if a time spent lead to a result in testing something, success or failure, for me this is well spent time.

Great and perfect and Thank you !

Right, i should have mentioned that may be as i read that second source you linked. According to this i have the it should (might) work for all starting from Windows XP SP2/SP3 and Server 2003 SP1, and that include 32Bit and 64Bit , as shown per declaration with 64bit size in that link, It is the same declared in DDK headers https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntddk/ns-ntddk-kuser_shared_data also here explain the size of KSYSTEM_TIME https://osm.hpi.de/wrk/2007/08/getting-os-information-the-kuser_shared_data-structure/ And there a confession to make there is a condition i omitted in the code because i don't see it as big relevant, in 64bit there is a loop to establish that High2Time and High3Time are identical, this happen if updating one was happening at this very exact moment, i tried to slow my CPU by overloading up to 100%, and couldn't make this trigger, then tried to downclock and overclock CPU, as mine is Intel unlocked (model with "k"), yet even over more than an hour and in both cases could capture such case not even once, and i am not saying it is right to capture it, but i am saying statistically i satisfied, also even when they are not identical, meaning the result will be as much as it was like 100ns before, so no harm there, this can affect and important for kernel drivers, but can not be critical for any software in user mode.

Well, not exactly, QueryPerformanceCounter does have higher resolution but with lower accuracy, it is tied to the CPU cycles, at that low level, yes it has very high resolution, but when the CPU throttle or switch power profile it will start to return far from accurate result, also will be far from accurate in hibernate, GetTickCount on other hand depends or gets its clock timing using BIOS clock interrupt which in turn gets its time from the MotherBoard chipset, this one doesn't suffer from power profile effect, these chipset runs at constant frequency and they are very accurate but with lower precision than the CPU, due to their difference in base frequencies (CPU and motherboard chipset).

I opened a thread about GetTickCount, that safely replace this GetTickCount64, but will wait until confirmation of success result as explained there, before suggesting to replace any short coming of GetTickCount64 this with that direct (emulated) version.

On side note: I never saw "/ph" and "/nph" being used, and honestly don't know what exactly they do, only can imagine or assume, If you have any resources on this, i would appreciate sharing !

Nice ! Few thoughts : 1) Albeit there is no mention for Remove/Delete a signature in Microsoft documentation in three different places for SignTool https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/signtool https://learn.microsoft.com/en-us/dotnet/framework/tools/signtool-exe https://learn.microsoft.com/en-us/windows/win32/seccrypto/signtool The command "remove" is useful and pretty needed, sometimes it is essential, example, you want to switch form internal debugging/testing signature to release, and don't want to ship with your organization internally issued signatures and its certificate, so remove/delete is needed, and it is there within SignTool.exe, i remember have seen in the documentation in the past ! 2) With SignTool there is "/ac" option for the Sign command, this one can be crucial for new CA certificates, as best practice dictate to include the chain of trust path excluding the root, root must not be included as it will be considered waste and manipulation (root should be presented and trusted by different source like OS store or any higher/adequate administrative authority), but CAs between end point and root can be the line between verification and failure, including the chain of trust is essential for old systems and/or new CAs, so you might need to consider to add it. 3) Identifying or choose the certificate by thumbprint is OK, but i would suggest to use similar method like SignTool and IIS, by adding "IssuedTo/SubjectName", this will minimize the hustle of update thumbprint on client/terminal side when more than 1 certificate do exist, as they will exist, like generally you order new certificate while the soon to expired still there, if you look at IIS, it always select the newer certificate after filtering the available certificates with Subject Alternative Name match the domain name, same for sign tool does the same by "/n" option and looking for the SubjectName, so adding this also make sense. Well, this comes to mind and thank you again !

Yes not for everyone, yet the decentralization and distribution of the signature log might help or at least increase the chance of avoiding catastrophic failure or again at least faster response, in case of compromise did happen, some might look and see logs with different colors of the names and/or the time of multi signature happened at 3AM then you go why and what Andres had signed binaries, could his station being hijacked !, lets notify him or the responsible person. Anyway, food for thought, and this what i did and my clients loved it !

Then i would expand on this and suggest to make like what i did, on every sing issued the result on both GUI and console client side, it does grab last few signing operation and disclose them to every one is singing, as the best security is transparency and awareness, this means any singing developer can have a glance of what have being signed last 5-10 singing procedures, with time, dates, authorization and the binary name. Just food for thoughts. And thank you very much !

@Vincent Parrett Feature suggestion even before seeing this great tool As i already did 3 projects for 3 different clients, although it wasn't for USB or hardware tokens, but for usual certificate and its private key, the project was to keep the private key securely stored away from developers machines, yet monitor what executables were signed and by whom, stored IPs and devs authentication in detailed nice logs, also the administrator could allow only the digest to be shipped to the server but also allow the administrator to choose who can not sign without uploading the whole binary to be stored on the server for .. security and trust reasons. My suggestion is to expand or at least consider the forced operation logging on server side, this is not something belongs to best practice and i am sure it will be requested sooner or later.

Name suggestion if you interested : "DSign" or "DSigning" from Distributed .. ihm... i meant Delphi . The latter yield zero search result on both DDG and Google.

Yes they have reasons, and this 100% doesn't include solving your mentioned problem, these APIs are about locking/reserving physical memory, to one end and one reason, minimizing page faults for one critical application, hence recover or reserve performance as much as possible, and by performance i mean the just to prevent losing performance due to high memory usage and paging to file, and that is it. I can't imagine how this can help your application not crashing, but i can few scenarios where it delay the crash enough that you don't notice, this does not fix the problem, and there is bug(s) somewhere, it might be 1) Your bug very similar to the @dummzeuch mentioned, it is coming from casting pointer to signed integer then perform some operations on that integer, like shuffling it to other variables, or do some arithmetic operation with it, back in days 32bit application had 2GB and there wasn't a problem, i mean there wasn't crashing or access violations (because the problem is there waiting), then comes the boot switch /3GB that allowed/added one extra GB to the memory rendering all the abusing of the pointer as access violation, but this didn't happen or noticed right away as it will happen arbitrary, and only when your application utilized so much memory, in newer Windows version, the OS started to make this allocation addresses more arbitrary, hence these bugs started to show even if your application didn't utilize a lot of memory, anyways, these access violation and miss use of pointers, could be easily found and fixed by use the FastMM4 with MEM_TOP_DOWN, which i remember is default, hence will fixed right away, without you might depend on luck and high memory usage to capture. 2) Your application in fact using high volume of memory but it does abuse threading and miss using timing, if you have one Sleep because you are assuming an operation will take 5ms and you gave it something like 500ms, that should be fine, right ? NO ! , you are wrongly assuming this can be enough, because when when paging hit, the operation will block, by operation i mean a single CPU instruction will trigger OS VMM intervention due to hard page fault, and this thread will block until VMM free some physical memory, not really free (!!) but stop another thread/process and then write its memory from the physical to the page file, then load you paged memory, then continue your thread, by continue i mean literally re-execute that single instruction, the one stopped the earth planet form rotation. These bugs coming from miss using timing where very frequent back in days with HDD, with SSD it is faster and wrong logic might pass unchallenged, yet with heavy software running on OS like Windows Defender that literally capable to utilize the disk operation at tens of thousands operations per second when it does scan, these bugs come to light again. So i hope that was readable and clear, and of course i hope helps identifying your bugs, but one thing is for sure denying physical memory by manipulating working set, is not good sign at all, let your application be free of bugs and let it take small extra time due paging, and let the OS perform as intended.

The listed errors are linker ones, which means there is a confliction in the compiled source units, to understand these errors you have to get in the shoes of the compiler and linker, the compiler check for the source file time for last modification and build the .o/.obj (same goes for the .dcu in Delphi), (well dates and times among other parameters but most relevant is the time) if these times are identical then will skip compiling !!, assuming it is the same and nothing changed then nothing to recompile, linker on other hand will build the executable binary from scratch and from its own build version, here comes the unresolved externals... in case the .o/.obj files were built/compiled with different compiler form different IDE. Delphi doesn't suffer form this because DCU files has the compiler version included (again among others, like all the compiling switches are there in the DCU) , while .o/.obj files can't be used effectively as dcu files. So it is either bug in the compiler where it should check for the compiler version (and project switches) before skip compiling, Or you have to clean your paths from all artefacts (.o , .obj...) to be able to build on different compiler, I can't say for sure about this being compiler bug or not.

At +5 pixel, most likely you are resizing the form from the corner, try to increase this, or pick a point where no resizing might happen, +10 do it , like this SimulateMouseDrag(left+10, top+10, left+200, top+200);

Should be {$SETPEFLAGS IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP or IMAGE_FILE_NET_RUN_FROM_SWAP or IMAGE_FILE_LARGE_ADDRESS_AWARE} You missed an "or" !

What happen if Windows Service called "Theme" is stopped and disabled ? Will the flicking continue to exist with RDP ?

I wouldn't expect much on/from this, for many years i am not fan of what Embarcadero focusing their effort and resources, but about this particular one, i don't think they can do much. Take an example CFG, it is still new and not fully matured by Microsoft itself, while the real deal (the devil most needed) in its parts is RFG, this one in particular is not standardized and i really don't expect they will have any specification any time soon if ever ! Without written specification, no compiler and linker can perform/produce compliant code, a code that OS require to to perform undocumented behavior while still changing on the OS part, so ... Embarcadero can't help or do much for now, yet there is parts can be implemented, here i am talking about parts to be comply with the known and documented part of the CFG. The request for RFG is outrageous and out of the reality as you mentioned it, even Rust with LLVM can't do it. I expect that audit is more like the more the merrier in a (longer) list of checkboxes without thinking them enough, and it is their right to do so after all, they should everything they can think of, the red line is were to make it a deal breaker. On this i agree, this is Embarcadero lack or lag in this space, they neglected this part for very long time, i mentioned 2 DLLs out of punch i came across and you have one, i had in few projects to remove the import for these two DLLs to raise a project rank in VirusTotal, signed or not signed was it. But for Embarcadero to do something about this they need put effort and ask for what should be removed or adjusted, the community can report them, of course some public awareness is critical here, so an initiative should be take a place, started by Embarcadero. I am out of touch with the new IDEs, and really don't know if the mentioned above DLLs still relevant now, but many here aware about this now and can help, as for FireMonkey and cross platforms.

Other than checking the Edition, i would do compile an empty unit and check for the artefact or the output, though i never installed or used CE, so might be wrong about this approach, but the fact it is not exiting with ExitCode=1 is disturbing non the less D:\Program Files (x86)\Embarcadero\Studio\16.0\bin>dcc32 EmptyUnit.pas Embarcadero Delphi for Win32 compiler version 29.0 Copyright (c) 1983,2015 Embarcadero Technologies, Inc. EmptyUnit.pas(8) 9 lines, 0.02 seconds, 15 bytes code, 4 bytes data. unit EmptyUnit; interface implementation end.

May be the approach is very similar between CnWizard Editor Enhancement and newer IDEs, adjusting the gutter after seeing the need to, combine this with very busy system at this moment to cause some delay in update. Anyways, i was just pointing that this behavior or visual effect is/was there with older IDEs.

I witness this in both Delphi 2010 and XE8 almost always, this visible more in XE8 and when the Editor open a big file for the first time, it adjust the gutter on them all, if the editor has a file with more than 10k line it will be most noticeable. BUT, 100% sure this artefact from CnPack/CnWizard in my case.