Update 2023-09-17-gsctool.md

1 files changed, 7 insertions, 7 deletions

diff --git a/_posts/2023-09-17-gsctool.md b/_posts/2023-09-17-gsctool.md
index ca0bce0..6af3087 100644
--- a/_posts/2023-09-17-gsctool.md
+++ b/_posts/2023-09-17-gsctool.md
@@ -120,7 +120,7 @@ scripts are loaded and compiled in game.
 The next task was figuring out the call chain (sequence of function calls) which
 is required for loading custom `GSC` scripts. So I decided to search for the
 keyword `script` and stumbled upon a function called `Scr_LoadScript`
-[here](https://github.com/lunarbin/CoD4x_Server/blob/14f0d8a205d80c9b30e308b57f0cd9bd6d7cdb1c/src/scr_vm_main.c#L1018)
+[here](https://github.com/callofduty4x/CoD4x_Server/blob/14f0d8a205d80c9b30e308b57f0cd9bd6d7cdb1c/src/scr_vm_main.c#L1018)
 which seemed to be responsible for loading a `GSC` or `CSC` script (`CSC` scripts are
 almost identical to `GSC` scripts but are executed by the client instead of a
 server).
@@ -133,7 +133,7 @@ unsigned int Scr_LoadScript(const char* scriptname)
 
 which I assumed was some type of resource/asset string. I therefore proceeded to
 look for any functions that would load assets and stumbled upon `DB_AddXAsset`
-[here](https://github.com/lunarbin/CoD4x_Server/blob/14f0d8a205d80c9b30e308b57f0cd9bd6d7cdb1c/src/bspc/db_miniload.cpp#L2919).
+[here](https://github.com/callofduty4x/CoD4x_Server/blob/14f0d8a205d80c9b30e308b57f0cd9bd6d7cdb1c/src/bspc/db_miniload.cpp#L2919).
 
 The function signature for `DB_addXAasset` was as follows:
 
@@ -143,7 +143,7 @@ XAssetHeader __cdecl DB_AddXAsset(XAssetType type, XAssetHeader header)
 
 I decided to search for the definition of `XAssetHeader`. `XAssetHeader` was
 defined as a union of various
-[structs](https://github.com/lunarbin/CoD4x_Server/blob/14f0d8a205d80c9b30e308b57f0cd9bd6d7cdb1c/src/xassets.h#L81):
+[structs](https://github.com/callofduty4x/CoD4x_Server/blob/14f0d8a205d80c9b30e308b57f0cd9bd6d7cdb1c/src/xassets.h#L81):
 
 ```
 union XAssetHeader
@@ -162,7 +162,7 @@ union XAssetHeader
 Out of all the structs listed `RawFile` seemed like the most interesting for our
 purposes (loading `GSC` script assets). Let's have a look at the `Rawfile`
 structure
-[itself](https://github.com/lunarbin/CoD4x_Server/blob/14f0d8a205d80c9b30e308b57f0cd9bd6d7cdb1c/src/xassets/rawfile.h#L5):
+[itself](https://github.com/callofduty4x/CoD4x_Server/blob/14f0d8a205d80c9b30e308b57f0cd9bd6d7cdb1c/src/xassets/rawfile.h#L5):
 
 ```
 struct RawFile
@@ -274,7 +274,7 @@ time after detouring.
 
 We would have to hook the function before loading a solo zombie match as script
 assets are loaded into memory shortly after starting a game mode. I wrote a
-simple detouring library called [cdl86](https://github.com/lunarbin/cdl86)
+simple detouring library called [cdl86](https://github.com/lunar-rf/cdl86)
 that can `hook/detour` functions either by inserting a `JMP` opcode at the target
 functions address to a detour function or through a software breakpoint.
 
@@ -463,7 +463,7 @@ Scr_FreeThread(handle, 0);
 ```
 
 We also obviously also need a compression library and for this I am using
-[miniz](https://github.com/lunarbin/miniz).
+[miniz](https://github.com/lunar-rf/miniz).
 
 So to summarize the steps to inject our `GSC` script via our `Scr_LoadScript` hook:
 
@@ -500,7 +500,7 @@ A simple challenge would be to find these offsets yourself, it is not difficult.
 # Source Code
 
 I have included the source code of my simple `GSC` loader in the
-[following](https://github.com/lunarbin/gsctool/) repo.
+[following](https://github.com/lunar-rf/gsctool/) repo.
 
 I have also included a sample `GSC` script that spawns a raygun at spawn in
 zombies solo mode and dumps `GSC` scripts as they are loaded via a