I am assigned by a project to clone E-passport using either Type A or Type B JavaCard. The card I had is from Javacard OS (https://javacardos.com/javacardforum/).
Step 1: Use pyApduTool to download the cap and install the applet as shown below:
Step 2: Use JMRTD to upload passport information and the APDU trace is given below:
There is no issue in cloning the E-passport and the E-passport can be read successfully using JMRTD.
However, I would like to be more flexible on passport Cloning. Instead of using JMRTD to upload the passport infomration, I extract APDU commands from JMRTD which is shown above and key in the APDU using python code.
The APDU commmand is given below:
RAW. C:
0000: 00 A4 04 0C 07 A0 00 00 02 47 10 01 .........G..
RAW. R:
0000: 90 00 ..
RAW. C:
0000: 00 A4 02 0C 02 01 1E .......
RAW. R:
0000: 6A 82 j.
RAW. C:
0000: 00 DA 00 62 1D 62 1B 04 09 31 32 33 34 35 36 37 ...b.b...1234567
0010: 38 39 04 06 37 35 30 31 30 31 04 06 32 35 30 31 89..750101..2501
0020: 30 31 01
RAW. R:
0000: 90 00 ..
RAW. C:
0000: 00 E0 00 00 06 63 04 00 5D 01 01 .....c..]..
RAW. R:
0000: 90 00 ..
RAW. C:
0000: 00 D6 00 00 5D 61 5B 5F 1F 58 50 3C 55 54 4F 42 ....]a[_.XP<UTOB
0010: 45 41 4E 3C 3C 48 41 50 50 59 3C 3C 3C 3C 3C 3C EAN<<HAPPY<<<<<<
0020: 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C <<<<<<<<<<<<<<<<
0030: 3C 3C 3C 3C 3C 3C 31 32 33 34 35 36 37 38 39 37 <<<<<<1234567897
0040: 55 54 4F 37 35 30 31 30 31 32 4D 32 35 30 31 30 UTO7501012M25010
0050: 31 37 31 32 33 34 35 36 37 38 39 3C 3C 3C 3C 3C 17123456789<<<<<
0060: 37 3C 7<
RAW. R:
0000: 69 85
..
Everytime, when I try to update the binary, the card returns 69 85. However, the problem is not coming out when using JMRTD.
Could someone help with that?
Thanks
Heng
I was ablet to clone passport using APDU command. The APDU trace from JMRTD is incomplete. You need to use USB BusHound to extract the detailed APDU commands.
Related
I was showing my kid some basic scripting with ffmpeg to show him how much easier it is with automation.
Which, of course, failed miserably.
Specifically, we wrote a simple python script that outputs something like:
ffmpeg -ss 0:00:00 -t 1:00:00 -i wholebook.mp3 'Part 01.opus'
ffmpeg -ss 1:00:00 -t 1:00:00 -i wholebook.mp3 'Part 02.opus'
ffmpeg -ss 2:00:00 -t 1:00:00 -i wholebook.mp3 'Part 03.opus'
.
.
.
Which works fine, so then I piped it to bash: python script.py | bash
ffmpeg converted the first part, then started spewing errors and data dumps for most of the rest. (Ok, it got part 15 right, too.)
Copy/pasting each command in turn works fine.
Changing the output to .mp3 didn't matter; it seems like it's erroring out while reading the input.
Why is piping these commands to bash failing?
Update: it's not just piping it to bash. If, instead of cutting & pasting each command and waiting for it to finish, he cuts & pastes the whole series of commands into the terminal (running bash), it fails in the same way.
The error output starts with:
stream #0:
keyframe=1
duration=0.026
dts=426.005 pts=426.005
size=418
stream #0:
keyframe=1
duration=0.026
dts=426.031 pts=426.031
size=418
stream #0:
keyframe=1
duration=0.026
dts=426.057 pts=426.057
size=418
and continues for many thousands of lines. At some point, it switches to:
stream #0:
keyframe=1
duration=0.026
dts=764.473 pts=764.473
size=418
00000000 ff fb 92 64 f0 89 f5 f8 6c 3f 83 2c 4b 52 00 00 ...d....l?.,KR..
00000010 0d 20 00 00 01 19 55 b0 fe ad 31 37 08 00 00 34 . ....U...17...4
00000020 80 00 00 04 71 63 57 34 87 7a a1 ad 69 ab 77 53 ....qcW4.z..i.wS
00000030 fd fb 88 28 d3 10 b2 66 9f 99 dc 82 46 27 44 a2 ...(...f....F'D.
00000040 75 a8 5d b1 83 34 9a 5e bd 72 59 b1 11 1e 0a b8 u.]..4.^.rY.....
00000050 6d e9 d1 61 94 5c b6 92 ac cf 16 4b 74 d4 7c b7 m..a.\.....Kt.|.
00000060 ab c7 7a 6a 6b 7e f1 4e 55 fc 69 dd 2a f0 e1 21 ..zjk~.NU.i.*..!
00000070 09 10 25 09 a8 79 fe d1 da cb 34 06 8a 08 28 21 ..%..y....4...(!
00000080 47 6d 5d b6 06 f1 57 af 59 7b 75 86 60 a8 dd 99 Gm]...W.Y{u.`...
00000090 a4 87 45 aa 90 e1 67 74 78 30 a1 83 08 ce d9 ee ..E...gtx0......
000000a0 4f cf 22 f8 a3 46 4a a1 7c 7b a1 e6 59 df 76 86 O."..FJ.|{..Y.v.
000000b0 53 c5 5e 85 1d 39 57 ac a3 0e c5 03 93 51 f6 c6 S.^..9W......Q..
000000c0 86 2b 9c e1 33 27 59 c8 96 76 db 1c 96 42 58 93 .+..3'Y..v...BX.
000000d0 ce 46 83 44 a2 48 e5 66 0a 60 30 70 27 bc 3f 2a .F.D.H.f.`0p'.?*
000000e0 2d d9 6d 4d d9 79 41 7c d8 fc a9 64 35 af 88 eb -.mM.yA|...d5...
000000f0 15 a4 32 b2 73 0b 18 88 04 81 c9 60 48 ba 97 54 ..2.s......`H..T
00000100 24 89 28 65 e4 8b 0e ce 11 a1 19 39 05 0e 0f 31 $.(e.......9...1
00000110 62 e7 9a 3d 5c 3e b9 64 69 4f f6 f1 1d 19 bb 8f b..=\>.diO......
00000120 e1 29 60 b8 d6 ca 35 f8 ce 50 d4 9f dd 4a e3 d7 .)`...5..P...J..
00000130 79 d3 75 8e 15 67 c9 8b ac d9 a5 6a fa 43 47 10 y.u..g.....j.CG.
00000140 d1 46 fd 9c 93 d8 a3 33 74 2e 80 00 82 94 4c f3 .F.....3t.....L.
00000150 0e 02 8c 07 41 31 48 95 d8 f2 85 89 38 5e 65 37 ....A1H.....8^e7
00000160 76 dd 2b 2e c5 1c 39 13 9b 9b ae ab 25 cc 79 45 v.+...9.....%.yE
00000170 1e 60 1d b0 20 cf d2 12 cc 80 57 9b 99 65 78 9c .`.. .....W..ex.
00000180 82 a3 03 c0 b2 11 6b a5 49 c2 85 bd 3f 90 d5 73 ......k.I...?..s
00000190 13 f4 9e c5 29 23 0a 2a 25 c5 9d eb 5e 9c 95 c9 ....)#.*%...^...
000001a0 ec aa ..
stream #0:
keyframe=1
duration=0.026
dts=764.500 pts=764.500
size=418
00000000 ff fb 92 64 ea 80 f5 14 69 41 cb 0c 34 72 00 00 ...d....iA..4r..
00000010 0d 20 00 00 01 1b 49 b0 fc ac bd 91 88 00 00 34 . ....I........4
00000020 80 00 00 04 5b 32 ac c2 16 a8 6d 65 8d 09 c5 3b ....[2....me...;
00000030 64 81 da 43 d5 27 4a 3d b1 8d c1 f5 95 ba e9 61 d..C.'J=.......a
00000040 62 a7 6a 5e 5d ab 58 7a 23 b7 8a f5 3f 2a 59 62 b.j^].Xz#...?*Yb
...
ffmpeg reads from stdin too, to allow you to change options or exit interactively. This means that the commands you meant for bash are instead read by ffmpeg, and e.g. a q will cause it to quit.
You can instead:
Run the command directly from Python, rather than writing commands to bash. This is generally more robust, since you don't have to do any shell escaping.
Use ffmpeg -nostdin ... or ffmpeg < /dev/null ... to prevent ffmpeg from consuming stdin.
Prepend a line with { and append a line with }. That way, bash will read all commands as a single group up front, so there's no remaining stdin to be had for ffmpeg.
I'm currently working on an old MS-DOS application, which uses DMI to identify the hardware. It worked fine in the past, but it seems to provide invalid data on newer systems (e.g. Skylake). As stated in the spec, we are scanning 0xF0000-0xFFFFF for the "SM" anchor string, this is still working as expected.
But now it seems that the data located at the "Structure table adress" (stored at offset 0x18h in the) are invalid (see dumps below). Tools like dmidecoe deliver correct information (however, it uses GetSystemFirmwareTable() on Windows). What I am doing wrong here?
EDIT (clarify situation)
On an older system I get expected data (dump is done in FreeDOS' debug98 utility) - following come from an IvyBridge system (3rd gen.):
-d F000:04C0
F000:04C0 5F 53 4D 5F 03 1F 02 07-77 00 00 00 00 00 00 00 _SM_....w.......
F000:04D0 5F 44 4D 49 5F E0 6E 04-10 BA 0E 00 17 00 27 00 _DMI_.n.......'.
F000:04E0 1E 66 60 68 00 F0 1F B8-90 D0 83 C0 0F 24 F0 A3 .f`h.........$..
F000:04F0 1D 03 B9 00 E0 2B C8 79-02 33 C9 89 0E 1F 03 33 .....+.y.3.....3
F000:0500 C0 66 2E 8B 1E 63 00 66-83 FB 00 74 0B 66 81 FB .f...c.f...t.f..
F000:0510 00 00 0E 00 72 02 8B C3-A3 19 03 F7 D0 A3 1B 03 ....r...........
F000:0520 66 61 1F C3 00 1E 50 68-00 F0 1F 0B DB 74 28 F7 fa....Ph.....t(.
F000:0530 C3 80 00 74 1C 2E 80 3E-24 05 00 75 43 83 F9 3E ...t...>$..uC..>
-d E000:BA10
E000:BA10 00 18 00 00 01 02 00 F0-03 7F 80 98 89 3F 01 00 .............?..
E000:BA20 00 00 03 0D 04 06 FF FF-41 6D 65 72 69 63 61 6E ........American
E000:BA30 20 4D 65 67 61 74 72 65-6E 64 73 20 49 6E 63 2E Megatrends Inc.
E000:BA40 00 42 51 37 37 52 31 31-31 00 30 37 2F 30 35 2F .BQ77R111.07/05/
E000:BA50 32 30 31 33 00 00 01 1B-01 00 01 02 03 04 00 00 2013............
E000:BA60 01 26 60 24 00 05 00 06-00 07 00 08 00 09 06 05 .&`$............
E000:BA70 06 20 00 20 00 20 00 30-30 30 30 30 31 32 36 36 . . . .000001266
E000:BA80 30 32 34 00 20 00 20 00-00 02 0F 02 00 01 02 03 024. . .........
Newer systems - in this case a Skylake based one (6th gen.) data are different. In the adress the SMI structure points to i do not get the expected data (I expcted to see the BIOS strings, but they are not there):
-d f000:05e0
F000:05E0 5F 53 4D 5F F3 1F 03 00-8C 01 00 00 00 00 00 00 _SM_............
F000:05F0 5F 44 4D 49 5F 15 CE 07-00 90 1D 87 1A 00 30 00 _DMI_.........0.
F000:0600 5F 53 4D 33 5F 4A 18 03-00 00 01 00 CE 07 00 00 _SM3_J..........
F000:0610 00 90 1D 87 00 00 00 00-00 00 00 00 00 00 00 00 ................
F000:0620 1E 66 60 68 00 F0 1F B8-00 C6 83 C0 0F 24 F0 A3 .f`h.........$..
F000:0630 8E 03 B9 00 E0 2B C8 79-02 33 C9 89 0E 90 03 33 .....+.y.3.....3
F000:0640 C0 66 2E 8B 1E 63 00 66-83 FB 00 74 0B 66 81 FB .f...c.f...t.f..
F000:0650 00 00 0E 00 72 02 8B C3-A3 8A 03 F7 D0 A3 8C 03 ....r...........
-d 871d:9000
871D:9000 76 06 D1 E9 73 08 8A 05-A4 88 44 FF 74 08 8B 05 v...s.....D.t...
871D:9010 A5 89 44 FE E2 F8 5F 5E-5D C2 04 00 55 8B EC 4C ..D..._^]...U..L
871D:9020 4C 56 57 83 7E 04 02 73-2D 83 7E 04 02 74 03 E9 LVW.~..s-.~..t..
871D:9030 18 01 8B 46 06 03 06 AC-10 8B F8 50 FF 76 06 FF ...F.......P.v..
871D:9040 16 AE 10 59 59 0B C0 7F-03 E9 FE 00 FF 76 06 57 ...YY........v.W
871D:9050 E8 9D FF E9 F4 00 8B 46-04 48 F7 2E AC 10 8B 56 .......F.H.....V
871D:9060 06 03 D0 8B FA 8B 46 04-D1 E8 F7 2E AC 10 8B 56 ......F........V
871D:9070 06 03 D0 8B F2 57 56 FF-16 AE 10 59 59 0B C0 7E .....WV....YY..~
Your SMBIOS structures are located at physical address 0x871d9000 (as seen from offset f000:0610, or offset x10 from the '_SM3_' anchor string), as Michael Petch points out.
This is a minor point but could be important depending on how your software is constructed. Keep in mind this is a SMBIOS 3.0 conforming structure (per the "_SM3_" anchor string) and that the structure table address can be on any 64-bit address. To ensure your software works in all systems, you should use the _SM3_ structure table address when present and enable your software to read any 64-bit physical address using big-real mode or other mechanism. When the _SM3_ structure is not present, then revert back to your old software flow.
As for why you are just now seeing this, is this the first time you have encountered a data structure that is above 1MB physical address?
I can't finish the authentication phase.
What I am using:
SAM module by NXP
Mifare Desfire PICC
I am following the next steps:
Get PICC SerialNumber (or UID) with GetVersion.
GET VERSION:
Tx: 90 60 00 00 00
Rx: 04 01 01 00 02 18 05 91 AF
GET VERSION 2:
Tx: 90 AF 00 00 00 00
Rx: 04 01 01 00 06 18 05 91 AF
GET VERSION 3:
Tx: 90 AF 00 00 00 00
Rx: 04 65 41 49 65 1B 80 8E 65 58 51 30 46 07 91 00
Get encrypted(RndB) from PICC.
Tx: 90 0A 00 00 01 00 00
Rx: 31 15 1A 19 DB ED CD 5A 91 AF
Send to SAM PICC_SN + ek(RndB).
Tx: 80 41 01 03 0F 80 1B 65 49 41 65 04 31 15 1A 19 DB ED CD 5A
Rx: 61 20
Get from SAM encrypted(RndA + RndB_rotated) + 1st half Session Key
Tx: 00 C0 00 00 20
Rx: F3 10 55 B1 D3 18 91 5B 92 48 16 1F E1 58 D5 CB E9 F3 51 04 41 8A 4E A5 A2 B5 67 CA FF D8 D2 35 90 00
Send PICC encrypted(RndA + RndB_rotated).
Tx: 90 AF 00 00 10 F3 10 55 B1 D3 18 91 5B 92 48 16 1F E1 58 D5 CB 00
Rx: 91 AE
So, this is a guide I have received from my suplier, and i don't have explanations about the apdus used; some i have found them on the internet, some others i guessed.
What I need to know is what does the next command i use:
to SAM module: 80 41 01 03 Lc Data
I need to know what encryption it deploys, why it needs PICC's UID (is this the IV), how can i know RndB, and what is expecting the PICC to end the authentication.
Thanks
Pd: Sorry for the text's format, it seems I'm unable to use correctly the tools for posting, everything gets in the same line it's disgusting...
I solved the problem and finished authentication.
The error was that i was requesting RndB encrypted with keyNo = 0, while corresponding key from SAM's key encryption should be keyNo = 2.
So:
--> 90 0A 00 00 01 02 00
<-- 91 B6 08 CE 9F B5 34 3B 91 AF
Carrying on, i finnish authentication:
--> 90 AF 00 00 10 0F DC FA B6 37 5F 30 34 D7 93 2D A1 3D D6 11 10 00
<-- E9 C2 F2 69 FE 38 78 28 91 00
But now I have the next problem. I've authenticated and I can read PICC's data but i'm afraid it's encrypted. I suppose it is encrypted with session key, so I need some apdu command to be sent to SAM, with data and session key, in order to decrypt data retrieved from PICC.
Am I right? if that is... which would be that SAM APDU?
I have a 240MB logfile from a PuTTY session. This was mistakenly logged in the "SSH packets and raw data" format instead of "All session output". If I open the file in a text editor then I can see that the data I require (the plain text).
The problem is extracting that from the raw data.
For example:
Incoming raw data at 2016-01-06 15:47:42
00000000 e8 fd c2 d2 88 a9 39 b9 2a 77 2a 7b 4a 60 fc 21 ......9.*w*{J`.!
00000010 1d f5 fc d4 b1 58 1f 4d 68 a4 ef 83 03 39 59 b7 .....X.Mh....9Y.
00000020 41 be 36 7b b5 3c 10 fa 65 27 77 30 77 97 02 39 A.6{.<..e'w0w..9
00000030 46 4c 28 da 5c c6 2c 1e ae 33 db e1 a8 09 ea 4a FL(.\.,..3.....J
00000040 06 94 c6 eb 38 8e d3 d3 33 13 78 08 7c 5f 41 56 ....8...3.x.|_AV
00000050 f1 13 9e e1 ....
Incoming packet #0x31, type 94 / 0x5e (SSH2_MSG_CHANNEL_DATA)
00000000 00 00 01 00 00 00 00 20 64 69 73 61 62 6c 69 6e ....... disablin
00000010 67 20 61 20 72 75 6e 6e 69 6e 67 20 77 61 74 63 g a running watc
00000020 68 64 6f 67 2e 2e 0d 0a hdog....
Incoming raw data at 2016-01-06 15:47:42
00000000 dc 96 f3 54 f8 a8 5c 83 80 7b a8 07 da 79 95 50 ...T..\..{...y.P
00000010 3f 19 2f 0c f0 03 a1 01 a3 33 2f 97 75 9d 47 15 ?./......3/.u.G.
00000020 b9 95 df c6 66 e0 50 32 88 1e db 5b 73 1b 7b ad ....f.P2...[s.{.
I think what I need to do is read only the sections of the file labelled "Incoming packet". Then I can read the ascii character codes and convert to readable text (this will recover the tabs, linefeeds and carriage returns).
I'm not familiar with awk or sed, but I know a bit of grep. How can I go about firstly extracting the sections (of variable size) that I need to translate from ASCII codes to text?
sed -n '/^Incoming packet/,/^Incoming raw data/{//!p}
This will print lines between the matches Incoming packet and Incoming raw. Process this output further to get your desired output.
Print only ASCII characters (print last 17 characters) from the matching line:
sed -n '/Incoming packet/,/Incoming raw data/{//!{s/^.*\(.\{17\}\)/\1/;p}}'
Ref:1, 2
I have Googled a lot and failed to find the decoding algorithm for the PDF417 barcode used by United States Postal Service. I want to fetch recipient and sender information with tracking number out of it.
I have successfully decoded the FedEx barcode with ANSI MH10.8.3 standard.
My question is, am I scanning the correct barcode (I am not from USA, so I don't know which barcode label USPS applies to their parcels) ? If no, then what barcode should I look for to fetch required information ? If Yes, then how can I decode this barcode ?
Please help,
Thanks.
Edit:
Here is another similar barcode
You should check this webpage:
https://en.wikibooks.org/wiki/International_Postage_Meter_Stamp_Catalog/United_States_of_America,_Part_3
As well as this page:
http://www.stamps.com/postage-online/how-it-works/
Your first barcode seems to have been generated by Endicia software (ID# starts with 071V), while the second example barcode was generated by stamps.com (as printed, and also ID# starts with 062S).
It seems that stamps.com service allows you to print stamps without providing the recipient address. For this reason, the barcode probably doesn't include any information about the recipient.
For the record, the decoded bars are as follows:
0000 50 01 dc 78 0c 00 30 37 31 56 57 6c 08 00 7a 86 | P~~x~~071VWl~~z~ |
0010 09 c5 4e d8 27 00 8a b7 32 01 24 4f 00 00 67 49 | ~~N~'~~~2~$O~~gI |
0020 6d 15 00 b5 c3 00 00 00 00 06 c1 31 02 b9 02 90 | m~~~~~~~~~~1~~~~ |
0030 d0 a4 4a 1c 02 2a 42 8f a7 3f 6d c7 03 ea e5 d7 | ~~J~~*B~~?m~~~~~ |
0040 3c 69 86 3c 50 29 28 32 11 74 6a 7f b4 af c7 90 | <i~<P)(2~tj~~~~~ |
0050 16 c3 90 bb fb 2a fa 4e 78 95 e6 20 69 c7 75 01 | ~~~~~*~Nx~~ i~u~ |
0060 00 00 | ~~ |
and:
0000 05 01 ff ff 00 00 30 36 32 53 3b 47 70 00 f2 ed | ~~~~~~062S;Gp~~~ |
0010 10 00 00 14 1e 00 56 52 33 01 59 33 01 00 00 00 | ~~~~~~VR3~Y3~~~~ |
0020 00 00 00 00 04 00 02 00 00 5c da 00 00 38 30 33 | ~~~~~~~~~\~~~803 |
0030 34 ae 69 57 0d 59 42 1c d4 0b 00 f2 d3 7f 4f f8 | 4~iW~YB~~~~~~~O~ |
0040 ef 69 53 a0 aa fb 9b cf 30 16 13 c3 08 3e 86 4a | ~iS~~~~~0~~~~>~J |
0050 7a e8 4c fe 1f eb 4d 2c 52 05 00 6f 33 01 00 | z~L~~~M,R~~o3~~ |
Bytes 06-09 (0-indexed) is the ID prefix in ASCII.
Bytes 0A-0D is the rest of the ID, encoded in binary in little endian. 3B 47 70 00 is 0x0070473B = 7358267, for the second stamp.
For the second stamp, bytes 5B-5D (6F 33 01) is actually 01 33 6F = 78703, the zip it was posted from. Unfortunately, it doesn't work with the first stamp.