Smart cards are in the embedded world one of the few hardware devices that can be subject to targeted physical attacks from malicious and skilled people. These physical attacks can target any element of the chip resulting in unpredictable effects on the executed software. For an applicative developer who is more familiar with a high level language, it is a difficult task to predict the consequences of such low level attacks. Analysing the consequences of a physical attack and creating a realistic and plausible attack model is the first step that leads to a better understanding of the security of an application. But even with this model it is still difficult to pinpoint locations in the source code where physical attacks might lead to security vulnerabilities. Different approaches and techniques exist to simulate faults at hardware or software level. However most of them focus either on a high level of abstraction as with software fuzzing techniques or a precise description of the low level hardware as with a VHDL simulator. Since one of the developer's goals is to implement high level countermeasures to prevent low level attacks, both preceding approaches lack of expressiveness. Thus, the challenge is to simulate with additional C code the consequences of low level attacks such as register disruption, processor instruction modification, arbitrary jumps. The second difficulty is to deal with the number of possible attacks which is related to the code size, the size of variable domains and the persistence of the attack effect. As it is impossible to exhaustively simulate all the possible attacks, our study focuses on jump attacks. These are classical attacks that lead to a change in the control flow of the code and can be used to bypass security checks. In this talk we will present a cost effective methodology and a technical solution to simulate, at C level, the effects of physical jump attacks. Experimental results compare the effect of simulated high level attacks to physical low level attacks. In order to benchmark and validate the methodology, the experiments use the SPEC 2000 benchmarks with well- studied open source C codes. To make the analogy with the smart card, we consider that a successful attack against a SPEC 2000 software induces a termination with a wrong output. Crashes and non terminating executions are safe results from a security point of view. The results also show how to identify vulnerable functions in a complete application. The knowledge of potential vulnerable locations in the source code of a project will enable a software developer to implement his countermeasures accordingly with more precision and assurance.