A blog that accompanies our progress creating this product

Setting an upper limit

When a software house uses the Wizdome system, there is always the scenario where you need to check (and display) the remaining credit which the end-user has. Another scenario could be checking the status of a pending payment initiated via our Payment gateway (powered by PayPal).

This remaining credit can be anything billable: amount of data (MB),  time of use (hours / days) and we even had once a customer who measured their diamonds….

We assume that a customer should pay up to a certain amount and after paying it, he will get an unlimited license or unlimited access to this specific feature / resources that is currently restricted. To embed this functionality in the Wizdome system, we have added an attribute named “Max Billable Value”. When the Max Billable Value is reached,  the customer doesn’t have to pay any further. For example, if the Restriction is ‘amount of data (MB)’, then if we set the Max Billable Value to 200 (MB), then the moment 200 MB were purchased, any additional MB will be added for free, or there will be no limitation on using any number of MB from that moment.

From the source code point of view, the constant RESTRICTION_REACHED_UNLIMITED which is -2, when returned by the GetRemainingCredit(Restriction Name), indicates that the upper limit has been reached.

For example, the following source code can be used to generate a message based on the situation which could either be:

  • Additional credit has been added.
  • Credit has been added to the point, the Max Billable Value was reached.
 message.Format(L"You have reached the maximum billable credit ");
 message.Format(L"You have %dMB credit. Payment was successful ", Global.GetRemainingCredit(MB_LIMIT));

We have recently added a unique feature to Wizdome: payment processing embedded in your program using just few lines of source code.

Wizdome has a built-in payment processing engine which allows you to accept payments from any credit card holder (regardless of being a PayPal customer) and pay for unlocking your software or for specific features. As part of Datattoo Recovery, one of our other products, the customer can pay per each MB of successfully restored data.

To process payments you need to choose 2 routes:

  1. Apply as a PayPal developers and obtain your own PayPal credentials
  2. Use Wizdome credentials and receive all payments from Secured Globe, Inc.

Technically, the SG_PayPal API is used as described below. Following, your program can continue as before, while Wizdome will continue monitor the status of each payment initiated and in the event of a successful payment to a Pending Transaction, the credit (“max” value) of the associated Restriction, will be updated accordingly, so if your program checks the allowed maximum value per each per-defined Restriction, the value will become higher and your software can give additional access flawlessly.

Void InitPayPal(BOOL Sandbox, LPTSTR User, LPTSTR password, LPTSTR signature, LPTSTR successUrl, LPTSTR failedURL)

Sandbox – indicates whether you are testing your integration using PayPal's Sandbox account, or going live.

User – your PayPal user name

Password – your PayPal password

Signature – you PayPal signature

successUrl – a url leading to a web page which you wish to be shown after successful payment.

failedURL – a url leading to a web page which you wish to be shown after failed / cancalled payment.

Initiating a payment

When you wish to initiate a payment, you call

BOOL InitiatePaypalPayment(int nUnits, int PricePerUnit, LPWSTR UnitName, LPWSTR RestrictionName)

nUnits (integer) - number of unique needed to be purchased

PricePerUnit (integer) - cost per each unit (in default currency).

UnitName (string) - the name of the unit to be purchased

RestrictionName (string) - optional - the name of any restriction tied to this transaction

For example: if you would like a data recovery software to allow recovery of 15 MB for the price of $15, and provided that a Restriction named “MB_RESTRICTION” was defined, you call this function using the following parameters:



By default the currency used for transactions is USD, however that can be changed.

Tying a transaction to a Restriction

Wizdome allows you to tie a transaction (payment) to a Restriction. When you do so, the user will be able to lift or change a Restriction by making a payment and without having to switch versions, restart your program or restart any work done by your end-users.

This article is about obfuscation and protection against hacking.

Copy protection can’t be complete without some sort of obfuscation. The Wikipedia definition of Obfuscation is:

Obfuscation is the willful obscuring of the intended meaning of communication, usually by making the message confusing, ambiguous, or difficult to understand. The obfuscation might be unintentional or intentional (although intent usually is connoted), and is accomplished with circumlocution (talking around the subject), the use of jargon (technical language of a profession), and the use of an argot (ingroup language) of little communicative value to outsiders”

When applying this to software copy protection, our goal is to prevent a hacker from using reverse engineering methods, or more simple, hacking a protected application (which can even be examining the strings and other resources within the application).

Preventing that is done in several layers:

Source code obfuscation – if various elements of the source code and resources are obfuscated before the program is built, the built program will be obfuscated.

Binary obfuscation – manipulating the executable whilst making it hard to reverse engineer. That is usually done by making changes in the executable and yet preserving its format so it can still be executed (obviously if you encrypt an entire executable, you will reach the goal of making it impossible to reverse engineer but with the price of ruining the executable (PE) format in a way that will make it impossible to run it.

So clearly you need to make enough changes and manipulation to make it next to impossible to hack and reverse engineer and yet preserve the PE structure so it will still be a valid executable.

One solution to this problem is packing the executable by another executable (“loader”). I personally find this approach problematic. First, anti viruses detect a packer + loader as malicious code. Second, it complicates the process of protecting a program while we, at Secured Globe, Inc. aim to make it as simple as possible. The mechanism of storing parts of a program encrypted and decrypting these parts during run-time can be embedded as part of the program itself without having to wrap it entirely. For example, all resources can be stored as binary encrypted data or even stored as encrypted data without using the mechanism of resources which can easily be hacked using dedicated tools. Also all strings can be kept encrypted and decrypted during run-time. Strings reveal a lot of information about an application, its credentials (for example a server to which the program connects to, etc.).

Michael Haephrati published an article with source code about string obfuscation. We have examined a source code level obfuscation system and put aside the fact it is really a hard and exhausting work to obfuscate a c++ source code, the results are quite good.

The following code segment:

for (i=0; i < M.length; i++){
   // Adjust position of clock hands
   var ML=(ns)?document.layers['nsMinutes'+i]:ieMinutes[i].style;

will be changed to

for(O79=0;O79<l6x.length;O79++){var O63=(l70)?document.layers["nsM

Focusing in c++, the features supported by Semantic Designs are:

  • Output encoding in ASCII, European ASCII, or UNICODE
  • No changes to the your C++ compilation or execution procedurs or environment
  • User definable list of preserved names
  • Predefined list of reserved identifiers for C++ standard libraries provided
  • Can preserve most preprocessor conditionals and macro calls in obfuscated source
  • Option to neatly format C++ source code to aid development before obfuscation.
  • Output encoding in ASCII, European ASCII, or UNICODE
  • Command line and GUI interfaces

To explain further, our goal is to disguise the following elements: API calls, variables, function names, program flow, as they also reveal a lot (as strings and resources do) and should be changed to meaningless names. That can be done in house by a simple search-replace taken place just before the final generation of the Release version, and right after all code changes are made and all tests are completed.

While the process of hiding and disguising strings, resources, variables and functions with in the program is quite straight forward, when it comes to calling an API function, things become more complex since you want to obfuscate an API call and yet have the operating system respond to it…

One way of doing it is as follow: Instead of calling the API function directly, we use

GetProcAddress(hModule,reinterpret_cast<const char*>(reinterpret_cast<int>(szName) ^ MASK)); 

Then you build on top of it a function that receives an encrypted name of the API function, decrypts it during runtime and return the address of the real (decrypted) API function name. In our example, the encryption method is a simple XOR but of course any ecryption can be used as long as it is straight forward to decrypt it during runtime.

Next, the program calls the function at the returned address without specifying its name in any way. As a result, it will be hard to find this call by examining the obfuscated executable.

Obfuscating an application won’t do any good if a hacker is trying to break it using a debugger, so anti-debug techniques are also required. For example: we can assume that if a debugger is ran, various actions that we can measure the time they take, will take more time to be completed, so one way is to measure them and compare the results.

Of course we can check the existence of a pre-defined list of process names which we know are associated with know debuggers.

We can digitally sign various parts of our program and compare it to an ad-hoc generated signature during runtime, so in case a manual change was made by a hacker we will detect it.

The most efficient protection is creating a virtual machine during runtime and running the program code in it. This VM should be a custom one not known to others so it will be impossible to debug it without knowing how it works and impossible to find out how it works without debugging it. That will lead the average hacker to a dead end.




SQLiteWrappers v1.06

We read about an excellent wrapper library by PJ Naughter, an old friend, who is constantly creating and updating great solutions, code snippets and libraries.

PJ Naughter's space

Just to let everyone know that v1.06 of SQLiteWrappers has been released. Updates for this version include:

  • Updated copyright details.
  • Updated the code to compile against SQLite 3.17.0. Added support for sqlite3_expanded_sql, sqlite3_trace_v2, sqlite3_set_authorizer & sqlite3_system_errno.
  • Updated the code to clean compile in VC 2017.
  • Removed support for the deprecated APIs: sqlite3_trace & sqlite3_profile.
  • Replaced NULL with nullptr throughout the code. This does mean that VC 2010 is now the minimum compiler required.

View original post

Tailor Made Licensing

We have published a new blog post named: Tailor Made Licensing – by Michael Haephrati at www.securedglobe.com. The post is about Tailor Made Licensing as opposed to shelf licensing. If you are a software vendor who is interested in having your own in-house licensing and copy protection system, developed especially for you, please read this post and contact us.



There are many ways to implement software licensing but all of them rely on several attributes among them the date and time in which the software was first used (or activated) and today’s date and time.

Since it is possible to back date one’s computer’s date and time for the purpose of extending a trial period, licensing systems usually contain methods for detecting such change. Here are some of them:

Connecting to an NTP server

NTP stands for Network Time Protocol, and it is an Internet protocol used to synchronize the clocks of computers to some time reference. NTP is an Internet standard protocol originally developed by Professor David L. Mills at the University of Delaware. NTP is the most advanced method for obtaining Internet time. A licensing system would make periodic checks, typically during the time the end-user is connected to the Internet, and compare the internal date and time to the one returned by the NTP server of their choice. Wizdome does the same.

Check time-stamps of commonly used OS files

During the operation of any operating system, certain files are created and updated for the purpose of day to day operation.

For example, Windows has WindowsUpdate.logbootstat.dat both in the Windows directory, and perfc009.dat in the System32 directory. All of them should contain today’s date, so if you find out that the local date and time are different than the modification date of these files, there might be a risk that the local date and time were tampered.

Keep your own track

Provided that a licensing mechanism keeps track of previous checks, it is possible to detect the moment when the most recent check shows an earlier date than a previous one. Since we can’t go back in time, that indicates a manual change in the local date and time. Further, if the licensing system measures the accumulated time in which the software is used, we can assume that today’s date minus first installation / activation date, can’t have a smaller value than the accumulated time in which the software has been used. An attempt to reset a trial / or other date tied license to an earlier date, might reveal such discrepancy.




Using Restrictions

Our new Wizdome licensing system allows defining any type of Restrictions for any purpose. We were in contact with a customer who manufacturers software and hardware based equipment for processing diamonds. They wanted to license their software so it will be restricted to certain amount of free usage, while anything further will be priced. The criteria of “usage” in their case is the total weight of diamonds processed, and that’s a perfect example of our Restriction mechanism.

The Wizdome Functional Manual says:

“Restrictions Wizdome contains a propriety class for generic restrictions of any kind. This class makes it possible to define any possible restriction such as: – How many MB of data are allowed to be used / saved / restored/ etc. – How many files are allowed to be processed – How many Kg of weight can be used (ideal for diamond cutting software)”.

How is that done?

Even though our system is generic and allows anything you can think of to be restricted, we have created a predefined list of restrictions:

typedef enum 






} Units;

StorageSize will be useful for restricting backup, data recovery and other software products that deals with amount of data. For example: you can restrict the amount of data (in MB) used by defining that any amount of data above 100 MB will require payment of X USD per MB.

Distance will be useful for restricting GPS, Running APPs and other software products that deals with distance. For example: you can restrict the distance (in Km) allowed to be used by a running App, requiring the user to pay for the full version after using 10 Km.

Weight will be useful for software products that deal with materials and their weight. For example: you can allow your Trial version to support weighting diamonds for a total of 100 Grams, and require payment for anything heavier.

Size will be useful for software product that deal with paper (scanners), printing and so on. A typical example would be supporting scanning a small portion but requiring payment for larger sizes.