I'm trying to change the card manager AID on a JavaCard 3.x smartcard by using a STORE DATA command. The current card manager AID is the factory default of A0 00 00 01 51 00 00 00. After authenticating with the card manager, the command I'm sending is:
=> 80 E2 80 00 0A 4F 08 A0 00 00 00 03 00 00 00
<= 6A 88
This command executes successfully on a JavaCard 2.2.x card - has this feature been deprecated on JC 3.x?
Looks like the JavaCard 3 needs the command data in DGI format for this to work:
=> 80 E2 80 00 0D 00 70 0A 4F 08 A0 00 00 00 03 00 00 00
<= 90 00
Related
When inserting an UICC in an iPhone SE2 and recording the APDU messages between the modem and the UICC I see a sequence opening a logical channel and trying to select an application. I could not find any reference to this application. What is it?
01 a4 04 0c 10 a0 00 00 00 09 02 03 ff ff ff ff 89 01 00 00 ff
The RID a0 00 00 00 09 is registered for the ETSI.
I wrote a basic helloworld.exe with C with the simple line printf("helloworld!\n");
Then I used UltraEdit to view the bytes of the EXE file and used also PE Explorer to see the header values. When it comes to Address of Entry Point, PE Explorer displays 0x004012c0.
Magic 010Bh PE32
Linker Version 1902h 2.25
Size of Code 00008000h
Size of Initialized Data 0000B000h
Size of Uninitialized Data 00000C00h
Address of Entry Point 004012C0h
Base of Code 00001000h
Base of Data 00009000h
Image Base 00400000h
But in UltraEdit I see 0x000012c0 after counting 16 bytes after magic 0x010B.
3F 02 00 00 E0 00 07 03 0B 01 02 19 00 80 00 00
00 B0 00 00 00 0C 00 00 C0 12 00 00 00 10 00 00
00 90 00 00 00 00 40 00 00 10 00 00 00 02 00 00
04 00 00 00 01 00 00 00 04 00 00 00 00 00 00 00
00 10 01 00 00 04 00 00 91 F6 00 00 03 00 00 00
00 00 20 00 00 10 00 00 00 00 10 00 00 10 00 00
00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00
00 E0 00 00 C0 06 00 00 00 00 00 00 00 00 00 00
Which one is correct?
simply read about IMAGE_OPTIONAL_HEADER structure
AddressOfEntryPoint
A pointer to the entry point function, relative to the image base
address. For executable files, this is the starting address. For
device drivers, this is the address of the initialization function.
The entry point function is optional for DLLs. When no entry point is
present, this member is zero.
so absolute address of EntryPoint is AddressOfEntryPoint ? ImageBase + AddressOfEntryPoint : 0
in your case AddressOfEntryPoint == 12c0 and ImageBase == 400000
as result absolute address of EntryPoint is 12c0+400000==4012c0
I'm working to get useful data from a VISA (such as PAN, expiry date...) credit card using a list of AIDs I got stuck.
I have been able to access to all the data manually. Using the next tutorial: http://www.openscdp.org/scripts/tutorial/emv/reademv.html
>>00 A4 04 00 07 A0 00 00 00 03 10 10 00
In ASCII:
<<o<EM>„<BEL> <0><0><0><ETX><DLE><DLE>¥<SO>P<EOT>VISA¿<FF><ENQ>ŸM<STX><VT><LF><0>
In Hexadecimal:
<<6F 19 84 07 A0 00 00 00 03 10 10 A5 0E 50 04 56 49 53 41 BF 0C 05 9F 4D 02 0B 0A 90 00
After that I used:
>>33 00 B2 01 0C 00 //sfi1, rec1
...
...
>>33 00 B2 10 FC 00 //sfi31, rec16
I continued with the tutorial and learned that the proper way to obtain the data was using GPO (Get Processing Options) command. And tried that next:
>>80 A8 00 00 0D 83 0B 00 00 00 00 00 00 00 00 00 00 00 00 // pdo = 83 0B 00 00 00 00 00 00 00 00 00 00 00 which suposse to be the correct one for VISA.
<< 69 85
So the condition of use is not satisfied.
>> 80 A8 00 00 02 83 00 00 //pdo= 83 00 that should work with every non visa card
<< 80 0E 3C 00 08 01 01 00 10 01 04 00 18 01 03 01 90 00
If this response is correct and it looks quite well for me as it starts by 80 and ends by 90 00, I am not able to identify AFL which I think that would make me possible to determine the PAN, expiry date... Can somebody help me?
The FCI that you received in response to the select command (00 A4 0400 07 A0000000031010 00) decodes to
6F 19 (File Control Information (FCI) Template)
84 07 (Dedicated File (DF) Name)
A0000000031010
A5 0E (File Control Information (FCI) Proprietary Template)
50 04 (Application Label)
56495341 ("VISA")
BF0C 05 (File Control Information (FCI) Issuer Discretionary Data)
9F4D 02 (Log Entry)
0B0A (SFI = 11; # of records = 10)
This FCI does not include any PDOL (processing options data list). Consequently, you need to assume a default value for the PDOL (which is an empty list for your card type). Consequently, the PDOL-related data field in the GET PROCESSING OPTIONS command must be empty:
83 00
Where 0x83 is the tag for PDOL-related data and 0x00 is a length of zero bytes.
Thus, the correct GPO command is (as you already found out):
80 A8 0000 02 8300 00
You got the response
800E3C00080101001001040018010301 9000
This decodes to
80 0E (Response Message Template Format 1)
3C00 (Application Interchange Profile)
08010100 10010400 18010301 (Application File Locator)
Consequently, the Application File Locator contains the following three entries:
08010100: SFI = 1, first record = 1, last record = 1, records involved in offline data authentication = 0
10010400: SFI = 2, first record = 1, last record = 4, records involved in offline data authentication = 0
18010301: SFI = 3, first record = 1, last record = 3, records involved in offline data authentication = 1
Consequently, you can read those record with the READ RECORD commands:
00 B2 010C 00
00 B2 0114 00
00 B2 0214 00
00 B2 0314 00
00 B2 0414 00
00 B2 011C 00
00 B2 021C 00
00 B2 031C 00
There are some threads for how to apply bluez as ibeacon or BLE peripheral.
But when I use ble scanner (a BLE central application on Android), that reveal the bluz peripheral as dual mode.
How should I do to disable the classic mode in bluez?
Since you are referring to that thread, you probably use hcitool to set the advertisement data and options.
You need to set change the Flag for BR/EDR support to 0. Thats Bit 2 of the Flags field (See Part A Supplement of the Bluetooth Core Spezification, p.12).
So the original 0x1A changes to 0x16:
Change
sudo hcitool -i hci0 cmd 0x08 0x0008 1e 02 01 1a 1a ff 4c 00 02 15 e2 c5 6d b5 df fb 48 d2 b0 60 d0 f5 a7 10 96 e0 00 00 00 00 c5 00 00 00 00 00 00 00 00 00 00 00 00 00
to
sudo hcitool -i hci0 cmd 0x08 0x0008 1e 02 01 16 1a ff 4c 00 02 15 e2 c5 6d b5 df fb 48 d2 b0 60 d0 f5 a7 10 96 e0 00 00 00 00 c5 00 00 00 00 00 00 00 00 00 00 00 00 00
Running btmon on another shell while executing the commands allows you to observe whats going on exactly.
I'm looking for an easy way to convert a simple binary file into a text-representation of its binary, where encoding doesn't matter. I know that the programmatic solution is straightforward, but I feel that there must be some arcane string of unix commands to accomplish this.
Am I off base? Is there a simpler solution than the programmatic?
base64 -e filename>xxx
on the other side
base64 -d xxx>filename
Use od. For example:
$ od -t x1 -An /bin/ls | head
7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
02 00 3e 00 01 00 00 00 e0 26 40 00 00 00 00 00
40 00 00 00 00 00 00 00 30 b6 01 00 00 00 00 00
00 00 00 00 40 00 38 00 09 00 40 00 1d 00 1c 00
06 00 00 00 05 00 00 00 40 00 00 00 00 00 00 00
40 00 40 00 00 00 00 00 40 00 40 00 00 00 00 00
f8 01 00 00 00 00 00 00 f8 01 00 00 00 00 00 00
08 00 00 00 00 00 00 00 03 00 00 00 04 00 00 00
38 02 00 00 00 00 00 00 38 02 40 00 00 00 00 00
38 02 40 00 00 00 00 00 1c 00 00 00 00 00 00 00
for example, to display a binary file as a sequence of hex codes:
od -t x1 file|cut -c8-
uuencode and uudecode were made for transferring binary content as ASCII characters. See the wikipedia entry.
max#upsight:~$ openssl base64 < /dev/urandom | head -10
qnISxigXTjgON+tkSDtRJ6fRNczsejY2bEC5D1W8fscy+6mopiGfVLvZ/bu99SrT
qdTRaeRXO8fgEejXsbTy4XP9MmCbAsBCSEvDpq5bfR/Sd7EjJLUxcRwzEMlhIrYT
m6J+20aR9M4g7pbT+hjjBE/gsHKxFfZQFgxT/tm1pEg6zMvQywjsrc7d+PSJQOHw
vzYXfWkyLO1nJm9g+Pw3rBI/UuV0+lmrIflhlj5CDWuaxDJUXJiWdsD6cGKLclfz
Mlh17mHwteqMLLSrTZ0QA0ygxISqiCf2sDtPgUToM7ZT2EbaNck5auxbhU+7OcxI
vBZRKozRZtfsZA0IUzMlIQmFanBdjOeGepQjgCDruq5hqEbNc1A+HhXqTtAr8Aic
4iNf36xZifDvASYy27hTVrlI/5kTeRZURqquaxHqum15VD5IC3J/sH+AwPpN1/qi
0YM8xt+LliVje7Oo7QiTona+VMjA//a715/0J8yeryLxTLSnT8JsXUpR0CiOgAcH
tQk9nzHCfMmFzb02nrhFJ0MjLCFgNJOiI1vT0AhNnMh449dcIkDDwyMpkRV4KZ1l
CSL+K4vXhMz3LhPKSihKbYLY6aJSnlPe/GiIOfl1g1VlbtoxJ7ZclpcOp4KWSKHV
...and so on
If the reason you're doing it is to see strings inside the binary data then there's a command called "strings" that will print all the strings in a file for you.
you can also use hexdump. Look at the man page for more options
$ hexdump binaryfile
Yes, you are off-base, this is nontrivial in the general case. Some commercial solutions exist, one we use is Autonomy Keyview.
I am assuming you mean including (e.g.) MSOffice and PDFs.