Here is a CAP file possible containing a malware code, without source code, and also without an export file.
It is a CAP file for old platform version, i.e. GP211.
I have a big experience Java reverse-engineering in Classic JVM and Dalvik. But Java Card is lesser popular and closer platform. Most tools are for CLASS/JAR or DEX, not CAP.
I found the several tools (including some VMs who simulates the JCOP) which could disassemble a CAP file, but the CAP is quite big, and the working with assembly code is too complex and slow for me.
And we cannot simply do "CAP text bytecode -> Notepad++ --> some Java Bytecode editor -> Java bytecode".
Too many differences between CAP bytecode and Java bytecode. Not just method table, it is also a big amount of different opcodes.
Just decompile the converter.jar of a Java Card Kit (it is a tool which converts CLASS -> CAP) and see that conversion is a quite complex process.
I need some automated converter.
Meanwhile, I developing a set of smart card solutions and the "CAP decompiler" will be a good piece in the list.
Yes, I'm going to write it.
I plan to build it on top of Javassist from one side, some CAP disassembling library from the second one, and some standard Java decompiler(-s) from the third one.
But I should be sure that there are no analogs.
QUESTION IS HERE:
Is there some tool in the Earth which can convert Java Card *.cap to Java *.class (or decompile *.cap directly) or no?
I am not asking for a library (i found some libraries), I am asking for a tool. Runnable.
(Also if you know some pitfalls in this bytecode conversion I will be grateful if you'll describe them to me. Now I saw it as just a copying one opcode list to another one with a giant if...else if...else if...else if... or switch...case...case...case tree (and some misc staff i.e. conversion of access modifiers, fields, etc).
To generate .class files out of .cap file use normalizer tool which is part of recent Java Card SDK ('Classic-3.0.4' worked for me).
For example to convert helloworld.cap from gpshell sources use the following command (you will have to adjust api_export_files path to the appropriate directory):
normalizer.bat normalize -i helloworld.cap -p /path/to/api_export_files
Then you can decompile output file ( net/sourceforge/globalplatform/jc/helloworld/AAA.class) using your favorite java decompiler, giving e.g.:
package net.sourceforge.globalplatform.jc.helloworld;
import javacard.framework.APDU;
import javacard.framework.Applet;
import javacard.framework.Util;
public class AAA
extends Applet
{
private static final byte[] sfield_token255_descoff10_staticref0 = { 72, 101, 108, 108, 111, 32, 87, 111, 114, 108, 100, 33 };
public void process(APDU paramAPDU)
{
byte[] arrayOfByte = paramAPDU.getBuffer();
paramAPDU.setIncomingAndReceive();
Util.arrayCopyNonAtomic(sfield_token255_descoff10_staticref0, (short)0, arrayOfByte, (short)0, sfield_token255_descoff10_staticref0.length);
paramAPDU.setOutgoingAndSend((short)0, sfield_token255_descoff10_staticref0.length);
}
public static void install(byte[] paramArrayOfByte, short paramShort, byte paramByte)
{
new AAA();
}
private AAA()
{
register();
}
}
Some additional (random) notes:
this approach does not straightforwardly work for all applets (some output .class files for an applet I wrote earlier were refused by decompiler as invalid, but YMMV)
you need to provide export files for all the applet's imported packages, including:
Java Card API (the latest version always worked for me, but YMMV)
Global Platform API, SIM-toolkit related APIs, card vendor extensions or any other publicly available packages (if any of them are used)
other non-public packages (which might/will cause trouble -- I have never dealt with that so can't help)
to get list of imported package AIDs you can either check appropriate structures in the CAP file (I am not aware of any publicly available tool for this, sorry) or just try incrementally (normalizer gives error messages like "Cannot find export file for imported package " for missing export files)
export package for the .cap itself is not necessary
it will be probably more difficult to re-compile the applet from reverse-engineered sources than it is for desktop java (partly depends on the used decompiler capabilities)
if all you need is to check if someone did not introduce a backdoor into a binary .cap file then it will be much simpler to build a clean .cap file from trusted sources (ideally using the same compiler) and compare decompiler outputs for both clean and suspicious cap files
check legality of whatever-you-are-doing
Good luck!
For those who are trying to perform reverse engineering and getting below errors while running normalizer:
Cannot find export file for imported package a0:0:0:0:62:0:1
Please provide the correct export file
Java Card JDK api export files missing.
-p /Users/user/etc/jcard-sdk-3.0.5u3/api_export_files/
Cannot find export file for imported package a0:0:0:0:9:0:3:ff:ff:ff:ff:89:10:71:0:2
Please provide the correct export file
Sim Toolkit JDK export files are missing
-p /Users/user/etc/etc/43019-560/Annex_B_Export_Files
Here is the details for Sim Toolkit JDK installation
Here is the command line script for running normalizer on linux variants:
java -server -Djc.home=/Users/user/etc/jcard-sdk-3.0.5u3 -cp .:../lib/* com.sun.javacard.normalizer.Main normalize -i /Users/user/test.cap -p /Users/user/etc/jcard-sdk-3.0.5u3/api_export_files/ -p /Users/user/etc/43019-560/Annex_B_Export_Files/
Related
Opening an *.ifc file we can find "File_Schema" in the Header, for example:
HEADER;
...
FILE_SCHEMA (('IFC4'));
ENDSEC;
We are downloading IFC stream file and it would be nice to know the file schema version for it.
Is it somehow possible to get this information via DataManagement API?
This is already an old post, but just to mention that for those who download the file before any other operation: once downloaded, the following command can be used (on a Unix-like environment) to get exactly the IFC schema (e.g. "IFC2X3", "IFC4"):
grep "^FILE_SCHEMA" file.ifc | cut -d"'" -f2
Of course this command can be integrated in a program written in Node.js for example (using childProcess.exec), or any other programming language. Note that this is usually faster than streaming the file and searching in it, or even using a language-specific library to "grep" the file, especially for big IFC files.
I am using an F# JSON type provider to create a type from a reference JSON document. The reference document "ReferenceItem.json" is part of the F# library. In addition I have a unit test project which tests the library. I am struggling with making the reference document available for the test project without duplicating it.
No matter how I mark "ReferenceItem.json" in Visual Studio (Content, None, Copy to Output etc.) my test project fails to compile because the statement JsonProvider<"ReferenceItem.json"> expects "Reference.json" to be present in the project source folder at compilation time. Including it as a linked item from the library project doesn't help: it's not copied at compile time to the test source folder. So I need to make a duplicate copy of the file in the test project.
I noticed that in F# projects I can mark files as "DesignData" or "DesignDataWithDesignTimeCreatableTypes", but I wasn't able to figure out how I can use them.
This is a tricky problem - when F# compiler references the library, it will invoke the type provider and so the type provider needs to be able to access the sample.
The easiest solution is to just always copy the sample json file so that it is in the folder from where the application is starting. This is obviously sub-optimal, and so we have another way of handling this using resources.
See the "Using JSON provider in a library" section of the documentation. The idea is that you can embed the sample document as a resource in the library and specify the resource name as an additional parameter:
type WB = JsonProvider<"../data/WorldBank.json",
EmbeddedResource="MyLib, worldbank.json">
This will then load the resource when using the library (but it still needs the file name in the original compilation mode). This is still somewhat experimental, so please open an issue on GitHub if you cannot get it to work!
I'm writing a simple Erlang program that requests an URL and parses the response as JSON.
To do that, I need to use a Library called Jiffy. I downloaded and compiled it, and now i have a .beam file along with a .app file. My question is: How do I use it? How do I include this library in my program?. I cannot understand why I can't find an answer on the web for something that must be very crucial.
Erlang has an include syntax, but receives a .hrl file.
Thanks!
You don't need to include the file in your project. In Erlang, it is at run time that the code will try to find any function. So the module you are using must be in the search path of the VM which run your code at the point you need it, that's all.
For this you can add files to your path when you start erlang: erl -pa your/path/to/beam (it exists also -pz see erlang doc)
Note that it is also possible to modify the path from the application itself using code:add_path(Dir).
You should have a look to the OTP way to build applications in erlang documentation or Learn You Some Erlang, and also look at Rebar a tool that helps you to manage erlang application (for example starting with rebar or rebar wiki)
To add to Pascal's answer, yes Erlang will search for your files at runtime and you can add extra paths as command line arguments.
However, when you build a project of a scale that you are including other libraries, you should be building an Erlang application. This normally entails using rebar.
When using rebar, your app should have a deps/ directory. To include jiffy in your project, it is easiest to simply clone the repo into deps/jiffy. That is all that needs to be done for you to do something like jiffy:decode(Data) in your project.
Additionally, you can specify additional include files in your rebar.config file by adding extra lines {erl_opts, [{i, "./Some/path/to/file"}]}.. rebar will then look for file.so using that path.
I want to use BIRT to generate reports against data that comes from a JSON based REST API. How can I import this data?
The process for doing this is described at http://developer.actuate.com/community/forum/?app=blog&blogid=45&showentry=471, but it turns out that there are a few important steps missing. I'll fill in a few blanks here.
The original instructions describe creating a Scripted Data Source, with an "open" script that makes use of the com.actuate.json.JSONParser class. First, it is important to realise that this class is not part of BIRT, and needs to be manually added (along with any dependencies).
The download provided by the original instructions provides the com.actuate.json.JSONParser class, but leaves it up to you to source the dependencies. To make things easier I have reimplemented the JSONParser library in Maven, which will then download and package the dependencies for you. It also includes some bug fixes and enhancements like GZIP compression support. You can get the Maven project from https://github.com/mcasperson/birt-jsonparser, and to build the JSONParser library and package the dependencies, run the command
mvn clean package dependency:copy-dependencies
This will result in the birt-jsonparser-0.0.1-SNAPSHOT.jar file being created in the target directory, and all the dependencies copied into the target\dependency directory. Copy all of these JAR files into the {BIRT_INSTALL}/plugins/org.eclipse.birt.report.viewer_{BIRT_VIEWER_VERSION}/birt/scriptlib directory to allow the JSONParser class to be accessed from within your BIRT report.
If you want to debug your report, these JAR files will also have to be referenced in the Debug profile.
I understand that Javadoc is a documentation generator from Sun Microsystems for generating API documentation in HTML format from Java source code.
I infer that the documentation is stored onto an HTML file.
Is there a way I can access it?
If yes where is it stored?
The word Javadoc can refer to
special comments in Java source files (preceding a declaration, and of the form /** ... */)
a program which converts these comments (as well as the declarations themselves) to readable output
the output itself, usually in HTML form.
The Javadoc program is contained in Sun's (or now Oracle's) Java Development Kit (JDK).
If you have installed a JDK (which you should if you do Java development), you can call it on the command line, passing it the package names to document, or some source file names. You should also indicate the output directory, using the -d option.
I'm assuming the following directory (and package) structure in my example below:
current directory
source
de
dclj
paul
examples
HelloWorld.java [containing package de.dclj.paul.examples; and public class HelloWorld { ... }]
docs
Then you use the following command line:
javadoc -sourcpath source -d docs de.dclj.paul.examples
It will then create a the documentation in the docs directory, with an index.html which you can open in your web browser, and other files reachable from it.
For more details have a look at the documentation linked above. For an example output, have a look at the Java Standard API Javadoc.
If you are using an IDE, you likely have a generate Javadoc button there, and the IDE might even show the formatted output of documentation of single classes or methods on the fly.