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.
Related
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
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've got a laptop (MSI GT72S) which features a manual GPU switch button. It can help me switch between the Nvidia GPU and the Intel one so that the disabled one will be hidden to the OS.
However, this function needs a driver called SCM which only supports Windows. When I press the button under Windows, there will be a pop-up window that asks me to reboot the machine so that it can switch to another GPU.
This is really a PIA to me as I use Linux far more often and every time I need to switch the GPU, I have to reboot into Windows and then reboot again. So I'd like to archive this function under Linux.
It seems that this is implemented by editing a block of the SMBIOS (not sure). When the Intel GPU is enabled, this block will be:
Handle 0x0052, DMI type 221, 96 bytes
OEM-specific Type
Header and Data:
DD 60 52 00 0D 01 00 00 00 00 00 00 02 00 FF FF
FF FF FF 03 04 FF FF FF FF FF 05 06 FF FF FF FF
FF 07 08 FF FF FF FF FF 09 00 00 00 00 00 00 0A
00 FF FF FF FF FF 0B 00 FF FF 00 00 00 0C 00 00
09 00 35 10 0D 00 FF FF FF FF FF 0E 00 FF FF FF
FF FF 0F 00 FF FF FF FF FF 10 11 01 02 02 03 00
Strings:
Lan Phy Version
Sensor Firmware Version
Debug Mode Status
Enabled
Performance Mode Status
Disabled
Debug Use USB(Disabled:Serial)
Disabled
ICC Overclocking Version
UNDI Version
EC FW Version
GOP Version
BIOS Guard Version
Base EC FW Version
EC-EC Protocol Version
Royal Park Version
BP1.2.2.0_RP03
...and when the Nvidia GPU is enabled,
Handle 0x0052, DMI type 221, 96 bytes
OEM-specific Type
Header and Data:
DD 60 52 00 0D 01 00 00 00 00 00 00 02 00 FF FF
FF FF FF 03 04 FF FF FF FF FF 05 06 FF FF FF FF
FF 07 08 FF FF FF FF FF 09 00 00 00 00 00 00 0A
00 FF FF FF FF FF 0B 00 FF FF 00 00 00 0C 00 FF
FF FF FF FF 0D 00 FF FF FF FF FF 0E 00 FF FF FF
FF FF 0F 00 FF FF FF FF FF 10 11 01 02 02 03 00
But I haven't touched such stuff before and I don't even know where to start. I have Googled it but few material was found. So I strongly need some suggestions now. Any help would be highly appreciated, thanks!
Looks like this is an OEM-defined structure (type 221) that reports status and version info. This information is built by the BIOS during POST, and posted to memory for reading by OS-based management agents (like dmidecode in Linux). Changing that information will not change the underlying configuration.
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
I have a very limited linux w/ few basic linux commands.
I need to replace a few chars in a hex / binary file:
INPUT:
# hexdump -C block.bin
00000000 11 11 50 04 42 00 00 00 58 00 00 00 3c 0e e2 d4 |..P.B...X...<...|
00000010 50 0b 00 00 00 80 00 00 00 00 00 00 00 00 d0 d7 |P...............|
00000020 1f 09 00 00 00 00 02 00 00 00 00 04 ff ff ff ff |................|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040 28 31 98 5b d3 0e 05 00 00 00 00 00 00 00 00 00 |(1.[............|
00000050 00 00 00 00 00 00 00 00 64 00 00 00 00 00 10 00 |........d.......|
00000060 00 ff ff ff ff 00 00 00 00 03 01 0d 03 01 0d 01 |................|
00000070 00 00 00 00 0c 00 01 02 00 00 00 00 00 ff ff ff |................|
00000080 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00000180 00 00 20 00 00 00 ff ff ff ff 01 00 00 0c 00 00 |.. .............|
00000190 04 00 00 00 02 00 00 04 00 00 00 00 00 00 ff ff |................|
000001a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
I need to change the following:
00000060 00 ff ff ff ff 00 00 00 00 03 01 0d 03 01 0d 01 |................|
00000070 00 00 00 00 0c 00 01 02 00 00 00 00 00 ff ff ff |................|
to (and rewrite back to the same file):
00000060 00 ff ff ff ff 00 00 00 00 03 01 0d 03 01 0d 02 |................|
00000070 01 00 00 00 0c 00 01 02 00 00 00 00 00 ff ff ff |................|
Like I've said, I have a handful of commands: hexdump, od, vi, nano, awk, sed, python.
Looking through the internet, many solutions require 3rd party installs or the use of 'xxd'. Both I cannot use.
Any suggestions?
Thanks!
I don't think trying this with sed or awk is a sane idea, so we're stuck with python, which is certainly powerful enough for this task. I'm thinking along these lines:
#!/usr/bin/python
# open file in binary mode for reading and writing
f = open("block.bin", "r+b")
# seek to position and read two bytes
f.seek(0x6f)
data = f.read(2)
# seek to position again
f.seek(0x6f)
# and write the transformed characters back
for d in data:
f.write(chr(ord(d) + 1))
f.close()