Pushing Valheim's Limits

I recently started playing the Viking survival game Valheim, released by Iron Gate Studios on February 2nd. Since release, it has surpassed 5 and a half million sales. It's a ton of fun, and I definitely think it's deserving of the explosion of attention it's gotten. A friend and I started a dedicated server and started playing pretty consistently, getting pretty close to endgame. At one point, he and I both died while exploring a swamp biome far away from our base, and we wanted to see if there was a way to fly back up there and get our stuff back with admin commands or something similar. Those commands existed, but it turned out that there was no way for either of us to access them on a server, even with admin privileges.

 

This got me thinking about how I could change that, because I knew that this game was made with Unity; something I have a decent amount of experience with. I also know that, because Unity games are powered by C#, their code should be able to be easily decompiled using a tool such as dnSpy or something similar, due to the way C# is compiled (C# -> IL/Intermediate Language -> native (executable) binary). Intermediate Language, as the name suggests, is not quite as close to machine language as, say, x86 assembly. .NET binaries are not compiled to machine code until they are actually executed, meaning what is stored on your machine until you start up the game is IL. Because IL isn't as "obfuscated" from a human perspective as machine code would be, it can be easily converted back into C#. So I started poking around Valheim's binaries using dnSpy, seeing what I could get out of the game.

 

Dev Commands

It turns out that enabling the built-in developer commands for use in multiplayer wasn't hard. Not only that, but I was able to enable them no matter what, even if I wasn't an admin.

The first thing that caught my eye when I opened dnSpy was a class called Console.

 

Console.cs in dnSpy

 

I quickly started looking around in this class, and I found the first thing I was looking for.

In the Console class, there is a method called InputText. It was clear that this was the method responsible for handling all Console input, and for dealing with the behaviors necessary depending on what commands were entered.

 

The InputText method


It didn't take too much looking around to find what I was really here for. Scrolling down a bit, I could see the text "devcommands" encased in an if-statement:

 

devcommands!

 

At first glance, this was all I needed. However, looking deeper, I realized that nothing of value was actually happening here - the boolean 'm_cheat' was simply being toggled, and the fact that cheats were just turned on/off was being logged using (what I assumed was) a logging class called Gogan. But there was nothing here that would be preventing me from enabling the dev commands in multiplayer; it was just toggling a variable. So I knew what I was really looking for would be somewhere else.

 

I kept scrolling down, and eventually, I came across all of the developer commands themselves:

 

The meaty bits


This definitely has what I'm looking for. Specifically, in the if-statement at the top, there are two conditions that are crucial here. Number one, ZNet.instance.IsServer() and number two, this.IsCheatsEnabled(). The first one would definitely cause me problems, because obviously, neither me or my friend are the server, we are just admins on the server. This condition would mean that dev commands simply cannot be used on a dedicated server, because with a dedicated server, no player is the server. The server is the server, but it is not a player. This is contrasted with a non-dedicated server, where one player is the host (server), and the rest are clients. Also, I needed to know what exactly caused this.IsCheatsEnabled() to return true. As I soon found out, this.IsCheatsEnabled() had the same condition:

 

 

Knowing this, I only had to do two simple things to (hopefully) gain access to the dev commands in multiplayer: remove the ZNet.instance.IsServer() requirement in InputText, and remove it in IsCheatsEnabled also. I was easily able to do that using dnSpy.

 

Some of dnSpy's extremely useful features, Edit Method highlighted

 

Using 'Edit Method', I removed the IsServer() requirement in IsCheatsEnabled:

 

 

and I removed it in InputText also:

 

 

So now, if all is working as intended, the game should only make sure we are 1. in an active server, 2. acting on the local player (our client & not someone else's), and 3. that we have enabled cheats (and that's all, no IsServer() checking). Opening up the game, joining the server, and running the devcommands console command, we get this result: 

 

 

This looks promising, but lets see if actually running a command does anything...

 

 

Looks like it worked! I can now spawn things, change the time of day, teleport, and change the weather (for example) on any server, regardless of admin status.

 

So, there are a few important things to be learned about Valheim from this. The biggest being, the servers are entirely (or almost entirely) client-authoritative. Basically, the server leaves all authenticity checking up to the client, and anything the client says is okay gets allowed by the server. It is well known that this approach leaves the door open to a lot of hacks such as this and other illegitimate behavior, but given the 10 player server limit, the overall co-op nature of the game, and the fact that all servers require a password to join, this was probably more of a design decision than a flaw and I doubt it will change anytime soon. Regardless, this was fun to explore, and it only scratches the surface of crazy things I was able to allow myself to do in multiplayer. I may write up some of the others, such as enabling debugmode (flying, instakilling, free build), giving myself full access to all wards (equivalent to cupboards in Rust; they prevent other players from building in your area), allowing myself to build in dungeons, creating a "bomb" hotkey that destroys/kills all objects within ~20 feet of me, and more in the future. Thanks for reading!


Update on Unity Survival Project

This post is essentially a brief explanation of what has been happening with the survival project which I was working on that is the topic of the previous two posts.

 

Progress

The project (previously referred to as Project Evergreen) has seen a lot of changes since the previous post, however I have not been working on it as of lately and have shifted my attention to other projects.

Since I last posted about Project Evergreen I have implemented a simple "round" based WAN multiplayer solution using the Photon platform, new weapons, a completely redesigned terrain, new animal models, and more GUI features. The last time I worked on the project, however, was around mid-march of this year. I plan to eventually return to the project in the future, but since I have last worked on it, I have been looking into Unreal Engine 4 (UE4), learning C++, strengthening my C# skills and have been writing various .NET projects having to do with World of Warcraft, a popular MMORPG, such as the vanillamultiboxer (you can find the GitHub repository on the downloads page.)

 

What's next?

Since I am a student attending university, most all of these projects are hobbyist in nature and my attention tends to shift around frequently. For now, I will continue with my current C# projects for World of Warcraft and other MMORPGs, and my plan is to get my multiboxer project to a place where I feel is a good stopping point as well as attempt to write a bot for World of Warcraft in order to strengthen my knowledge of reverse engineering and memory editing. I'll continue to post updates to this blog page relating to my personal ideas, thoughts, and learning journey.


Wolves, Bears, and Health Items

Unnamed Unity Survival Project v0.0.10

I feel as though I'm at a good point in the development of this project to write up a post about what I have so far. I've been working somewhat frequently over the past month on this game, with intermittent help from a friend with some art assets and advice, and although I don't have much so far, the foundation has been laid. Until further notice, I will be referring to this project as Project Evergreen.

 

General Game Concept

As it currently stands, Project Evergreen will be about surviving a brutal wilderness, with starvation, thirst, wild animals and other people being your greatest threats to survival. You will start out with a few simple items, wander around in the wilderness cutting trees for wood, mining for ore, and hunting for food. You will build a basic little house, repeat the process, build a better house, maybe kill a few people or raid their houses for resources, and build an even better house. The cycle goes on. If this sounds like any games you've already heard of, the correlation is not accidental; I have definitely been inspired by the survival genre. However, this is not to say that the game I'm working on will be a carbon copy of the others; by the time of release, I guarantee that it will be set apart in a number of different ways which I won't disclose yet. To sum it up, my idea of what this project will look and feel like in its final state will be a sort of anarcho-primitivism simulator with some FPS and RPG elements thrown in for good measure.

 

Progress So Far

As I've alluded to before, if you jumped into this game now with no prior knowledge of what it was supposed to be, a mass-multiplayer survival game might not be your first conclusion. Currently, I have a basic player (with no model) that can walk around, run, jump, and look around, and starts with an AK-74M.

 

First sights of the game after loading in (HUD disabled)

 

The area you spawn into is a sizeable wooded Island with mountains, grass, varying topology, large coniferous trees, some exploding crates (obligatory), and some bears/wolves that wander around and try to eat you. I have been putting the majority of my time into the core game systems required for a survival game up until this point, so although you may not see much, there's a lot going on in the backend.

 

Bears and Wolves

The bears and the wolves share the same brain. They have a basic AI system which I wrote that tells them to wander around a certain area until they are either shot or they spot a player. When that happens, they chase after you and attack until the player either kills them or outruns them. If the player manages to outrun them, they go back to wandering. Both the bear and the wolf enemy utilizes a decently intelligent yet brutally simple pathfinding system called NavMesh, and so they do quite well at avoiding obstacles while wandering or chasing.

 

Bears and wolves chasing me, also shown is the health HUD, action bar, and an early concept buff (resolution is not correctly configured, so ignore the odd placement)

 

Their animations are all working at about 80%; they both are animated for just about any situation a game like this could throw at them, and the only problems I've found so far are that they sometimes stay idle while wandering around, and their attacks are sometimes not synced with the damage they're dealing.

 

Inventory System

The inventory system has actually come out quite nicely so far, and it's what I have been putting a good deal of my time into fine-tuning in the last week or two. The inventory system will be the backbone of most all other actions that the player performs, so I feel that I need to mostly finish it before I can move on.

 

The inventory UI with a concept Item and the tooltip displayed

 

As it stands, the inventory looks quite basic. I wrote a very useful system for dealing with different item types which makes it easy for different types of items to be created that perform different actions when used while having to write minimal code. In Project Evergreen, just about all game components will derive from the inventory (as previously stated) such as weapons, building, consumables, resources, crafting, and so on.

 

Health/Stat System

The health system so far is fairly standard. All targetable entities have a set maximum health value, an armor value, the ability to be healed in a number of different ways (I have three different health consumables implemented now: bandages, medpacks, and injectors, hence the title), and will soon have a number of different resistance stats, such as cold resistance, heat resistance, poison resistance et cetera. These stats will be increased by the types of clothing the player is wearing, along with the armor (albeit to a lesser degree.) The amount of armor that an entity has decreases incoming damage by a static amount.

 

The early health HUD showing damage, hunger, and thirst (both concept)

 

Future Plans

I'm approaching the point where I have most of the foundational, basic game system in place, and I can start implementing content. When I feel I have finished the inventory system, I'll begin working on the building system; arguably one of the most important and difficult features in the game. One of the biggest tasks at hand now is changing the fact that weapons/tools are not deployed or used via the inventory, but are still separate from it and use an old pre-inventory weapon system that I developed very early on. I also plan on writing a buff system, and most consumable objects will give you a buff of some sort which adds stats or health, and many different attacks will apply debuffs that cause bleeding or poisoning.

 

Project Evergreen has no sound whatsoever at this point, and I'm soon going to look at implementing ambient sounds first, music, enemy, footstep and then finally gun sound effects later on. I'm also going to implement multiplayer sooner than later, as I don't want to have to rewrite the entire game to accommodate it if it ever came to that. Most all of the core game systems will likely come before I start replacing the prototype art assets; I'm going to have to learn how to be an artist because right now, I'm definitely more keen on the logical side of things. 😆


What is hyp3.us?

This website/design/platform was built from the ground up entirely by me in highschool as a web design project. It has seen numerous different uses over the years, mostly being purposed as a hobbyist project/playground for testing my web development skills. I've been wanting to put it to use for something for a long time, and at one point I was using it as a  platform to promote a Minecraft bot program I wrote in 2014, and then a game I worked on for a couple of weeks during the same year, and then again for a different Minecraft 'bot flooder' program I wrote in 2015, while intermittently being used for me to test out different web design ideas.

I never really went very far with any of those projects, and to this day most of them sit in their exact same states as they were, 4-5 years ago, on a desktop that I no longer use. However, a friend and I have started on a new project in Unity3D, a survival game currently dedicated to Legacy Rust (I will diverge from that as a model as I get better at using Unity, and as I get further along in development. Legacy Rust was simply the inspiration for me to begin creating the game.) I plan on finishing and ideally releasing it eventually. With that in mind, I decided to repurpose this website as a blog for the various checkpoints in the development of the unnamed project. I'll start posting detailed updates about what we're currently working on, and what stage in the development the game is in.

 

Here's a teaser:


Copyright © 2014-2021 Iota