We have a 3m microtouch display. It's connected to my Debian system via USB and recognized as human interface (hid). I am trying to access and push realtime information... if its getting touched I want to know where (x,y) and pipe it through netcat to another host.
Unfortunately I am only able to get raw data using:
cat /dev/input/event2 | hexdump
or
evtest
You get hexcode that seem nowhere documented...
Does anybody have a clue how to get that information? There must be a way to extract it from the hexcode. Unfortunately I have no idea how to interpret the hexcode. I couldn't find any source where its documented...
Is there a way the Kernel could provide me those desired information in realtime?
As a workaround, is there, maybe, a solution where the X-Server could tell me? The touchscreen behaves like a mouse in X. I actually already tried to get x,y-position of the mouse via xlib. But it was too slow and wouldn't tell me if somebody is touching or not...
evtest sample output:
Event: time 1425319271.595631, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value 51
Event: time 1425319271.595631, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 10304
Event: time 1425319271.595631, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 30629
Event: time 1425319271.595631, type 3 (EV_ABS), code 48 (ABS_MT_TOUCH_MAJOR), value 893
Event: time 1425319271.595631, type 3 (EV_ABS), code 49 (ABS_MT_TOUCH_MINOR), value 414
Event: time 1425319271.595631, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
Event: time 1425319271.595631, type 3 (EV_ABS), code 0 (ABS_X), value 10304
Event: time 1425319271.595631, type 3 (EV_ABS), code 1 (ABS_Y), value 30629
Event: time 1425319271.595631, -------------- SYN_REPORT ------------
Event: time 1425319271.601632, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 10306
Event: time 1425319271.601632, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 30625
Event: time 1425319271.601632, type 3 (EV_ABS), code 48 (ABS_MT_TOUCH_MAJOR), value 962
Event: time 1425319271.601632, type 3 (EV_ABS), code 49 (ABS_MT_TOUCH_MINOR), value 421
Event: time 1425319271.601632, type 3 (EV_ABS), code 47 (ABS_MT_SLOT), value 1
Event: time 1425319271.601632, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value 52
Event: time 1425319271.601632, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 15416
Event: time 1425319271.601632, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 24159
Event: time 1425319271.601632, type 3 (EV_ABS), code 48 (ABS_MT_TOUCH_MAJOR), value 649
Event: time 1425319271.601632, type 3 (EV_ABS), code 49 (ABS_MT_TOUCH_MINOR), value 354
Event: time 1425319271.601632, type 3 (EV_ABS), code 0 (ABS_X), value 10306
Event: time 1425319271.601632, type 3 (EV_ABS), code 1 (ABS_Y), value 30625
Event: time 1425319271.601632, -------------- SYN_REPORT ------------
Event: time 1425319271.606626, type 3 (EV_ABS), code 47 (ABS_MT_SLOT), value 0
Event: time 1425319271.606626, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 10318
Event: time 1425319271.606626, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 30609
Event: time 1425319271.606626, type 3 (EV_ABS), code 48 (ABS_MT_TOUCH_MAJOR), value 1014
Event: time 1425319271.606626, type 3 (EV_ABS), code 49 (ABS_MT_TOUCH_MINOR), value 426
Event: time 1425319271.606626, type 3 (EV_ABS), code 47 (ABS_MT_SLOT), value 1
Event: time 1425319271.606626, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 24161
Event: time 1425319271.606626, type 3 (EV_ABS), code 48 (ABS_MT_TOUCH_MAJOR), value 681
Event: time 1425319271.606626, type 3 (EV_ABS), code 49 (ABS_MT_TOUCH_MINOR), value 376
Event: time 1425319271.606626, type 3 (EV_ABS), code 0 (ABS_X), value 10318
Event: time 1425319271.606626, type 3 (EV_ABS), code 1 (ABS_Y), value 30609
Event: time 1425319271.606626, -------------- SYN_REPORT ------------
Event: time 1425319271.611629, type 3 (EV_ABS), code 47 (ABS_MT_SLOT), value 0
Event: time 1425319271.611629, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 10320
Event: time 1425319271.611629, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 30605
Event: time 1425319271.611629, type 3 (EV_ABS), code 48 (ABS_MT_TOUCH_MAJOR), value 1053
Event: time 1425319271.611629, type 3 (EV_ABS), code 49 (ABS_MT_TOUCH_MINOR), value 430
Event: time 1425319271.611629, type 3 (EV_ABS), code 47 (ABS_MT_SLOT), value 1
Event: time 1425319271.611629, type 3 (EV_ABS), code 48 (ABS_MT_TOUCH_MAJOR), value 705
Event: time 1425319271.611629, type 3 (EV_ABS), code 49 (ABS_MT_TOUCH_MINOR), value 392
Event: time 1425319271.611629, type 3 (EV_ABS), code 0 (ABS_X), value 10320
Event: time 1425319271.611629, type 3 (EV_ABS), code 1 (ABS_Y), value 30605
Console-based solution
You can obtain parsed coordinates using evtest tool.
If you only need single-touch coordinates: look for ABS_X and ABS_Y fields:
type 3 (EV_ABS), code 0 (ABS_X), value 10306
type 3 (EV_ABS), code 1 (ABS_Y), value 30625
If you need multi-touch coordinates:
ABS_MT_SLOT represents number of finger
ABS_MT_POSITION_X and ABS_MT_POSITION_Y -- coordinates
Finger #0:
type 3 (EV_ABS), code 47 (ABS_MT_SLOT), value 0
type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 10318
type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 30609
Finger #1:
type 3 (EV_ABS), code 47 (ABS_MT_SLOT), value 1
type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 20301
type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 24161
For example, if you need to send single-touch coordinates via network, you can use script like this:
#!/bin/sh
# ---- Global variables ----
input=/dev/input/event0
code_prefix="ABS"
code="${code_prefix}_[XY]"
val_regex=".*(${code_prefix}_\(.\)), value \([-]\?[0-9]\+\)"
val_subst="\1=\2"
# ---- Functions ----
send_axis() {
# 1. Convert axis value ($1) from device specific units
# 2. Send this axis value via UDP packet
echo $1
}
process_line() {
while read line; do
axis=$(echo $line | grep "^Event:" | grep $code | \
sed "s/$val_regex/$val_subst/")
if [ -n "$axis" ]; then
send_axis $axis
fi
done
}
# ---- Entry point ----
if [ $(id -u) -ne 0 ]; then
echo "This script must be run from root" >&2
exit 1
fi
evtest $input | process_line
Program-based solution
You can write C application that will read your event file. Obtained binary data can be easily interpreted, see section 5 in kernel documentation.
You can wait for next data portion using select() syscall.
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <linux/input.h>
/* Change it to your dev file for the touch screen */
#define EVENT_DEVICE "/dev/input/event2"
#define EVENT_TYPE EV_ABS
#define EVENT_CODE_X ABS_X
#define EVENT_CODE_Y ABS_Y
/* TODO: Close fd on SIGINT (Ctrl-C), if it's open */
static int fd = -1;
int main(int argc, char *argv[])
{
struct input_event ev;
char name[256] = "Unknown";
fd_set readfds;
/* /dev/input/event* files are only readable by root:input */
if ((getuid()) != 0) {
fprintf(stderr, "You are not root! This may not work...\n");
return EXIT_SUCCESS;
}
/* Open device for non-blocking read */
fd = open(EVENT_DEVICE, O_RDONLY | O_NONBLOCK);
if (fd == -1) {
fprintf(stderr, "%s is not a vaild device\n", EVENT_DEVICE);
return EXIT_FAILURE;
}
/* Print device name */
ioctl(fd, EVIOCGNAME(sizeof(name)), name);
printf("Reading from:\n");
printf(" - device file: %s\n", EVENT_DEVICE);
printf(" - device name: %s\n", name);
/* Prepare for select(): zero and set the fd into fd_set */
FD_ZERO(&readfds);
FD_SET(fd, &readfds);
/* Press Ctrl-C to stop the program */
for (;;) {
const size_t ev_size = sizeof(struct input_event);
ssize_t size;
int ret;
/* struct timeval timeout = { 30, 0 }; */
/*
* select(): no-timeout version, just stop on errors or
* interrupts.
*/
ret = select(fd + 1, &readfds, NULL, NULL, NULL);
/*
* select(): timeout-enabled version, stop if no event has
* occurred until timeout; might be useful e.g. for background
* tasks.
*/
/* ret = select(fd + 1, &readfds, NULL, NULL, &timeout); */
if (ret == -1) {
perror("Error: select() failed");
goto err;
} else if (ret == 0) {
fprintf(stderr, "Error: select() timeout\n");
continue;
}
size = read(fd, &ev, ev_size);
if (size < ev_size) {
fprintf(stderr, "Error: Wrong size when reading\n");
goto err;
}
if (ev.type == EVENT_TYPE && (ev.code == EVENT_CODE_X
|| ev.code == EVENT_CODE_Y)) {
/* TODO: convert value to pixels */
printf("%s = %d\n", ev.code == EVENT_CODE_X ? "X" : "Y",
ev.value);
}
}
return EXIT_SUCCESS;
err:
close(fd);
return EXIT_FAILURE;
}
Coordinates units
First of all you need to know next things:
where is coordinates origin point (i.e. [x=0;y=0])
which units your device is using for representing coordinates
This information usually can be found in driver code for your device.
This is the driver for your device.
So it seems like you need to divide your axis value from evtest by 65535 and multiply it by width or height of device (in pixels). For example, if you get X=30000, and width of your LCD panel is 1080 pixels, you need to do:
X = round((30000 / 65535) * 1080) = 494 pixels
You get hexcode that seem nowhere documented...
This is documented by the device itself, which is how the hid-multitouch driver can interpret the USB data it receives.
You can find the information using the following commands:
$ lsusb # determine the bus & device numbers
...
Bus 001 Device 067: ID 1aad:000f KeeTouch
...
$ sudo usbhid-dump -a 1:67 -e d
001:067:002:DESCRIPTOR 1615651625.434241
05 0D 09 04 A1 01 85 03 09 22 09 00 15 00 26 FF
00 75 08 95 09 81 02 A1 00 05 0D 09 51 15 00 26
FF 00 75 08 95 01 81 02 05 0D 09 42 15 00 25 01
75 01 95 01 81 02 09 32 81 02 09 47 81 02 95 05
81 03 05 01 09 30 26 FF 7F 55 00 65 00 35 00 46
00 00 75 10 95 01 81 02 09 31 35 00 46 00 00 81
02 05 0D 09 48 15 00 26 FF 7F 75 10 95 01 81 02
09 49 15 00 26 FF 7F 75 10 95 01 81 02 C0 A1 00
05 0D 09 51 15 00 26 FF 00 75 08 95 01 81 02 05
0D 09 42 15 00 25 01 75 01 95 01 81 02 09 32 81
02 09 47 81 02 95 05 81 03 05 01 09 30 26 FF 7F
55 00 65 00 35 00 46 00 00 75 10 95 01 81 02 09
31 35 00 46 00 00 81 02 05 0D 09 48 15 00 26 FF
7F 75 10 95 01 81 02 09 49 15 00 26 FF 7F 75 10
95 01 81 02 C0 A1 00 05 0D 09 51 15 00 26 FF 00
75 08 95 01 81 02 05 0D 09 42 15 00 25 01 75 01
95 01 81 02 09 32 81 02 09 47 81 02 95 05 81 03
05 01 09 30 26 FF 7F 55 00 65 00 35 00 46 00 00
75 10 95 01 81 02 09 31 35 00 46 00 00 81 02 05
0D 09 48 15 00 26 FF 7F 75 10 95 01 81 02 09 49
15 00 26 FF 7F 75 10 95 01 81 02 C0 A1 00 05 0D
09 51 15 00 26 FF 00 75 08 95 01 81 02 05 0D 09
42 15 00 25 01 75 01 95 01 81 02 09 32 81 02 09
47 81 02 95 05 81 03 05 01 09 30 26 FF 7F 55 00
65 00 35 00 46 00 00 75 10 95 01 81 02 09 31 35
00 46 00 00 81 02 05 0D 09 48 15 00 26 FF 7F 75
10 95 01 81 02 09 49 15 00 26 FF 7F 75 10 95 01
81 02 C0 A1 00 05 0D 09 51 15 00 26 FF 00 75 08
95 01 81 02 05 0D 09 42 15 00 25 01 75 01 95 01
81 02 09 32 81 02 09 47 81 02 95 05 81 03 05 01
09 30 26 FF 7F 55 00 65 00 35 00 46 00 00 75 10
95 01 81 02 09 31 35 00 46 00 00 81 02 05 0D 09
48 15 00 26 FF 7F 75 10 95 01 81 02 09 49 15 00
26 FF 7F 75 10 95 01 81 02 C0 A1 00 05 0D 09 54
15 00 25 1F 75 08 95 01 81 02 C0 09 55 85 FD 15
00 26 FF 00 75 08 95 01 B1 02 C0 05 0D 09 0E A1
01 85 FC 09 52 09 53 15 00 26 FF 00 75 08 95 02
B1 02 C0
001:067:001:DESCRIPTOR 1615651625.436655
05 01 09 02 A1 01 85 02 09 01 A1 00 06 00 FF 09
00 15 00 26 FF 00 75 08 95 09 81 02 05 01 09 30
09 31 15 00 26 FF 7F 75 10 95 02 81 02 05 09 19
01 29 08 15 00 25 01 95 08 75 01 81 02 C0 C0
001:067:000:DESCRIPTOR 1615651625.437001
06 00 FF 09 00 A1 01 09 00 85 01 A1 00 09 00 15
00 26 FF 00 35 00 46 FF 00 75 08 95 3F 81 02 C0
09 02 85 FE A1 00 09 06 15 00 26 FF 00 35 00 46
FF 00 75 08 95 3F B1 02 C0 C0
I use the lsusb command to determine the bus and device numbers and pass that to the usbhid-dump command. You can use the dump command without those numbers, but then you get a list of all your devices. Probably not what you want in most cases.
The codes in there are interpreted by the hid_parser() command in the kernel. Only some devices may not be properly recognized and that's when you need this information.
How to interpret that data is defined by the USB consortium. At this time, it is version 1.11 and it can be found on this page for the hid type of devices.
This mainly includes Keyboards, Mice, Touchscreens, Touchpads, Joysticks, although some other types of devices support this too (your Power button, various buttons on your monitor, etc.)
Related
Does JCOP/J3A081 support int data type?
I am using latest eclipse JCOP tools for java card applet development. I need to store big integer values in a card so I have used the INTEGER data type (int) for balance in my applet. it is compiling without any error but getting error 6A80 on uploading the CAP file into JCOP J3A081 cards. I have tried all combinations of GP 2.1.1, GP 2.2.1, JDK 2.2.2, JDK 3.0.4 library but getting the same error.
Are int data type variables and JCint library supported by J3A/J2A series cards? if yes how to resolve the issue?
Applet source code:
Note: if I remove int data type variable and JCint references then no error comes.
- version
current version is 5.32.0.4 [1]
build timestamp is 27-01-2020 12:10:53
- /terminal
--Opening terminal
Session ID: 6527B91D44DD89CDE6AB60FCA590DF06
> /list-readers
----------------------
Name ( Type )
----------------------
> /card -v
Warning: Usage of /atr with no preceding of /reset is deprecated. /reset is invoked.
IOCTL().
ATR: 3B89800150565F4A334130383150
ATR:
Hist = PV_J3A081
T = 0
T = 1
=> 00 A4 04 00 00 .....
(12493 usec [SYS])
<= 6F 65 84 08 A0 00 00 00 03 00 00 00 A5 59 9F 65 oe...........Y.e
01 FF 9F 6E 06 47 91 00 78 34 00 73 4A 06 07 2A ...n.G..x4.sJ..*
86 48 86 FC 6B 01 60 0C 06 0A 2A 86 48 86 FC 6B .H..k.`...*.H..k
02 02 01 01 63 09 06 07 2A 86 48 86 FC 6B 03 64 ....c...*.H..k.d
0B 06 09 2A 86 48 86 FC 6B 04 02 15 65 0B 06 09 ...*.H..k...e...
2B 85 10 86 48 64 02 01 03 66 0C 06 0A 2B 06 01 +...Hd...f...+..
04 01 2A 02 6E 01 02 90 00 ..*.n....
Status: No Error
FCI Data:
Max. Block Length: 255
CPLC Data:
Operating System ID : 4791
Operating System release date : 0078 (18.3.20X0)
Operating System release level : 3400
Security Domain Management Data:
Global Platform Version: 2.1.1
Secure Channel Protocol: 02 (option 15)
cm> /identify
FABKEY ID: 0x02
PATCH ID: 0x21
TARGET ID: 0x00 (null)
MASK ID: 0x34 (52)
CUSTOM MASK: 00000000
MASK NAME: NX011D
FUSE STATE: fused
ROM INFO: 58E957
COMBO NAME: null-m34.02.21-NX011D
cm> get-cplc -v
=> 80 CA 9F 7F 00 .....
(8475 usec [SYS])
<= 9F 7F 2A 47 90 51 68 47 91 00 78 34 00 31 30 04 ..*G.QhG..x4.10.
81 33 96 75 18 48 12 31 37 00 00 00 00 0F 20 38 .3.u.H.17..... 8
34 38 31 33 33 00 00 00 00 00 00 00 00 90 00 48133..........
Status: No Error
IC Fabricator : 4790
IC Type : 5168
Operating System ID : 4791
Operating System release date : 0078 (18.3.20X0)
Operating System release level : 3400
IC Fabrication Date : 3130 (10.5.2003)
IC Serial Number : 04813396
IC Batch Identifier : 7518
IC Module Fabricator : 4812
IC Module Packaging Date : 3137 (17.5.2003)
ICC Manufacturer : 0000
IC Embedding Date : 0000
IC Pre-Personalizer : 0F20
IC Pre-Perso. Equipment Date : 3834
IC Pre-Perso. Equipment ID : 38313333
IC Personalizer : 0000
IC Personalization Date : 0000
IC Perso. Equipment ID : 00000000
cm> /cap-info "C:\Users\pp\eclipse-workspace\testJCOP\bin\com\pryogika\jc\javacard\jc.cap"
CAP file name : C:\Users\pp\eclipse-workspace\testJCOP\bin\com\pryogika\jc\javacard\jc.cap
CAP file version : 2.2
Java package name : com.pryogika.jc
Internal pkg. name : com/pryogika/jc
CAP file components :
Header.cap (38 Bytes)
Directory.cap (36 Bytes)
Import.cap (36 Bytes)
Applet.cap (22 Bytes)
Class.cap (17 Bytes)
Method.cap (82 Bytes)
StaticField.cap (13 Bytes)
ConstantPool.cap (41 Bytes)
RefLocation.cap (16 Bytes)
Descriptor.cap (90 Bytes)
Debug.cap (500 Bytes)
Integer support : yes
Package version : 1.0
Package AID : "HelloJCOP"
Import AIDs :
A0000000620101 (javacard.framework) version 1.3
A00000006202080101 version 1.0
A0000000620001 (java.lang) version 1.0
Applet AIDs :
"HelloJCOPApplet"
Code size to load : 301 bytes
Code size on card :
pkgAID : 9
applet AIDs : 22
classes : 17
methods : 82
statics : 0
exports : 0
-------------------------------------
overall : 130 bytes
SHA-256 (Load File data): FD9E6BDB25A9C863B83C1ECE829F66DBEAA64B38BF5CD4EA953651B110AAD209
SHA-256 (Load File dbg) : 07F25D2E0A470C0AFECCADEF1387986D70C71606E33DD339ED89F4CE1CA84467
SHA-256 (Load File) : CE72441BF5B56BB36A4AEBE3F3A96725D0A36926697B9187C3873C3437CBEAA4
SHA-1 (Load File data): C5EFC5FAAE4FB711E327F5563C48888EA56F81D5
SHA-1 (Load File dbg) : 41264E6C8F21F1C46F2BE7EBCF70CAE00624A277
SHA-1 (Load File) : EB826D7E56AFF5AAF4C4CD3FC4FB5850DD81D91F
DAP block(s) : none
Load Token(s) : none
Install Token(s) : none
Delete Token(s) : none
cm> set-key 1/1/DES-ECB/404142434445464748494a4b4c4d4e4f 1/2/DES-ECB/404142434445464748494a4b4c4d4e4f 1/3/DES-ECB/404142434445464748494a4b4c4d4e4f
cm> init-update
=> 80 50 00 00 08 11 A9 0F 67 2B 22 B6 E1 00 .P......g+"...
(37691 usec [SYS])
<= 00 00 31 30 04 81 33 96 75 18 01 02 00 3E 60 17 ..10..3.u....>`.
08 B3 12 20 F1 76 A5 F1 D0 6D 12 BD 90 00 ... .v...m....
Status: No Error
cm> ext-auth plain
=> 84 82 00 00 10 3F BE FC 67 E2 96 5E DF A7 85 B1 .....?..g..^....
9C CF C3 A4 F2 .....
(42458 usec [SYS])
<= 90 00 ..
Status: No Error
cm> card-info
=> 80 F2 80 00 02 4F 00 00 .....O..
(8862 usec [SYS])
<= 08 A0 00 00 00 03 00 00 00 07 9E 90 00 .............
Status: No Error
=> 80 F2 40 00 02 4F 00 00 ..#..O..
(7220 usec [SYS])
<= 6A 88 j.
Status: Reference data not found
=> 80 F2 10 00 02 4F 00 00 .....O..
(8838 usec [SYS])
<= 6A 88 j.
Status: Reference data not found
Card Manager AID : A000000003000000
Card Manager state : INITIALIZED
cm> upload -b 250 "C:\Users\pp\eclipse-workspace\testJCOP\bin\com\pryogika\jc\javacard\jc.cap"
=> 80 E6 02 00 16 09 48 65 6C 6C 6F 4A 43 4F 50 08 ......HelloJCOP.
A0 00 00 00 03 00 00 00 00 00 00 00 ............
(13758 usec [SYS])
<= 00 90 00 ...
Status: No Error
=> 80 E8 00 00 FA C4 82 01 2D 01 00 23 DE CA FF ED ........-..#....
02 02 05 00 01 09 48 65 6C 6C 6F 4A 43 4F 50 0F ......HelloJCOP.
63 6F 6D 2F 70 72 79 6F 67 69 6B 61 2F 6A 63 02 com/pryogika/jc.
00 21 00 23 00 21 00 13 00 21 00 26 00 0E 00 4F .!.#.!...!.&...O
00 0A 00 0D 00 00 00 57 00 00 00 00 00 00 00 00 .......W........
03 01 00 04 00 21 03 03 01 07 A0 00 00 00 62 01 .....!........b.
01 00 01 09 A0 00 00 00 62 02 08 01 01 00 01 07 ........b.......
A0 00 00 00 62 00 01 03 00 13 01 0F 48 65 6C 6C ....b.......Hell
6F 4A 43 4F 50 41 70 70 6C 65 74 00 08 06 00 0E oJCOPApplet.....
00 00 00 80 03 00 FF 00 07 01 00 00 00 1C 07 00 ................
4F 00 01 10 18 8C 00 00 7A 05 30 8F 00 01 3D 8C O.......z.0...=.
00 02 18 1D 04 41 18 1D 25 8B 00 03 7A 04 23 18 .....A..%...z.#.
8B 00 04 60 03 7A 19 8B 00 05 2D 1A 04 25 73 00 ...`.z....-..%s.
1B 00 00 00 00 00 09 12 0A 36 1A 08 23 8D 00 06 .........6..#...
3B 19 08 07 8B 00 07 70 08 11 6D 00 8D 00 08 7A ;......p..m....z
08 00 0A 00 00 00 00 00 00 00 00 00 00 05 00 00 ................
(25820 usec [SYS])
<= 6A 80 j.
Status: Wrong data
jcshell: Error code: 6a80 (Wrong data)
jcshell: Wrong response APDU: 6A80
cm> /list-v
Global:____________________________________________
SESSION.ID=0FA5DF09FC02F2276D5A113D1591EE7C
cap.applet.aids=48656C6C6F4A434F504170706C6574
cap.package.aid=48656C6C6F4A434F50
exec.dir=C:\Users\pp\Desktop
jcop.v242=false
last.apdu.executiontime=25.717
last.apdu.executiontime.unit=msec
last.executiontime=52.0
last.executiontime.unit=msec
last.response.status=6a80
logfile.list=
cm> card-info
=> 80 F2 80 00 02 4F 00 00 .....O..
(17196 usec [SYS])
<= 08 A0 00 00 00 03 00 00 00 07 9E 90 00 .............
Status: No Error
=> 80 F2 40 00 02 4F 00 00 ..#..O..
(20679 usec [SYS])
<= 6A 88 j.
Status: Reference data not found
=> 80 F2 10 00 02 4F 00 00 .....O..
(8299 usec [SYS])
<= 6A 88 j.
Status: Reference data not found
Card Manager AID : A000000003000000
Card Manager state : INITIALIZED
No, these cards have not supported the int type. For full certainty simply ask for the data sheet or user's manual from NXP, and if it is not in there, ask them directly.
If you want to support bigger data types then this is of course possible, but you'll have to program it yourself. In that case the fact that objects are stored in persistent memory will of course not be of any help, but it can be done.
Otherwise: it depends on what kind of integer support you require. Just addition or subtraction is very easy to implement yourself on a byte-by-byte base. For cryptographic purposes you may need to look a lot deeper. Sometimes you can also use existing API's such as DH key agreement to perform e.g. modular exponentiation. There are for instance libraries to perform Elliptic Curve calculations (which require big integer).
I use 'socat TCP4-LISTEN:8080,fork EXEC:./bashttpd' for http server. when try to receive image file from client socat remove some byte and corrupt my image.
correct:
01b0 0a 89 50 4e 47 0d 0a 1a 0a 00 00 00 0d 49 48 44 ..PNG........IHD
01c0 52 00 00 07 80 00 00 04 38 08 02 00 00 00 67 b1 R.......8.....g.
01d0 56 14 00 00 00 09 70 48 59 73 00 00 11 b0 00 00 V.
incorrect:(socat -> read line -> xxh)
00000000: 89 50 4e 47 0d 0a .PNG..
00000000: 1a 0a ..
00000000: 0d 49 48 44 52 07 80 04 38 08 02 67 b1 56 14 09 .IHDR...8..g.V
how to solve this problem?
thanks
I have a Java Card with an applet installed on it that returns the following response when I send 00 40 00 00 to it:
Connect successful.
Send: 00 40 00 00
Recv: 61 32
Time used: 15.000 ms
Send: 00 C0 00 00 32
Recv: 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 90 00
Time used: 15.000 ms
The tool that I use (PyAPDUTool), have an option labeled "Auto Get Response". When I check this option, I don't need to send Get Response command (00 c0 00 00 32) anymore:
Send: 00 40 00 00
Recv: 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 90 00
Time used: 15.000 ms
Okay. Now I want to have the above behavior on another Java Card. So I wrote the following program:
package testPrjPack;
import javacard.framework.*;
public class TestPrj extends Applet
{
public static byte[] data = {(byte)0x01 ,(byte)0x02 ,(byte)0x03 ,(byte)0x04 ,(byte)0x05 ,(byte)0x06 ,(byte)0x07 ,(byte)0x08 ,(byte)0x09 ,(byte)0x0A ,(byte)0x0B ,(byte)0x0C ,(byte)0x0D ,(byte)0x0E ,(byte)0x0F ,(byte)0x10 ,(byte)0x11 ,(byte)0x12 ,(byte)0x13 ,(byte)0x14 ,(byte)0x15 ,(byte)0x16 ,(byte)0x17 ,(byte)0x18 ,(byte)0x19 ,(byte)0x1A ,(byte)0x1B ,(byte)0x1C ,(byte)0x1D ,(byte)0x1E ,(byte)0x1F ,(byte)0x20 ,(byte)0x21 ,(byte)0x22 ,(byte)0x23 ,(byte)0x24 ,(byte)0x25 ,(byte)0x26 ,(byte)0x27 ,(byte)0x28 ,(byte)0x29 ,(byte)0x2A ,(byte)0x2B ,(byte)0x2C ,(byte)0x2D ,(byte)0x2E ,(byte)0x2F ,(byte)0x30 ,(byte)0x31 ,(byte)0x32};
public static void install(byte[] bArray, short bOffset, byte bLength)
{
new TestPrj().register(bArray, (short) (bOffset + 1), bArray[bOffset]);
}
public void process(APDU apdu)
{
if (selectingApplet())
{
return;
}
byte[] buf = apdu.getBuffer();
switch (buf[ISO7816.OFFSET_INS])
{
case (byte)0x40:
ISOException.throwIt((short)0x6132);
break;
case (byte)0xC0:
Util.arrayCopyNonAtomic(data,(short)0, buf, (short)0, (short)0x32);
apdu.setOutgoingAndSend((short)0,(short)0x32);
break;
default:
ISOException.throwIt(ISO7816.SW_INS_NOT_SUPPORTED);
}
}
}
After installing the .cap file on the new Java Card, I have the following response for both Auto Get Response option checked and unchecked:
As you see above, the Auto Get Response doesn't work anymore and I need to send Get Response command manually.
I'm curious to know what is wrong with this tool or my program? Is the issue related to the communication protocol? (The first card working with T=0 and the second one working with T=1).
Nothing is wrong. T=1 just doesn't use GET RESPONSE at all, so there is no reason for Python to handle it automatically.
Important: note that Java Card also handles the GET RESPONSE automatically, so you should never have to implement it explicitly.
For example: How would one decode the following ethernet frame?
00 26 b9 e8 7e f1 00 12 f2 21 da 00 08 00 45 00 05 dc e3 cd 20 10 35 06 25 eb 0a 0a 0a 02 c0 a8 01 03 c3 9e 0f 40 00 00 10 00 00 00 14 00 70 10 00 5c 59 99 00 00 02 04 05 b4 01 03 03 06 00 00 01 98 64 34 e8 90 84 98 20 12 18 19 04 85 80 00
I know that the first 6 bytes are the MAC destination address : 00 26 b9 e8 7e f1 The next 6 bytes are the source MAC address : 00 12 f2 21 da 00 The next 2 bytes show the ethernet type : 08 00 The next 4 bytes are : 45 00... Ipv4... "5" the number of bytes in the header.. and "00" means there are no differentiated services.
What I don't know is what anything after that is or how to read it.
Anyone help?
Rearranging a bit your packet, we have:
00 26 b9 e8 7e f1 00 12 f2 21 da 00 08 00 45 00
05 dc e3 cd 20 10 35 06 25 eb 0a 0a 0a 02 c0 a8
01 03 c3 9e 0f 40 00 00 10 00 00 00 14 00 70 10
00 5c 59 99 00 00 02 04 05 b4 01 03 03 06 00 00
01 98 64 34 e8 90 84 98 20 12 18 19 04 85 80 00
If you know that the first 6 octets form the destination mac address, that means that it is an Ethernet layer 2 packet.
According to IEEE 802.3, $3.1.1:
First 6 octets are the destination mac address (00 26 b9 e8 7e f1)
Next 6 octets are the source mac address (00 12 f2 21 da 00)
Next 4 octets are, optionally the 802.1Q tag (present, 08 00 45 00)
Next 2 octets are either:
Maximum payload size - aka MTU (if <= 1500, which is the case, 05 dc is 1500)
Ethernet 2 frame (if >= 1536)
Next is the payload ranging from 46 octets (if the 802.1Q tag is absent) or 42 octets (if the 802.1Q tag is present) to up to 1500 octets (starts at e3 cd 20 10 ..., ends either at 20 12 18 19 or at 03 06 00 00, depends on the 7th item)
Last 4 octets form the CRC32 code (either 01 98 64 34 or 04 85 80 00, depending on the 7th item)
There is also 12 octets used for padding (random - not so random - bytes), that may or may not be inserted in this packet. (if inserted, the padding is e8 90 84 98 20 12 18 19 04 85 80 00)
I am trying to write a tcp server to get the data from Heacent 908 GPS tracker. After establishing the connection from the tracker I am getting the following buffer output.
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 06 64 be 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 06 64 be 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 06 64 be 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 06 64 be 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 06 64 be 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 06 64 be 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 06 64 be 0d 0a>
I am not sure how to decode this data into proper readable format.
Note: Off course I have tried to reach the manufacture but they are not responding at all.
What type of possible encoding formats are there for TCP protocol?
On next day I got data like this
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 07 75 37 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 07 75 37 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 07 75 37 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 07 75 37 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 07 75 37 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 07 75 37 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 07 75 37 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 07 75 37 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 07 75 37 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a>
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a>
<Buffer 78 78 1f 12 0e 02 14 13 01 14 c8 03 5f a6 50 07 f7 f8 c1 32 35 39 01 9a 04 0f a2 00 b0 5a 00 1a 9b 7a 0d 0a>
<Buffer 78 78 1f 12 0e 02 14 13 01 1e c8 03 5f ad bc 07 f7 f0 76 41 35 40 01 9a 04 0f a2 00 b0 5a 00 1b b6 31 0d 0a>
Something is being changed but not sure what is it...
You ask what possible encoding formats there are for TCP. That's a bit of an odd question: there are an unbounded number of encoding formats using TCP as the underlying protocol. But no matter, we can try to figure out this one!
You've posted some sample messages. Let's see if we can translate them:
byte 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
rev 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
----------------------------------------------------------
hex 78 78 0d 01 03 87 11 31 20 86 48 42 00 06 64 be 0d 0a
text x x \r -- -- -- -- 1 -- H B -- -- d -- \r \n
dec 13 1 3 17 0 6 100 13 10
be32 [218170247] [288432262] [ 419006]
----------------------------------------------------------
hex 78 78 0d 01 03 87 11 31 20 86 48 42 00 07 75 37 0d 0a
text -- u 7
dec 7 117 55
be32 [ 488759]
----------------------------------------------------------
hex 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a
text -- -- --
dec 8 141
be32 [ 560576]
----------------------------------------------------- byte 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35
hex 78 78 1f 12 0e 02 14 13 01 14 c8 03 5f a6 50 07 f7 f8 c1 32 35 39 01 9a 04 0f a2 00 b0 5a 00 1a 9b 7a 0d 0a
text -- -- -- -- -- -- -- -- -- -- _ -- P -- -- -- -- 2 5 9 -- -- -- -- -- -- -- -- -- xx -- z \r \n
----------------------------------------------------------
hex 78 78 1f 12 0e 02 14 13 01 1e c8 03 5f ad bc 07 f7 f0 76 41 35 40 01 9a 04 0f a2 00 b0 5a 00 1b b6 31 0d 0a
text -- -- -- A 5 # -- xx -- 1
Some potentially interesting facts:
Starts with "xx\r\01" which more or less seems like a possible header. But later messages start with "xx" and something else. Anyway, given that NMEA has a prefix of "GP" I wouldn't be shocked if these devices used "xx" for "something that's not NMEA."
Has "HB" in the middle, which could mean "heartbeat" since this is repeating, perhaps waiting for a reply from the server.
Ends with "\r\n" which is a common line ending (on Windows in particular), though the rest doesn't appear to be entirely textual.
The earlier messages are 18 bytes long and the later ones 36 bytes. A guess would be the short ones are status updates or heartbeats and the long ones are actual location information. 36 bytes is enough if we figure:
4 byte latitude: 24 bits if you pinch (see), 25-32 bits more likely
4 byte longitude: same as latitude
6 byte timestamp: 39 bits if using epoch time with centiseconds, 32/48/64 bits more likely
2 byte altitude: I suspect this device doesn't publish altitude at all, given some of the docs
So I think what is going on is that these messages you see are just the device "pinging" the server and waiting for a response. What sort of response? Well, you could try to brute force it, but far, far easier would be to set up a bridge in your program that takes whatever it receives from the device, sends it to the manufacturer's server, and does the same thing in reverse for the responses to the device. This way you will quickly be able to gather a corpus of valid messages which will be very helpful if we really do need to reverse engineer this thing. Or if you're lucky it will turn out to use some standard protocol like NMEA after negotiating the initial session.
Edit: now that you've given us more messages from the device, we can see that it does seem to send something else with variable content. Maybe that's the location data, but I don't have time to try to reverse engineer it right now. One idea is to physically move the unit from west to east or north to south and capture the messages it sends during that time, to try to isolate which parts of the messages are the longitude and which are the latitude (and perhaps timestamp too).
I think it's fairly clear that the first two bytes are "xx" as a header, and the last two are "\r\n" as a terminator. That leaves 32 bytes of payload in the longer messages, all of which appears to be binary data.
It's the GT06 protocol and you can find it's specs here:
http://www.traccar.org/devices/
http://www.traccar.org/docs/protocol.jsp
https://dl.dropboxusercontent.com/s/sqtkulcj51zkria/GT06_GPS_Tracker_Communication_Protocol_v1.8.1.pdf
You can do it this way:
client.on('data', (buffer) => {
const decodedData = buffer.toString('utf8')
console.log(decodedData)
})