Skip navigation

Image making operators utilities

To make STB software image customers (operators) must use the following utilities provided by the manufacturer:

Operator Utilities to make STB software image

Attention!
If current used customized firmware were based on firmware version below 0.2.14-r8 it is recommended to remake it using specified Operators Utilities and present manual for improving STB security level.

Requirements to OS

It is required to use *nix system i386 (32-bit). We recommend using Ubuntu OS distributions.

If customers have 64-bit System they must additionally install the appropriate packages to supporting the 32-bit shared libraries. For example, for Ubuntu 14.04 - 16.04, must be installed lib32z1 package (32-bit shared libraries for AMD64).

All examples in this manual are given for Ubuntu Server 12.04 i386.

Required packets

Example. It is enough to install next package

  • for Ubuntu Server 12.04 i386: sudo apt-get install mtd-utils

  • for Ubuntu Server 12.04-16.04 x86_64: sudo apt-get install mtd-utils && sudo apt-get install lib32z1

Utilities

Operator utilities allow to make three different variants of STB software image:

  • PublicImage - image which is signed with standard “public key” - STB_PUBLIC.
    Updating variants: Starting from 0.2.14-r8 updates via HTTP or USB from portal to manufacturer STB software version only, (STB software versions that were assembled directly by the manufacturer and provided for automatic and manual updates located by manufacturer's URL).
    From Booloader menu can be updated on PublicImage or CustomImage (transitional version) via Multicast/USB with bootstrap/TFTP
  • CustomImage - image which is signed with “custom-key”. This key is created by operator without manufacturer.
    Updating variants: Updates via HTTP or USB from portal on STB software versions that are signed by the same key (custom-key). It is used if there is a need in STB update from portal (HTTP or USB update method).
    From Booloader menu can be updated on PublicImage or CustomImage (transitional version) via Multicast/USB with bootstrap/TFTP
  • OperatorImage - image which is signed with “operator key”. “Operator key” should be signed by manufacturer.
    Updating variants: Updates on STB software versions which are signed by “operators key" only.

Before building the image of the STB software, we recommend to read the following documentation: Operator's Guide (pdf), Specification JavaScript API (SW ver. prior to 0.2.18), Specification JavaScript API (SW ver. from 0.2.18)

It is recommended: Run all commands with root permission. Use tar console archivator.
Warning!The Command Shell which is in the scripts and System Shell can be different from each other!

Key points

1. Preparing of uImage, uImzlib_null.img, uImzlib.img

MAG-250/254/270 next files is used: vmlinux.bin.mag<model_number>

MAG256/324/349/351 next files is used: uImage_mag<model_number>.clean

where is <model_number> - STB model number (250, 254, 270, 256, 324, 349 or 351) vmlinux.bin.mag<model_number> or  uImage_mag<model_number>.clean take from release: http://soft.infomir.com/mag<model_number>/release/ and place to ./images directory.

Pay attention! For MAG322 is used files with <model_number> = 324

2. Kernel sign

The next script file is used: ./kernel_sign_<model_number>.sh where is <model_number> - STB model number (250, 254, 270, 256, 324, 349 or 351)

For example, for MAG254: ./kernel_sign_254.sh

Use for MAG322 and MAG324 models the same file: ./kernel_sign_324.sh

3. Profile preparing

The next script file is used: ./img_make.profile.mag<model_number> For example, for MAG254: ./img_make.profile.mag254

Use for MAG322 and MAG324 models the same file: ./img_make.profile.mag324

  Example of ./img_make.profile.mag254
#    Kernel's file system
export KERNEL_PATH=./uImzlib_mag254.img
#    File name for enviroment variable
export ENV_VARIABLE_PATH=./images/env_mag254.txt
#    Userfs
export USERFS_VERSION=1
export USERFS_PATH=./images/userfs.img
#    File name for SecondBoot
export SECONDBOOT_PATH=./images/SbootIm_mag254
#    File name for Logotype
#export LOGOTYPE_PATH=./images/logo.bmp.gz
export MAG200_OP_KEY=STB_PUBLIC

For correct work of KERNEL_PATH operator utility should be: ./uImzlib_mag<model_number>.img For example, for MAG254: ./uImzlib_mag254.img Variables ENV_VARIABLE_PATH , USERFS_VERSION , USERFS_PATH , SECONDBOOT_PATH , LOGOTYPE_PATH can be commented. In this case there will not be such section. Variable MAG200_OP_KEY should contain key identifier (ID), with which image will be signed.

  • Example:

export MAG200_OP_KEY=ID_key

where ID_KEY

should be:

  • STB_PUBLIC - for public image making. Utilities contain public key;
  • Custom-key ID - for custom image making;
  • Operators key ID - for operator image making.
  Profile variables description
Name Description
KERNEL_PATH The location of the image file system that contains the core. If the variable is not assignment, then use the ./UImzlib.img.
ENV_VARIABLE_PATH This variable should contain the path to the file, which contains the bootloader variables and their meaning. An example of such a file, see env.txt, He shows how to set variables of bootloader, in particular, font color and background color. “$” Symbol should be screened.
USERFS_VERSION Number of image version,which should be present in NAND partition named “Userfs”. If number of current image and new one are the same, update will not work.
USERFS_PATH The location of the image user file system (image to be recorded in the section “NAND” with the title “Userfs”). The image is prepared using the userfs_img.sh.Previously the operator must put the necessary files to it in a subdirectory named /userfs.
SECONDBOOT_PATH The path to the second image bootloader.
LOGOTYPE_PATH The path to the file logo, prepared by the operator.
  Example of env.txt
bg_color=0x00006498
fg_color=0x00FFFFFF
portal1=http://10.1.0.1/stalker_portal/c/index.html
language=en
update_url=http://10.1.0.1/imageupdate
ntpurl=10.1.0.1
timezone_conf=Europe/Kiev

Most used variables

4. Imageupdate making

Syntax:

./img_make.sh <version_number> "<description>" <path_to_rootfs> <modelname> <path_to_profile>

Example for MAG254:

./img_make.sh 218 "Test_my_version" ../../254/rootfs-0.2.18r14 MAG254 ./img_make.profile.mag254

Example for MAG256:

 ./img_make.sh 220 "Test_my_version" ../../256/rootfs-2.20.04 MAG256 ./img_make.profile.mag256

where:

<version_number>

version number of the image, must be a number (3 digits). After successfully upgrading the standard Bootstrap variable of bootloader “Image_Version” takes this value.

<description>

description of STB software image. Attention! Spaces are not allowed! After successfully upgrading the standard Bootstrap variable of bootloader “Image_Desc” takes this value

<path_to_rootfs>

the location/path to the Root File System STB. Root File System rootfs-….tar.gz you can get from release (MAG200, MAG250)

<modelname>

Model of STB for which the image is making. Can be MAG200, MAG250, MAG254, MAG256, MAG270, MAG322, MAG324, MAG349, MAG351, etc.

<path_to_profile> 

Profile/path to profile, in which additive sections can be configured. Must have the name of the next format: img_make.profile.<modelname>

Update, Automatic software update, Variables cheking system

By default, update and automatic software update is performed on the factory version.

“Software update” in “System settings” - By default, updates on manufacturer version. It is recommended to change URL of your STB software image version. Variable:

update_url

“Autoupdate module” from “Settings” in main menu - By default, autoupdate is turned on and initialize update to manufacturer's STB software versions. Update also available in manual mode.it is recommended to turn off or change URL to yours. Variables:

autoupdate_cond

,

betaupdate_cond

. Read more - Software autoupdate module

Variables cheking system - With purpose to increase security and control variables changing it is recommended to check necessary/critical variables while STB software version loades (for example:

portal1

,

portal2

,

update_url

,

autoupdate_cond

 etc.). Read more - Variables checking while portal starts

Notes on using GPG

The program gpg is used for working with keys and creating the digital signature of images. gnupg.org, GNU Privacy Guard - Wikipedia

To transfer the key from one device to another you may use the following commands:

  • for preserving the information of the key in the file and:
 gpg -o opsecbin.KEY --export-secret-keys ID_Key
  • for adding this key to gpg and:
 gpg --import opsecbin.KEY
  • for viewing currently available keys:
gpg --list-keys

PublicImage - preparing, making

CustomImage - preparing, making

OperatorImage

Instructions for making and updating the image are provided after agreeing the procedure for signing the operator's key with the commercial department.


Need Help

Dave is an expert on the MAG STB and the author of this article.

Was this article helpful?

Yes No

Sorry to hear that.
How can we improve this article?

We use cookies in order to optimise our website, provide you with the best possible user experience and help us promote our products. Please read our Cookie Policy to find out how we use cookies and how you can control cookies.
By using this website or closing this message, you acknowledge our Privacy Policy and agree to our use of cookies as described in our Cookie Policy.