Chaos Digest Dimanche 20 Juin 1993 Volume 1 : Numero 57 ISSN 1244-4901 Editeur: Jean-Bernard Condat (jbcondat@attmail.com) 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: linux-activists-request@niksula.hut.fi 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: user@anonymous.edu 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: pk@cs.few.eur.nl (Paul Kranenburg) Newsgroups: alt.sources Subject: unstrip a stripped dynamically linked executable. Keywords: dynamic linking, debugging Message-ID: <1992Jan22.161325.22872@cs.few.eur.nl> Date: 22 Jan 92 16:13:25 GMT Sender: news@cs.few.eur.nl Reply-To: pk@cs.eur.nl 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 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 '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 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: ymcrabbe@email.teaser.com (Yves-Marie Crabbe ) Subject: File 2--Djinn unie France Telecom et IBM France (produit) Repost from: telecom13.405.1@eecs.nwu.edu 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 ************************************