Steamless Unpacker Variant 2.1 After Unpack Looks Like Virus File

Hi atom0s Firstly I Thank You Make For This Tool,This Tool Work Flawless 🥇 But I Some Problem With Steamless Unpacker Variant 2.1, Everytime İf I Use Steamless Unpacker Variant 2.1 After Unpacked Exes Looks Like Virus File (TR/Crypt.XPACK.Gen).I Try To Close "Keep Bind Section" and Use "Experimental Features" But Didn't Change Anything, I Unpack 30+ Games With Your Tool But When Unpack Variant 2.1 I Have Problem Game Exes Please Can You Fix This Problem ? Note: My Opinion, Unpacking Good But Rebuild Process Have Some Problem Best Regards Dark Frost

Steamless does not introduce any new data/code into the file that is unpacked. Any resulting binary issues, such as false-positives from an AV would be due to the file's data itself. Steamless decrypts the files code section and restores it. So if that code section has any markers/signatures that will trigger a false-positive from an AV, that is on the game, not Steamless.

Steamless does not introduce any new data/code into the file that is unpacked. Any resulting binary issues, such as false-positives from an AV would be due to the file's data itself. Steamless decrypts the files code section and restores it. So if that code section has any markers/signatures that will trigger a false-positive from an AV, that is on the game, not Steamless.

I Compare with HxD Hex Editor 2 game exe's (Saints Row 2 Steam (Unpacked by Steamless tool Without "Keep Bind Section") and Saints Row 2 GOG lastes version) sorry you misunderstood me , I doesnt say introduce any new data or code into the file and ı dont blame you and Steamless tool, I just say maybe unpacker variant 2.1 clean or change to some little code in game exe I found some deleted code in resource section I restore some code in resource section and exe doesnt give false warning. If you want to look game files, I upload game files for you ,) Desktop.zip New Note: ı See SizeOfImage is incorrectly calculated #27 issue in https://github.com/atom0s/Steamless/issues/27 ı just change some code in pe and resource section,maybe this affect is antivirus false positive ? Pe Section Best Regards Dark Frost

Steamless does not alter the data you are seeing there. That is the NT header 'Characteristics' field which is set to 0x102 in the untouched, packed/protected Steam file. Steamless does not alter that field at all when unpacking. It just copies over the existing headers. The GOG version just marks the file as 4gb aware which is why it's 0x122 for the GOG version.

As for the other differences, here's a run down of what is different between the Steam file and GOG file:

DOS Stub - In the Steam file, there is a Valve specific DOS stub. I have not taken the time to reverse the purpose of this in full yet but in general, I've seen it used for validation. Because of that, Steamless does not remove it by force. It's not always removed / completely removed from non-Steam versions of games either like this one. Instead, it's just null data.
The Characteristics field of the NT header (IMAGE_NT_HEADERS->FileHeader->Characteristics) which is what you pointed out in your screenshot. This is not Steamless altering the value. It is 0x102 in the SteamStub packed file without being unpacked. GOG marks the file as being 4gb aware which causes the 0x122 value. This is not a result of using Steamless, it is what was originally in the file.
The Checksum (IMAGE_NT_HEADERS->OptionalHeader->Checksum) is set to 0 when SteamStub is ran on a file. This is the DRM's doing and not Steamless. Windows does not require this field to be filled out when running PE files either so there is no reason for Steamless to recalculate it.
The section sizes. This is where I feel the issues may arise if anything. Steamless does currently attempt to realign the section sizes by force. This is due to the fact that when I first made Steamless, the few files I had to work with and test against required the sections (mainly the code (.text) section) to be realigned. However, I feel at this point with all the samples I've seen, that it may have just been a custom added layer of protection for the given game I saw it in. So far, I have not encountered the issue with anything else. But I just haven't had time to add the option to not do this yet.
There is 1 call in the code that is different. This is something that looks to be a patch done for the GOG version. (This is not Steamless doing anything to the decrypted code section data.) The call adjustment looks like it deals with a chunk of code that is used for frame limiting the game. Based on this chunk of code, it looks like the game tries to limit the FPS to 30 if it detects framerates under 35, then tries to cap to under 1000 if it's higher.

However, in the GOG version, there is a custom patch made to the file which is why this call is different. In the Steam version, it does a simple call and goes on its way like normal. In the GOG version the call is patched with a jump that goes to an injected bit of data/code at the end of the .text section. That looks like this:

.text:00DB71F4 ; START OF FUNCTION CHUNK FOR sub_D20360
.text:00DB71F4
.text:00DB71F4 loc_DB71F4:                             ; CODE XREF: sub_D20360+9FA↑j
.text:00DB71F4                 nop
.text:00DB71F5                 mov     ecx, offset unk_1000000
.text:00DB71FA
.text:00DB71FA loc_DB71FA:                             ; CODE XREF: sub_D20360+96E9B↓j
.text:00DB71FA                 nop
.text:00DB71FB                 loop    loc_DB71FA
.text:00DB71FD                 nop
.text:00DB71FE                 nop
.text:00DB71FF                 nop
.text:00DB7200                 call    sub_D20230
.text:00DB7205                 jmp     loc_D20D5F

I can't say for sure why they are modding this function like this, but it looks to be some means of a custom fix/patch made by GOG. Part of this function looks derp'd so I assume it's written to/rebuilt elsewhere in the game before being fully used/jumped to. Not sure if GOG lists changes they make to games/fixes they include, but this appears to be a mod by them involving the FPS potentially. Perhaps to fix a bugged part/quest of the game or something that has FPS issues.

Coupled with the info above in 5, there is the extra stub data written to the end of the .text section I showed above.
At the very end of the .text section data in the Steam unpacked file is 16 bytes of 0x10. I honestly have no idea what this is, and I'd assume it's just left-over padding for the encryption or something similar. Steamless is not creating this data, and it's completely from the originals encrypted data. GOG's version does not have it, so I'd guess it's padding/left-over junk from the encryption of SteamStub. If you step through the code of the 2.1 unpacker and break on line 407 and let the data decrypt, you'll see before, it's 00's and after it's the 0x10's.

In summary, the only thing here that isn't ideal is the section sizes being realigned. Outside of that, everything else is explainable and not a result of what Steamless is doing.

As a side note; in the future when I do get time, I plan to add several features that will address some of the things mentioned here.

Option to chosoe if the DOS stub should be kept as-is, removed, or simply nulled.
Option to choose if the header Checksum is recalculated after unpacking.
Option to choose if sections should be realigned or not.
Option to enable 4gb awareness on the resulting file. This is not something that is needed of Steamless and has nothing to do with the project, but it's a common fix/suggestion in gaming in general that it doesn't hurt to include.

Regarding the virus detection/false positive, I'd guess if anything, it's from the section size alignments. Outside of that, the file is exactly the same as GOG's outside of the things listed above. All said and done, there are only 60 bytes different between the two files, not couting the 144 byte DOS stub.

Again Thanks for taking the time for me :) after you wrote ı checked from PE section to bind section byte to byte, and ı found the problem finally :) Problem is under the text sections value not same after the unpacking I Upload ss for checking Problem but gog and orginal steam version text sections have same value Samegogandsteam I fix the unpacked steam files value's, orginal steam version's value problem is fixed and now antivirus software doesnt give false positve :) can you fix this problem be fixed in the future updates ? Note: I dont like GOG version :) because if ı start game, game stucking after few seconds Best Regards and thanks for guiding me :) Dark Frost

Steamless does not alter the data you are seeing there. That is the NT header 'Characteristics' field which is set to 0x102 in the untouched, packed/protected Steam file. Steamless does not alter that field at all when unpacking. It just copies over the existing headers. The GOG version just marks the file as 4gb aware which is why it's 0x122 for the GOG version.

As for the other differences, here's a run down of what is different between the Steam file and GOG file:
1. DOS Stub - In the Steam file, there is a Valve specific DOS stub. I have not taken the time to reverse the purpose of this in full yet but in general, I've seen it used for validation. Because of that, Steamless does not remove it by force. It's not always removed / completely removed from non-Steam versions of games either like this one. Instead, it's just null data.

2. The Characteristics field of the NT header (IMAGE_NT_HEADERS->FileHeader->Characteristics) which is what you pointed out in your screenshot. This is not Steamless altering the value. It is 0x102 in the SteamStub packed file without being unpacked. GOG marks the file as being 4gb aware which causes the 0x122 value. This is not a result of using Steamless, it is what was originally in the file.

3. The Checksum (IMAGE_NT_HEADERS->OptionalHeader->Checksum) is set to 0 when SteamStub is ran on a file. This is the DRM's doing and not Steamless. Windows does not require this field to be filled out when running PE files either so there is no reason for Steamless to recalculate it.

4. The section sizes. This is where I feel the issues may arise if anything. Steamless does currently attempt to realign the section sizes by force. This is due to the fact that when I first made Steamless, the few files I had to work with and test against required the sections (mainly the code (.text) section) to be realigned. However, I feel at this point with all the samples I've seen, that it may have just been a custom added layer of protection for the given game I saw it in. So far, I have not encountered the issue with anything else. But I just haven't had time to add the option to not do this yet.

5. There is 1 call in the code that is different. This is something that looks to be a patch done for the GOG version. (This is not Steamless doing anything to the decrypted code section data.) The call adjustment looks like it deals with a chunk of code that is used for frame limiting the game. Based on this chunk of code, it looks like the game tries to limit the FPS to 30 if it detects framerates under 35, then tries to cap to under 1000 if it's higher.
However, in the GOG version, there is a custom patch made to the file which is why this call is different. In the Steam version, it does a simple call and goes on its way like normal. In the GOG version the call is patched with a jump that goes to an injected bit of data/code at the end of the .text section. That looks like this:
.text:00DB71F4 ; START OF FUNCTION CHUNK FOR sub_D20360
.text:00DB71F4
.text:00DB71F4 loc_DB71F4:                             ; CODE XREF: sub_D20360+9FA↑j
.text:00DB71F4                 nop
.text:00DB71F5                 mov     ecx, offset unk_1000000
.text:00DB71FA
.text:00DB71FA loc_DB71FA:                             ; CODE XREF: sub_D20360+96E9B↓j
.text:00DB71FA                 nop
.text:00DB71FB                 loop    loc_DB71FA
.text:00DB71FD                 nop
.text:00DB71FE                 nop
.text:00DB71FF                 nop
.text:00DB7200                 call    sub_D20230
.text:00DB7205                 jmp     loc_D20D5F
I can't say for sure why they are modding this function like this, but it looks to be some means of a custom fix/patch made by GOG. Part of this function looks derp'd so I assume it's written to/rebuilt elsewhere in the game before being fully used/jumped to. Not sure if GOG lists changes they make to games/fixes they include, but this appears to be a mod by them involving the FPS potentially. Perhaps to fix a bugged part/quest of the game or something that has FPS issues.
1. Coupled with the info above in 5, there is the extra stub data written to the end of the .text section I showed above.

2. At the very end of the .text section data in the Steam unpacked file is 16 bytes of 0x10. I honestly have no idea what this is, and I'd assume it's just left-over padding for the encryption or something similar. Steamless is not creating this data, and it's completely from the originals encrypted data. GOG's version does not have it, so I'd guess it's padding/left-over junk from the encryption of SteamStub. If you step through the code of the 2.1 unpacker and break on line 407 and let the data decrypt, you'll see before, it's 00's and after it's the 0x10's.
In summary, the only thing here that isn't ideal is the section sizes being realigned. Outside of that, everything else is explainable and not a result of what Steamless is doing.

As a side note; in the future when I do get time, I plan to add several features that will address some of the things mentioned here.
* Option to chosoe if the DOS stub should be kept as-is, removed, or simply nulled.

* Option to choose if the header Checksum is recalculated after unpacking.

* Option to choose if sections should be realigned or not.

* Option to enable 4gb awareness on the resulting file. This is not something that is needed of Steamless and has nothing to do with the project, but it's a common fix/suggestion in gaming in general that it doesn't hurt to include.
Regarding the virus detection/false positive, I'd guess if anything, it's from the section size alignments. Outside of that, the file is exactly the same as GOG's outside of the things listed above. All said and done, there are only 60 bytes different between the two files, not couting the 144 byte DOS stub.

Update: I Have Same İssue and Again I have Virus Warning Unpack Prototype.exe Game and my writing way not working this time :(

Hello, responding to this issue again as the latest version of Steamless should now fully handle this file properly. The newest version of Steamless fixes a decryption issue that was happening with two of the unpackers that affects this file along with others. You can find the latest version of Steamless here:

https://github.com/atom0s/Steamless/releases/latest

Please Note: When unpacking the Steam version of this game, the resulting binary is not going to match the GoG version completely. There are several changes done to the Steam version.

The IMAGE_NT_HEADERS->IMAGE_FILE_HEADER->Characteristics flag has the IMAGE_FILE_LARGE_ADDRESS_AWARE disabled on the Steam version.
The IMAGE_NT_HEADERS->IMAGE_OPTIONAL_HEADER32->CheckSum value will not produce the same result due to changes to the file.
There are two patches to the code section of the Steam version that will cause the file to be different than the GoG version. You can find more info on this here: https://www.saintsrowmods.com/forum/threads/gog-version-of-sr2-fixed.16589/post-104511

The remaining file data is a 100% match to the GoG version now.

atom0s / Steamless

Steamless Unpacker Variant 2.1 After Unpack Looks Like Virus File #46