I want to print the serial number which is store in the EEPROM of my Beaglebone Black hardware with U-Boot. I finally came up with this command
i2c md 0x50 10.2 C
0010: 32 30 34 33 53 42 42 30 31 36 34 34 2043SBB01644
However the output does not suit me.
I only want to retrieve the serial number 2043SBB01644 is there a way? (with i2c command or other command)
I have also noticed that there is [special environment variable] such as serial# which print the serial number.
How to configure this serial# environment variable on a custom board for instance?
I'm trying to read the LoginItems preferences file to change a Network Volume a user has in their login items. Which mounts when they log in.
I can read the login items using NSUserDefaults and getting it as an NSDictionary. The problem is that the volume mount details are stored as binary data. The data appears to be an Alias file format except it's missing the header: 62 6F 6F 6B 00 00 00 00 6D 61 72 6B 00 00 00 00
I've tried using the current NSURL resourceValuesForKeys:fromBookmarkData: but it did not return the remote share. I realised that the machine they were created on is a 10.6 machine and these calls were only made available in 10.11.
So I tried using the old deprecated Core Carbon libraries PTRToHand and FSCopyAliasInfo to get information out of this file but all it says is that it is an Alias pointing to /Volumes/ShareMount and makes no mention of which server it is trying to connect to.
The binary data does show the string smb mount for the server.
0000000: 0000 0000 00a0 0003 0001 0000 0000 0000 ................
0000010: 0000 4244 6375 0001 ffff ffff ffff ffff ..BDcu..........
0000020: 0000 0000 0000 0000 0000 1201 fffe 0000 ................
0000030: 0000 0000 0000 ffff ffff 000e 000a 0004 ................
0000040: 006d 0061 0072 006b 000f 000a 0004 006d .m.a.r.k.......m
0000050: 0061 0072 006b 0012 0000 0013 000d 2f56 .a.r.k......../V
0000060: 6f6c 756d 6573 2f6d 6172 6b00 0009 002b olumes/mark....+
0000070: 002b 6369 6673 0000 0100 0000 736d 623a .+cifs......smb:
0000080: 2f2f 6d61 726b 4031 302e 3130 312e 3232 //mark#10.101.22
0000090: 322e 3138 352f 6d61 726b 0000 ffff 0000 2.185/mark......
I've compared this data with the wikipedia article on Macos Aliases and a python module that reads aliases both of them spcify the version number should be 2, however the byte in this position (byte 6) is 3, after this byte the binary compatibility between the two no longer match.
Does anyone know about this Version 3 Alias format?
I've found two web pages that seem to document the exact same problem I'm having;
One only available via wayback: Reversing Mac Alias v3 Data Objects He has only parsed 1 file here and an SMB mount one is slightly different.
Apple's Bookmark Data Exposed Pretty much describes the steps that I have followed myself to end up asking this question.
Thanks
I have one communication between terminal and chip on APDU, and I need to decode that communication.
It's something like this:
Terminal: 00 B6 02 00 06 00
Chip: 49 55 7B 2C 1F 30 57 35 63 7D 24 7B 60 21
Terminal:00 B5 03 0B 04 02 00
Chip:45 43 3C 3B 4A 31 51 35 53 4B 34 2C 30 21
From what I know, terminal is sending commands to smart card chip, and smart card chip is giving response.
So, I need to know what is their communication about. It has to do with EMV standards and APDU.
How can I decode it? What are the steps and rules?
The communication between chip and terminal is using APDUs. Command APDU and response APDU. Below will give you idea about the struct of messages. For detailed reading download the documents(those are called books in emv world) from here. Infact the below are copy paste from Book 3. Have a detailed look and come back if you need more information.
All data are in hex.
The command APDU has the below format.
[Class] [Instruction] [Parameter 1] [Parameter 2] [Length of command
Data] [Command]
[Length of maximum expected data response]
Response APDU has the format
[Data] [2 bytes status of APDU execution( See coding of Sw1 Sw2 below]
Coding of the Class Byte
The most significant nibble of the class byte indicates the type of command. 0' Inter-industry command, '8' Proprietary to this specification.
Instruction bytes define the funtions you wish to do. Coding of the
Instruction Byte is
I have a certain file structure like this
>ID1
data about ID1....
................
................
>ID2
data about ID2....
................
................
................
................
>ID3
data about ID3....
................
................
...............
>ID1
data about ID1....
................
>ID5
data about ID5....
................
................
I want to remove these duplicate blocks of IDs. For eg in the above case it is ID1. It should be noted that only the ID part is same, the data after that could be different. However, I want to keep the first one and remove all the other ones. How can I do this in shell scripting manner?
In awk
awk '/^>/{p=!($0 in a);a[$0]}p' file1
I am using LFTP to transfer files from a server, which unfortunately does not recognize the PORT command. I do not have control over the server (do not know in detail what server is) and I have to use the active mode.
This is the command line as:
lftp -e 'debug 10;set ftp:passive-mode off; set ftp:auto-passive-mode no; ls; bye;' -u user,password ftp://ftp.site.com
This is the debug output:
<--- 200 Using default language en_US
---> OPTS UTF8 ON
<--- 200 UTF8 set to on
---> OPTS MLST modify;perm;size;type;UNIX.group;UNIX.mode;UNIX.owner;
<--- 200 OPTS MLST modify;perm;size;type;UNIX.group;UNIX.mode;UNIX.owner;
---> USER xxxxx
<--- 331 Password required for xxxxx
---> PASS xxxxxx
<--- 230 User xxxxx logged in
---> PBSZ 0
<--- 200 PBSZ 0 successful
---> PROT P
<--- 200 Protection set to Private
---> PORT 172,16,133,11,146,168
<--- 500 Illegal PORT command
---> LIST
---> ABOR
---- Closing aborted data socket
---- Chiusura del socket di controllo
It seems that LFTP renounces to connect to data socket because the remote server does not support the PORT command. Is there a way to convince LFTP can still connect to port 20? By FTP manual obviously no problem.
The issue, I think, is not that the FTP server doesn't support the PORT command (it does), but rather, it doesn't like the IP address/port that your FTP client is sending in the PORT command.
PORT 172,16,133,11,146,168
...tells the server to connect to address 172.16.133.11, port 37544*. The interesting part here is the IP address: it's an RFC 1918 address (i.e. it's a private network address). That, in turn, suggests that your FTP client is in a LAN somewhere, and is connecting to an FTP server using a public IP address.
That remote FTP server cannot connect to a private network address; by definition, RFC 1918 address are not publicly routable.
Thus it very well could be that the FTP server is trying to make a connection to the address/port given in your PORT command, fails, thus that is why the FTP server fails the command, saying:
500 Illegal PORT command
To make a PORT command work with that FTP server, you would need to discover the public IP address that that server can connect to, to reach your client machine. Let's say that this address is 1.2.3.4. Then you would need to tell lftp to use that address in its PORT command, using the ftp:port-ipv4 option.
Chances are, though, that public IP address is the address of a NAT/router/firewall, and that that NAT/router/firewall will not allow connections, from the outside world to a high numbered port (e.g. 37544), to be routed to a machine within the LAN. This is one of the issues with active FTP data transfers, i.e. FTP data transfers which use the PORT (or EPRT) commands: they are not considered "firewall-friendly".
Hope this helps!
* - why 146,168 translates to port 37544?
According to FTP's RFC959 those parameters are:
(...) 16-bit TCP port address. This address information is broken into
8-bit fields and the value of each field is transmitted as a decimal
number (in character string representation).
146 dec = 10010010 bin = A
168 dec = 10101000 bin = B
A B
10010010 10101000 bin = 37544 dec