Last 5 News Posts:

I recently released the newest version of my Steamless project (v3) which has brought some major changes to the project as a whole. I wanted to go over some of Steamless' life as a project to help others understand my intentions with the project, its source code, and its future. But for that, I will give some background to the project as well as some info on each version.

Steamless - The Beginning

    Steamless was created after I was beginning to see a huge increase in the games I had on Steam using a custom packer. Given that I am a game hacker at heart, my first instincts when getting a new game is to almost immediately check out the files. The intent is not always to hack the game immediately, but more or less my curiosity getting the best of me and wondering about the files. Things such as what they are written in, what they are packed with (if anything), what they are obfuscated with (if anything) and so on. It's just more or less me being interested in how something was made.

    More and more I started seeing files with some similar characteristics and annoying things to deal with such as anti-debugging techniques and static file analysis prevention due to packed sections. So I set out to learn more about the protection and possibly ways to remove it if something already existed. Through searching, I found some vague articles discussing the protection (mostly on crack forums/sites). But I couldn't find any solid information on unpacking the protections or any automated tools for the process.

    Because of this, I set out and began working on Steamless as a handful of games I was interested in hacking basically needed it. I spent about a week or so working on the unpacking analysis, jotting down information that I learned from how the file(s) worked for the few games I tested with from the start. After learning some key points of the protection I had a better understanding of what to look for online in terms of potential tools and dumps of similar information. This is when I stumbled upon Golem's wiki page found here:

    His wiki article at the time covered some basic information about the protection and a great database of games protected with the DRM. This was a helping push in the right direction on some of the parts of the DRM I was still working on reversing.

Steamless v1

    The first iteration of Steamless was a simple console window that only supported SteamStub v3.0 (as I have dubbed it). It was very 'static' in terms of how it was implemented and it worked on a handful of games only. It had issues with certain situations and was more or less just a start of the project. This version was coded in C/C++ and was not really well designed or optimized for how the DRM was designed. Given that I had only really tackled the 32bit version of the 3.0 DRM, the project was lacking in features and support.

    During this time I had talked with Golem directly about his work with the packer, got some insight on the earlier versions of the DRM and begun reworking some of the internals of Steamless. Him and I exchanged some of our personal progress and overall was a great push to keep the project going and begin working on supporting other versions of the DRM.

Steamless v2 / Steamless.NET

    At this point of the project, I had begun rewriting Steamless to be more scalable towards supporting other versions of the DRM. The C/C++ version was rewritten to include support for both SteamStub v2 and SteamStub v3. (As well as detection for v1 but no support.) My work on the SteamStub v2 variant was still really fresh and rough. The variant required using some disassembling to pull the required data which included the usage of the BEA disassembly engine for the C/C++ version of the project. It was a rough start to supporting the 32bit variant but was a fun time reversing and learning more about the older versions of the DRM.

    This was also the time I felt the project was getting some reputation but not much contributions back. Mainly because most of the people commenting on it and discussing it were not developers that used the C/C++ languages. From my experience with various reversing forums and peers, I felt it was best to move the project to C# as .NET is a fairly popular language in the reversing scene for making tools and such. I ported the current code base of Steamless to C# and dubbed the project Steamless.NET. When I did this, the idea was to maintain two projects for Steamless. The original C/C++ version and the new C# version, however that was fairly short lived after taking a step back and realizing that any contributions to one or the other would have to be ported to the other to keep both projects on the same level. I felt this was going to cause the project to become stagnant over time and one or the other would becoming the dominating project either way.

    Because of this, I decided it was best to just drop the C/C++ version and stick to the .NET (C#) version instead.

Steamless v3

    While Steamless v2 was working great for many games, I was not happy with the code base. It was fairly rough to add support for other versions of the DRM and was not really friendly in terms of having more developers contribute to the project. I also was not happy with the license choice was it felt it didn't serve the project well. I also had failed to bring the full v2 support to the public version that was released due to a lack of free time. Another issue I was having was a large influx of help/support requests on how to use it as many people were not really familiar with using a command line tool.

    I felt it was a good time to really revamp the project by doing a few major changes to it:
    1. A full overhaul of the code, making it much cleaner and modular for others to create their own packers in the form of a plugin.
    2. Make Steamless have a UI instead of being a command line tool to help with those that were struggling to use it.
    3. Add support for the v2 packer in the public release.
    4. Add support for the new v3.1 variant of the DRM that was introduced recently.
    5. Prep the code base to be able to support 64bit versions of the DRM.
    6. Change the projects license to something more suitable for its nature.

    Thus, Steamless v3 was born. I dropped the '.NET' part of the name as I no longer supported the C/C++ version and just titled the project Steamless. A full rewrite of the code base was done and a UI written in WPF was born.


    Steamless v3 introduced a module setup for the unpackers of each variant version which makes updating things as well as adding support for other versions of the DRM a breeze.
    The UI was designed to be simple, to the point, and easy to use for anyone.

    I decided on the 'Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License' licensing system as well as the new license of the source code for the project as I felt the Creative Commons licenses better suited the project than the GNU GPL. The idea behind Steamless was more or less an educational project for myself, and I wanted to share that knowledge and information about DRM to others.

Gitlab vs. Github

    During the Steamless project, I had moved from Github to Gitlab due to how Github's internal workings was happening. Employees were treated horribly and a full overhaul of the companies original motto and purpose was done. The CEO had become more or less a puppet to his investors and was more interested in money than his family he had created. I really disliked this and opt'd to move all my projects to Gitlab, a fully open source project similar to Github. While I still use Gitlab as my main repository site of choice for off-site hosting, Steamless felt like it was being neglected for not being on the 'mainstream' platform of choice by most developers. (You can read more about Githubs corruption here: ... ory-2016-2 )

    When I released Steamless v3's source code this past week, I felt it was in the best interest of the project to move it back to Github. Not because I like using Github or have changed my opinion about their company, but simply because Steamless was not getting the same level of attention it was before I moved it to Gitlab.

The Future of Steamless

    From here forward, I would personally like to get Steamless to a point where it can support most, if not all, of the Steam DRM protected games. Along with that, I want to be able to have support for 32bit as well as 64bit in a single project. (Given that loading the file is not required, a single 32bit version of Steamless can cover both 32bit and 64bit unpacking.) However, my free time (or lack thereof) really prevents me from handling most of this. Which is why I opt'd to make Steamless an open source project from the start.

    I would love to see others interested in the topic of DRM as well as how packers work. While SteamStub DRM is not anything super amazing, it is a great DRM for beginners to get their feet wet in understanding and reversing. (The way I would describe it to people would be is that it is a glorified version of UPX with some customizations and anti-debugging protections.)

    My wishlist for Steamless going forward would be the following:
    • Support for SteamStub variant 1.
    • 32bit support for all variants.
    • 64bit support for all variants.
    • Proper support for TLS callbacks and options to handle those files as desired. (My newest commits to variant 3.1 demonstrate what I mean here.)
    • Some cleanup to the UI, nothing major as I made it basic to begin with.
Hello everyone,

This morning my server was backed up and moved to new hardware and then reimported on a new setup as my host is upgrading. Because of this, the last handful of hours has been 'lost' and a rollback to this mornings clone is now live.

Some posts / pm's may have bene lost.

Overall this should not impact nearly anyone and everything should continue to work as normal.
Once again, a software developer feels the need to completely change a feature that has been the same for decades to please a minority, yet claim that the people using said feature are the minority to begin with. In a recent Chrome update, they decided to remove the ability to navigate backward via the backspace button directly. Instead, you now have to hit ALT+Backspace. Their claim is that too many people were complaining about losing form information by accident. And also claimed that 0.04% of Chrome users use the backspace button to navigate backward. I call utter bullshit on that number.

Either way, you can restore the backspace functionality by adding the following to your Chrome shortcut:
--enable-blink-features=BackspaceDefaultHandler --test-type
The other night a friend of mine informed me that a link of mine was not working for a file shared via Dropbox. I tested link myself and indeed it was not working. First thought was maybe the link expired so I had the client generate one for the file again and nope, it was the same link. Still didn't work. Tried renaming the file to get a new link, still nada. I landed up logging into my account on their website to find, buried within my account settings that my public link sharing was banned.

Skimming their forums, this seems to be their new method of trying to force people into paid accounts as many other users have started having the same problem.

Dropbox never informed me in any manner that I was getting banned due to bandwidth issues, at least that is what the site says is the reason in a very vague manner. No email, no popup from their Desktop app (which will still generate shared links for me even though they are banned), nothing.

Other users have complained about their terrible support as of late too, tickets getting automated responses immediately after being posted and having the ticket force-closed as 'Resolved' from the automated response. It's a shame that an awesome piece of software has turned into junkware with terrible support. Sadly, everything is turning into that if it's not paid for. Free users that tend to drive their product to be a success are always forgotten and treated like trash.

At this time I have completely removed everything of mine from Dropbox and will not be using it again. I have moved majority of my Dropbox files to a public folder here:

You should be able to find everything from my Dropbox here. If you see something missing feel free to let me know.

I am looking into alternatives to Dropbox as well if anyone has any suggestions.
Over the last month or so my main focus on The Division has been playing in the lower level Dark Zones as a twinked character. For those that are unaware what that means, it means that I play in a bracket of the Dark Zone at the highest level it allows with the best gear I can possibly get/make to use in that bracket. In the Division, the brackets are:
- 1-14
- 15-19
- 20-24
- 25-29
- 30 (160 and below gear score)
- 30 (161 to 199 gear score)
- 30 (200+ gear score)

I have grown to enjoy the Dark Zone a lot but there are definitely problems with it going forward. This is not a Q_Q turn off pvp or enable pvp to be toggled post. That is the whole point of the DZ so no, I do not want it removed. But I do want to cover some problems I see with the Dark Zone:

1. Enemies are too strong.
Since 1.2 hit, enemy strength has definitely changed in the lower level dark zones. Especially enemies that use SMGs. Prior to 1.2, I could run around a low-level dark zone without almost ever touching my heal unless fighting another player. Mobs would do close to no damage to me. Then after 1.2, SMG mobs can almost kill me in 1 clip by themselves. What also makes no sense is that they are stronger than the boss mobs, guards with heavy machine guns, and pretty much any other large scale mob. The damage from SMG based mobs definitely feels broken.

It is not a cry for a nerf, but rather a check to see if things were over-tweaked or something since they are doing so much more damage than before and so much more damage than other mobs.

2. Enemies do not scale properly between DZ01-DZ06.
For this one, I will take the bracket 20-24 for example. In DZ01 the mobs are 19-20 with an occasional 21. DZ02-03 the mobs go from 21-24. So far so good. However, then 05-06 the mobs jump to 27/28+ there is no middle ground that should happen to scale up properly. This causes the low-level Dark Zone to have m ost people hanging out down in the lower DZ areas regardless of their level/gear/skill. This causes newer people in the bracket being targeted for easy kills more often because people have no reason to go into the higher areas because they will just get 1 shot by anything.

A suggestion here is to bring mob levels into scale with the level range of the bracket.
- DZ01: 19-20 (with bosses at 21)
- DZ02: 20-21 (with bosses at 22)
- DZ03: 21-22 (with bosses at 23)
- DZ04: 22-24 (with bosses at 25)
- DZ05: 25 (with bosses at 26)
- DZ06: 26 (with bosses at 27)

Making use of Purple/Yellow mob types as needed and were applicable. This would make the DZ05/DZ06 in the 20-24 bracket manageable without just getting 1 shot.

3. Exp from mobs does not scale properly.
This is one of the biggest issues, in my opinion, with the Dark Zone. Experience does not scale up with the varying DZ zones (01-06). This is one of the reasons that the Dark Zone becomes hated by newer players very quickly. When someone high-level dark zone rank comes and kills a low-end player, that low-end player usually wants to just leave/quit the Dark Zone. But the game is designed for this to happen. I will take the DZ20-24 bracket for example again.

Mobs in the DZ01 area give roughly 150 exp per kill. Mobs in the DZ06 give roughly 170 exp per kill. This is a massive under-scaling for the difficulty difference between the mobs in DZ01 and DZ06. Along with that, the amount of exp needed to level your DZ rank hits a high curve after level 10. While killing mobs is a valid method of leveling til around 40-50, you will start to slow down a major amount afterward.

Take for example, someone that is DZ rank 90. To get to 91, the required amount of exp is: 122,500

So at DZ01 that would take 816 mob kills at ~150 exp per kill.
Or, that would only take ~17 player kills at ~7000 exp per kill.

Clearly, this shows that going rogue is the clear way to level when you are high DZ rank.

You need 148,105 exp to level from 98 to 99. Again, that is ~987 kills at 150 exp. Or just 21 rogue kills at ~7000 exp per kill.

But atom0s! Just put on Increased Kill Exp gear you noob!

While that can help your incoming exp pretty well, it has a downside too. You sacrifice your stats to roll specifically for those boosts. Most people are going to focus on doing damage and surviving. Not focus on getting experience. This is something that in a game like this, is going to usually be ignored for doing more damage. Along with that, the items that can roll Increased Kill Exp have a chance of rolling much better secondary stats that assist with killing and surviving.

- Mask: Enemy Armor Damage
- Body: Ammo Capacity
- Knee Pads: Enemy Armor Damage, Scavaging, Resists

At low levels you lack gear set bonus' and such so you are usually forced to take specific rolls. Not to mention getting good rolls on other stats to line up with being able to even reroll the secondary stat.

You will basically be forced to roll a second set of gear just for exp per kill. And with the lack of stash space in this game (thankfully being addressed in the next major update) it is hard to hold two sets of gear for multiple characters with a shared stash. Especially when you have multiple bracket twinked characters.

With the hostile state of the Dark Zones now too with rope cutting and just general trolling, running around in gear that is not going to help you survive a pvp match is typically not peoples first choice to do. The population of the low level brackets is extremely random too due to people leveling up to 30 popping in at random along with the other twinks. One day a zone can be dead, and the next it can be packed. This can also change per-hour in some cases where the DZ will be empty then full a few hours later.

Having experience scale with the level of the DZ area would be nice to see, even if its not a huge amount increase, something is better.