EP1436703A2 - Method for producing an error detection message in a portable data medium - Google Patents
Method for producing an error detection message in a portable data mediumInfo
- Publication number
- EP1436703A2 EP1436703A2 EP02772281A EP02772281A EP1436703A2 EP 1436703 A2 EP1436703 A2 EP 1436703A2 EP 02772281 A EP02772281 A EP 02772281A EP 02772281 A EP02772281 A EP 02772281A EP 1436703 A2 EP1436703 A2 EP 1436703A2
- Authority
- EP
- European Patent Office
- Prior art keywords
- program
- portable data
- data carrier
- source code
- troubleshooting
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/366—Software debugging using diagnostics
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/3636—Software debugging by tracing the execution of the program
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/3648—Software debugging using additional hardware
Definitions
- the invention relates generally to the field of software development for portable data carriers, in particular in the form of chip cards, and more particularly to the field of troubleshooting software that is intended for execution by a processor of a portable data carrier or a chip card.
- Portable data carriers in the form of chip cards are well known in many configurations. For example, they become
- Access control or used in payment transactions usually have a semiconductor chip with a processor and at least one memory.
- chip cards are also available in other designs, e.g. as a keychain or rings.
- the term “chip card” is used to refer to all of these configurations.
- chip cards which provide coded error information on the chip card when an error occurs during program execution.
- This error information must be evaluated by experts, assigned to the respective sections in the source code of the program being executed, and then passed on to the actual program developer. This process is cumbersome and in turn prone to errors.
- the invention is intended to do this Contribute to increasing the reliability of troubleshooting in chip card programs and / or reducing the effort associated with troubleshooting and / or reducing or avoiding the effort associated with programming a software emulator.
- the invention is based on the basic idea of storing, at least during the design process, the data required for convenient troubleshooting in the chip card itself and the processor of the chip card ⁇ for accessing this data, for generating a fault-finding message understandable for the programmer and for output use this message as the output data record of the chip card.
- At least one transmission table with a plurality of entries is provided as part of the assignment data stored on the chip card. Each entry is preferably assigned to a range of the program counter count. In those program sections for which the troubleshooting is to be carried out, at least one entry in the transmission table is preferably provided for each program counter reading.
- the entries in the transmission table preferably each contain at least one entry relating to the source code of the program being executed. For example, the number of a source code line and / or the name of a source code construct and / or a reference to a name of a source code construct can be contained in each entry of the transfer table. This information preferably relates to that area, in particular that line of the source code, which corresponds to the program counter reading for which the entry in the transfer table is intended.
- a “source code construct” is to be understood in particular, but not exclusively, to mean the names of variables, constants, functions, procedures, methods and modules.
- the term “reference” is to be understood here in particular, but not exclusively, as pointers, references, identifiers (tags) or index numbers.
- APDU application protocol data unit
- the event evaluated in the troubleshooting is preferably the occurrence of an error or an exception or an interruption. These events can be triggered at the hardware or software level. If a software exception, e.g. If an access attempt occurs outside the boundaries of a memory field, this is preferably first processed by a customary exception handler in order to trap exceptions that may be provided in the normal program flow. In preferred embodiments, the occurrence of an exception only leads to the execution of the method according to the invention if it is ensured that the exception indicates an error or an unintended problem.
- the occurrence of the predetermined event is monitored on the chip card during program execution.
- program is to be understood in the broadest sense as a sequence of commands for the chip card processor.
- preferred embodiments of the invention intercept error events that occur during the execution of an application program and / or a runtime environment, in particular a virtual machine, and / or an operating system routine including hardware-related drivers of the chip card ,
- the program counter evaluated according to the invention is the program counter register of the processor or a virtual program counter of a runtime environment, which can be implemented by a further processor register or as at least one word in the memory of the chip card.
- a virtual program counter can in particular be part of a virtual machine, for example a Java TM virtual machine.
- the functionality according to the invention is used only for the purpose of troubleshooting during the development phase. This functionality can preferably be removed after completion of the program development in order to avoid security gaps.
- the error handling routine required for executing the method and / or the assignment data are included in a preparatory step as a so-called patch
- a method and a computer program product that automatically generate such error handling routines and / or mapping data and preferably provide them in the form of a patch are also considered to be within the scope of the invention.
- the error handling routine can preferably be connected to at least one program routine of the chip card via one or more exit points - and corresponding return points.
- This program routine can in particular be a runtime environment in which exceptions are processed while a user program is running.
- the chip card is preferably functional in the same way with and without the patch applied, except for error handling.
- FIG. 1 is a schematic representation of the functional layers of a chip card and the data flow according to an embodiment of the invention
- FIG. 2 shows the data structures used for storing the assignment data in the exemplary embodiment from FIG. 1, and
- FIG. 3 shows a flow diagram of the method sequence in the exemplary embodiment from FIG. 1.
- FIG. 1 shows a portable data carrier in the form of a chip card 10, which corresponds to the exemplary embodiment described here
- the chip card 10 is designed in accordance with version 2.1.1 of the Java Cßrrf TM standard from Sun Microsystems, Inc. Documentation about this standard can be found on the Internet at http://java.sun.com/products/javacard.
- other configurations of the chip card 10 are provided, which can generally be any smart card provided with a microprocessor or microcontroller.
- a hardware layer 12 has a processor 14, a memory 16 and other modules, not shown, which are integrated in a single semiconductor chip.
- the memory 16 is divided into several areas, for example a program memory, a P ⁇ fc / i memory, a working memory or the like, which are used in suitable technologies, for example as a mask-programmed ROM, EEPROM, RAM, etc. are implemented.
- the processor 14 has several registers, including a program counter 18.
- the elements of the hardware layer 12 are known per se, except for the programming of the memory 16, which will be described in detail below.
- a hardware-related operating system 20 is based on the hardware layer 12 and in particular provides drivers for modules of the hardware layer 12 as well as basic routines for file system administration and input and output routines.
- a VM layer 22 is set up on the hardware-related operating system 20, which provides a virtual machine 24 - here abbreviated to" VM ".
- the virtual machine 24 is generally a Program which simulates a different, generally standardized environment on the given chip card hardware
- the virtual machine 24 is a Java TM virtual machine, as described in the document “Java Card TM 2.1.1 Virtual Machine Specification”, Revision 1.0 dated May 18, 2000 (available at http://java.sun.com/products/javacard).
- virtual machine 24 may have other features or may be absent.
- the virtual machine 24 has a virtual program counter 26, which is implemented by a register of the processor 14 or by means of the memory 16.
- An exception processing module 28 is also provided in the virtual machine 24.
- the exception processing module 28 contains program routines that are called when an exception event occurs. The associated process steps are described in more detail below.
- An application program 32 is arranged in an application program layer 34. The application program 32 uses the interfaces provided by the API layer 30 in order to implement the desired function for the user of the chip card 10.
- the API layer 30 corresponds to the specification in the document "Java Card TM 2.2.1 Application Programming Interface", revision 1.0 of May 18, 2000 (available at the address given above), and the application program 32 is an im Byte TM present Java TM cardlet (CAP). Only one application program 32 is shown by way of example in FIG. 1, but if the chip card 10 is sufficiently powerful, several application programs 32 can also be loaded into the memory 16 and executed in parallel.
- CAP Java TM cardlet
- the components and program components of the chip card 10 described so far are known per se.
- the present exemplary embodiment of the invention relates to the functionality described in detail below, which makes it possible to generate a message intended for troubleshooting as output data record 38 of the chip card 10.
- an error handling routine 40 is provided in the VM layer 22.
- the error handling routine 40 is an optional addition - in the form of a patch - to the virtual machine 24, more precisely to its exception processing module 28, tethered.
- the exception processing module 28 has a exit point 42, which branches to the error handling routine 40.
- a return point 44 of the exception processing module 28 After the end of processing in the error handling routine 40, there is a return to a return point 44 of the exception processing module 28. While only one exit and return point 42, 44 is shown in FIG. 1, further such points are in the exception processing module in alternative embodiments 28 or in other program routines stored on the chip card 10, for example those of the operating system 20 or the application program 32.
- the error handling routine 40 has access to assignment data 46.
- the method is used when searching for errors in the application program 32.
- the assignment data 46 therefore contain information relating to the source code of the application program 32, and the assignment data 46 are loaded into the memory 16 of the chip card 10 together with the application program 32. For these reasons, the assignment data 46 is shown in the application program layer 34 in the conceptual view of FIG. 1. In alternative embodiments in which the troubleshooting in other program routines of the chip card 10 is to be supported, e.g. in the virtual
- the assignment data 46 relate to the source code of these program routines.
- the structures used for storing the assignment data 46 are roughly indicated in FIG. 1 and shown in more detail in FIG. 2.
- a transmission table 48 and a constant pool 50 are provided.
- the transfer table 48 contains a plurality of entries, which are shown as lines in FIG. 2.
- An entry is provided with the reference number 52 as an example.
- Each entry 52 defines that area of the virtual program counter 26 (VPC) or, in alternative embodiments, the program counter 18 (PC) for which the entry 52 is provided.
- the limits of this area start and end are specified in two fields 52A, 52B.
- each entry 52 has a field 52C which contains the line number of that source code line which corresponds to the area defined by the fields 52A, 52B. For example, if 32 byfecotiss instructions with addresses 456 to 466 were generated when line 123 of the source code of the application program was translated, fields 52A, 52B and 52C would contain the values 456, 466 and 123.
- each entry 52 in the transfer table 48 contains a reference to an entry 54 in the constant pool 50.
- the constant pool 50 has a plurality of entries; in FIG. 2 only the entry 54 is provided with a reference symbol as an example.
- Each entry 54 in the constant pool 50 contains, in a text field 54A, the name of a construct in the source code of the program being debugged — here the application program 32.
- Another field 54B denotes the end of the name.
- an indication of the length of text field 54A arranged in front of text field 54A can also be used.
- names of methods or functions or procedures or modules from the source code of the application program 32 are primarily given in the text fields 54A of the constant pool 50.
- the reference in field 52D of the entry in the transfer table 48 designates that entry 54 in the constant pool 50 which contains the name of the method or function or procedure or the module from the source code of the application program 32 in which the program counter range defined in the entry 52 is located located.
- This method or function procedure or module also contains the source code line specified in entry 52 in field 52C.
- further textual information relating to the source code of the executed program is contained in the constant pool 50 or in other structures of the assignment data 46 or in other fields of the memory 16.
- This can e.g. be symbolic names of variables or constants or parameters, or names of structure units of the program.
- the memory 16 preferably also contains textual descriptions of the possible causes of error or exception events. Conceptually, these descriptions can be assigned to the error handling routine 40, but they can also be contained in the constant pool 50 or in other data structures.
- the references stored in the fields 52D of the transmission table are pointers which point to the start of the corresponding entry 54 in the constant pool 50.
- the references in the fields 52D of the transfer table 48 are then not pointers, but rather corresponding identifiers which correspond to the respective identifiers in the constant pool 50.
- the data of the constant pool 50 are stored directly in the transmission table 48.
- the source code of the application program 32 is first translated in the exemplary embodiment described here. Furthermore - through an additional program that is integrated into the translator or designed as an external program may be - the mapping data 46, the error handling routine 40 and the data required to install the exit point 42 are determined and provided in the form of a patch. This patch is then loaded into a conventional chip card 10.
- the application program 32 can be loaded into the chip card 10 on this occasion or before or only later.
- the assignment data 46 is always loaded together with the application program 32, while the error handling routine 40 is loaded into the chip card 10 together with the virtual machine 24.
- step 60 in FIG. 3 If, during the execution of the program by the processor 14 of the chip card 10, an exception or, in alternative embodiments, an interrupt occurs (step 60 in FIG. 3), this leads to a call to the exception processing module 28 first of all checks whether the exception is due to a program error or should be caught in the running program (trapping). In the former case, a jump is made via the exit point 42 to the error handling routine 40.
- the error handling routine 40 first accesses the virtual program counter 26, step 62 in FIG. 3, in order to determine its counter reading.
- the program counter 18 is accessed instead, as is indicated in FIG. 1 by a dashed arrow.
- Step 64 in FIG. 3 is then searched for that entry 52 in the transmission table 48 which is assigned to the current program counter reading.
- the transfer table 48 can be run through in sequence, or a binary search method can be used if the entries in the transfer table 48 are sorted, for example, by increasing values in the fields 52A.
- the found entry 52 in the transmission table 48 contains in field 52C the line in the source code during the execution of which the runtime error occurred.
- step 68 the message provided for troubleshooting is generated from the two items of information determined in this way, which relate to the source code of the program being executed.
- this message can be, for example:
- a symbolic description of the cause of the error is preferably generated within the chip card 10, so that the message is then e.g. would read:
- the message generated in step 68 is output in a final step 70 as an output data record 38, in particular in the form of a response APDU, from the chip card 10. It can be from a usual terminal received and provides the developer with valuable information for program development without the need for additional hardware.
- the exit point 42 is removed again in order to rule out possible safety risks.
- the error handling routine 40 and the assignment data 46 are preferably also removed - or not even loaded into the chip card 10 at all - so that the finished product has as much free memory 16 as possible.
- the invention simplifies the test sequence, as a result of which considerable cost savings are possible or the quality of the finished product can be increased by expanding the tests.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
- Signal Processing For Digital Recording And Reproducing (AREA)
Abstract
Description
Claims
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE10145783 | 2001-09-17 | ||
DE2001145783 DE10145783A1 (en) | 2001-09-17 | 2001-09-17 | Generate a troubleshooting message for a portable disk |
PCT/EP2002/010085 WO2003025753A2 (en) | 2001-09-17 | 2002-09-09 | Method for producing an error detection message in a portable data medium |
Publications (1)
Publication Number | Publication Date |
---|---|
EP1436703A2 true EP1436703A2 (en) | 2004-07-14 |
Family
ID=7699316
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP02772281A Withdrawn EP1436703A2 (en) | 2001-09-17 | 2002-09-09 | Method for producing an error detection message in a portable data medium |
Country Status (3)
Country | Link |
---|---|
EP (1) | EP1436703A2 (en) |
DE (1) | DE10145783A1 (en) |
WO (1) | WO2003025753A2 (en) |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE10324384B3 (en) * | 2003-05-28 | 2004-11-04 | Giesecke & Devrient Gmbh | Debugging method for installation of user program in portable data carrier e.g. smart card, using diagnosis program for detection of faults in installation routine |
DE102004007614A1 (en) * | 2004-02-17 | 2005-09-01 | Giesecke & Devrient Gmbh | Data carrier with sequence diagnostics memory |
DE102005028394A1 (en) | 2005-06-20 | 2006-12-28 | Giesecke & Devrient Gmbh | Method for treatment of failure events at portable data carrier involves treatment of failure event during installation of data carrier and appears in data carrier during predetermined execution of application program |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
FR2667419A1 (en) * | 1990-10-02 | 1992-04-03 | Gemplus Card Int | Memory-card application-program debugging process and debugging system |
US5371747A (en) * | 1992-06-05 | 1994-12-06 | Convex Computer Corporation | Debugger program which includes correlation of computer program source code with optimized object code |
US5446900A (en) * | 1992-07-24 | 1995-08-29 | Microtec Research, Inc. | Method and apparatus for statement level debugging of a computer program |
US5581696A (en) * | 1995-05-09 | 1996-12-03 | Parasoft Corporation | Method using a computer for automatically instrumenting a computer program for dynamic debugging |
DE19930120A1 (en) * | 1999-06-30 | 2001-01-11 | Siemens Ag | Multiprocessor-trace concept for system-on-semiconductor chip applications |
DE19954810B4 (en) * | 1999-11-13 | 2007-12-27 | Tenovis Gmbh & Co. Kg | Method for generating and debugging a machine program |
-
2001
- 2001-09-17 DE DE2001145783 patent/DE10145783A1/en not_active Withdrawn
-
2002
- 2002-09-09 WO PCT/EP2002/010085 patent/WO2003025753A2/en not_active Application Discontinuation
- 2002-09-09 EP EP02772281A patent/EP1436703A2/en not_active Withdrawn
Non-Patent Citations (1)
Title |
---|
See references of WO03025753A3 * |
Also Published As
Publication number | Publication date |
---|---|
DE10145783A1 (en) | 2003-04-24 |
WO2003025753A2 (en) | 2003-03-27 |
WO2003025753A3 (en) | 2004-01-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE69720821T2 (en) | Debugging system for programs with a graphical user interface | |
DE60031370T2 (en) | TOKEN-BASED LINKAGE | |
DE69533005T2 (en) | Byte code program interpreter, method and arrangement with pretest of data type restrictions | |
DE69932371T2 (en) | Movable instrumentation tags for testing and troubleshooting a computer program | |
DE69714752T2 (en) | USE OF A HIGH PROGRAMMING LANGUAGE IN A MICRO CONTROLLER | |
DE60021066T2 (en) | Checking a software package | |
DE102006007084B4 (en) | A system for providing programs to a user-operable device | |
DE102009024605B4 (en) | Apparatus and method for bypassing a first program code section with a replacement program code section | |
DE19960050A1 (en) | Test code generation method for automatic testing procedure for computer system using visual representation for selection of test object and test object options | |
DE10225664A1 (en) | System and method for checking polling events with polling wrappers | |
DE19536548A1 (en) | Generation of software tools for initialisation and personalising of memory card, smart card | |
EP1611510B1 (en) | Controlled execution of a program used for a virtual machine on a portable data carrier | |
DE60002455T2 (en) | METHOD AND DEVICE FOR AUTOMATIC SOFTWARE TESTING | |
DE102004057490B4 (en) | Device and method for processing a program code | |
DE60224937T2 (en) | METHOD AND ARRANGEMENT FOR ASSOCIATING APPROVED APPLET FILES | |
DE10038499A1 (en) | Formal verifying method for development in data processor involves executing verification algorithm using one limit of signal envelope, and limiting state-space search by using verification algorithm | |
DE10357257A1 (en) | Java smart card chip with memory area reserved for global variables | |
EP1436703A2 (en) | Method for producing an error detection message in a portable data medium | |
EP1709534B1 (en) | The running of a program by a virtual machine | |
DE102005060714B4 (en) | Data processing device, memory card, method of operating a data processing device and method of manufacturing a data processing device | |
DE10324384B3 (en) | Debugging method for installation of user program in portable data carrier e.g. smart card, using diagnosis program for detection of faults in installation routine | |
DE19926467C1 (en) | Computer system operating method has each individual program command of loaded computer program checked before program execution | |
EP1732001B1 (en) | Validation of a program on a data carrier intended for native execution by a processor | |
DE102018001565A1 (en) | Security element and method for access control to a security element | |
EP1516245B1 (en) | Device and method for processing a sequence of jump instructions |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
AK | Designated contracting states |
Kind code of ref document: A2 Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LI LU MC NL PT SE SK TR |
|
AX | Request for extension of the european patent |
Extension state: AL LT LV MK RO SI |
|
RIN1 | Information on inventor provided before grant (corrected) |
Inventor name: STOCKER, THOMAS Inventor name: KRAMPOSTHUBER, GEORG |
|
17P | Request for examination filed |
Effective date: 20040708 |
|
17Q | First examination report despatched |
Effective date: 20071005 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN |
|
18D | Application deemed to be withdrawn |
Effective date: 20150401 |