第一章：JavaCard虚拟机概述

各位同学，咱们今天聊聊JavaCard虚拟机。嗯，这玩意儿看着不起眼，但里面门道不少。我做了十几年智能卡安全，第一次接触JavaCard时，说实话，有点懵——这跟标准Java差别太大了。

1.1 JavaCard技术背景

先说说为什么要有JavaCard。你想想看，一张银行卡、一张SIM卡，里面能跑Java程序，这事儿在90年代可是个创举。传统智能卡用汇编或C语言开发，每换一个芯片厂商，代码就得重写。那叫一个痛苦。

JavaCard的出现，说白了就是为了解决这个问题。它让智能卡应用可以跨平台运行。我在项目中遇到过一家银行，他们发卡量上千万张，芯片供应商换了三家，但应用代码几乎没改——这就是JavaCard的价值。

我记得2010年左右，国内开始大规模推广金融IC卡，JavaCard几乎成了标配。为什么？因为银行需要动态加载应用，传统卡片根本做不到。

1.2 JavaCard与标准Java的区别

这里我要重点强调一下。很多新手上来就按标准Java的思路写JavaCard代码，结果跑不起来。为什么？因为JavaCard是个极度精简的版本。

对比项	标准Java	JavaCard
内存	几百MB到几GB	几KB到几十KB
垃圾回收	有，自动管理	没有，手动管理
字符串	String类完整支持	不支持String，只能用byte数组
多线程	原生支持	不支持，单线程模型
浮点数	float/double	不支持

你看这个表格，差距一目了然。我刚开始做JavaCard开发时，习惯性地new了一个String对象，结果编译直接报错。嗯，这里要注意：JavaCard连String类都没有，所有文本处理都得用byte数组。

还有一个关键区别：JavaCard的应用是事件驱动的。不像标准Java有main函数，JavaCard的Applet通过process方法响应APDU指令。这个设计理念完全不同。

1.3 JavaCard虚拟机架构

好，咱们来看看JavaCard虚拟机到底长什么样。我画了一张架构图，你一看就明白。

这张图展示了JavaCard的完整软件栈。从下往上，每一层都依赖下一层提供服务。我重点说说JCVM这一层。

1.3.1 JCVM的核心组件

JavaCard虚拟机由两部分组成：

• 解释器（Interpreter）：负责执行字节码。嗯，这里要注意，JavaCard的字节码是标准Java字节码的子集，大概只有一半的指令。
• 运行时环境（JCRE）：管理Applet的生命周期、分配内存、处理APDU分发。

我举个例子，你写了一个Applet，卡片上电后，JCRE会先初始化，然后调用Applet的install方法。之后每次收到APDU指令，JCRE就调用process方法。这个流程我调试过无数次。

1.3.2 内存模型

JavaCard的内存分三块：

内存区域	特点	典型大小
RAM	临时数据，掉电丢失，读写快	2-8KB
EEPROM/Flash	持久化存储，可擦写，速度慢	32-256KB
ROM	只读，存放固件和API类库	64-512KB

这里有个坑：EEPROM的写入次数有限，大概10万次左右。我见过一个项目，因为频繁写EEPROM，卡片用了半年就坏了。所以，能放RAM的数据别放EEPROM。

1.3.3 字节码执行

JCVM解释器逐条执行字节码。每条指令都是1字节的操作码，后面可能跟操作数。举个例子：

// JavaCard源码
short a = 0x1234;
short b = 0x5678;
short c = (short)(a + b);

// 对应的字节码（简化）
SLOAD 0    // 加载局部变量0（a）
SLOAD 1    // 加载局部变量1（b）
SADD       // 执行short类型加法
SSTORE 2   // 结果存入局部变量2（c）

你看，就这么简单的加法，在JavaCard里要拆成4条指令。为什么？因为卡片CPU资源有限，解释器得一步步来。

1.3.4 安全机制

JavaCard的安全设计是分层级的：

• 字节码校验：加载Applet时检查字节码合法性
• 防火墙机制：不同Applet之间不能直接访问对方对象
• 事务管理：保证数据操作的原子性
• 加密服务：硬件加速的DES、AES、RSA等算法

我记得有一次做安全审计，发现某个Applet的防火墙配置有漏洞，导致恶意Applet能读取其他应用的密钥数据。这个案例告诉我们：安全机制不是摆设，每个细节都得检查。

好了，第一章的内容就这些。JavaCard虚拟机虽然小巧，但五脏俱全。理解它的架构，是后续学习攻击方法的基础。下一章咱们会深入字节码层面，看看哪些指令容易被利用。