We Keep Coding

Sending APDU commands to Write Data to a smartCard Reader using java smartcardio functions

I am trying to write data to contactless card in HID Omnikey 5122 device using java smartcardIO functions.
The Data that I need to insert to the card is {00 01 02 03}.
APDU command I am trying to send through channel.transmit function is {FF D6 00 04 04 00 01 02 03}
where:
FF is CLS
D6 is INS
00 is P1
04 is P2
04 is Number of bytes to update
00 01 02 03 is the data that I need to insert.
I am not able to correctly build the APDU command through below function. Can some one help me with this. I am using functions available in java smartcardio library.
ResponseAPDU respApdu = channel.transmit(
new CommandAPDU(0xFF,0xD6,0x00,0x04,0x04,
new byte[] {(byte) 0x00,
(byte) 0x01,
(byte)0x02,
(byte)0x03}));
I am getting syntax error like constructor command is having invalid arguments.

It looks like you are trying to send an UPDATE BINARY APDU to update the transparent file at offset 4 (this is what you provide in P1-P2). You have to use a CLA byte of 00h (if that file operation doesn't require the use of Secure Messaging).
Since P1-P2 doesn't specify a short file identifier in your case, your currently selected file has
to be compatible with the READ/UPDATE BINARY commands
to have file size >=9 byres.

How to decode APDU GPO response wrapped in tag 77

I followed this tutorial and I have recieved the following response from the GPO command:
7716820239009410100101011002020018010200200102009000
When I try parsing the response:
response tag = 77
AIP = ??
AFL = ??
Could some one help me with a method of getting the Application Interchange Profile (AIP) and Application File Locator (AFL). The tutorial explains only that with tag 80, and the reference book EMV_v4.3_Book_3_Application_Specification says that tag 77 is out of their solution scope.

The response that you got in return to the GET PROCESSING OPTIONS command is in BER-TLV format and decodes like this:
77 16 [tag = Response Message Template Format 2, length = 22 bytes]
82 02 [tag = Application Interchange Profile, length = 2 bytes]
3900 [value = AIP]
94 10 [tag = Application File Locator (AFL), length = 16 bytes]
10010101100202001801020020010200 [value = AFL]
9000 [status word = no error]
For decoding BER-TLV by hand, you could use am online parser like https://www.emvlab.org/tlvutils/. For integration into your own application, you might want to have a look at Is there a Java parser for BER-TLV?.

Java String internal representation

I understand that the internal representation of Java for String is UTF-16. What is java string representation?
Also, I know that in a UTF-16 String, each 'character' is encoded with one or two 16-bit code units.
However, when I debug the following java code
String hello = "Hello";
the variable hello is an array of 5 bytes 0x48, 0x101, 0x108, 0x108, 0x111
which is ASCII for "Hello".
How can this be?

I took a gcore dump of a mini java process with this code:
class Hi {
public static void main(String args[]) {
String hello = "Hello";
try {
Thread.sleep(60_000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
And did a gcore memory dump on Ubuntu. (usign jps to get the pid and passed that to gcore)
If found this: 48 65 6C 6C 6F in the dump using a Hexeditor, so it is somewhere in the memory as ASCII.
But also 48 00 65 00 6C 00 6C which is part of the UTF-16 representation of the String

String internal representation is not specified, it's the implementation detail, so you cannot rely on it. It's very likely that in JDK-9 it will be changed to use double encoding (Latin-1 for strings which can be encoded in Latin-1, UTF-16 for other strings). See JEP-254 for details. This feature is already integrated in OpenJDK master codebase, so if you are using Java-9 early access builds, you will have actually 5 bytes.

Write hex numbers stored as strings to hex file directly in Java?

I'm writing a small assembler in Java that converts ARM assembly code to hex file that will be executed by a virtual ARM CPU on FPGA.
For example
Sub R0, r15, R15
Add R2, R0, #5
aDD R3, R0, #12
SUB R7, r3, #9
will be translated to machine(hex) code as
E04F000F
E2802005
E280300C
E2437009
which are stored as strings line by line in a string array output in my code.
So how can I write the machine code to hex file which is exactly what it literally is? Instead of being encoded as text.
So when I open the output file with tools like Hexeditor it will show the encoding exactly as (without newline sign of course...)
E0 4F 00 0F E2 80 20 05 E2 80 30 0C E2 43 70 09
Currently I tried:
OutputStream os = new FileOutputStream("hexcode.hex");
for (String s : output) {
int value = Integer.decode(s);
os.write(value);
}
os.close();
but it gives me errors
Exception in thread "main" java.lang.NumberFormatException: For input string:"E04F000F"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:580)
at java.lang.Integer.valueOf(Integer.java:740)
at java.lang.Integer.decode(Integer.java:1197)
at assembler.Assembler.main(Assembler.java:220)
Any help? Million thanks!

use Integer.parseInt(s, 16) instead of Integer.decode(string)
"16" tells it it is a hex-string

SMB JCIFS file writing issue

I want to write a password protected file at remote location in JAVA. So I am using SMB api(JCIFS).
However I am seeing an inconsistency in the data written at destination file.
E.g.
If my intension is to write the data as,
AB
CD
EF
GH
When I write the data in file,
The api misses some characters,
Some times it writes,
AB
CDE //EF not on next line & 'E' missed by api.
GH
some times it writes,
AB
CD
EFH
I am using SMBFileOutputStream to write a line by line in file.
smbOutputStream.write(myString.getByte);