DEV Community: Orkhan Huseynli

A gentle introduction to signed integer representation

Orkhan Huseynli — Mon, 09 Sep 2024 05:20:09 +0000

Introduction

When we talk about numbers and data types in programming we generally mention how many bytes they occupy in memory. For example, we say that 32 bit integer can hold values from 0 up to 2³²-1, 64 bit can hold up to 2⁶⁴ - 1 and etc. However, this examples are true when the integer is unsigned, which means that it consists of only positive numbers.

In signed integers, the ones that hold both negative and positive values, the minimum and maximum values are different: 32 bit signed integers can hold values from -2³¹ up to 2³¹-1.

Why? To understand it deeply, let see it visually.

Unsigned integers in binary

Let's say we have a 4 bits and we want to store unsigned integers in this 4 bits. The minimum value that we can store is 0 when the maximum value is 15. Let's write them all down to see it:

0000 -- 0 in decimal, this is the minimum
0001 -- 1 in decimal
0010 -- 2 in decimal
0011 -- 3 in decimal
0100 -- 4 in decimal
0101 -- 5 in decimal
0110 -- 6 in decimal
0111 -- 7 in decimal
1000 -- 8 in decimal
1001 -- 9 in decimal
1010 -- 10 in decimal
1011 -- 11 in decimal
1100 -- 12 in decimal
1101 -- 13 in decimal
1110 -- 14 in decimal
1111 -- 15 in decimal, this is the maximum

This is pretty clear and an usual way of how we think of binary representation of integers. What about negative numbers? If 4 bit integer was signed then its minimum value would be -8 (-2³) when the maximum value would be 7(2³-1).

Again why? Let's write them down:

0000 -- 0 in decimal
0001 -- 1 in decimal
0010 -- 2 in decimal
0011 -- 3 in decimal
0100 -- 4 in decimal
0101 -- 5 in decimal
0110 -- 6 in decimal
0111 -- 7 in decimal, this is the maximum
1000 -- (-8) in decimal, this is the mimimum
1001 -- (-7) in decimal
1010 -- (-6) in decimal
1011 -- (-5) in decimal
1100 -- (-4) in decimal
1101 -- (-3) in decimal
1110 -- (-2) in decimal
1111 -- (-1) in decimal

Now, this looks quite confusing, isn't it? One question you may ask is: Why is 1111 is -1 and 1000 is -8?. Now, if you add -7 and 7 or -1 and 1 or -5 and 5 in binary, you will see that you get 0 in binary (in 4 bytes, ignore the carry). Why this works? Is it a magic? To understand it clearly we need to understand complements technique. The reason, why negative 1 is 1111, because 1111 is 2's complement of positive one (0001). So, what is complement technique?

Complement tehcnique

Let's first begin with the decimal world. If we want to find 9's complement of any decimal number, we subtract it from all 9's. For example, if we want to find 9's complement of 58, we subtract 58 from 99:

99 - 58 = 41 --> is 9's complement of 58

If we add 1 to 41, we will get 42 and that will be 10's complement. So, adding 1 to the 9's complement gave us 10's complement. This is simply, subtracting 58 from 10.

99 - 58 + 1 = 42 --> is 10's complement of 58

Similarly, if we want to find 2's complement of any binary number, we subtract it from all 1's to find 1's complement and add 1 to it to get 2's complement. So, 1's complement of 1001 is: 1111 - 1001 = 0110 and adding 1 to it will give us 2' complement: 0110 + 0001 = 0111. But, how computers subtract a number from the other?

If you were careful, you would notice that to find 1's complement of binary number we don't need to practically subtract the number from 1111. Just flipping the bits would give us the right answer, so instead of subtracting, we could apply logical NOT operator to the number: NOT 1001 = 0110 --> 1's complement of 1001

Subtracting using complement

Since there is no subtraction operation in computers, we also need to subtract numbers using addition. Luckily, complement technique also helps here.

Again in the decimal world! Let's say we want to subtract 58 from 87. 10's complement of 58 is 42, and if you add 87 and 42 together it will give you 129. Remove, 1 from 129 (because we are only working with 2 digits and ignoring the overflows) and you will get 29. Guess what? 87 - 58 is 29.

Similarly, in binary world, if you want to subtract a number from another, find 2's complement of the small number and add it with the other. For example, to calculate 1100 1011 - 1001 1100, (203 - 156 in unsigned representation) find 2's complement of 1001 1100 which is NOT 1001 1100 + 0000 0001 = 0110 0011 + 0000 0001 = 0110 0100 and then adding it with the first number will give us 1100 1011 + 0110 0100 = 010010 1111. Since we ignore overflows, we will ignore first two digits of the result and our result will be 0010 1111 which is 47 in decimal (203 - 156 = 47).

Conclusion

Now, hopefully it makes sense why the negative numbers were depicted in the way they are. And as you already understood from the examples above any signed integers minimum value will be -2^n-1 and maximum value will be 2^n-1-1. If anyone asks you what is, let's say negative 8 in binary, just find what is positive 8 in binary, then two's complement of that number will be negative 8.

The contents of this article is heavily based on Number Theory for Programmers course on Udemy, so I highly recommend you to enroll and learn more.

Making Your NPM Package Executable

Orkhan Huseynli — Wed, 12 Apr 2023 21:13:45 +0000

You've probably seen such NPM packages, that you can execute on the shell directly. Let's take cowsay package for example. If you run npx cowsay Mooo! in your terminal, you'll see such an output:

Alternatively, you can install this package as a global dependency and then run it:



$ npm install -g cowsay
$ cowsay Mooo!

Shebang

The reason why we can run it in the terminal directly using cowsay command is because its executable file added to our PATH when we installed it with -g flag. You can see where it's located using which command:



$ which cowsay
/usr/bin/cowsay

If you inspect it with long listing format, you'll notice that, it's actually a symbolic link to a JavaScript file:



$ ls -l /usr/bin/cowsay
/usr/bin/cowsay -> ../lib/node_modules/cowsay/cli.js

When we install a package globally on a Linux system, the package will be downloaded into {prefix}/lib/node_modules folder and its bin files will be linked to {prefix}/bin folder. In our case the prefix is just /usr (run npm prefix -g to see it).

But how does the bash know which interpreter to use to execute this file? Well, if you see the first line of this JavaScript file you'll notice an output as following:



$ head -1 /usr/lib/node_modules/cowsay/cli.js
#!/usr/bin/env node

This line is called hash bang (or shebang) and it is used in scripts to indicate an interpreter for execution under UNIX/Linux operating systems. Simply, this is a directive for the bash that tells it to use indicated interpreter to execute the file.

Let's create a JavaScript file which has no extension and try to execute it using the shell:



$ touch my_script
$ echo "const os = require('os'); console.log(os.cpus().length);" >> my_script
$ chmod u+x my_script
$ ./my_script
./my_script: line 1: syntax error near unexpected token `('
./my_script: line 1: `const os = require('os'); console.log(os.cpus().length);'

If you see these errors, then you're on the right track. The file contains JavaScript code but the shell by default will try to interpret it using /usr/bin/bash interpreter, if you don't believe me, just run bash my_script to get the same results.

To execute this file using Nodejs, we either need to run node my_script or we need to add Shebang line. Let's do the latter. After adding the Shebang, your my_script file should look like mine:



#!/usr/bin/node
const os = require('os');
console.log(os.cpus().length);

You can try running it again as before or you can move this file to /usr/bin directory and try running it directly on your terminal. It will show you the number of logical CPU cores on your machine. For me it is 16:



$ sudo mv my_script /usr/bin/my_script
$ my_script
16

Hi-Mom CLI

Now, let's turn famous hi-mom NPM package to a CLI application. Firsly, let's clone the repository and open it in our editor:



$ git clone https://github.com/tsivinsky/hi-mom.git
$ cd hi-mom && code .

Let's create a cli.js file in the root of the project folder and add the following code as its contents:



#! /usr/bin/node
import { hiMom } from "./index.js";

const name = process.argv[2];
const lang = process.argv[3];

console.log(hiMom(name, lang));

Also add the following line to the package.json file to show NPM where to look for bin files:



...
"bin": "./cli.js",
...

We also need to make sure that this file has execute permission for all users and groups:



$ chmod +x cli.js

Now, if you run npx hi-mom you'll see the desired output:

To be able to call it whithout npx, we need to install it globally, hence this package needs to be published to NPM registry. But to keep it simple, we can just create a symbolic link for it. Just run npm link in the root of project folder.

Then you can run it everywhere:

Conclusion

I hope this article was helpful. If you have any questions or contradictions, please leave a comment and if you liked this post, like and share. Thanks a lot for reading.

References

https://docs.npmjs.com/cli/v9/configuring-npm/package-json#bin
https://docs.npmjs.com/cli/v9/commands/npm-install#global
https://docs.npmjs.com/cli/v9/configuring-npm/folders#description
https://www.baeldung.com/linux/shebang

Verifying Integrity of Files using NodeJS

Orkhan Huseynli — Sat, 01 Apr 2023 19:22:14 +0000

While using third party JavaScript or CSS libraries from CDN, you've probably came across with integrity attribute on script or link tags.

<script 
  src="https://code.jquery.com/jquery-3.6.4.min.js" 
  integrity="sha256-oP6HI9z1XaZNBrJURtCoUT5SUnxFr8s3BzRl+cbzUq8=" 
  crossorigin="anonymous">
</script>

If you haven't researched about them till now, then you're in the right place.

Man in the Middle Attacks

It's possible that the any data which travels through internet can be modified till it reaches to our machine. An attacker might use techniques such as network eavesdropping to intercept the requests and responses between you and the server and might manipulate the file before you even receive it.

We need a way to verify that the file we've received has not been tempered with.

Subresource Integrity in Browsers

Browsers implement a security feature called Subresource Integrity (SRI) to verify integrity of the resource they fetch and execute.

The garbage looking string of characters you see as the value of integrity attribute is Base64 decoded cryptographic digest formed by applying specific hash algorithm to the contents of the file.

If any characters inside the file changes, then the calculated hash will also change, thus integrity verification will fail, thus the browser will know that the file has been tempered with.

If browsers cannot verify integrity of the file being requested, they'll show error message similar to this:

Failed to find a valid digest in the 'integrity' attribute 
for resource '<resource-name>' with computed SHA-256 integrity '<calculated-hash>'. 
The resource has been blocked.

Performing Integrity Check with NodeJS

To show a little demo how this check might be implemented, I'll use NodeJS's crypto module. We'll use the same jquery file the you saw in the first paragraph. I'll download that file into my machine to be able to make modifications later.

Let's create an index.js file and import fs and crypto modules:

import crypto from 'crypto';
import fs from 'fs';

We'll need fs module to read contents of the file that we want to verify integrity of. Let's declare resource name and expected integrity:

const resource = 'jquery-3.6.4.min.js';
const expectedIntegrity = 'oP6HI9z1XaZNBrJURtCoUT5SUnxFr8s3BzRl+cbzUq8=';

Note that sha256 in front of the value of integrity attribute is just the name of hashing algorithm that this hash has been calculated with, so we skip it when comparing.

Let's read the file contents and calculate the digest using sha256 algorithm:

const jquerySource = fs.readFileSync(resource);
const digest = crypto
  .createHash('sha256')
  .update(jquerySource, 'utf8')
  .digest();

const calculatedIntegrity = digest.toString('base64');

The value of digest variable is a type called Buffer which is just bunch of bytes, so we need to convert it to a string in base64 encoding.

And finally, we just need to compare calculatedIntegrity with expectedIntegrity, if they are equal then the jquery-3.6.4.min.js has not been tempered with, if not, it means something has changed inside the file:

if (calculatedIntegrity == expectedIntegrity) {
  console.log('✔️ Resource integrity verified!');
} else {
  console.log(`❌ Failed to find a valid digest in the 'integrity' attribute 
  for resource '${resource}' with computed SHA-256 integrity '${calculatedIntegrity}'.`);
}

If you run this code using node index.js then, you might see this output:

$ node index.js
✔️ Resource integrity verified!

Now, if you change the contents of jquery-3.6.4.min.js file, and run the code again, then you'll see output similar to this:

$ echo 'some malicious code' >> jquery-3.6.4.min.js
$ node index.js
❌ Failed to find a valid digest in the 'integrity' attribute 
  for resource 'jquery-3.6.4.min.js' with computed SHA-256 integrity '+FiqKbj0h12Db1PZj62G+h2BMtOueBg26YQOJFY+6wg='.

Conclusion

I hope this article was helpful for you, I suggest you read more at article at Smashing Magazine about Subresource Integrity and share your thoughts.

You can see the full version of the code we wrote at my GitLab repository.