Here is an example by Fusix, though it uses classes too. We are working on it. Also I think we'll use previous contribution.
why not use xml instead of ini file? support already exists for xml. the issues you pointed out i will correct. thanks for the code check. will u use the ini file loading by Fusix? i can add the getKeyValue*** related functions i created to the Fusix code
UPDATE: A new INI reader module has been commited into the repository. Linking it with rdpwrap... also I'll test it. Yes, I used Fusix's code and also mentioned your help (see git history). Updated source is on GitHub, it looks like finished. Also I think INI is more readable by most of the users.
true the ini file is easier to read but most users cannot edit it. because you need to use ida pro to search the asm its always going to be non user friendly. so the use of an easy to read ini file is moot at this point. if we could add self updating to the hook then the need to use ida pro to update the ini file would not be necessary. the ini file too would not really be necessary as it would update itself. i noticed you have an address search function in the code. possibly it could be used to guess the address locations? to recap. ini support is added to github? does it support the latest version of termsrv.dll for win 8.1? or should i crack out ida pro to update my ini file using the latest github code? Also using the compiled c++ dll is clunky. installing it needs to be done via the batch file. i could wrap an installer around it using VS click once install feature. that way the installer for the c++ dll works similar to the delphi version you have.
I'll leave update feature to the end users. Because automatic update requires implementing algorithms such as update authenticity. Some antivirus software doesn't like automated update. INI contains some settings which can be modified by a regular user, such as some policy values. Also it's simpler to replace old INI file with a new one and restart the service. This code was from older versions, maybe even from the first beta version, because offsets was not used. Now it isn't needed because we have offsets. Searching for some offsets automatically is impossible due to technical problems. I already commited new INI file to GitHub. It supports latest termsrv of Win 8.1. We are on finish line. C++ installer is not needed. You can test your builds by replacing (renaming) old version with the new, then restarting the service.
the c++ code doesn't compile because some delphi specific functions were included. also some old ini file handling was still there. windows primarily supports unicode so any winapi specific funtions you may use would require unicode parameters. mixing ansi with unicode calls for conversions and such, what a pain! i converted everything to unicode as there is no way to modify winapi functions. some unsecure c functions were used as well, should be converted to safe and for ease of use switched to straight C++11
i may have found some issues, specifically with 6.3.9600.17415 which is the whole reason i am involved! i see that you have support for it in the ini file. BUT when i use the delphi version to install the ini file is not installed. should i include it manually? even if i include it manually it is not working. seems like it is not loading it. is it in the correct location? same dir as the rdpwrap.dll correct? i am going to test this out on a VM today to try to hash out some issues.
Yes, you need to place INI file in the same folder with rdpwrap.dll (copy it manually) I didn't updated the binary for INIs on git, so I'll attach it for you.
is this part of the INI correct? ; .text:0000000180033CE3 lea rcx, [rsp+190h+VersionInformation] ; lpVersionInformation ; .text:0000000180033CE8 mov ebx, 1 <- 0 ; .text:0000000180033CED mov [rsp+190h+VersionInformation.dwOSVersionInfoSize], 11Ch ; .text:0000000180033CF5 mov [rdi], ebx ; .text:0000000180033CF7 call cs:__imp_GetVersionExW SingleUserPatch.x64=1 SingleUserOffset.x64=33CE9 <===== SingleUserCode.x64=Zero shouldnt it be 33CE8
how are you getting the c++ code to compile? there are missing references all over the place! Specifically in the Hook function. PatchList is not declared anywhere and almost right below its first use is INI->ReadSection which doesn't exist. Also this line is not possible Patch.length and SListFind function does not exist
Hi binarymaster, a big thanks to you, really a very great tool. I have tried it on W8.1 (core) and it works fine. Only one question: a new feature to implement remoteapp on W8.1 (core)?
Yes, it's correct. The 33CE8 offset points to <mov ebx> opcode, and the 33CE9 offset contains DWORD = 1, and I change it to 0 (zero). C++ code is in incomplete state for now, it would not compile But we are working on it. The binary file I posted in previous message is built off Delphi source code version. Well... that's interesting idea, but I didn't use it and I need to know more technical information about it.