[Tutorial] Implementing Custom WZ Encryption

Page 1 of 2 12 LastLast
Results 1 to 15 of 20
  1. #1
    Moderator Eric is online now
    ModeratorRank
    Jan 2010 Join Date
    DEV CityLocation
    3,185Posts

    [Tutorial] Implementing Custom WZ Encryption

    [Tutorial] Implementing Custom WZ Encryption
    I kept debating whether or not to release this, but since this no longer serves any use to me I figured why not.

    So, what is "Custom WZ Encryption"?
    This custom encryption involves changing keys and IVs to completely re-write the file data. There are two main parts on how the encryption is managed:
    1. By now, many of you realize that there's differences in encryption between GMS, BMS, KMS, JMS, etc, as well as them being changed themselves over the years. These encryption differences are referred to as "BasicKeys" (or, "IV's"). An IV/BasicKey is a 4-byte key that helps encrypt/decrypt blocks of data in AES. For all versions of MapleStory, Nexon always uses AES-256bit encryption, but the IVs were different. In this tutorial, we'll be creating our own IV and re-writing the WZ file from it's current IV to your newly created one.
    2. Anyone who knows how AES works knows that it involves not only an IV, but a UserKey as well. While Nexon may have changed the IV on all of their versions, the key was always the same. In this tutorial, we'll be creating our own new UserKey as well as an IV to ensure the best encryption.


    With this new "Custom WZ Encryption", can it still be reversed?
    Anything can be reversed. However, as far as noob-proofing goes, you're definitely set. The only way you'll be able to reverse this is through other AoBs (Array of Bytes). They'll need to find both the UserKey and your BasicKey located in your DLLs in order to fully decrypt it. If you want to make it harder to get, you could create a function hook that alters the key and IV on runtime manually, and then virtualize or obfuscate the functions in some way to make it harder for the person to reverse. Usually that won't be the case, since WZ Edit leeching is a thing of the past for the most part -- you rarely see it happen anymore.

    How involved is this "Custom WZ Encryption" as far as setting it up?
    You're expected to know how to compile C# code, as well as where to find everything in MapleLib, so that you can properly update HaRepacker to support your new encryptions. On top of that, you'll need to know how to search and modify AoBs in a Hex Editor (like HxD for example). If you can do that, then this should be easy for you.

    NOTE: While I did implement all of this long ago on HaSuite, it should all work the same on the new HaRepacker-resurrected program.

    Modifying MapleLib
    Step 1: Creating our own AES UserKey and IV.
    Find the CryptoConstants file in the MapleLib project. In here, you'll find the default UserKey:
    Code:
    /// <summary>
    /// AES UserKey used by MapleStory
    /// </summary>
    public static byte[] UserKey = new byte[128] { //16 * 8
        0x13, 0x00, 0x00, 0x00, 0x52, 0x00, 0x00, 0x00, 0x2A, 0x00, 0x00, 0x00, 0x5B, 0x00, 0x00, 0x00,
        0x08, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x60, 0x00, 0x00, 0x00,
        0x06, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x43, 0x00, 0x00, 0x00, 0x0F, 0x00, 0x00, 0x00,
        0xB4, 0x00, 0x00, 0x00, 0x4B, 0x00, 0x00, 0x00, 0x35, 0x00, 0x00, 0x00, 0x05, 0x00, 0x00, 0x00,
        0x1B, 0x00, 0x00, 0x00, 0x0A, 0x00, 0x00, 0x00, 0x5F, 0x00, 0x00, 0x00, 0x09, 0x00, 0x00, 0x00,
        0x0F, 0x00, 0x00, 0x00, 0x50, 0x00, 0x00, 0x00, 0x0C, 0x00, 0x00, 0x00, 0x1B, 0x00, 0x00, 0x00,
        0x33, 0x00, 0x00, 0x00, 0x55, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x09, 0x00, 0x00, 0x00,
        0x52, 0x00, 0x00, 0x00, 0xDE, 0x00, 0x00, 0x00, 0xC7, 0x00, 0x00, 0x00, 0x1E, 0x00, 0x00, 0x00
    };
    First, rename your "UserKey" variable into "UserKeyNexon". This is now MapleStory's UserKey. Now go ahead and copy that entire variable and create a copy, name it "UserKeyOrion". This is now your custom UserKey. Do you notice the numbers that I've bolded out in the key? Those are the values you change to whatever you want your new key to be. Nexon has broke their AES implementation, so don't change anything other than the first digit of every row!

    Now that you have a UserKey, you need a IV. Scroll down and find the "WZ_GMSIV" variable:
    Code:
    /// <summary>
    /// IV used to create the WzKey for GMS
    /// </summary>
    public static byte[] WZ_GMSIV = new byte[4] { 0x4D, 0x23, 0xC7, 0x2B };
    This is GMS's IV key, copy it all to a new variable and rename it "WZ_ORIONIV". This is now your new IV, and you can change it to whatever you like!

    Once you've created your new UserKey and IV, you'll need to scroll down and change the "getTrimmedUserKey" function to this:
    Code:
    /// <summary>
    /// Trims the AES UserKey for use an AES cryptor
    /// </summary>
    public static byte[] getTrimmedUserKey(bool bOrion)
    {
        byte[] key = new byte[32];
        for (int i = 0; i < 128; i += 16)
        {
            key[i / 4] = (bOrion ? UserKeyOrion[i] : UserKeyNexon[i]);
        }
        return key;
    }
    Since we now use an entirely new key (and soon, version), we're going to also want to add this as an existing encryption to choose from. So first, in the HaRepacker project, go to Properties->Resources. You should see strings like "EncTypeGMS", "EncTypeMSEA", etc. Scroll down to the bottom, and create a new name called "EncTypeOrion", with the value of your encryption (name it whatever you'd like, e.g "Orion (custom)").
    Next, we need to add this resource to our encryption lists. Go into the file MainForm on the HaRepacker project, and at the top of the code/file you're going to see references to Resources.EncTypeXXX. Now, in order for this to work, you're going to need to add HaRepacker.Properties.Resources.EncTypeOrion to the top of the list. So if the first element being added is GMS, then insert this one before it.

    NOTE: In HaRepacker-resurrected, these are stored in an array, so just make the above resource the first element of the array. On top of that, the next step can be ignored because that listBox adding method is called from anywhere that uses them.

    Then, after we added support to load and view our new encryption, we need to support saving it; thus, go into the SaveForm file within the HaRepacker project. Find the constructor, and once again add the same EncTypeOrion resource to the top of the list. It should look like so:
    Code:
    public SaveForm(HaRepackerMainPanel panel, WzNode wzFile)
    {
        InitializeComponent();
        encryptionBox.Items.Add(HaRepacker.Properties.Resources.EncTypeOrion);
        encryptionBox.Items.Add(HaRepacker.Properties.Resources.EncTypeGMS);
        encryptionBox.Items.Add(HaRepacker.Properties.Resources.EncTypeMSEA);
        encryptionBox.Items.Add(HaRepacker.Properties.Resources.EncTypeNone);
        this.wzNode = wzFile;
        this.wzf = (WzFile)wzFile.Tag;
        this.panel = panel;
    }
    In case you're wondering, the reason why this goes first is because below, when we add our new version (WzMapleVersion.ORION), it's at the top of the enumeration (aka valued at 0). Since we compare and use the current selected index of the encryption against the enumeration values, that means that our custom encryption has to be index 0 as well. Feel free to change that, it's just how I decided to do this.

    Step 2: Applying our new AES key changes across MapleLib.
    Now that we made our own AES key, let's make our own version! Find the WzMapleVersion file in the MapleLib project. Above the GMS enumeration, add ORION.
    Code:
    public enum WzMapleVersion
    {
        ORION,
        GMS,
        EMS,
        BMS,
        CLASSIC,
        GENERATE,
        GETFROMZLZ
    }
    Once you've added your new version, find the file WzTool in the MapleLib project. Look for the function "GetIvByMapleVersion", and add apply your new version in the switch-case.
    Code:
    public static byte[] GetIvByMapleVersion(WzMapleVersion ver)
    {
        switch (ver)
        {
            case WzMapleVersion.ORION:
                return CryptoConstants.WZ_ORIONIV;
            case WzMapleVersion.EMS:
                return CryptoConstants.WZ_MSEAIV;//?
            case WzMapleVersion.GMS:
                return CryptoConstants.WZ_GMSIV;
            case WzMapleVersion.BMS:
            case WzMapleVersion.CLASSIC:
            default:
                return new byte[4];
        }
    }
    In addition, add this new method to the class:
    Code:
    public static bool DetectIfOrion(byte[] iv)
    {
        if (iv == CryptoConstants.WZ_ORIONIV)
        {
            return true;
        }
        return false;
    }
    Once that's done, we can go back and handle checking for the UserKey. Find the file AESEncryption in the MapleLib project. You're going to see two "aesCrypt" methods, replace the first one with this:
    Code:
    public static byte[] aesCrypt(byte[] IV, byte[] data, int length)
    {
        bool bOrion = WzTool.DetectIfOrion(IV);
        return aesCrypt(IV, data, length, CryptoConstants.getTrimmedUserKey(bOrion));
    }
    If you have any errors from the above, make sure you've add the namespace that WzTool is using.

    After updating the AES crypt functions, we need to go update our key generation. Find the WzKeyGenerator file in the MapleLib project. Scroll down and find the "GenerateWzKey" function. Create a new parameter after byte[] WzIv called bool bOrion:
    Code:
    public static byte[] GenerateWzKey(byte[] WzIv, bool bOrion)
    Then, in the return statement, add bOrion to the parameter of your "getTrimmedUserKey" function.

    In order to determine whether or not to use your custom user key or nexon's, we check the IV input. We generate UserKey's from the IV in our readers and writers because that's how the properties are decrypted/encrypted within the file. So, first locate WzBinaryReader in the MapleLib project, and update its constructor:
    Code:
    public WzBinaryReader(Stream input, byte[] WzIv)
        : base(input)
    {
        bool bOrion = WzTool.DetectIfOrion(WzIv);
        WzKey = WzKeyGenerator.GenerateWzKey(WzIv, bOrion);
    }
    Then, go find WzBinaryWriter and update its constructor as well:
    Code:
    public WzBinaryWriter(Stream output, byte[] WzIv, bool leaveOpen)
        : base(output)
    {
        bool bOrion = WzTool.DetectIfOrion(WzIv);
    
        this.WzIv = WzIv;
        this.WzKey = WzKeyGenerator.GenerateWzKey(this.WzIv, bOrion);
        this.StringCache = new Hashtable();
        this.LeaveOpen = leaveOpen;
    }
    In addition, create a "WzIv" byte-array variable:
    Code:
    public byte[] WzIv { get; set; }
    Step 3: Adding support for cross-key saving (GMS/KMS/JMS/etc -> Your new version).
    Find SaveForm in the HaRepacker project, and change the "PrepareAllImgs" function to:
    Code:
    public void PrepareAllImgs(WzDirectory dir)
    {
        dir.ParseImages();
    }
    Scroll down to the "saveButton_Click" function, and below the if (versionBox.Value < 0) check, create a new bool:
    Code:
    bool bUseOrionKey = (wzf.MapleVersion != (WzMapleVersion) encryptionBox.SelectedIndex) && (WzMapleVersion) encryptionBox.SelectedIndex is WzMapleVersion.ORION;
    Now in the same function, find the 2 "wzf.SaveToDisk" calls, and add "bUseOrionKey" parameter to the end:
    Code:
    wzf.SaveToDisk(this.path, bUseOrionKey);
    wzf.SaveToDisk(this.path + ".temp", bUseOrionKey);
    Once that's done, we need to add that parameter to the actual method. Find WzFile in the MapleLib project, and update the "SaveToDisk" method:
    Code:
    public void SaveToDisk(string path, bool bUseOrionKey)
    {
        WzIv = WzTool.GetIvByMapleVersion(mapleVersion);
        CreateVersionHash();
        wzDir.SetHash(versionHash);
        wzDir.SetIV(WzIv);
        ...
    }
    Notice the method call in bold? Make sure to add that, we'll implement it in a moment. After adding that call, change these two calls to now use bUseOrionKey:
    Code:
    wzDir.GenerateDataFile(tempFile, bUseOrionKey);
    wzDir.SaveImages(wzWriter, fs, bUseOrionKey);
    Almost done! Go and find WzDirectory within the MapleLib project. Scroll down and find the "SaveImages" method and change it to look like this:
    Code:
    internal void SaveImages(BinaryWriter wzWriter, FileStream fs, bool bUseOrionKey)
    {
        foreach (WzImage img in images)
        {
            if (bUseOrionKey)
            {
                img.changed = true;
            }
            ...
         }
         ...
    }
    Then, right below it, change "GenerateDataFile" to look like this:
    Code:
    internal int GenerateDataFile(string fileName, bool bUseOrionKey)
    {
        ...
        for img ...
        if (bUseOrionKey)
        {
            img.changed = true;
        }
        ...
    }
    Finally, right before "SetHash", add this:
    Code:
    internal void SetIV(byte[] newWzIv)
    {
        this.WzIv = newWzIv;
        foreach (WzDirectory dir in subDirs)
            dir.SetIV(newWzIv);
    }
    Perfect! Now, you can successfully save from MapleStory's encryption to your own.

    Step 4: Fixing the List.wz bug so that you can save encrypted entities from List.wz.
    While you may be able to save images, properties, directories, and files just fine without problem, this doesn't take into account the entities used in List.wz. A workaround for this exists by just dumping the XMLs of the mobs that exist in List.wz and re-importing them, but we shouldn't have to do that.

    So, first go and find WzDirectory in MapleLib, and look for the "ParseImages" function. Change it to look like this:
    Code:
    public void ParseImages()
    {
        foreach (WzImage img in images)
        {
            if (reader.BaseStream.Position != img.Offset)
            {
                reader.BaseStream.Position = img.Offset;
            }
            img.ParseImage(true);
        }
       ...
    }
    Then, locate WzCanvasProperty in the MapleLib project, and add in the following condition above the width/height/format writing:
    Code:
    if (PngProperty.parsePNG && PngProperty.listWzUsed)
    {
        PngProperty.CompressPng(PngProperty.png, writer.WzIv);
    }
    writer.WriteCompressedInt(PngProperty.Width);
    writer.WriteCompressedInt(PngProperty.Height);
    writer.WriteCompressedInt(PngProperty.format);
    Next, go to WzPngProperty in the MapleLib project, and add a new bool:
    Code:
    internal bool parsePNG = false;
    After that, find the WzPngProperty constructor. First, to fix the parseNow bug, move the "wzReader" assignment from the bottom of the constructor to the top. That way, when you parse in the constructor, wzReader isn't null. Right below "wzReader", assign the new "parsePNG" property to the "parseNow" parameter:
    Code:
    internal WzPngProperty(WzBinaryReader reader, bool parseNow)
    {
        wzReader = reader;
        parsePNG = parseNow;
    Scroll down until you find the "ParsePng" function, and look for the while loop. Add a check for when blocksize is 0, you break out of the loop:
    Code:
    while (reader.BaseStream.Position < endOfPng)
    {
        blocksize = reader.ReadInt32();
        if (blocksize == 0)
        {
            break;
        }
        for (int i = 0; i < blocksize; i++)
        {
            dataStream.WriteByte((byte)(reader.ReadByte() ^ wzReader.WzKey[i]));
        }
    }
    Last, but not least, update the "CompressPng" function by adding a new parameter:
    Code:
    internal void CompressPng(Bitmap bmp, byte[] WzIv = null)
    Then, in the function look for the initialization of a WzBinaryWriter, and change it to this:
    Code:
    WzBinaryWriter writer = new WzBinaryWriter(memStream, WzIv == null ? WzTool.GetIvByMapleVersion(WzMapleVersion.GMS) : WzIv);
    NOTE: Since I did this part in HaRepacker where saving PNG's is a meme, this part will likely differ from that of HaRepacker-resurrected, where PNG's compress back to their original format. You should be able to apply the same logic here to that repacker.

    Anyways, once that's all done, you should no longer have corrupted mob images from List.wz mobs.

    Modifying MapleStory DLL's
    Since we've now created our own UserKey and IV, we have to change it in our DLL files in order for the client to be able to read and identify this new encryption. The WZ Key is used in both ZLZ and PCOM, but the client will only utilize the key from PCOM when parsing the WZ files.

    So, open your PCOM.dll file in a hex editor, and search for the following AoB: "4D 23 C7 2B". This is the IV for GMS, so MSEA would be "B9 7D 63 E9", and so on. Now, just like GMS's IV is 0x4D, 0x23, 0xC7, 0x2B, apply your IV in place of Nexon's in your DLL. So if yours is 0x1, 0x2, 0x3, 0x4 -> "01 02 03 04".

    Once you have updated your IV, search for this AoB next: "13 00 00 00 52 00 00 00 2A". This should be the same across all clients, so there isn't any alternate AoBs for other regions to search for. Now, remember what I said earlier, only change the first value of each row to your new values that you put in your user key.

    If you followed the above correctly, then you should've found and changed the following values:


    Save that to your new PCOM.dll (NOTE: make sure to backup your original just in case!), and now your client can read your "Custom WZ Encryption" :). All you have to do from here is get a MapleStory WZ file, do a File->Save, and change the region to your own. You need to do this for all of your files, including List.wz! Until every file is on that new encryption, your client will crash saying missing files -- so you can't test it until after re-saving everything. Also, please note that in order to re-write an entire raw file to this encryption, that it must load and decrypt the entire file into memory, and then re-encrypt it completely upon saving to disk. This means that it is going to eat your ram like it's candy, so make sure to close your programs to allocate HaRepacker plenty of memory (especially when it comes to Map/Mob files).

    Other than that, I hope I didn't forget anything! If I did, please let me know~
    Enjoy!

    - Eric
    Last edited by Eric; 01-10-18 at 10:36 PM. Reason: Explained adding a new resource and listBox item for your crypto.


  2. #2
    Member Arnah is offline
    MemberRank
    Mar 2016 Join Date
    87Posts

    Re: [Tutorial] Implementing Custom WZ Encryption

    How do I use this to hack orion
    Don't use Vertisy

    I made phoenix :smile:

  3. #3
    Account Upgraded | Title Enabled! br1337 is offline
    True MemberRank
    Apr 2015 Join Date
    280Posts

    Re: [Tutorial] Implementing Custom WZ Encryption

    In addition to what Eric said, if you want to change the Maple Story packet encryption key, for older versions, search for this AOB:
    13 ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 08 ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 06

    XREF in ida to and replace all the push [key address] to point to your own key.

    DWORD dwProtect; VirtualProtect(addy1, 4, PAGE_EXECUTE_READWRITE, &dwProtect); VirtualProtect(addy2, 4, PAGE_EXECUTE_READWRITE, &dwProtect); *(addy1) = (DWORD)&AesKey::aesKey_with_xor; *(addy2) = (DWORD)&AesKey::aesKey_with_xor;

  4. #4
    Member newbane2 is offline
    MemberRank
    May 2015 Join Date
    26Posts

    Re: [Tutorial] Implementing Custom WZ Encryption

    Nice release, but I feel like you just made this method fairly useless by formally releasing it.

  5. #5
    Account Upgraded | Title Enabled! br1337 is offline
    True MemberRank
    Apr 2015 Join Date
    280Posts

    Re: [Tutorial] Implementing Custom WZ Encryption

    Quote Originally Posted by newbane2 View Post
    Nice release, but I feel like you just made this method fairly useless by formally releasing it.
    Eric release the idea, you could just replace the xrefs to the key(and key location) with virtualized code.

  6. #6
    Moderator Eric is online now
    ModeratorRank
    Jan 2010 Join Date
    DEV CityLocation
    3,185Posts

    Re: [Tutorial] Implementing Custom WZ Encryption

    Quote Originally Posted by Arnah View Post
    How do I use this to hack orion
    o i think u confuse this with my other elite haxor tool Orion2 Repacker

    Quote Originally Posted by br1337 View Post
    In addition to what Eric said, if you want to change the Maple Story packet encryption key, for older versions, search for this AOB:
    13 ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 08 ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 06

    XREF in ida to and replace all the push [key address] to point to your own key.
    I'm assuming since you're referring to packet encryption that this is in regards to the client? If that's the case, are you sure this would work? You'd need proper CRC bypasses in order to modify that without crashing. Since Nexon doesn't actually offer any protection to any of their own libraries, changing the keys here wouldn't require any bypass. Oh, and just curious, but is the AES key in the client actually stored in a memory protected region? That's interesting if it is, I wasn't aware -- I'd of just directly wrote an AoB to memory at that address without giving myself readwrite access xD

    Quote Originally Posted by newbane2 View Post
    Nice release, but I feel like you just made this method fairly useless by formally releasing it.
    Well, like I mentioned in the beginning, this no longer serves any use to me, so if any other server wishes to better encrypt their files then this is a great method of doing so. However, yes, you're entirely right; if you follow my tutorial and update HaRepacker yourself, and then go and find the AoBs changed in X server's DLL, you can just as easily update and apply their keys to the program. Personally (from what I've seen at least in the past), the people that do end up leeching other servers usually wouldn't be able to pull that off. In addition, I mentioned an alternative (yet more advanced) method of changing the key just like @br1337 had mentioned. You could keep the key the default and not change a single AoB (so when people search, they assume nothing was even changed because the DLL is still in-tact). Instead, you can hook functions on runtime to execute a custom call which will update the crypto key, and then you can use something like Themida SDK and virtualize that function (an example of this would be to look at rajan's authhook release, he vm's his winsock hooks). At that point, the only people who would be able to reverse the key are people who know their way around debuggers.

    --
    Also, I forgot one thing in this tutorial that I had just caught; adding a new resource/listBox item to handle switching to your new encryption. In case anyone doesn't already know how to do this, I've updated the thread. Make sure that the new listBox item is first in the collection for it to work correctly.

  7. #7
    .. .-- - .-.. .. ...- . iwtLive is offline
    True MemberRank
    Sep 2012 Join Date
    259Posts

    Re: [Tutorial] Implementing Custom WZ Encryption

    nvm...
    Last edited by iwtLive; 14-10-18 at 07:55 PM.

  8. #8
    Registered loveGMS is offline
    MemberRank
    Nov 2019 Join Date
    21Posts
    thanks
    Last edited by loveGMS; 14-01-20 at 09:50 AM.

  9. #9
    Member LastBattle is offline
    MemberRank
    Aug 2009 Join Date
    93Posts

    Re: [Tutorial] Implementing Custom WZ Encryption

    [Release] Harepacker resurrected

    Time for your response, @Eric implemented a bruteforcer.
    Modern CPU are fast enough these days for looking up a 4 billion key space.

  10. #10
    Moderator Eric is online now
    ModeratorRank
    Jan 2010 Join Date
    DEV CityLocation
    3,185Posts

    Re: [Tutorial] Implementing Custom WZ Encryption

    Quote Originally Posted by LastBattle View Post
    [Release] Harepacker resurrected

    Time for your response, @Eric implemented a bruteforcer.
    Modern CPU are fast enough these days for looking up a 4 billion key space.
    While this will work with Nexon's various WZ encryptions, it only decrypts half of what this tutorial does. The other half actually changes the entire AES encryption across all the files. Currently we only change 8 of the primary key bytes here, but I could probably get it to work on a different 128-byte key with some DLL edits towards the AES cipher. Either way, nice tool, but it'll take a while to decrypt both the IV and AES key here; it'd be faster to just reverse it out of their files lol.

  11. #11
    Hardcore Member duke is offline
    MemberRank
    Nov 2007 Join Date
    144Posts

    Re: [Tutorial] Implementing Custom WZ Encryption

    @Eric,
    Nice release.
    I followed this guide step by step and attempted to re-compile .
    however, I encountered some issues while trying to compile with the Harepacker-resurrected, release 3.0 source code.

    would you mind giving out some help?


  12. #12
    Moderator Eric is online now
    ModeratorRank
    Jan 2010 Join Date
    DEV CityLocation
    3,185Posts

    Re: [Tutorial] Implementing Custom WZ Encryption

    Quote Originally Posted by duke View Post
    @Eric,
    Nice release.
    I followed this guide step by step and attempted to re-compile .
    however, I encountered some issues while trying to compile with the Harepacker-resurrected, release 3.0 source code.

    would you mind giving out some help?

    This isn't intended to be used on Harepacker-resurrected, just the original HaRepacker source code. As far as Harepacker-resurrected goes, they have custom IV encryption on there. For people who have a harder time compiling this stuff, you could use that as an alternative (the only difference being you won't have a custom AES layer on top of that IV).

  13. #13
    Hardcore Member duke is offline
    MemberRank
    Nov 2007 Join Date
    144Posts

    Re: [Tutorial] Implementing Custom WZ Encryption

    Thank you @Eric,

    I will try with the original HaRepacker~ I found some github hosting HaRepacker source code. could you share the one you used?
    is this a good source ?https://forum.ragezone.com/f702/rele...2-1-a-1068988/ :)

    Quote Originally Posted by Eric View Post
    This isn't intended to be used on Harepacker-resurrected, just the original HaRepacker source code. As far as Harepacker-resurrected goes, they have custom IV encryption on there. For people who have a harder time compiling this stuff, you could use that as an alternative (the only difference being you won't have a custom AES layer on top of that IV).
    Last edited by duke; 12-05-20 at 02:29 AM.

  14. #14
    Moderator Eric is online now
    ModeratorRank
    Jan 2010 Join Date
    DEV CityLocation
    3,185Posts

    Re: [Tutorial] Implementing Custom WZ Encryption

    Quote Originally Posted by duke View Post
    Thank you @Eric,

    I will try with the original HaRepacker~ I found some github hosting HaRepacker source code. could you share the one you used?
    is this a good source ?https://forum.ragezone.com/f702/rele...2-1-a-1068988/ :)
    Yes, I used the source code from that release (available on OP's github).

  15. #15
    Hardcore Member duke is offline
    MemberRank
    Nov 2007 Join Date
    144Posts

    Re: [Tutorial] Implementing Custom WZ Encryption

    Thank you @Eric !



Page 1 of 2 12 LastLast

Advertisement