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?
Related
I have been working on some device that allowed login via telnet and I extracted some data from devices and made some reports, without any problems. recently, I had to switch to SSH while rest of the script is all the same, only login procedure has been changed from telnet to SSH. after switching to SSH, I am facing some problem with the data extracted that there are some invalid characters in some of the lines, below is an example: as can be seen, there is an invalid character after PON7 in the line:
OLT:LT6.PON7.ONT1,ALARM,Date time,
problem is that this invalid character is not even visible in the bash/csv file, but it was discovered when I copied the line in notepad++ or while posting it here.
now I have two problems:
1st: if someone knows what is causing these invalid characters while switching between telnet/ssh.
2nd: how to deal with this invalid character in BASH as it is not even visible in BASH, but this report is being used somewhere and these invalid characters are causing problems.
Edit:
Pasting the text into a text-to-hex converter produces this:
4f 4c 54 3a 4c 54 36 2e 50 4f 4e 37 11 2e 4f 4e 54 31 2c 41 4c 41 52 4d 2c 44 61 74 65 20 74 69 6d 65 2c
It looks like there's a DC1 character (hex 11) between the "7" and the ".".
Unfortunately, this edit also has the side effect of removing the character from the sample text.
Passing your text through a text to hexadecimal converter shows that the invisible character is an ASCII DC1 character (hex 11, octal 021). This character is also known as Ctrl-Q or XON. It's sometimes used in flow control.
In a bash script, you could filter it out using the tr program:
echo $badtext | tr -d '\021'
SSH doesn't inherently insert DC1 characters into text streams. If you're getting a DC1 character in the output from a device, presumably the device sent that character.
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
How to automate task in OllyDBG? I want to create a script.
I bp on a certain address and go to its stack arguments. There are four stack arguments. I use the address of the 2nd argument and the size from the 4th argument and dump the HEX data into a log file.
For example :
I set a breakpoint at 512A12 and I see the following in stack:
00192003 005DB123 RETURN to program.005DB123 from program.00512A12
00192011 0018F058 - 1st argument
00192028 03F48D78 - 2nd argument
00192032 03F48D78 - 3rd argument
00192036 00000500 - 4th argument
So I dump the data from address starting at 00192028 03F48D78 - 2nd argument where 03F48D78 is the address to start the dump from.
And I use the size from the 4th argument 00192036 00000500 - 4th argument where 500 is the size of the data to be dumped.
The data is saved in a log file. It is a hex data from the dump section in OllyDBG.
Now I want to loop this function and automate it. How can this automation be done in Ollyscript or something else?
Afaik none of existing plugins offer windbg's .writemem functionality
uploaded below is an ollydbg plugin enhanced from anonymouse (openrce blog)
modified cmdline plugin with an added command .writemem
Download and put the dll in ollydbg 1.10 plugin path.
possible crash path fixed (FindModule -> Mod-name can be null if FindModule return null in such cases added "unknown_module" string as modulename for sprintf_s)
http://wikisend.com/download/750442/cmdline.dll
This plugin is an enhanced version of modified cmdline plugin for ollydbg 1.10 by anonymouse (openrce blog) and contains one extra command .writemem
enhancements being original source altered considerably to make it compile with visual studio 2010 express (old commands not tested)
one extra command .writemem added (similar to windbg's .writemem)
usage as follows alt+f1 or plugin -> cmdline plugin .
in the dialog box type
writemem [esp+0x4] dword [esp+0x10] c:\dumps
or may be
writemem 0x403085 0x45 f:\foo\blah
first command will dump 0xxxx bytes pointed by [esp+0x10] from address pointed by [esp+0x4] to the preexisting folder c:\dumps
second command will dump 0x45 bytes from 0x402085 to the specified folder
to automate use this command with conditional log breakpoint pass commands to plugin when paused functionality (shift+f4)
in the edit box enter
.writemem <address> <size> <folder path>
.run
when ever the breakpoint is hit the memory contents will be dumped
another snapshot to explain the words better below
This tutorial might help:
http://x9090.blogspot.com/2009/07/ollyscript-tutorial-unpack-upx.html
Also, you can read some scripts carefully to learn more about Olly scripting.
The actual function I need in the end to complete my task is as following.
Its an encryption / Decyption function
0x1 PUSH EBP - the encrypted data is loaded.
0x5 RETN - the data is decrypted
So the encrypted/decrypted data is loaded in the stack values as I earlier explained.
1 - When bp hits 0x1 PUSH EBP
2 - We goto stack values
3 - We follow the 2nd argument as start address for the chunk of encrypted data and the 4th argument for the size of the data.
4- We dump using wrtiemem from cmdline mod
Also we follow the same for decrypted data
1 - When bp hits 0x5 RETN
2 - We goto stack values
3 - We follow the 2nd argument as start address for the chunk of decrypted data and the 4th argument for the size of the data.
4- We dump using wrtiemem from cmdline mod.
I was wondering if the data could be saved in one text file called encdec.txt
Encrypted HEX Values
Decrypted HEX Values.
For exammple:
ENC - 88 F4 62 71 3D 25 CD 7C 72 76 8E 14 95 0B D1 8B
DEC - 3E 2E BA 24 FA 22 47 A0 00 0F A5 0E F7 B0 9C 32
If the above is done then I need to automate the HEX search and replace values from encdec.txt on the target encrypted file.
So the automation would check the line " ENC - 88 F4 62 71 3D 25 CD 7C 72 76 8E 14 95 0B D1 8B " and search for it on the targeted file and replace the values with hex values in "DEC - 3E 2E BA 24 FA 22 47 A0 00 0F A5 0E F7 B0 9C 32"
I am not an experienced ruby programmer, so bear with me. I have a problem with this specific text file containing two lines ( this issue shows up only on occasions) :
trim(0, 15447)
0, 15447
I am trying to read these two lines with the following code:
File.open(trim).each do |line|
puts line
end
I normally obtain the normal output, but here, I get only one line, with some characters missing:
0, 1544715447)
If I want to check the character codes, I get this:
irb(main):120:0> File.open(trim).each do |line|
irb(main):121:1* puts '========================'
irb(main):122:1> puts line
irb(main):123:1> puts '........................'
irb(main):124:1> puts line.each_byte {|c| print c, ' ' }
irb(main):125:1> end
========================
0, 1544715447)
........................
116 114 105 109 40 48 44 32 49 53 52 52 55 41 13 48 44 32 49 53 52 52 55 trim(0,0, 15447
=> #<File:E:\Public\Public_videos\Soccer\1995_0129_odp_es\950129-ODP_&m3_trim30.txt>
I frankly don't understand what is going on, as I don't see any hidden character, and this happen randomly, but consistently with some files.
Any suggestion to help me understand or avoid this issue would be greatly appreciated.
What happened is that your file had two "lines" separated by a carraige return character, and not a linefeed.
You showed the bytes in your file as
116 114 105 109 40 48 44 32 49 53 52 52 55 41 13 48 44 32 49 53 52 52 55
That 13 is a carriage return, which is sometimes "displayed" by the writer going back to the start of the line it is writing.
So first it wrote out
trim(0, 15447)
then it went back to the start of the same line and wrote
0, 15447
overlaying the initial line! What do you end up with?
0, 1544715447)
Your "problem" is probably best fixed by reencoding that text file of yours to use a better way to separate lines. On Unix systems, including OSX these days, the line terminator is character 10 - known as LINE FEED. Windows uses the two-character combination 13 10 (CR LF). Only old Mac systems to my knowledge used the 13.
Many text editors today will allow you to select a "line ending" option, so you might be able to just open that file, then save it using a different line ending option. FWIW my guess is that you are using Windows now, which is known for rendering CRs and LFs differently than *Nix systems.
I need to pass a link to file from a user process to the OSX kernel driver. By link i mean anything that uniquely identifies a file on the local filesystem. I need that link to do I/O on that file in kernel. The most obvious solution seems to pass a file name and use a VFS vnode lookup. However i noticed, that Apple Disk Images helper process passes a raw data array for image-path property to driver when attaching a disk image file:
<2f 56 6f 6c 75 6d 65 73 2f 73 74 6f 72 61 67 65 2f 74 65 73 74 32 2e 64 6d 67>
What is that diskimages-helper passes to the kernel driver? Some serialized type perhaps? If yes, what type is it and how can i use it?
I don't know anything about Mac OS X kernel programming, but that "raw data array" you posted is instantly recognisable as ASCII text. It is the string /Volumes/storage/test2.dmg.
(The usual "UNIX way" to pass a file from userspace to the kernel is for the userspace application to open the file and pass the file descriptor in).