I am trying to activate a card using CRS applet of GP
The full Command APDU passed was 80F001010A4F08XXXXXXXXXXXXXXXX00 (
when group by bytes CLA::80 INS::F0 P1::01 P2::01 Lc::0A TAG::4F L::08
V::AID::XX XX XX XX XX XX XX XX 11 Le::00)
XX XX XX XX XX XX XX XX is the AID place holder .
The CRS is present and I am able to get the global counter too.
But when I try above Command to activate I am getting 6D 00 ( which interprets to “Invalid Instruction”), but for my best knowledge the command APDU is well formed according to GP spec.
Related
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'd like to replace the first stage bootloader in the nand flash on a sama5d36 based system running 4.1.0-linux4sam_5.1 and buildroot-2016.02.
I can replace the kernel image with flashcp just fine, but when I try it with the bootloader, flashcp runs without errors, but the system doesn't boot afterwards, stays at the ROMBOOT prompt.
buildroot:~# flashcp -v at91bootstrap.bin /dev/mtd0
Erasing block: 1/1 (100%)
Writing kb: 14/14 (100%)
Verifying kb: 14/14 (100%)
buildroot:~# reboot
[...]
Sent SIGKILL to all processes
Requesting system reboot
�RomBOOTRestarting system
Then I can write the same bootloader image with sam-ba, and it will boot, so the image is good. How can it be flashed in Linux, without user intervention?
There should be a 208 byte header preceding the actual boot code at the beginning of the flash.
From the SAMA5D3 Datasheet (that I should have read before posting the question)
After Initialization and Reset command, the Boot Program reads the first page without an ECC check, to determine if the NAND parameter header is present. The header is made of 52 times the same 32-bit word (for redundancy reasons) which must contain NAND and
PMECC parameters used to correctly perform the read of the rest of the data in the NAND.
The header is of course there when I dump the contents of the boot sector
buildroot:~# hd < /dev/mtd0 | head -4
00000000 05 24 90 c0 05 24 90 c0 05 24 90 c0 05 24 90 c0 |.$...$...$...$..|
*
000000d0 0e 00 00 ea 05 00 00 ea 05 00 00 ea 05 00 00 ea |................|
000000e0 05 00 00 ea cc 3b 00 00 06 00 00 ea 06 00 00 ea |.....;..........|
the first four bytes are repeated over and over, and the ARM jump table begins at offset 0xD0 (=208=52 * 4)
sam-ba takes care of this header when it writes the boot sector, but the Linux mtd driver and flashcp treats it as ordinary data, so I should supply it.
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 using dtruss on MacOS X 10.8.5 in an attempt to see the conversation between a running application and an SSL server it talks to. Unlike strace on Linux, I'm not seeing full strings of data in the output, like I would expect to find as the program does send and recv on the file descriptor.
How can I get dtruss to show me the data which the app is sending and receiving with the SSL server?
Before anyone tells me to proxy the connections to an SSL server I control, yes I know this trick, and no this particular app is too smart to fall for it.
dtruss is both an elegant example of a script written for DTrace and a demonstration of what DTrace can accomplish. However, although its similarity to truss or strace is deeply welcome on the relatively barren OS X, I suspect that dtruss was never intended to be a complete substitute for either.
In any case, your question is a bit ambiguous: I'm not sure whether you are concerned that the strings that you see are truncated or that you don't see any strings at all for sendto() or recvfrom() (the underlying interfaces revealed by DTrace). I'll address both.
Firstly, DTrace collects data in the kernel; user-land buffers are obtained with the D language's copyin() or copyinstr() before being recorded and transmitted back to the consumer --- typically the dtrace(1) command. DTrace requires that its kernel buffer size be known at compile-time and therefore imposes a limit on the otherwise unpredictable length of a string. This limit is 256 bytes by default; if you are seeing truncation then you could change the limit by adding, e.g.,
#pragma D option strsize=512
below dtruss's existing pragma.
Secondly, dtruss is hard-coded to know about the formatting requirements of a variety of system calls. You don't see any buffer interpretation for sendto() or recvfrom() in its output because they're not handled explicitly in the source. There's nothing to stop you finding somewhere suitable to add them but you could instead write your own script:
bash-3.2# cat sr.d
#pragma D option rawbytes
syscall::sendto:entry,
syscall::recvfrom:entry
/pid == $target/
{
self->bufp = arg1;
self->size = arg2;
}
syscall::sendto:return,
syscall::recvfrom:return
/pid == $target && self->bufp && self->size/
{
printf("%s():\n", probefunc);
tracemem(copyin(self->bufp, self->size), 64);
printf("\n");
self->bufp = self->size = NULL;
}
bash-3.2# dtrace -qs ./sr.d -p 16988
sendto():
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
0: 68 65 6c 6c 6f 00 00 00 00 00 00 00 00 00 00 00 hello...........
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
^C
bash-3.2#
Note that, as for strings, we're obliged to provide a hard limit on tracemem()'s use of DTrace's data-recording buffer. If the limit is rarely approached then this has the irritating result that the output can be overwhelming and mostly redundant. If you know that you're looking for strings then you could simply use copyinstr() instead; if you have a more modern DTrace implementation than my OS X 10.6.8 then you may find that you can write
tracemem(copyin(self->bufp, self->size), 64, self->size);
where the second argument is still a hard limit on the number of bytes recorded but the number of bytes displayed is limited by the optional third argument.
Finally, note that the user-land address is recorded on entry to the system call but used only on exit. This is a common idiom that allows the system call to fault-in the data if necessary --- DTrace won't do so itself and will produce an error at run-time if asked to trace a non-resident address.