Solana noob here.
I'm trying to understand PDAs and ATAs better and one thing I first want to understand is the difference between a System Account and A Token Account.
What types of data does each type of Account hold?
Is one derived from another?
Can a program have both types of accounts associated with it?
context: https://spl.solana.com/associated-token-account
A system account is one that was created by the Solana system program. It is typical that these are often considered a wallet conceptually.
A Token account is an account that is "owned" by the Token program. This enables the Token program to update the information in that account, whereas if other programs try to modify the data execution will fail.
What data, if any, is in one of these program owned accounts it defined by the program that owns it.
Other notes:
Programs themselves are accounts that are owned by the BPFLoader program
You can discover what is what from the command line with:
solana account ...
(see solana account --help for more options)
For example, on a Program account in devnet:
Public Key: SampGgdt3wioaoMZhC6LTSbg4pnuvQnSfJpDYeuXQBv
Balance: 0.00114144 SOL
Owner: BPFLoaderUpgradeab1e11111111111111111111111
Executable: true
Rent Epoch: 213
Length: 36 (0x24) bytes
0000: 02 00 00 00 a4 6d da 51 48 e4 d4 48 b1 19 5e 80 .....m.QH..H..^.
0010: a7 ff 85 8a c9 06 49 f3 63 d8 5f 7f 8b 32 6a 4d ......I.c._..2jM
0020: 9a a6 00 d6 ....
The owner is the BPF program loader
Whereas for my default wallet for devnet:
solana account .config/solana/id.json
Public Key: 5VhBw95K4NYEgQDgEA7335znvVgwUifMPVy6cqFVq5rZ
Balance: 29.355201517 SOL
Owner: 11111111111111111111111111111111
Executable: false
Rent Epoch: 270
The owner is the system program
Related
I'm developing an application that require a client authentication to a server using a smart card.
As a guide, i'm tracing a normal web authentication with a browser and i've seen that the SSL/TLS packet containing the "Certificate Verify" structure is created using the signing session of the card.
Analizing the CCID-APDU packet sent to the card reader i've seen this dump:
6f 05 01 00 00 00 41 00 01 00 00 2a 80 86 00 01 01 00 00 01 ff ff ........
The answer of this command is actually the content sent to the 'Certificate Verify' SSL/TLS structure.
The strange thing is that the APDU command sent is
00 2a 80 86 00
Looking at the APDU documentation this is a "PSO: DECIPHER" command but shouldn't it be a signature command? (00 2A 9E 9A xx)
Would anyone be able to clarify this behavior?
Tnx
PSO DECIPHER shares with signature generation that it applies the private key. It is significantly simpler, since it is restricted to one data block, i. e. the command data field of the APDU. PSO CDS for Compute Digital Signature has lots of additional complications like chaining (data split to several commands), hashing (with various algorithms to use), padding (with various padding schemes) to ensure correct data length etc.
So it seems, that your analyzed solution is optimized for the specific scenario required, and as many optimizations clarity is somewhat reduced as side effect.
I am trying to use UPDATE BINARY command using APDU command for modify IMSI code, but The response is 98 04.
A0 A4 00 00 02 3F 00 -> SELECT MF
A0 A4 00 00 02 7F 20 -> Select DF_GSM
A0 A4 00 00 02 6F 07 ->Select EF_IMSI
A0 D6 00 00 09 [08 79 03 30 60 00 61 33 23] -> UPDATE IMSI FOR RANDOM NUMBER
when doing this I get the following response 98 04 and it is not modified.
According to the documentation The response 98 04 can mean the following:
access condition not fulfilled
unsuccessful CHV verification, at least one attempt left
unsuccessful UNBLOCK CHV verification, at least one attempt left
authentication failed
How I can change IMSI?
Thank you.
From 3GPP-TS-11.011 - You have to verify ADM first in order to update EF_IMSI. See link. Typically only the network has the "password". Otherwise anyone with the password can impersonate the identity of someone else's SIM card.
EF_IMSI Update Conditions
In order to update IMSI file on SIM , UPDATE command header and data part should be generated according GSM 03.48 specification. For the SIM file structure 31.102 is the specification.
Command header parameters should be obtained from SIM vendor. Minimum security Level parameter will definitely enforce encryption and cryptographic cHecksum usage for securing the command data, because real SIM card card manager expects MSL parameters something like that 0x25, so KiC and KiD key values are required.
You need first to Verify CHV (PIN1 for IMSI).
Use the following APDU and replace your PIN1 value.
-> A0 20 00 01 08 31 32 33 34 FF FF FF FF
<- 90 00
Caution: If you use wrong PIN value, it will be disabled after 3 times.
I am trying to generate AC manually, I have a tool to generate AC but I want to generate it by my own to understand the algorithm for the same.
My calculation is fine for Discover card but it is failing for MasterCard. As per my understanding, data used to generate AC is depend on Tag 8C - CDOL1 which we provide to card with Gen AC command + AIP + ATC.
AIP and ATC - accessed internally by ICC.
Data used to generate AC is:-
data part of Gen AC command + value of tag 82 + value of tag 9f36 + 80 + optional 00 to make it multiple of 8.
this is my logic ,it might be I am using wrong data to calculate A.C that's why getting different result from my test tool.
Terminal Supplied Data
Amount, Authorised - 000000000201
Amount, Other - 000000000000
Terminal Country Code - 0826 - United Kingdom
Terminal Verification Results - 00 00 00 00 00
Transaction Currency Code - 0826 - Pound Sterling
Transaction Date - 15 04 28
Transaction Type - 00 - Goods and Services
Unpredictable Number - 30 90 1B 6A
Terminal Type - 23 - Attended, offline only. Operated by Merchant
Data Authentication Code - 00 00
ICC Dynamic Number - 1E AB C1 26 F8 54 99 76
CVM Results - 00 00 00
Gen AC Using CDOL1
80 AE 40 00 2B 0000000002010000000000000826000000000008261504280030901B6A2300001EABC126F8549976000000
this command is returning 9F26.
data i used for calcatation is:-
0000000002010000000000000826000000000008261504280030901B6A2300001EABC126F85499760000003800000180 [ data is multiple of 8]
Where 3800 is AIP 0001 is ATC and 80 for Padding [ Padding method 2 EMV] This is my logic, Is any body tell me where I should focus more to generate same AC as my tool generated.
MasterCard Application Cryptogram (AC) generation is more complicated than other card schemes.
Card can use different ICC Session Key Derivation (SKD) methods:
MasterCard Proprietary SKD, where involved Application Transaction Counter (ATC) and Unpredictable Number (UN);
EMV2000 Method, where involved only ATC - see EMV 4.0, Book 2;
EMV Common Session Key (CSK) Method, where involved only ATC - see EMV 4.2, Book 2;
Data Objects (DO) can be with different sets of additional or modified values:
Card Verification Results (CVR) can be 6 or 4 bytes.
The offline counters from Issuer Application Data (IAD) can be included.
Last online ATC value can be included.
The used method and data variant can be detected by Cryptogram Version Number (CVN) and Application Control bits. CVN is sub-field of IAD tag 0x9F10 .
The detailed information are proprietary and available for the MasterCard members.
For deep learning about it take a look into "M/Chip Card Application Cryptographic Algorithms" and M/Chip Card Application references.
When monitoring DDE messages with DDESpy, I can capture what I am looking for, however DDESpy truncates it:
[1ff8:212781728] CB(Execute, fmt=0x0("?"), 39002100, c001("WWW_OpenURL") 0(""), 3d003b00, 0, 0)=3e004300
Input data=
22 00 68 00 74 00 74 00 70 00 3a 00 2f 00 2f 00 ".h.t.t.p.:././. 6e 00 65 00 77 00 73 00 2e 00 79 00 63 00 6f 00 n.e.w.s...y.c.o.
...
Now, this is truly annoying, because what I am really after are the parameters at the end of the input data (after the ....)
How could I get that data?
The location of the DDEML API is important to DDE monitoring
applications. DDEspy from Microsoft and our Dynamic Data Studio use
the DDEML APPCLASS_MONITOR facility. Message hooks can read the memory
handles of the data attached to a WM_DDE_xxx message, but for 32-bit
applications the handles have no meaning in other process spaces. The
32-bit version of the DDEML API extracts and passes some data to a
monitoring application, but only the first 28 bytes. There is no way
to obtain more than this.
Apparently this is why I am seeing only the first 28 bytes. I guess I am out of luck.
Source: http://www.angelfire.com/biz/rhaminisys/ddeinfo.html
I've been playing around with capturing the input from my keyboard device:
/dev/input/by-path/platform-i8042-serio-0-event-kbd
for me, and I was wondering if there was any specification for what it returns, using
od -tx1 /dev/input/by-path/platform-i8042-serio-0-event-kbd
to listen. I'm curious mostly due to the behavior of certain keys; the meta, arrow keys, numpad forward slash.
0520300 ac 9d 86 4c 6b 0f 04 00 04 00 04 00 (db) 00 00 00
0520320 ac 9d 86 4c 8c 0f 04 00 01 00 (7d) 00 00 00 00 00
0520340 ac 9d 86 4c 95 0f 04 00 00 00 00 00 00 00 00 00
Every other key I've looked at so far has the two bytes in parentheses as matching values, is there any reason these are special?
/dev/input/by-path/platform-i8042-serio-0-event-kbd is just a symlink to /dev/input/eventX event device file. Data can be read from event device files as
struct input_event {
struct timeval time;
__u16 type;
__u16 code;
__s32 value;
};
defined in /usr/include/linux/input.h.
Possible values of type are prefixed with EV_.
Possible values of code depend on type. They are prefixed with KEY_ or BTN_ or REL_ or so on.
Possible values of value depend on both type and code. For example for key-press events value equals 1 and for key-release events 0.
You can examine event data with:
evtest /dev/input/eventX
where X is the event device number of your keyboard (or any other event device). One key press or release normally emits three events (EV_MSC, EV_KEY and EV_SYN).
Some keys have unusual scan codes...
From: http://www.beyondlogic.org/keyboard/keybrd.htm (with edits) :
Now there's 101 keys and 8 bits make 256 different combinations, thus you only need to send one byte per key, right?
Nope. Unfortunately, a handful of the keys found on your keyboard are extended keys, and thus require two scan codes. These keys are preceded by a E0 (hex). But it doesn't stop at two scan codes either. How about E1,14,77,E1,F0,14,F0,77! Now that can't be a valid scan code? Wrong again. It's happens to be sent when you press the Pause/Break key. Don't ask me why they have to make it so long! Maybe they were having a bad day or something?