|
Chaos Digest 1.57
NOTICE: TO ALL CONCERNED Certain text files and messages contained on this site deal with activities and devices which would be in violation of various Federal, State, and local laws if actually carried out or constructed. The webmasters of this site do not advocate the breaking of any law. Our text files and message bases are for informational purposes only. We recommend that you contact your local law enforcement officials before undertaking any project based upon any information obtained from this or any other web site. We do not guarantee that any of the information contained on this system is correct, workable, or factual. We are not responsible for, nor do we assume any liability for, damages resulting from the use of any information on this site.
Chaos Digest Dimanche 20 Juin 1993 Volume 1 : Numero 57
ISSN 1244-4901
Editeur: Jean-Bernard Condat ([email protected])
Archiviste: Yves-Marie Crabbe
Co-Redacteurs: Arnaud Bigare, Stephane Briere
TABLE DES MATIERES, #1.57 (20 Juin 1993)
File 1--Guerilla dans les logiciels Unix (licence)
File 2--Djinn unie France Telecom et IBM France (produit)
Chaos Digest is a weekly electronic journal/newsletter. Subscriptions are
available at no cost by sending a message to:
[email protected]
with a mail header or first line containing the following informations:
X-Mn-Admin: join CHAOS_DIGEST
The editors may be contacted by voice (+33 1 47874083), fax (+33 1 47877070)
or S-mail at: Jean-Bernard Condat, Chaos Computer Club France [CCCF], B.P.
155, 93404 St-Ouen Cedex, France. He is a member of the EICAR and EFF (#1299)
groups.
Issues of ChaosD can also be found from the ComNet in Luxembourg BBS (+352)
466893. Back issues of ChaosD can be found on the Internet as part of the
Computer underground Digest archives. They're accessible using anonymous FTP:
* kragar.eff.org [192.88.144.4] in /pub/cud/chaos
* uglymouse.css.itd.umich.edu [141.211.182.53] in /pub/CuD/chaos
* halcyon.com [192.135.191.2] in /pub/mirror/cud/chaos
* ftp.cic.net [192.131.22.2] in /e-serials/alphabetic/c/chaos-digest
* cs.ubc.ca [137.82.8.5] in /mirror3/EFF/cud/chaos
* ftp.ee.mu.oz.au [128.250.77.2] in /pub/text/CuD/chaos
* nic.funet.fi [128.214.6.100] in /pub/doc/cud/chaos
* orchid.csv.warwick.ac.uk [137.205.192.5] in /pub/cud/chaos
CHAOS DIGEST is an open forum dedicated to sharing French information among
computerists and to the presentation and debate of diverse views. ChaosD
material may be reprinted for non-profit as long as the source is cited.
Some authors do copyright their material, and they should be contacted for
reprint permission. Readers are encouraged to submit reasoned articles in
French, English or German languages relating to computer culture and
telecommunications. Articles are preferred to short responses. Please
avoid quoting previous posts unless absolutely necessary.
DISCLAIMER: The views represented herein do not necessarily represent
the views of the moderators. Chaos Digest contributors
assume all responsibility for ensuring that articles
submitted do not violate copyright protections.
----------------------------------------------------------------------
Date: Mon Jun 14 12:53:35 GMT 1993
From: [email protected]
Subject: File 1--Guerilla dans les logiciels Unix (licence)
Guerilla Guide to Licensing Software
DRAFT VERSION 0.1
Abstract
This short article discusses some of the weaknesses of various licensing
schemes to control the use and distribution of Unix software. In particular,
examples will be given of actual commercial products which can be "cracked"
with a minimum of effort. The intention is to provide some observations which
will be of use to implementers and designers of software or those integrating
licence managers into their products.
DISCLAIMER: I am not recommending that you steal software. The purpose of this
article is to point out to vendors to weaknesses of the schemes they use.
Please do not use this information for illegal purposes.
For obvious reasons the author of this document wishes to remain anonymous.
Network licence servers or node locked licences have become very popular in
the Unix world over the last few years. Most vendors now use them, as they
provide an easy means to control the use and distribution of commerical
software with a minimum of customer inconvenience. Unfortunately many of these
provide a false sense of security for the vendor in that any skilled "cracker"
can break the scheme thus turning a demonstration version into an unauthorised
unlimited licence version or adding licences to an already purchased version.
In particular, many vendors provide demonstration versions of software which
either have expiry dates (fully functional short term licences) or have
limited functionality. This approach is inherently weak in that it is usually
possible to convert this demonstration version into a fully functional long
term version. Vendors like this sort of scheme because a customer can call up
and purchase the product, and have a licensed version immediately, if he/she
has a demonstration version, say from a CD-ROM library of demonstration
programs. However, in this case, the demonstration version will undoubtedly
be distributed to a lot of potential customers. From the vendor's point of
view, the sort of "cracking" which turns a demonstration version into a
"real" version is probably a more serious problem that "cracking" to gain
extra licences.
I'm going to start with a brief overview of the methods most of these products
use to generate licences. Most of the schemes use some sort of cryptogra-
phically strong hash function to give a level of security. Examples of these
are MD2, MD4, MD5, Snefru and the NIST Secure Hash Standard (FIPS-180). These
hash functions all have the property that it is computationally difficult to
determine the input given the output or to determine two outputs which hash to
the same value. The security of the system usually relies on the secrecy of
the hash function used and the difficulty of inverting that function.
a) Node-locked licences.
These are licenses to run a certain number of copies of a product on a
single computer. Usually some sort of unique host identifier is hashed
together with the number of licences, expiry date, and possibly some customer
identification information (company name &c.). The host identifier and number
of licences are stored in plaintext together with the hash value, e.g.:
hostid 66777777
hostname foo
licences 7
key 4f4c998319b26020a20ed60e146c7d60
For our example the hash function is a function H of hostid, hostname and
licenses, probably constructed using the composition of some simple string
manipulation and either one of the "secure" hash functions mentioned above
or perhaps a hash function designed by the licensing software vendor.
The vendor, given the hostid, hostname and licences, computes
H(hostid,hostname,licences)
and gives this to the customer upon purchase. The product would check the
hash value by computing H(hostid,hostname,licenses) and checking that value
against the licence key. If they don't match, a violation is detected and
presumably the product will not function correctly. In our specific example
if an unscrupulous customer changes the value to "licences" to 8, the key
the product computes will not match the key value given by the vendor and
a violation will be detected.
Now, you might ask, "why is this system inherently weak?". Well, the answer
is sort of obvious, if our unscrupulous user could monitor the execution of
the program in order to find out what the key should be given altered
licensing data, then he/she could "crack" the system. If a demonstration
version has an expiry date, this sort of scheme might allow someone to change
this date and therefore have access to a "real" version of the product.
b) Floating licences:
Are essentially very similar. A licence server runs on a host or set
of hosts. The verification of the key is usually done by the server on
startup. Some sort of protocol (which might include encryption) is used for
client-server communications.
The attacks I give below will involve actual modification of the product in
question. None of them took over four hours (and I'm not a particularly
talented hacker).
As an aside, an obvious solution to the above would be the use of public key
methods. There are two obvious problems here, the first being that all such
methods are patented and thus the user would have to pay a license fee. The
second is that digital signature algorithms often would produce keys that are
much too large for the average user to type in. Clearly a 128 byte key (256
hex digits) would be acceptable to most customers, but if you use something
like RSA to sign your licensing information, you are looking at something on
that scale.
Types of attacks:
1. Bypass the licensing routines altogether;
2. Run the licensing routine but change its return value;
3. Determine what the licence key "should be" given the other (altered)
licensing data;
4. Change the values of certain interesting variables.
The attacks I'll discuss will involve the use of some sort of debugger.
The appropriate debugger often depends on the system you are working with.
Usually lower level debuggers are better as little or no symbolic
information will be available (most vendors strip binaries). However, in many
cases if the product is dynamically linked, you can "unstrip" the relevant
programs to restore much of the symbolic data. Obviously you are ahead if
there is a routine called check_licence() and you know when and where it is
called, you have some useful information to attack the product. (an unstrip
program for sun os 4.1 is included with this file. The same sort of thing
works under AIX 3.2 and Solaris 2.x, for example).
So for licence software designers and integrators.
I. First principle
+------------------
Obscure symbolic information:
* Strip your binaries.
* Statically link if possible.
* If you can't statically link, try and obscure the symbol names. One
way to do this is to obfuscate all of the symbol names in your
distribution version. (opqcp available in comp.sources.misc vol 13 is
a useful tool for this, some might argue that using C++ is enough ;-) ).
The sample attacks will explain some obvious avenues of attack. The product
names will be changed to protect the vendors in question.
EXAMPLE 1
Product A, Sun 4, SUN OS 4.1.1
Product A is a nifty tool. The vendor will send you a demo version
if you call and ask. The demo version is fully functional, but will
expire after a couple of weeks.
Step 1 is to unstrip (indeed this one is dynamically linked).
Step 2. Change the expiry date in the licence file from 31-Dec-1992
to 31-Dec-1999 (now the key won't match what the vendor would have given
us if he/she had given us that expiry date).
A little work with adb reveals the following:
product A forks before it checks the licensing information. The child
does all the work.
So, step 3, reverse the sense of the test after the fork.
The source code (which we don't have) looks something like:
if (fork()) {
/* parent - just die */
exit(0);
}
else {
/* child - do the work */
}
So, we try and reverse the test. The resulting binary won't work properly
of course, but the point is to get some information on how things work.
So we:
cp product_a product_a_hacked_version
adb -w ./product_a_hacked_version
0x2664 - reverse the sense of this test.
i.e.
change
_main+0x30: be,a _main + 0x40
to
_main+0x30: bne,a _main + 0x40
e.g. you might do this by
0x2664?w 3280
It turns out (this is too easy), if you set a breakpoint on strncmp
after doing this, you will find that (on the first call to strncmp) one
of the parameters contains the value of the key from the licence file and
one of them contains the value the key should have.
One can then proceed by changing the key in the licence file. In this
case, I could change the expiry date to some date in 1999.
4> adb ./product_a_hacked_version
strncmp:b
:r 0 1 ./product_a_hacked_version
SIGCHLD 20: child status change
stopped at _isatty+0x98: bgeu _isatty + 0xc0
:c 0
breakpoint _strncmp: save %sp, -0x60, %sp
:s
stopped at _strncmp+4: call __DYNAMIC + 0x60
:s
stopped at _strncmp+8: sethi %hi(0xb000), %g0
$C
_strncmp(0x11330,0x157dc,0x14,0xf7fff314,0xf7fff314,0x63) + 8
_lm_checkout(0xe3f8,0x3ff00000,0x0,0x1,0x0,0xe3b0) + a60
_lm_checkout(0xe3f8,0x3ff00000,0x0,0x1,0x0,0xe3b0) + dc
_main(0x4,0x0,0x0,0x1,0x0,0x834) + 29c
0x11330?s
__mb_cur_max+0x1fc: 5AA6DC71361F95E20D1C
and yes, this is the required key value.
("too easy" you say, this product sells for over $2000 per licence!).
Indeed, the "unhacked" version runs nicely with the key and expiry date in
the new licence file. You might say that the vendor was singularly stupid,
but strangely enough, this sort of thing is very common.
II. Second Principle
+--------------------
Fully functional date locked demonstration versions are dangerous things.
III. Third Principle
+--------------------
Lock a smart hacker who knows nothing about the internals of your product
(new employees can be good for this) in a room with your product for a day
and see if he/she can crack it. Certainly this sort of thing is standard
practice in the design of cryptosystems.
IV. Fourth Principle
+--------------------
Try and obscure the functioning of your licensing code.
EXAMPLE 2
The case of product B
I'm going into somewhat less detail here because this is in a way similar
to product A. Product B is statically linked :-(
Product B is another nifty tool selling for >$1000 per license.
The vendor will give you a date locked fully functional version.
If the licence key is not verified (expired or whatever), product
B comes up in demonstration mode which has restricted functionality.
The mode (demonstration or licenced) is controlled by a single boolean
variable (integer value 0 or 1). This variable is checked when
someone tries one of the restricted functions, and the user
is either permitted to perform the function or not based on the
value of this variable.
The way to crack this, of course, was to insert an instruction near
the end of the licensing code which set the data location to the value 1.
Clues:
1. Whenever a restricted function was performed that address was accessed.
It wasn't accessed otherwise after the initial startup;
2. Value of 0 or 1 was a dead giveaway. A pointer to a string might have
been a better choice for the value of TRUE.
EXAMPLE 3
The case of product C
Product C is less expensive than either of the above. It was somewhat
harder to crack. Product C is also statically linked :-( We start
working from the case where there is an expired demonstration licence.
We use adb again. The following steps do the trick.
1. Locate main;
2. Find the call directly from main which prints out a message which
indicates that the licence file is invalid;
3. proceed down the "tree" of calls to find the lowest level routine
which prints this message. A little trial and error shows the conditional
branch which determines if a key is valid in this routine. Note that
this happens just after getimeofday is called!
or %o2, 0x57, %o2
mov 0x5, %o0
call 0x412c8
nop
ba 0x69e18
clr %i3
ld [%o5 + 0x37c], %o5
andcc %o5, 0x2, %g0
be,a 0x69e24
orcc %g0, %i3, %g0
call 0x13af50 - this calls gettimeofday(2)
clr %o0
ld [%i5 + 0x10], %o7
cmp %o7, %o0
0x69e08 bl,a 0x69e24 (originally bgeu,a 0x69e24)
orcc %g0, %i3, %g0
mov 0x1, %l2
clr %i3
clr %i0
Now the expired demo license will serve as a perpetual demo licence.
The demo version is fully functional
Now the expired demo license will serve as a perpetual demo licence.
The demo version is fully functional
EXAMPLE 4
The case of product D
Product D is statically linked.
We can bypass the licence routine completely by replacing the call to it with
a nop. The folling is an RS6000 exmaple.
0x10018444 (???) 4818e101 bl 0x101a6544 (???)
replace this with 38600000 lil r3,0
again we could determine the routine of interest by finding out which routine
printed the violation message when there was no licence.
Another option in this case was to insert a return instruction just after the
call to the licence routine (which incidentally calls gethostid first thing
and later displays a message about not being able to get a licence).
- From this we might observe, two related principles.
V. Fifth Principle. Modularity is a bad thing
+---------------------------------------------
If someone can subvert your code by altering one routine or changing one
variable, then the code is vunerable. Software engineering practice would
seem to dictate that you should have one routine or small set of routines
where all of the licensing code resides. However, this sort of approach is
inherently insecure. For instance in the above the routine which prints the
message indicating a licensing violation was the routine which verified the
licensing data. It would have been much better to seperate the two.
VI. Sixth Principle
+-------------------
When you write code for the licensing system, make sure that it can't be
easily subverted by changing any one single instruction. Program defensively.
Check often for licence violations. Duplicate all the "check" code if
necessary, so that the subversion of a single routine will not sucessfully
crack the system. If the cracker has to simultaneously modify three or more
instructions/variables, cracking is significantly harder.
Certainly it is impossible to make your system unbreakable. Consider in all
of the above, a somewhat experienced hacker could crack the system in less
than four hours. The goal of the implementor should be to design the licensing
components in a sufficiently convoluted way so that much more effort is
needed.
APPENDIX
Unstrip for Sun 4/sun os 4.1.1
+++++
From: [email protected] (Paul Kranenburg)
Newsgroups: alt.sources
Subject: unstrip a stripped dynamically linked executable.
Keywords: dynamic linking, debugging
Message-ID: <[email protected]>
Date: 22 Jan 92 16:13:25 GMT
Sender: [email protected]
Reply-To: [email protected]
Organization: Erasmus University Rotterdam
Lines: 1319
Ever found the odd core file lying around in your root directory
and discovered that it was dropped by some system supplied daemon
which didn't even contained a name list?
If this happens on SunOS 4.x system (and it certainly does happen on
ours) and the executable is dynamically linked (as most of them are)
you may at least be able to get a decent traceback with adb(1)
after forcing the necessary symbolic information into the open
again.
This is the purpose of the enclosed programme, which takes advantage
of the fact that the run-time linker (ld.so) needs the same symbolic
information to perform its task and is therefore included in
the executable's text segment by its companion, ld(1).
Quote from README:
"Information for the run-time linker is stored in an executable's text
and data segment. This includes a symbol- and string table in standard
(a.out) format. Careful examination of the <link.h> header file and
tracing of some simple dynamically linked programs reveal the intrinsics
of the run-time link process, enabling the extraction of the symbol
table and putting it back on the spot where it used to be before
the executable was stripped."
Cheers, Paul.
--------------------------------------------------------------------------
#! /bin/sh
# This is a shell archive. Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file". To overwrite existing
# files, type "sh file -c". You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g.. If this archive is complete, you
# will see the following message at the end:
# "End of archive 1 (of 1)."
# Contents: Makefile README defs.h nm.c nmd.1 unstrip.1 unstrip.c
# util.c
# Wrapped by pk@kaa on Wed Jan 22 16:35:51 1992
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f 'Makefile' -a "${1}" != "-c" ; then
echo shar: Will not clobber existing file \"'Makefile'\"
else
echo shar: Extracting \"'Makefile'\" \(746 characters\)
sed "s/^X//" >'Makefile' <<'END_OF_FILE'
X#
X# @(#)Makefile 1.2 92/01/22
X#
XBINDIR=/usr/local/bin
XMANDIR=/usr/local/man/man1
XCC=cc
XCFLAGS=-O
XOBJS=util.o
XKIT= Makefile README unstrip.1 nmd.1 defs.h util.c unstrip.c nm.c
X
Xall: nm unstrip
X
Xnm: nm.o $(OBJS)
X $(CC) $(CFLAGS) -o $@ nm.o $(OBJS)
X
Xunstrip: unstrip.o $(OBJS)
X $(CC) $(CFLAGS) -o $@ unstrip.o $(OBJS)
X
Xd2o: d2o.o $(OBJS)
X $(CC) $(CFLAGS) -o $@ d2o.o $(OBJS)
X
Xinstall: nm unstrip
X install -m 555 nm $(BINDIR)/nmd
X install -m 555 unstrip $(BINDIR)
X
Xinstall.man: unstrip.1 nmd.1
X install -m 444 unstrip.1 $(MANDIR)
X install -m 444 nmd.1 $(MANDIR)
X
Xclean:
X rm -f *.o a.out core nm unstrip d2o Part?? nm.tar.Z
X
Xkit: $(KIT)
X makekit $(KIT)
X
Xtar: $(KIT)
X tar cf - $(KIT) | compress > nm.tar.Z
X
Xnm.o: defs.h
Xunstrip.o: defs.h
Xd2o.o: defs.h
END_OF_FILE
if test 746 -ne `wc -c <'Makefile'`; then
echo shar: \"'Makefile'\" unpacked with wrong size!
fi
# end of 'Makefile'
fi
if test -f 'README' -a "${1}" != "-c" ; then
echo shar: Will not clobber existing file \"'README'\"
else
echo shar: Extracting \"'README'\" \(1634 characters\)
sed "s/^X//" >'README' <<'END_OF_FILE'
X@(#)README 1.2 92/01/22
X
Xunstrip - restore symbols and relocation bits in a dynamically
X linked object file
X
Xnmd - a nm(1) like programme that is capable of showing the name
X list and relocation information of dynamically linked executables
X
X
XInformation for the run-time linker is stored in an executable's text
Xand data segment. This includes a symbol- and string table in standard
X(a.out) format. Careful examination of the <link.h> header file and
Xtracing of some simple dynamically linked programs reveal the intrinsics
Xof the run-time link process, enabling the extraction of the symbol
Xtable and putting it back on the spot where it used to be before
Xthe executable was stripped.
X
XFortunately, the "internal" symbol table still includes entries
Xof symbols that were already resolved by the static linking process,
Xprovided they carry the "external" attribute.
X
XThe mechanisms employed by the dynamic linker have been declared
Xvolatile by Sun (cf. link(5)), so these programs may stop working
Xat any moment (perhaps even without upgrading your OS :-).
X
XHowever, the SVR4 SPARC ABI specifies many items related to dynamic
Xlinking and also documents the relocation types which are nowhere to
Xbe found in SunOS 4.1.x documentation (most notably the RELOC_JMP_SLOT
Xtype that appears to define the relation of a symbol to the Procedure
XLinkage Table). If this extrapolates to SunOS 4.1.x, some hacks in
Xthese programs could be cleaned up.
------------------------------
Date: 19 Jun 93 13:59:59 GMT
From: [email protected] (Yves-Marie Crabbe )
Subject: File 2--Djinn unie France Telecom et IBM France (produit)
Repost from: [email protected]
DJINN: the new French intelligent computer interface
Paris, France, June 19, 1993: France Telecom and IBM France have
teamed up for the first time to offer an innovative "communications"
personal computer known as Djinn. The world's number four
telecommunications operator and the world leader in the computer
market have put their combined technical and marketing power behind
Djinn, a product whose state-of-the-art technology will make PC
communications as ubiquitous as desktop computers themselves.
Djinn is a fax, Minitel videotex terminal, answering machine and
powerful personal computer all in one. The launch of this innovation
will drive development throughout the entire industry, since Djinn at
last creates direct integration of personal computer and
telecommunications environments.
Pre-development studies suring Djinn project have underlined a number
of important points:
* Both professional users and consumers express spontaneous confidence
in the quality of a PC-based telecoms product offered by France Telecom
and IBM, two brand names with substantial "credibility capital";
* The entire target population, from small businesses and professionals
to managers in larger firms, expresses demand for both open solutions
(acquisition of a single telecommunications device) and packaged
solutions (telecommunications device bundled with a PC).
Consequently, both types of products will be marketed:
* Djinn* is designed for connection to any PC equipped with Windows**.
The product consists of a modem (developed by Com1) and software
(developed by Integro) offering fax, Minitel videotext, answering
machine and telephony functions. The retail price is FRF3,990
(excl. VAT);
* The package product consists of the Djinn unit and an IBM PS/Value
Point*** (386 SLC-25 MHz), sold for FRF12,000 (excl. VAT).
Both solutions will be sold by IBM dealers and by IBM's direct sales
network.
The Djinn unit will also be marketed by France Telecom subsidiary EGT
under the France Telecom Equipements brand name.
_____
* Djinn is a registered trademark of France Telecom.
** Windows is a registered trademark of Microsoft Corp.
*** PS/Value Point is a registered trademark of International Business
Machines.
Djinn: A communications genie in every computer
Djinn is the first PC-based solution for the Windows operating
environment with a single application that integrates telephone
applications: fax, answering machine and videotex terminal. The
combination of these functions in a single unit ushers in a vast
improvement in the daily working environment.
Djinn comes in a pocket format box (95 x 60 mm) and features extremely
simple software which takes full advantage of the flexibility of the
Windows user interface. The solution is based on the use of an
external unit -- linked to the PC via the telephone network -- and an
innovative telecommunications application. The application is
designed around the "telephone directory/ agenda", which manages the
different features.
Djinn users must be equipped with a telephone and a PC with Windows
(minimum configuration 386SX/20 MHz, 4 Mb RAM, 60 Mb hard disk, VGA
screen, DOS v5.0 and Windows v3.1).
Djinn features:
DIRECTORY-AGENDA: UNIFIED PERFORMANCE
The directory-agenda is a powerful "personal organizer" which
groups full information on individuals (telephone, fax numbers). The
user simply clicks on the name of an individual to directly dial the
number and speak with the party to discuss a document on the screen
and then fax it, for example.
The directory-agenda also has an automatic calling feature and enables
access to services via the Teletel videotex hosts.
ON-SCREEN TELEPHONE
On-screen telephone use is simple and efficient. Dedicated icons
enable automation of features such as appointment reminders, directory
assistance or optional services like call forwarding, three-way
conferencing, or call waiting.
FAX TRANSMISSION HAS NEVER BEEN EASIER
With the "quick fax" feature, a text editor is used to add a
message to a personalized header page and send it immediately. The
fax selector function enables a document to be faxed from any Windows
application (word processor, spreadsheet, graphics, etc.) as easily as
launching a print job, with or without a cover page.
If the PC is connected to a scanner, documents not on the computer can
also be scanned and faxed.
Fax reception is active whenever the PC is on. The user is notified
that a fax has arrived and can then check the fax reception status
log.
ANSWERING MACHINE FUNCTION
The PC also becomes an answering machine with Djinn, since the
integrated microphone allows recording of several different messages.
Messages left by callers are digitized and stored on the hard disk
(the computer must of course be left on to activate this feature).
THE MARRIAGE OF MINITEL AND WINDOWS
Djinn enables access to all Teletel videotex hosts, along, with
four streamlined adaptations for easy use of the railway and airline
timetable services, telephone directory assistance and Minicom
services. All four services are transformed into full-fledged
applications. For example, all information requests are grouped on
one or two screen pages. For a train reservation on French national
railways (SNCF), for example, the screen shows the destination, date
and times, smoking/no-smoking seat selection, etc. database
information requests are executed as background tasks, keeping the
computer free to run other applications.
Djinn also integrates the Teletel High Speed photo mode (4,800 baud).
ONLINE USER SUPPORT
A user support server provides downloading of software updates or
dedicated adaptation of server applications. Djinn includes automatic
"click" access to the user support server.
Promotional campaign:
Market launch of Djinn will be supported by an advertising campaign
signed by France telecom in partnership with IBM. The theme of the
campaign is: "When your PC becomes a fax, Minitel and answering
machine, it's not magic, it's Djinn" [Quand votre micro devient fax,
Minitel, repondeur... ce n'est pas sorcier, c'est Djinn].
The campaign kicked off on June 10th and will be run in computer and
business trades, as well as in spezialized sector trades such as
medical, hotel of construction industry publications.
Djinn development parteners:
COM1
Founded in 1987, COM1 is specialized in the design and
development of telecommunications products. The European leader in
the modem market, COM1 has manufactured nearly 300,000 modems. In
1992 the company had sales of FRF90 million and sold over 100,000
modems.
COM1 is centered on its powerful R&D department. Manufacturing
operations are carried out in partnership with Slectron.
Bordeaux-based Selectron is an affiliate of one the United States'
leading specialists in high integration electronics contract work.
Other manufacturing partners are Cotee (Merignac) and Sofrel (Angers).
France Telecom acquired an equity stake in COM1 in 1990 via its
Innovacom subsidiary. AT&T Paradyne recently signed a technical and
marketing agreement with COM1 giving the company exclusive
distribution rights for its PCMCIA high-speed radio transmission
products (V32 and V32bis) for the EC, the former Soviet Union, Africa
and the Middle East.
Among the major accounts for which COM1 works are IBM France (and four
of its European subsidiaries), Toshiba, Apple and Hewlett-Packard USA.
INTEGRO
Founded in 1981, Integro is a French company with a number of
foreign affiliates (including subsidiaries in the United States and
the UK). The company generates a significant percentage of its sales
-- which rose from FRF10 million to FRF60 million between 1988 and
1992 -- in export markets. Integro currently has a work force of 100
persons, half of them involved in research and development.
Integro software products are designed to serve two areas of needs:
* Progressive evolution from centralized to distributed information
processing, enabling communications between workstations with these
two different types of architecture;
* creation of client-server architectures to guarantee total consistency
between existing IT resources and focused on department and cooperative
type computing solutions.
------------------------------
End of Chaos Digest #1.57
************************************
|
|
