cs.rin.ru
Open in
urlscan Pro
2a06:1700:0:3a:43:5352:494e:1337
Public Scan
Submitted URL: https://cs.rin.ru/forum/viewtopic.php?p=2536753#p2536753
Effective URL: https://cs.rin.ru/forum/viewtopic.php?p=2536753
Submission: On May 07 via manual from JP — Scanned from JP
Effective URL: https://cs.rin.ru/forum/viewtopic.php?p=2536753
Submission: On May 07 via manual from JP — Scanned from JP
Form analysis 5 forms found in the DOM
POST ./search.php?sid=237186f86bf190177834285ce5f8d8ee
<form method="post" id="topic-search" action="./search.php?sid=237186f86bf190177834285ce5f8d8ee">
<input class="inputbox search tiny" type="text" name="keywords" id="search_keywords" size="22" value="Search this topic…" onclick="if(this.value=='Search this topic…')this.value='';" onblur="if(this.value=='')this.value='Search this topic…';">
<input class="button1" type="submit" value="Search">
<input type="hidden" value="119395" name="t">
<input type="hidden" value="msgonly" name="sf">
<input type="hidden" name="terms" value="any">
</form>POST ./search.php?sid=237186f86bf190177834285ce5f8d8ee
<form method="post" id="topic-search" action="./search.php?sid=237186f86bf190177834285ce5f8d8ee">
<input class="inputbox search tiny" type="text" name="keywords" id="search_keywords" size="22" value="Search this topic…" onclick="if(this.value=='Search this topic…')this.value='';" onblur="if(this.value=='')this.value='Search this topic…';">
<input class="button1" type="submit" value="Search">
<input type="hidden" value="119395" name="t">
<input type="hidden" value="msgonly" name="sf">
</form>Name: viewtopic — POST ./viewtopic.php?f=29&t=119395&sid=237186f86bf190177834285ce5f8d8ee
<form name="viewtopic" method="post" action="./viewtopic.php?f=29&t=119395&sid=237186f86bf190177834285ce5f8d8ee"><span class="gensmall">Display posts from previous:</span> <select name="st" id="st">
<option value="0" selected="selected">All posts</option>
<option value="1">1 day</option>
<option value="7">7 days</option>
<option value="14">2 weeks</option>
<option value="30">1 month</option>
<option value="90">3 months</option>
<option value="180">6 months</option>
<option value="365">1 year</option>
</select> <span class="gensmall">Sort by</span> <select name="sk" id="sk">
<option value="a">Author</option>
<option value="t" selected="selected">Post time</option>
<option value="s">Subject</option>
</select> <select name="sd" id="sd">
<option value="a" selected="selected">Ascending</option>
<option value="d">Descending</option>
</select> <input class="btnlite" type="submit" value="Go" name="sort"></form>POST ./search.php?sid=237186f86bf190177834285ce5f8d8ee
<form method="post" id="topic-search" action="./search.php?sid=237186f86bf190177834285ce5f8d8ee">
<input class="inputbox search tiny" type="text" name="keywords" id="search_keywords" size="22" value="Search this topic…" onclick="if(this.value=='Search this topic…')this.value='';" onblur="if(this.value=='')this.value='Search this topic…';">
<input class="button1" type="submit" value="Search">
<input type="hidden" value="119395" name="t">
<input type="hidden" value="msgonly" name="sf">
<input type="hidden" name="terms" value="any">
</form>Name: jumpbox — POST ./viewforum.php?sid=237186f86bf190177834285ce5f8d8ee
<form method="post" name="jumpbox" action="./viewforum.php?sid=237186f86bf190177834285ce5f8d8ee" onsubmit="if(document.jumpbox.f.value == -1){return false;}">
<table cellspacing="0" cellpadding="0" border="0">
<tbody>
<tr>
<td nowrap="nowrap"><span class="gensmall">Jump to:</span> <select name="f" onchange="if(this.options[this.selectedIndex].value != -1){ document.forms['jumpbox'].submit() }">
<option value="-1">Select a forum</option>
<option value="-1">------------------</option>
<option value="26">Russian Forums (Форумы)</option>
<option value="5"> Новости</option>
<option value="1"> Общий форум</option>
<option value="2"> Counter Strike</option>
<option value="3"> Сервер cs.rin.ru</option>
<option value="4"> Книга жалоб</option>
<option value="9"> Читы и Читеры</option>
<option value="6"> Оффтопик</option>
<option value="8"> Чемпионат</option>
<option value="11"> Опросы</option>
<option value="27">English Forums</option>
<option value="10"> Main Forum</option>
<option value="29" selected="selected"> Releases</option>
<option value="30"> Tutorials</option>
<option value="32"> Standalones</option>
<option value="38"> Other Gaming Platforms</option>
<option value="41"> Temporarily Restricted Topics</option>
<option value="14"> Off Topic</option>
<option value="20"> Developer Forum</option>
<option value="22"> Steam Content Sharing</option>
<option value="19"> Foreign Languages Forum</option>
<option value="15"> Archive</option>
<option value="31"> Ancient Threads</option>
<option value="24"> Junk</option>
</select> <input class="btnlite" type="submit" value="Go"></td>
</tr>
</tbody>
</table>
</form>Text Content
We need your help!
For 17 years, this forum has served us as a platform for sharing games with each
other, graciously hosted by the owner of RIN for all this time. Sadly, he can no
longer afford our server.
To keep this forum alive, we need your help with covering the hosting expenses.
For more information, click here.
Close
CS.RIN.RU - STEAM UNDERGROUND COMMUNITY
The password is "cs.rin.ru".
Forum rules :: Donate Chat :: FAQ
Register Search :: Login
It is currently Tuesday, 07 May 2024, 09:11
|
View unanswered posts | View active topics
Board index » English Forums » Main Forum » Releases
[RELEASE] KOALYPTUS - RUNTIME BINARY PATCHING FRAMEWORK
Go to page 1, 2, 3 Next
Page 1 of 3
[ 43 posts ]
Print view Previous topic | Next topic
Author Message acidicoala
Post subject: Koalyptus - Runtime binary patching framework
Posted: Friday, 04 Feb 2022, 21:44
Super flooder Почетный графоман
Joined: Thursday, 02 Jul 2020, 12:22
Posts: 746
Location: Eucalyptus tree
Koalyptus
A framework for patching Windows executables at runtime.
Description
Koalyptus is a framework that can be used to dynamically patch executables in
memory. Such runtime patches have the advantage of keeping executables
unmodified, being resilient against updates, and requiring less maintenance. The
framework is composed of two new open-source libraries: [[Please login to see
this link.]] and [[Please login to see this link.]].
* Lyptus is a DLL that will apply patch(es) in the memory of the process that
loads it. The patch(es) to be applied are configured in the Lyptus.json
config file. Each patch includes a binary pattern, which will be used to
search for patching address, an offset to be applied to the found address, as
well as the replacement bytes.
* Koaloader is a DLL loader, which itself will be automatically loaded by an
executable via search order hijacking. The DLL(s) to be loaded are configured
in a Koaloader.json config file. The config defines a list of DLLs to load
via relative or absolute file paths.
The 2 libraries can work independently of each other. You can use Koaloader to
load any DLL you want. You can inject Lyptus via any other method you prefer.
But when used together, they form a framework that has a number of useful
applications. The framework works in the following manner:
1. Koaloader is disguised as one of the supported proxy DLLs, such as
version.dll.
2. Koaloader is placed in the DLL search path, so that it would be
automatically loaded by the target process on start-up.
3. As soon as Koaloader is loaded by the target process, it will load the
Lyptus DLL.
4. As soon as Lyptus is loaded by Koaloader, it will apply the patches defined
in its config file.
The format of each of the configuration files is described in the corresponding
repository READMEs. Configuration files themselves are shipped in the release
archives of each library.
Of course you still have to use reverse engineering techniques to find a good
binary pattern that will work across as many executable versions as possible.
That's why I published this post in the Developer Forum.
Usage examples
* Some Lego games developed by Traveller's Tales will deliberately exit when
presented with unpacked game resources, even though the games are perfectly
capable of loading them. Luckily, it is possible to patch the executables of
those games to force the loading of unpacked game resources. But instead of
doing that manually for each game executable, and re-doing the patch if an
update comes up, you can use same Koalyptus configuration that will apply to
several games, reducing the maintenance burden to zero. In fact, this
solution was used in the recently published [[Please login to see this
link.]] repack by Masquerade64.
* A Total War Saga: TROY is a game that has DLL integrity checks that crash the
game if it is loaded with modified DLLs, preventing the use of common DLC
Unlockers. Although it is possible to manually patch away those integrity
checks in the executable, this approach has all the same pitfalls. The
situation is even more dire for people with slow internet connections, since
the game is protected by Denuvo, so the executable size balloons up to half a
gigabyte. However, using Koalyptus framework I have posted a configuration
setup, that dynamically patches away the integrity checks. Assuming the
binary pattern holds up, this patching method will be resilient across many
game updates.
* theHunter: Call of the Wild in one of its updates has introduced a file size
check on DLLs that it loads, preventing direct use of Steam/EOS emulators.
However, Koalyptus setup in this post can automatically patch away those
checks. Additionally, it contains patches to unlock DLCs. While it is not
guaranteed that this setup will keep working after game updates, it is still
better than manually patched executables, which are 100% guaranteed to be
outdated by the next update.
Tips
* How to discover which Koaloader DLLs are supported by a game/program
Acknowledgements
I want to express my sincere gratitude to Masquerade64 for inspiring me to
develop this tool, as well as for helping to test it during development. Cheers!
_________________
My Projects
ScreamAPI [ ]
ScreamDB
DreamAPI [ ]
Uplay R2 Unlocker [ ]
Uplay R1 Unlocker [ ]
Koalageddon [ ]
Koalyptus
SmokeAPI [ ]
Koalageddon v2 [ ]
My PMs are not a private support hotline. Use corresponding forum topic instead.
Last edited by acidicoala on Tuesday, 01 Mar 2022, 12:27, edited 4 times in
total.
Top
Kacim62BOBO
Post subject: Re: Koalyptus - Runtime binary patching framework
Posted: Friday, 04 Feb 2022, 22:04
Advanced forumer Завсегдатай
Joined: Friday, 04 Sep 2020, 17:02
Posts: 114
Location: Ghostam City
Awesome! Thank you very much
A Linux port would be nice
_________________
The only way to beat your enemy, is to become your enemy.
Top
Masquerade!
Post subject: Re: Koalyptus - Runtime binary patching framework
Posted: Friday, 04 Feb 2022, 22:18
Junior Moderator
Joined: Saturday, 17 Nov 2018, 12:40
Posts: 7078
Location: Monte d'Or
Thanks for all the help over the last week glad to see a solution with many
purposes stem from a few LEGO games!
_________________
Forum Rules | FAQ | Recommended Download/Upload Sites
See a post that might violate the rules? Please use the report button () to flag
it to a staff member!
[[Please login to see this link.]]
Top
yui_
Post subject: Re: Koalyptus - Runtime binary patching framework
Posted: Sunday, 06 Feb 2022, 02:57
Advanced forumer Завсегдатай
Joined: Wednesday, 14 Oct 2020, 14:10
Posts: 204
Location: Kadath
Truly the C++ wizard at work once again!
Amazing work as always acidicoala, kudos to you
_________________
You can't just copy-paste pseudocode and call it a day...
Top
predprey
Post subject: Re: Koalyptus - Runtime binary patching framework
Posted: Friday, 25 Feb 2022, 09:04
Advanced forumer Завсегдатай
Joined: Saturday, 02 Apr 2016, 11:37
Posts: 106
For Koaloader v2.0.0, is the version.dll in every proxy dll folder required on
top of the respective dll too?
Top
xan105
Post subject: Re: Koalyptus - Runtime binary patching framework
Posted: Friday, 25 Feb 2022, 10:22
Advanced forumer Завсегдатай
Joined: Sunday, 29 Oct 2017, 10:51
Posts: 224
I have a dumb question ^_^ sorry if it seems obvious to others.
Can Lyptus be loaded by Mr Goldberg's Steam Emu experimental when using:
Quote:
Support for loading any dlls:
Any files put in the steam_settings\load_dlls\ folder will be loaded
automatically using the LoadLibraryA function.
Edit:
Quote:
[16:20:25.798] ┃ Lyptus v1.0.1
[16:20:25.799] ┃ Initialization complete
Well I suppose it means yes. Cool stuff indeed
_________________
Need achievement support ? Achievement Watcher
Top
acidicoala
Post subject: Re: Koalyptus - Runtime binary patching framework
Posted: Friday, 25 Feb 2022, 13:08
Super flooder Почетный графоман
Joined: Thursday, 02 Jul 2020, 12:22
Posts: 746
Location: Eucalyptus tree
predprey2 wrote:
For Koaloader v2.0.0, is the version.dll in every proxy dll folder required on
top of the respective dll too?
No, you should pick only 1 dll. I mention version.dll because it is most likely
to be picked up by programs and games. But since this isn't always the case,
there are 18 other alternatives.
Edit:
I just checked the release zip and saw that it includes version.dll in every
folder. Please ignore it, as it has been an error in packaging process. It will
be fixed in the next release.
xan105 wrote:
I have a dumb question ^_^ sorry if it seems obvious to others.
Can Lyptus be loaded by Mr Goldberg's Steam Emu experimental when using:
Quote:
Support for loading any dlls:
Any files put in the steam_settings\load_dlls\ folder will be loaded
automatically using the LoadLibraryA function.
Edit:
Quote:
[16:20:25.798] ┃ Lyptus v1.0.1
[16:20:25.799] ┃ Initialization complete
Well I suppose it means yes. Cool stuff indeed :o
Yes, the original post clearly states that:
acidicoala wrote:
You can inject Lyptus via any other method you prefer.
_________________
My Projects
ScreamAPI [ ]
ScreamDB
DreamAPI [ ]
Uplay R2 Unlocker [ ]
Uplay R1 Unlocker [ ]
Koalageddon [ ]
Koalyptus
SmokeAPI [ ]
Koalageddon v2 [ ]
My PMs are not a private support hotline. Use corresponding forum topic instead.
Top
acidicoala
Post subject: Re: Koalyptus - Runtime binary patching framework
Posted: Tuesday, 01 Mar 2022, 12:24
Super flooder Почетный графоман
Joined: Thursday, 02 Jul 2020, 12:22
Posts: 746
Location: Eucalyptus tree
How to discover which Koaloader DLLs are supported by a game/program
For Koaloader to be automatically loaded on process start up, it is necessary to
put it in the path where a game attempts to find it. While you can try to guess
it by placing the DLLs in various game/program directories, it is better to
eliminate all the guesswork by using a Process Monitor [[Please login to see
this link.]] with the following filters to determine which DLLs a game/program
attempts to load and at which path:
Spoiler
Attachment:
procmon.jpg
You do not have the required permissions to view the files attached to this
post.
_________________
My Projects
ScreamAPI [ ]
ScreamDB
DreamAPI [ ]
Uplay R2 Unlocker [ ]
Uplay R1 Unlocker [ ]
Koalageddon [ ]
Koalyptus
SmokeAPI [ ]
Koalageddon v2 [ ]
My PMs are not a private support hotline. Use corresponding forum topic instead.
Top
acidicoala
Post subject: Re: Koalyptus - Runtime binary patching framework
Posted: Sunday, 06 Mar 2022, 23:21
Super flooder Почетный графоман
Joined: Thursday, 02 Jul 2020, 12:22
Posts: 746
Location: Eucalyptus tree
In the new release version v2.2.0 [[Please login to see this link.]] Koaloader
can automatically load DLLs without Koaloader.json file. In the absence of a
config file, it will scan parent folders & recursively scan child folders for
DLLs with well-known names, such as Unlocker, Lyptus, ScreamAPI, etc. Full list
is available in project's README. This means that when used with ScreamAPI,
UplayR1Unlocker, or UplayR2Unlocker, only 2 DLLs would need to be installed, as
config files for each of them are optional.
This also facilitates interesting installation techniques, such as placing
ScreamAPI32 & ScreamAPI64 in the root of Epic Games Library, and putting
Koaloader in desired folders. This reduces duplication of ScreamAPI DLLs across
several game folders. Example setup:
EpicGamesLibrary/
├─ Game32/
│ ├─ Game.exe
│ ├─ version.dll (Koaloader)
├─ Game64/
│ ├─ Game.exe
│ ├─ version.dll (Koaloader)
├─ ScreamAPI32.dll
├─ ScreamAPI64.dll
_________________
My Projects
ScreamAPI [ ]
ScreamDB
DreamAPI [ ]
Uplay R2 Unlocker [ ]
Uplay R1 Unlocker [ ]
Koalageddon [ ]
Koalyptus
SmokeAPI [ ]
Koalageddon v2 [ ]
My PMs are not a private support hotline. Use corresponding forum topic instead.
Top
devilwhite_007
Post subject: Re: Koalyptus - Runtime binary patching framework
Posted: Wednesday, 09 Mar 2022, 18:34
Super flooder Почетный графоман
Joined: Friday, 26 Jan 2018, 13:16
Posts: 980
Location: 0.0.0.0
Thanks for this awesome method. But when you say "Epic Games Library" do you
mean the folder located in 'Program Files x86'. Since did try that as mentioned
by renaming the EOS-SDK from ScreamAPI to ScreamAPI32/64. Dropped version.dll in
Kena root folder or Win64 folder. But it doesnt unlock the deluxe stuff.
Top
acidicoala
Post subject: Re: Koalyptus - Runtime binary patching framework
Posted: Wednesday, 09 Mar 2022, 18:37
Super flooder Почетный графоман
Joined: Thursday, 02 Jul 2020, 12:22
Posts: 746
Location: Eucalyptus tree
devilwhite_007 wrote:
Thanks for this awesome method. But when you say "Epic Games Library" do you
mean the folder located in 'Program Files x86'. Since did try that as mentioned
by renaming the EOS-SDK from ScreamAPI to ScreamAPI32/64. Dropped version.dll in
Kena root folder or Win64 folder. But it doesnt unlock the deluxe stuff. :?:
No, I mean the folder where you install EGS games. If you install your games in
'Program Files x86' then yes, otherwise it's whatever folder you picked.
_________________
My Projects
ScreamAPI [ ]
ScreamDB
DreamAPI [ ]
Uplay R2 Unlocker [ ]
Uplay R1 Unlocker [ ]
Koalageddon [ ]
Koalyptus
SmokeAPI [ ]
Koalageddon v2 [ ]
My PMs are not a private support hotline. Use corresponding forum topic instead.
Top
predprey
Post subject: Re: Koalyptus - Runtime binary patching framework
Posted: Thursday, 10 Mar 2022, 03:20
Advanced forumer Завсегдатай
Joined: Saturday, 02 Apr 2016, 11:37
Posts: 106
Hi, can I request a few features for Lyptus?
1. Allow for specifying addresses to replace at instead of searching for
patterns. Preferably also parse for process/module names and converting these to
their memory addresses.
2. For patterns that are not unique, allow for replacing all matched addresses
or a specific one by its order position.
3. When encountering memory regions with write protection, disable read only and
replace the bytes then set page protection back to original. Tried using the
empty space at the end of the PE header as a code cave but got an invalid memory
access error.
Thanks!
Top
acidicoala
Post subject: Re: Koalyptus - Runtime binary patching framework
Posted: Thursday, 10 Mar 2022, 04:23
Super flooder Почетный графоман
Joined: Thursday, 02 Jul 2020, 12:22
Posts: 746
Location: Eucalyptus tree
predprey2 wrote:
Hi, can I request a few features for Lyptus?
1. Allow for specifying addresses to replace at instead of searching for
patterns. Preferably also parse for process/module names and converting these to
their memory addresses.
2. For patterns that are not unique, allow for replacing all matched addresses
or a specific one by its order position.
3. When encountering memory regions with write protection, disable read only and
replace the bytes then set page protection back to original. Tried using the
empty space at the end of the PE header as a code cave but got an invalid memory
access error.
Thanks!
1. I think you wanted to say offset/RVA, instead of address? If yes, then why
would you use Koalyptus? Such an offset is likely to break upon next update, so
why not just patch the exe/dll itself to keep the footprint small?
2. Replacing all matched addresses seems a reasonable feature. I'm not too sure
about picking one of matches in case of a non-unique pattern. If you only need
to patch one of them, then why not instead adjust the pattern to make it unique?
Thanks to the offset field, you should almost always be able to pick a unique
pattern. Can you give any examples justifying this feature?
3. This sounds like a good idea that I can incorporate into the next release.
_________________
My Projects
ScreamAPI [ ]
ScreamDB
DreamAPI [ ]
Uplay R2 Unlocker [ ]
Uplay R1 Unlocker [ ]
Koalageddon [ ]
Koalyptus
SmokeAPI [ ]
Koalageddon v2 [ ]
My PMs are not a private support hotline. Use corresponding forum topic instead.
Top
predprey
Post subject: Re: Koalyptus - Runtime binary patching framework
Posted: Friday, 11 Mar 2022, 01:35
Advanced forumer Завсегдатай
Joined: Saturday, 02 Apr 2016, 11:37
Posts: 106
acidicoala wrote:
predprey2 wrote:
Hi, can I request a few features for Lyptus?
1. Allow for specifying addresses to replace at instead of searching for
patterns. Preferably also parse for process/module names and converting these to
their memory addresses.
2. For patterns that are not unique, allow for replacing all matched addresses
or a specific one by its order position.
3. When encountering memory regions with write protection, disable read only and
replace the bytes then set page protection back to original. Tried using the
empty space at the end of the PE header as a code cave but got an invalid memory
access error.
Thanks!
1. I think you wanted to say offset/RVA, instead of address? If yes, then why
would you use Koalyptus? Such an offset is likely to break upon next update, so
why not just patch the exe/dll itself to keep the footprint small?
2. Replacing all matched addresses seems a reasonable feature. I'm not too sure
about picking one of matches in case of a non-unique pattern. If you only need
to patch one of them, then why not instead adjust the pattern to make it unique?
Thanks to the offset field, you should almost always be able to pick a unique
pattern. Can you give any examples justifying this feature?
3. This sounds like a good idea that I can incorporate into the next release.
Hi, thanks for reviewing my request.
1. This is actually linked to 3, because when I had to use the PE magic
signature as a pattern + offset, to point to the code cave. Though it works, I
guess it would be easier to just specify something like example.exe+0x500. It's
mostly just for convenience like when one is too lazy to find a unique pattern
and don't care about breaking between updates.
2. Sometimes the address at which we want to replace is right inside a
subroutine which is entirely similar in assembly to a few other subroutines, bar
the registers or memory location specified.
This may be because it is one of many obfuscation functions used by devs or the
devs wrote many similar functions like having separate but similar functions for
calculating ability/power gauges.
In such cases, the functions when compiled would yield mostly the exact same
instructions, but the memory locations specified therein would differ
accordingly to the offset in the object structure.
Ideally, to ensure compatibility between updates where object structures and
thus offsets to specific variables may change, we would use wildcards for the
operands, matching only the instructions opcodes.
However, in this case, because there are several subroutines with such similar
opcodes entirely, there wouldn't be a unique pattern.
In some cases, the nearest unique pattern would be in the previous or next
subroutine. However if we use it along with an offset to our desired subroutine,
it also defeats the purpose of prolonging compatibility between updates as it
can easily break by devs adding a completely unrelated function and the compiler
readjusts the order of subroutines.
If we can specifiy a specific match to replace, we can use the wildcard pattern
here, and select the exact subroutine we want to replace, and it would only
break if the devs added another similar function and the compiler somehow
decides that it should be positioned right in the middle of the existing order.
Top
acidicoala
Post subject: Re: Koalyptus - Runtime binary patching framework
Posted: Saturday, 12 Mar 2022, 04:21
Super flooder Почетный графоман
Joined: Thursday, 02 Jul 2020, 12:22
Posts: 746
Location: Eucalyptus tree
predprey wrote:
1. This is actually linked to 3, because when I had to use the PE magic
signature as a pattern + offset, to point to the code cave. Though it works, I
guess it would be easier to just specify something like example.exe+0x500. It's
mostly just for convenience like when one is too lazy to find a unique pattern
and don't care about breaking between updates.
Ok, but the question still remains: why would you want configure Koaloader &
Lyptus with a patch using offset that will break on next update? Why not patch
that exe/dll directly?
predprey wrote:
2. Sometimes the address at which we want to replace is right inside a
subroutine which is entirely similar in assembly to a few other subroutines, bar
the registers or memory location specified.
This may be because it is one of many obfuscation functions used by devs or the
devs wrote many similar functions like having separate but similar functions for
calculating ability/power gauges.
In such cases, the functions when compiled would yield mostly the exact same
instructions, but the memory locations specified therein would differ
accordingly to the offset in the object structure.
Ideally, to ensure compatibility between updates where object structures and
thus offsets to specific variables may change, we would use wildcards for the
operands, matching only the instructions opcodes.
However, in this case, because there are several subroutines with such similar
opcodes entirely, there wouldn't be a unique pattern.
In some cases, the nearest unique pattern would be in the previous or next
subroutine. However if we use it along with an offset to our desired subroutine,
it also defeats the purpose of prolonging compatibility between updates as it
can easily break by devs adding a completely unrelated function and the compiler
readjusts the order of subroutines.
If we can specifiy a specific match to replace, we can use the wildcard pattern
here, and select the exact subroutine we want to replace, and it would only
break if the devs added another similar function and the compiler somehow
decides that it should be positioned right in the middle of the existing order.
Ok, it looks like there are some legitimate use cases. Still curious to hear
about concrete cases, but the generic description makes sense. Since I am not
personally motivated to implement those features, I cannot say if and when they
will be added.
In either case, I could attempt to implement them only after the JSON parsing
library I use (nlohmann/json) updates its vcpkg release. It would included a
recently added feature that enables developers to use macros for defining config
structure with optional keys. Because the features you are asking for definitely
are calling for usage of optional keys in config file. At the moment optional
keys require manual JSON deserialization, which is a hassle I wish to avoid.
_________________
My Projects
ScreamAPI [ ]
ScreamDB
DreamAPI [ ]
Uplay R2 Unlocker [ ]
Uplay R1 Unlocker [ ]
Koalageddon [ ]
Koalyptus
SmokeAPI [ ]
Koalageddon v2 [ ]
My PMs are not a private support hotline. Use corresponding forum topic instead.
Top
Display posts from previous: All posts1 day7 days2 weeks1 month3 months6 months1
year Sort by AuthorPost timeSubject AscendingDescending
Page 1 of 3
[ 43 posts ] Go to page 1, 2, 3 Next
Board index » English Forums » Main Forum » Releases
WHO IS ONLINE
Users browsing this forum: codytorrent, Dalba, demoluci, ElectroBlueGuy,
hotlines, orion108, Runtzz and 5 guests
Jump to: Select a forum ------------------ Russian Forums (Форумы) Новости
Общий форум Counter Strike Сервер cs.rin.ru Книга жалоб Читы и
Читеры Оффтопик Чемпионат Опросы English Forums Main Forum
Releases Tutorials Standalones Other Gaming Platforms
Temporarily Restricted Topics Off Topic Developer Forum Steam Content
Sharing Foreign Languages Forum Archive Ancient Threads Junk
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum
Powered by phpBB® Forum Software © phpBB Group