Patch for ISO1444B - send raw command

jonor · 2013-08-26 20:32:17

I developed a simple patch for send raw command with ISO1444B.
I take the code of ISO15693 and with some adjument it is working also with ISO1444B.

With this patch I have done some improvement to my old patch for SRIX4K. CodeIso14443bAsReader is now static, it is a internal function.

You can download here http://www.sendspace.com/file/rj02ch
Sorry for the link, but I tried to put the code in tag code and when I tried to apply the patch I have many FAILED, I think the problem is the end of row.

I hope is usefull to someone.

asper · 2013-08-26 20:58:33

Litterally FANTASTIC ! I hope someonea can implement this patch in the official branch adding also "ISO14443B raw commands" command (and I will update the gui!).
Does the srix4k 06 command works with your patch ? Are you able to replicate this patch for ISO14443A?
Anyway you are AMAZING ! Thank you relly really much!!

jonor · 2013-08-26 21:08:44

Yes 06 00 is working with Srix4k and SRI512. But this is good for every tag ISO14443B. Also the reader ISO14443B is partial, it send only REQB, now should be easy to implement a complete reader with scripting.
I think is possible to replicate also for ISO14443A. I will try!

asper · 2013-08-26 21:21:39

I LOVE you man !!! ^_^

holiman · 2013-08-27 07:44:31

Nice to hear! I've been slow moving during the summer, I tested the raw iso 14443a-stuff the other day, but didn't get the results I expected (I try to use the raw-commands to send an auth, and expect to get a nonce back. somehow thiis fails, and I'm not sure why). I'll commit my still not-working writeraw-14a script, if anyone wants to take a look.

Are you aware that there is already send-raw-14a-code in the armsrc? I started writing it, but then noticed that someone already had . All I'm doing is trying to use that existing piece of code, and if anyone cares to join in getting that working it's much appreciated.

Oh, and I take at look at and commit your patch, but I don't know if I have any ISO1444B-cards to test it with...

holiman · 2013-08-27 07:51:53

And another thing - is the patch for the scripting-branch or the main branch ?

jonor · 2013-08-27 17:17:08

My patch is for main branch, I need to test for scripting. Today I discovered a bug in my patch. Every send set off the signal field and after put on, so the tag lost the state.
I will send a new patch for main branch.
With my patch I can send only byte and not a portion, as nibble. If is usefull for ISO14443B I can try to implement it.

asper · 2013-08-27 17:30:06

Holiman, can you make a little "how-to-use-scripting" tutorial or write me how it works so I can make one ?

jonor · 2013-08-27 18:04:51

New patch with bug correct. Here for download http://www.sendspace.com/file/zkq7dy please ignore my previous link.
Now I can talk from client with SRI512 or SRIX4K manually. For these tags there are already functions implemented in pm3, but I can test only with them.

# Inventory
proxmark3> hf 14b raw -c -p 06 00
received 3 octets
64 5A D5
CRC OK
# Select Chip ID (return by Select)
proxmark3> hf 14b raw -c -p 0E 64
received 3 octets
64 5A D5
CRC OK
# Get UID but I got error
proxmark3> hf 14b raw -c -p 0B
received 3 octets
15 5E AE
CRC failed
# Try another one with Get UID OK I got it (byte are obfuscated by me)
proxmark3> hf 14b raw -c -p 0B
received 10 octets
15 5E AE 70 23 05 02 D0 42 CA
CRC OK
# Try to read block 0x00 with fails
proxmark3> hf 14b raw -c -p 08 00
received 10 octets
FF FF FF FF 47 0F 00 00 00 00
CRC failed
# another try OK
proxmark3> hf 14b raw -c -p 08 00
received 6 octets
FF FF FF FF 47 0F
CRC OK
# Read Block 0x01 OK
proxmark3> hf 14b raw -c -p 08 01
received 6 octets
FF FF FF FF 47 0F
CRC OK

It's just an example.
I begin to analize the branch scripting.

asper · 2013-08-27 18:36:27

Can you describe -c and -p parameters so that I can update the GUI ?

jonor · 2013-08-27 19:00:25

The help of this parameter is present also in the client proxmark

-r    do not read response
-c    calculate and append CRC
-p    leave the field on after receive

holiman · 2013-08-28 07:03:02

@asper - I definitely need to do that. I'll explain it a bit here.

@jonor - No need to do anything special for the scripting branch. Instead of implementing a new Cmdline-command, you can put together the usbpacket in lua and send to the client.

Now, my attempt to do this can be seen in https://code.google.com/p/proxmark3/source/browse/branches/scripting/client/scripts/writeraw.lua?spec=svn757&r=757.

First I load the 'commands'-library, and prints out a description. The commands-library is only a utility to use when packing data. One could skip the commands-library if one wanted to, but then have to call the bin-library directly to help go from data in strings ("AABBCC00") into actual bits.

local cmds = require('commands')
local desc =
[[

This script is a work in progress, not yet functional. It is an attempt to use the raw-writing 
capabilities already present within the devices

]]
print(desc)

Initiaize some raw data I'm going to want to send

-- Some raw data
local rawdata = "6000F57b" --mf_auth
local TIMEOUT = 2000 -- Shouldn't take longer than 2 seconds

Define a helper function that prints out the content of a USB command

function show(usbpacket)
        if usbpacket then
                local response = Command.parse(usbpacket)
                print(response)
        end
end

Now, in order to understand the next part, you should also look at the arm-side implementation . (https://code.google.com/p/proxmark3/source/browse/branches/scripting/armsrc/iso14443a.c?r=757)

void ReaderIso14443a(UsbCommand * c)
{
        iso14a_command_t param = c->arg[0];
        uint8_t * cmd = c->d.asBytes;
        size_t len = c->arg[1];
  uint32_t arg0 = 0;
  byte_t buf[USB_CMD_DATA_SIZE];
  
  iso14a_clear_trace();
  iso14a_set_tracing(true);

        if(param & ISO14A_REQUEST_TRIGGER) {
    iso14a_set_trigger(1);
  }

        if(param & ISO14A_CONNECT) {
                iso14443a_setup();
                arg0 = iso14443a_select_card(NULL,(iso14a_card_select_t*)buf,NULL);
                cmd_send(CMD_ACK,arg0,0,0,buf,sizeof(iso14a_card_select_t));
//    UsbSendPacket((void *)ack, sizeof(UsbCommand));
        }

Above, it shows that the device receives the command, and uses cmd->[arg0] to check what to actually do. For example, ISO14A_CONNECT.
A little further down:

 if(param & ISO14A_RAW) {
                if(param & ISO14A_APPEND_CRC) {
                        AppendCrc14443a(cmd,len);
                        len += 2;
                }
                ReaderTransmit(cmd,len);
                arg0 = ReaderReceive(buf);
//              UsbSendPacket((void *)ack, sizeof(UsbCommand));
    cmd_send(CMD_ACK,arg0,0,0,buf,sizeof(buf));
        }

So there's the functionality to send raw data, optionally with crc.

Both the connect ISO14A_CONNECT-flag and ISO14A_RAW-flag, on a packet, will trigger the client to send a CMD_ACK. So we'll have to deal with it several times.
Ok, back to the script:

-- Want to do both connect and send raw, so we should AND the two commands
-- ISO14A_COMMAND.ISO14A_RAW(8) and ISO14A_CONNECT (1). However, we don't have a 
-- bitlib yet, so we'll do it manually, 1 & 8 == 9
-- ISO14A_NO_DISCONNECT = 2 ==> 11

print(string.len(rawdata))
local command = Command:new{cmd = cmds.CMD_READER_ISO_14443a, 
                                                                        arg1 = 3, -- Connect (1) and don't disconnect (2)
                                                                        arg2 = 0-- string.len(rawdata), 
                                                                        --data = rawdata
                  }

Above, we iniitialize a new command. The cmd type is CMD_READER_ISO_14443a,, our arg1 is the thing which is interpreted as cmd->arg[0] back in the device-code.
There we put 3, which is ISO14A_CONNECT(1) and ISO14A_NO_DISCONNECT (2). OK, so we prepared a packet which means "please connect and don't disconnect the tag".
We define two more packets:

local mf_auth = Command:new{cmd = cmds.CMD_READER_ISO_14443a, 
                                                                        arg1 = 6, -- Send raw 
                                                                        arg2 = string.len(rawdata), 
                                                                        data = rawdata}
local quit = Command:new{cmd = cmds.CMD_READER_ISO_14443a, 
                                                                        arg1 = 0, -- Nothing 
                                                                        }
                                                                       
core.clearCommandBuffer()
--print("Sending")
--print(command)
local err = core.SendCommand(command:getBytes())

In the mf_auth-packet, it can be seen that I put 'rawdata' within 'data', and the length of 'rawdata' in arg2. Arg2 will show up on the device-side as cmd->arg[1], while data will wind up as c->d.asBytes.

And finish with sending it to device (above). Lua does not have exceptions, so the norm is to use several return values in case of failures. Or, if there is *no* return value in the success-case, use return value only in case of failure. Below some error handling:

if err then
        print(e
        return nil, err
end

And if we sent the packet ok, we should be getting a CMD_ACK from the connect:

local cardselect = core.WaitForResponseTimeout(cmds.CMD_ACK,TIMEOUT)
print("Card select:")
show(cardselect)
--local response = core.WaitForResponseTimeout(cmds.CMD_ACK,TIMEOUT)
--print("Raw response:")
--show(response)

local answer = ""

Now, I wanted to send the auth-packet and get a nonce back. So in a little loop, each time the user presses a key, we send mf_auth:

while answer ~='q' do
        
        local err = core.SendCommand(mf_auth:getBytes())
                if err then
                        print(err)
                        return nil, err
                end
        local nonce = core.WaitForResponseTimeout(cmds.CMD_ACK,TIMEOUT)
        print("Nonce:")
        show(nonce)
        io.write("Write q to quit, hit any char to get a nonce ")
        io.flush()
        answer=io.read(1)

end

Don't know if I made anything clearer, but perhaps. Currently, I don't receive nonces like I think I should, and I'm not sure why.

asper · 2013-08-28 18:34:02

@holiman: thank you, now it's a bit clearer to me anyway I think have to experiment a lot in order for me to "own" script functionality
Maybe this can sounds as a stupid consideration to you about your insuccess with ISO14443A raw auth command but... do you previously send the 26 (request command) command and receive the 0400 answer and then the 93 20 (anticollision) command ? I think it will not be possible to send an auth without a previous request+anticollision...

@jonor: does your ISO1444B raw command works with hex data without spaces (es. is 0801 equal to send 08 01 like in ISO15693 raw) ?

New command added to the GUI, waiting to test the new changes in the main/script branch !

Last edited by asper (2013-08-28 18:48:42)

jonor · 2013-08-28 20:52:58

asper wrote:

@jonor: does your ISO1444B raw command works with hex data without spaces (es. is 0801 equal to send 08 01 like in ISO15693 raw) ?

I have copied the code and have changed for my scope. So without know it, this function is implemented. I'm a good copier.
You should be try my patch without wait for inclusion in svn, but I think without little antenna and without option -O2, this patch don't work for you with your little rfid tag.

holiman · 2013-08-29 09:07:26

Sorry that it hasn't been committed yet, I had hoped to get it done yesterday, but didn't have the time. I'll try to get it done this weekend.

Also, @asper, do you know if the lua branch compiles/works on windows, or do you still need that binary that you sent? Because my fear of breaking windows-build is the only thing that keeps me from committing it to main. The longer I wait, the more difficult the merging will be (another reason for me to merge scripting/main before committing more stuff to main).

asper · 2013-08-29 12:02:53

Compiling works fine and also executing; i don't know if executing will sto working if i remove the additional dlls and other files anyway this should not be a problem because i always provide them! What about my previous post iso14443a raw command consideration?

holiman · 2013-08-29 12:24:11

@asper, good, then I will try to merge them in the near future.

What about my previous post iso14443a raw command consideration?

About iso1443a raw - that's what I've been trying to get working... My long++ post above is about just that...?? (oh, and sorry for hijacking the thread like this...:))

It is already implemented (by someone else) in the armsrc, I'm experimenting with how to invoke it and I am not getting the results I'm expecting. It's not tied to scripting-branch per se, it's just that it's easier for me to experiment in lua instead of doing it in c, so that's why I'm doing my experimentation in that branch.

holiman · 2013-09-01 19:37:49

Committed as r759

asper · 2013-09-01 21:21:17

Compiled r762 for windows but red led keeps staying on when i use whatever 14443B commands (no tag in the field).... can someone replicate this under linux ? If not the problem seems to be the windows compiled version.

(OT; r761 and r762 versions shiw wrong OS version = r760[/OT])

Last edited by asper (2013-09-01 21:23:09)

holiman · 2013-09-02 11:36:22

@jonor, could you take a look at the red-led thing ?

Regarding the OS version, I'll take a look. But I suspect that it may be some bad mojo with how the build-subversion-magic handles svn branches (r761 and r762 were scripting-branch only).

jonor · 2013-09-03 20:10:04

All commands 14443B not has FpgaWriteConfWord(FPGA_MAJOR_MODE_OFF); and LED_D_OFF(); at end of the functions, it's normal from the first version of firmware.
In my SendRawCommand you can choose if set the signal power to off or continue to hold signal power to on.

asper · 2013-09-03 20:35:17

You are right jonor, removing the -p parameter switchs the led to off.

Can I contact you in private jonor ?

Last edited by asper (2013-09-03 20:35:31)

jonor · 2013-09-04 19:50:29

asper wrote:

(OT; r761 and r762 versions shiw wrong OS version = r760[/OT])

Thats is correct as tell also holiman. The script tools/mkversion.pl take the version from current branch. Revisions in svn are unique for all branches.

asper wrote:

Can I contact you in private jonor ?

Ok you should be receive my private message in other forum.

Last edited by jonor (2013-09-04 19:52:05)

jonor · 2013-09-11 11:56:12

holiman wrote:

Don't know if I made anything clearer, but perhaps. Currently, I don't receive nonces like I think I should, and I'm not sure why.

Maybe I understand the issue, when you send raw data with

local mf_auth = Command:new{cmd = cmds.CMD_READER_ISO_14443a, 
									arg1 = 6, -- Send raw 
									arg2 = string.len(rawdata), 
									data = rawdata}

arg1
6 => 110
Don't disconnect and APDU

You should be send 10 => 1010
Don't disconnect and Raw

Now I can't try it, when I come back to home I will try.

holiman · 2013-09-12 10:11:53

Nice, thanks!

I haven't tested it either, had a bit of computer problems (had to reinstall my os, but didn't lose any data) - did it work?

asper · 2013-09-12 11:37:34

I just tested ISO1444B raw commands and they work flawlessly (with the new antenna) !
Hope to test ISO14443A raw very soon !

EDIT:
In the meantime I am working to the GUI to make some new tags implementation using the new raw functions ! Stay tuned !

Last edited by asper (2013-09-12 11:38:10)

jonor · 2013-09-12 12:16:37

holiman wrote:

I haven't tested it either, had a bit of computer problems (had to reinstall my os, but didn't lose any data) - did it work?

There is another issue, string.len return a wrong len

local mf_auth = Command:new{cmd = cmds.CMD_READER_ISO_14443a,
                                                                        arg1 = 10, -- Send raw
                                                                        arg2 = string.len(rawdata)/2,    
                                                                        data = rawdata}

with these changes I got nonce. But Mifare reply to auth_comand only the first time, other auth commands are ignored, so while loop should be changed.

holiman · 2013-09-12 12:29:46

Wohoo!

Yeah, that while-loop is crap, I just placed it there to be able to test it better, to be able to wait a moment before sending auth - to rule out timing-issues giving me the same nonce every time I tried.

That script is meant as a proof-of-concept and example to build other stuff from, not to really do anything useful.

One remaining problem: from what I can determine, the device does calculate the length of data read from the tag correctly. I don't know why, and right now it seems up to the host to 'know' how many bytes should have been read in a response. That's not so good. Is that an issue for 14443B also, or is it a bug only within 14443A?

asper · 2013-09-12 13:58:02

WOHOHOHO !!!

Now nonce is receive so I think raw for ISO14443A should arrive really soon in the client !

I continue to love you both !!!

I would like to post a "maybe" bug; using raw commands on SRIX4K with the new jonor-suggested small antenna i noticed that the 1st time I try to get the UID (after initiate and select) i always receive only the 1st 3 bytes... sending the command again I obtain the full correct uid... is this a pm3 bug or something similar ?

I attach the new-still-prototype GUI interface for SRIX4K tags:

I hope to have time to add lot of tags so that people can learn how they works !

Last edited by asper (2013-09-12 14:22:36)

jonor · 2013-09-12 20:06:05

holiman wrote:

One remaining problem: from what I can determine, the device does calculate the length of data read from the tag correctly. I don't know why, and right now it seems up to the host to 'know' how many bytes should have been read in a response. That's not so good. Is that an issue for 14443B also, or is it a bug only within 14443A?

Sorry I don't understand very well your problem. You have the length of returned bytes in arg0. PM3 detect this length with End Of Frame.

asper wrote:

i always receive only the 1st 3 bytes... sending the command again I obtain the full correct uid... is this a pm3 bug or something similar ?

I have this problem also with my antenna and PM3, I don't know why. I will try to debug.

holiman · 2013-09-13 07:54:54

holiman wrote:

You have the length of returned bytes in arg0. PM3 detect this length with End Of Frame.

Hmm... are you sure about this ? My testing indicated that the length reported by the device is always 1. More specifically, on the device-side, ReaderReceive() calls GetIso14443aAnswerFromTag() and returns Demod.Len. The Demod.Len, in this scenario, seem to always be '1' (which is then sent back to the host).

I will take another look, perhaps I misunderstood something.

Last edited by holiman (2013-09-13 07:55:25)

jonor · 2013-09-13 08:42:08

holiman wrote:

Hmm... are you sure about this ?

Sure
My output, first comand return 2 byte, auth command return 4 byte. I repeated this test 10 times and I have always the same result.

This script is a work in progress, not yet functional. It is an attempt to use the raw-writing 
capabilities already present within the devices


4
Card select:
CMD_ACK (255)
args : (2, 0, 0)
data:
1518DC7300000000000004040008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Nonce:
CMD_ACK (255)
args : (4, 0, 0)
data:
4C5A44E500000000000004040008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000030FD200030FD20000000000098FD2000000000407F53110030FD20002A00000007010000A55711004650474120696D616765206275696C74206F6E2032303132

holiman wrote:

My testing indicated that the length reported by the device is always 1. More specifically, on the device-side, ReaderReceive() calls GetIso14443aAnswerFromTag() and returns Demod.Len. The Demod.Len, in this scenario, seem to always be '1' (which is then sent back to the host).

Try to recompile your firmware with option -O2 in common/Makefile.common. I will try to recompile with -Os for understand if I have the same problem.

EDIT:
works also with -Os, I don't know because you have always 1.

Last edited by jonor (2013-09-13 08:56:49)

holiman · 2013-09-13 09:00:54

Well, if it works for you then I probably misunderstood something. Perhaps the other errors that were present made me mistake this for a bug. Don't waste any time on this ...

I have a lot of work (real work) in the near future, but hope to get a chance to do some proxmarking sometime within the next week. If things seem alright, I hope to clean up some of the scripts, add a bit-library (for bit-manipulation, OR:ing and AND:ing), possibly add some checks so it alerts if started from another directory than /client (since that will result in pm3 not finding scripts nor dumpfiles), and commit scripting to main.

After that, I would like to produce a few different scripts, primarily one to help with LF-identification. LF is a bit of a gray area for me - I have mostly worked with mifare. It seems to be a hassle to figure out the modulation and decoding, and then it seems that for some tags external tools are needed for the decoding. I would like to make a script which basically 'listens', and tries different variants of lf-operations, demodulations etc until it figures out what the heck that tag is, and what it's saying.

I also hope that a script-section is opened on this forum. (moderators, pretty please..?)

asper · 2013-09-13 09:27:02

Great holiman !
Is it possible to add the ISO14443A raw command in the client before all those beautiful ideas ?
I ask this because, thanks to Gaucho, the GUI now has the possibility to make some "easy script" using the existing pm3 commands and this will be really great to finally have all HF raw capabilities !!

I am just updating the GUI exe and settings !

holiman · 2013-09-13 09:50:08

@asper - it's all already in there. Jonor just now confirmed that it works - the error was just in my script.

Or do you mean implement it as a command-line command? I'd rather see that you wrote scripts in lua rather than scripting the commandline, since scripting the commandline is very limited (what you can do with the data, what output to display, you need to parse output rather than operate on the actual raw data returned from the device, difficult to share basic libraries etc).

holiman · 2013-09-13 09:58:14

Heh, I just checked the other post (http://www.proxmark.org/forum/viewtopic.php?pid=8225#p8225). All of a sudden, pm3-scripting has two meanings - lua-scripting *or* windows-gui scripting. It's fun that the community is active, even though I personally think lua is a more sensible path forward..

Anyway, instead of implementing a command line for send raw, I can make a compromise; how about calling somehting like "script run hfraw.lua -b 0x000DEADBEEF -x -y", which, under the hood, runs the raw-script, which is modified to accept a few parameters? It makes sense to implement parameters for invoking scripts anyway, and making the script accept them if I add support in the lua-integration should be pretty trivial. And besides, it will make the script useful other than being a PoC.

Proxmark3 community

Announcement

#1 2013-08-26 20:32:17

Patch for ISO1444B - send raw command

#2 2013-08-26 20:58:33

Re: Patch for ISO1444B - send raw command

#3 2013-08-26 21:08:44

Re: Patch for ISO1444B - send raw command

#4 2013-08-26 21:21:39

Re: Patch for ISO1444B - send raw command

#5 2013-08-27 07:44:31

Re: Patch for ISO1444B - send raw command

#6 2013-08-27 07:51:53

Re: Patch for ISO1444B - send raw command

#7 2013-08-27 17:17:08

Re: Patch for ISO1444B - send raw command

#8 2013-08-27 17:30:06

Re: Patch for ISO1444B - send raw command

#9 2013-08-27 18:04:51

Re: Patch for ISO1444B - send raw command

#10 2013-08-27 18:36:27

Re: Patch for ISO1444B - send raw command

#11 2013-08-27 19:00:25

Re: Patch for ISO1444B - send raw command

#12 2013-08-28 07:03:02

Re: Patch for ISO1444B - send raw command

#13 2013-08-28 18:34:02

Re: Patch for ISO1444B - send raw command

#14 2013-08-28 20:52:58

Re: Patch for ISO1444B - send raw command

#15 2013-08-29 09:07:26

Re: Patch for ISO1444B - send raw command

#16 2013-08-29 12:02:53

Re: Patch for ISO1444B - send raw command

#17 2013-08-29 12:24:11

Re: Patch for ISO1444B - send raw command

#18 2013-09-01 19:37:49

Re: Patch for ISO1444B - send raw command

#19 2013-09-01 21:21:17

Re: Patch for ISO1444B - send raw command

#20 2013-09-02 11:36:22

Re: Patch for ISO1444B - send raw command

#21 2013-09-03 20:10:04

Re: Patch for ISO1444B - send raw command

#22 2013-09-03 20:35:17

Re: Patch for ISO1444B - send raw command

#23 2013-09-04 19:50:29

Re: Patch for ISO1444B - send raw command

#24 2013-09-11 11:56:12

Re: Patch for ISO1444B - send raw command

#25 2013-09-12 10:11:53

Re: Patch for ISO1444B - send raw command

#26 2013-09-12 11:37:34

Re: Patch for ISO1444B - send raw command

#27 2013-09-12 12:16:37

Re: Patch for ISO1444B - send raw command

#28 2013-09-12 12:29:46

Re: Patch for ISO1444B - send raw command

#29 2013-09-12 13:58:02

Re: Patch for ISO1444B - send raw command

#30 2013-09-12 20:06:05

Re: Patch for ISO1444B - send raw command

#31 2013-09-13 07:54:54

Re: Patch for ISO1444B - send raw command

#32 2013-09-13 08:42:08

Re: Patch for ISO1444B - send raw command

#33 2013-09-13 09:00:54

Re: Patch for ISO1444B - send raw command

#34 2013-09-13 09:27:02

Re: Patch for ISO1444B - send raw command

#35 2013-09-13 09:50:08

Re: Patch for ISO1444B - send raw command

#36 2013-09-13 09:58:14

Re: Patch for ISO1444B - send raw command

Board footer