Request => 00 A4 00 00 02 7FF0 00
Response<= 00 00 00 00 7F F0 02 00 00 00 00 00 13 33 01 15
TAG_OPERATION (10017), Length: 4, Data: 02 00 00 00
TAG_OBJECT_ID (10018), Length: 27, Data:
TAG_TOP (65001001), Length: 21, Data:
TAG_ELEMENT (65001002), Length: 15, Data:
TAG_ARRAY (1001b), Length: 10, Data:
TAG_SYSCONFIG (1001e), Length: 5, Data:
TAG_GENERAL_CONFIG (102a0), Length: 0, Data:
TAG_CONSTRAINT (10019), Length: 24, Data:
TAG_DATA (1001a), Length: 19, Data:
TAG_GENERAL_CONFIG (102a0), Length: 14, Data:
TAG_BOOLEAN (10072), Length: 9, Data:
TAG_STATS_LOGGING (102a6), Length: 4, Data: 00 00 00 00 ""
10/13/2015 06:04:09.196: NAVICIMOM
hr = 0x0
time to complete: 62 msec
<--- Last TLD Request Repeated --->
10/13/2015 06:25:04.259: NAVICIMOM
Please refer to GSM11.11 specification.
Request:
00 CLASS = USIM
A4 = SELECT Command
00 00 = P1 P2
02 = Length
7FF0 = File ID
Response also defined in GSM11.11 Section 9.2.1. basically its saying the id is 7FF0. 02 means its a DF (Folder). something seams wrong with the "13" as this should be the length of the data to follow.
the 01 should mean this directory has 1 sub-directory and the 15 should mean it has 0x15 files within it.
Related
I have written a program to use an external (wireless) numpad as an input device for gaming. I am using NUMPAD0, NUMPAD. and ENTER for the modifier keys shift, ctrl and alt respectively and I've keymapped the rest of the numpad keys to WASD and some other keys. I've setup a LowLevelKeyboardProc to intercept and eat the "real" input of the numpad and send a custom WM_MESSAGE to my application's Windows Message loop to then send the keymapped "new" input via SendInput (using the scan codes of the keys I want to simulate).
This all works fine and as expected. Except for the left shift key:
Whenever I press NUMPAD0, which is mapped to left shift, not only the correct scan code 0x2A = 42 is send, but also another key with scan code 0x022a = 554. This seems like some sort of flag in bit #9, since 554 is 42 + 2^9, but I can find any documentation on this.
I've read about extended 2-byte scan codes with prefix 0xE0, but not 0x02 as in this case. This also only happens with the simulated shift key; ctrl and alt a behaving just fine.
Relevant parts of both the keyboard hook and the windows messaging stuff:
LowLevelKeyboardProc:
LPWSTR convertToHex(LPBYTE in, size_t size_in_Bytes)
{
std::stringstream tempS;
tempS << std::hex;
for(int i = 0; i<size_in_Bytes; i++)
{
tempS << std::setfill('0') << std::setw(2) << int(in[i]) << " ";
}
std::string tempString = tempS.str();
std::wstring tempW(tempString.begin(), tempString.end());
LPWSTR out= (LPWSTR) malloc((tempW.size()+2)* sizeof(WCHAR));
StringCbCopyW(out, tempW.size()* sizeof(WCHAR), tempW.c_str());
return out;
}
LRESULT CALLBACK LowLevelKeyboardProc(__in int nCode, __in WPARAM wParam, __in LPARAM lParam)
{
KBDLLHOOKSTRUCT *key=(KBDLLHOOKSTRUCT *)lParam;
wchar_t tempString[128];
LPWSTR hexOut = convertToHex((LPBYTE) key , sizeof(KBDLLHOOKSTRUCT));
StringCbPrintfW(tempString, sizeof(tempString), L"HEX: %s \n", hexOut);
OutputDebugStringW(tempString);
free(hexOut);
//if(key->scanCode > 0xFF)
// return -1; //ignore strange scancode
if(nCode==HC_ACTION)
{
if(isNumpad)
{
auto it = KeyMap.find(key->scanCode);
if(it != KeyMap.end())
{
PostMessage(hwndMain, WM_MY_KEYDOWN, (key->flags & 128), it->first);
StringCbPrintfW(tempString, sizeof(tempString), L"Intercept Key, VK: %d, scan: %d, flags: %d, time: %d, event: %d \n", key->vkCode, key->scanCode, key->flags, key->time, wParam);
OutputDebugStringW(tempString);
return -1;
}
}
}
// delete injected flag
//UINT mask = (1<<4);
//if(key->flags & mask)
// key->flags ^= mask;
//key->scanCode = MapVirtualKey(key->vkCode, MAPVK_VK_TO_VSC);
StringCbPrintfW(tempString, sizeof(tempString), L"Output key: VK: %d, scan: %d, flags: %d, time: %d, event: %d \n", key->vkCode, key->scanCode, key->flags, key->time, wParam);
OutputDebugStringW(tempString);
return CallNextHookEx(hhkHook,nCode,wParam,lParam);
}
Windows Message stuff:
case WM_MY_KEYDOWN:
{
DWORD OLD_KEY = lParam;
DWORD NEW_KEY = KeyMap[OLD_KEY];
bool keyUP = wParam;
INPUT inputdata;
inputdata.type=INPUT_KEYBOARD;
inputdata.ki.dwFlags=KEYEVENTF_SCANCODE ;
inputdata.ki.wScan=NEW_KEY;
inputdata.ki.wVk=MapVirtualKey(NEW_KEY, MAPVK_VSC_TO_VK);
inputdata.ki.time = 0;//key->time;
inputdata.ki.dwExtraInfo = 0;//key->dwExtraInfo;
if(keyUP)
{
inputdata.ki.dwFlags |= KEYEVENTF_KEYUP;
}
Sleep(1);
bool sendKey=false;
switch(inputdata.ki.wScan)
{
//there once was some additional logic here to handle the modifier keys ctrl, alt and shift seperately, but not anymore
default:
{
sendKey=true;
}
break;
}
if (sendKey)
{
UINT result = SendInput(1, &inputdata, sizeof(INPUT));
if(!result)
ErrorExit(L"SendInput didn't work!");
}
}
break;
Output when pressing the normal shift key on a physical keyboard:
//key down
HEX: a0 00 00 00 2a 00 00 00 00 00 00 00 29 cf d2 00 00 00 00 00 00 00 00 00
Output key: VK: 160, scan: 42, flags: 0, time: 13815593, event: 256
//key up
HEX: a0 00 00 00 2a 00 00 00 80 00 00 00 e5 cf d2 00 00 00 00 00 00 00 00 00
Output key: VK: 160, scan: 42, flags: 128, time: 13815781, event: 257
Output when pressing the simulated shift key on the numpad:
//keydown event numpad
HEX: 60 00 00 00 52 00 00 00 00 00 00 00 a1 ea d2 00 00 00 00 00 00 00 00 00
Intercept Key, VK: 96, scan: 82, flags: 0, time: 13822625, event: 256
//keydown event simulated shift key
HEX: a0 00 00 00 2a 00 00 00 10 00 00 00 a1 ea d2 00 00 00 00 00 00 00 00 00
Output key: VK: 160, scan: 42, flags: 0, time: 13822625, event: 256
// key up event with strange scancode 554 <- THIS IS WHAT I AM TALKING ABOUT!
HEX: a0 00 00 00 2a 02 00 00 80 00 00 00 3d eb d2 00 00 00 00 00 00 00 00 00
Output key: VK: 160, scan: 554, flags: 128, time: 13822781, event: 257
// key up event numpad
HEX: 2d 00 00 00 52 00 00 00 80 00 00 00 3d eb d2 00 00 00 00 00 00 00 00 00
Intercept Key, VK: 45, scan: 82, flags: 128, time: 13822781, event: 257
// key down with strange scan code
HEX: a0 00 00 00 2a 02 00 00 00 00 00 00 3d eb d2 00 00 00 00 00 00 00 00 00
Output key: VK: 160, scan: 554, flags: 0, time: 13822781, event: 256
//key up event simulated shift key
HEX: a0 00 00 00 2a 00 00 00 90 00 00 00 3d eb d2 00 00 00 00 00 00 00 00 00
Output key: VK: 160, scan: 42, flags: 128, time: 13822781, event: 257
Another thing to note is that the key-up event of this strange key scan code 554 is also exactly in reverse to what the rest is (see output).
As I can simply eat the key event for this strange scan code 554, this is actually not much of a problem functionality-wise, but I would still like to know what this scan code 554 is all about.
I want to read values in the function mv from a json object :
{ name: 'user_step4#upload',
data:
<Buffer ff d8 ff e0 00 10 4a 46 49 46 00 01 01 00 00 48 00 48 00 00 ff e1 00 4c 45 78 69 66 00 00 4d 4d 00 2a 00 00 00 08 00 02 01 12 00 03 00 00 00 01 00 06 ... >,
size: 6841698,
encoding: '7bit',
tempFilePath: '',
truncated: false,
mimetype: 'multipart/form-data',
md5: '226d9791b4e0d637cee207a2f832900e',
mv: [Function: mv] }
Data is a Buffer data type.
Try to convert to string data type.
object.data.toString()
yourJsonObject.data.toString() will convert your buffer to String.
yourJsonObject.mv.toString() will help you to print the function code.
I have data from an api that has returned like this:
var body = data;
data is equal to:
ByteBuffer {
buffer:
<Buffer 09 62 61 1f 04 01 00 10 01 11 61 99 5d 05 01 00 10 01>,
offset: 0,
markedOffset: -1,
limit: 18,
littleEndian: true,
noAssert: false
}
I've tried passing different functions to it to try to get the data from it. (I'm expecting at least 2 IDs.) Here is what I have tried so far and their results:
var message = body.readUint32(); // 526475785
var message = body.readCString(); // [blank]
var message = body.readUint8(); // 16
var message = body.readUint64(); // Long { low: -1721691903, high: 66909, unsigned: true }
I also tried:
var message = new ByteBuffer(8 + 8 + 4 + Buffer.byteLength(body.buffer) + 1, ByteBuffer.LITTLE_ENDIAN);
which returned:
ByteBuffer {
buffer:
<Buffer 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00>,
offset: 0,
markedOffset: -1,
limit: 39,
littleEndian: true,
noAssert: false
}
I also tried passing just 'body' in but that didn't work at all. Should I be parsing this differently? What exactly should I change to get the data? Thank you
You have to flip the bytebuffer first to make the ByteBuffer ready for read operations.
After the buffer is ready for read operations, use readIString to read the whole buffer as a string, you can use other operations such as readInt32 if you are expecting the buffer to be of other values than a string (I'm assuming a string since it is coming from an API).
body.flip().readIString();
A link to the ByteBuffer docs:
https://github.com/dcodeIO/bytebuffer.js/wiki/API
I am trying to test amazon web node api sdk for lex for audio input and output and successfully configured it, but when I test it, it sends me garbage inputTranscript(like "yeah", "oh no", "um yeah", etc.) in response.
The request parameters are as below,
var params = {
botAlias: 'Test', /* required */
botName: 'Revert', /* required */
contentType: 'audio/l16; rate=16000; channels=1', /* required */
inputStream: <Buffer 52 49 46 46 80 55 02 00 57 41 56 45 66 6d 74 20 10 00 00 00 01 00 02 00 80 3e 00 00 00 7d 00 00 04 00 10 00 64 61 74 61 54 55 02 00 00 00 00 00 00 00 ... >, /* required */
userId: '12321', /* required */
accept: 'audio/*',
sessionAttributes: {"firstName": "Joe"}
};
The response I am getting as below,
{ contentType: 'audio/mpeg',
sessionAttributes: { firstName: 'Joe' },
message: 'Sorry No Match',
dialogState: 'ElicitIntent',
inputTranscript: 'yeah',
audioStream: <Buffer 49 44 33 04 00 00 00 00 00 23 54 53 53 45 00 00 00 0f 00 00 03 4c 61 76 66 35 37 2e 35 36 2e 31 30 31 00 00 00 00 00 00 00 00 00 00 00 ff f3 60 c4 00 ... > }
For voice recording I am using my laptop inbuilt mic and RecordRTC api as,
recorder = RecordRTC(microphone, {
type: 'audio',
recorderType: StereoAudioRecorder,
desiredSampRate: 16000
});
The recorded voice is encoded into base64 and sent to node server where it is decoded back and sent to lex api in buffer format.
I'm working to get useful data from a VISA (such as PAN, expiry date...) credit card using a list of AIDs I got stuck.
I have been able to access to all the data manually. Using the next tutorial: http://www.openscdp.org/scripts/tutorial/emv/reademv.html
>>00 A4 04 00 07 A0 00 00 00 03 10 10 00
In ASCII:
<<o<EM>„<BEL> <0><0><0><ETX><DLE><DLE>¥<SO>P<EOT>VISA¿<FF><ENQ>ŸM<STX><VT><LF><0>
In Hexadecimal:
<<6F 19 84 07 A0 00 00 00 03 10 10 A5 0E 50 04 56 49 53 41 BF 0C 05 9F 4D 02 0B 0A 90 00
After that I used:
>>33 00 B2 01 0C 00 //sfi1, rec1
...
...
>>33 00 B2 10 FC 00 //sfi31, rec16
I continued with the tutorial and learned that the proper way to obtain the data was using GPO (Get Processing Options) command. And tried that next:
>>80 A8 00 00 0D 83 0B 00 00 00 00 00 00 00 00 00 00 00 00 // pdo = 83 0B 00 00 00 00 00 00 00 00 00 00 00 which suposse to be the correct one for VISA.
<< 69 85
So the condition of use is not satisfied.
>> 80 A8 00 00 02 83 00 00 //pdo= 83 00 that should work with every non visa card
<< 80 0E 3C 00 08 01 01 00 10 01 04 00 18 01 03 01 90 00
If this response is correct and it looks quite well for me as it starts by 80 and ends by 90 00, I am not able to identify AFL which I think that would make me possible to determine the PAN, expiry date... Can somebody help me?
The FCI that you received in response to the select command (00 A4 0400 07 A0000000031010 00) decodes to
6F 19 (File Control Information (FCI) Template)
84 07 (Dedicated File (DF) Name)
A0000000031010
A5 0E (File Control Information (FCI) Proprietary Template)
50 04 (Application Label)
56495341 ("VISA")
BF0C 05 (File Control Information (FCI) Issuer Discretionary Data)
9F4D 02 (Log Entry)
0B0A (SFI = 11; # of records = 10)
This FCI does not include any PDOL (processing options data list). Consequently, you need to assume a default value for the PDOL (which is an empty list for your card type). Consequently, the PDOL-related data field in the GET PROCESSING OPTIONS command must be empty:
83 00
Where 0x83 is the tag for PDOL-related data and 0x00 is a length of zero bytes.
Thus, the correct GPO command is (as you already found out):
80 A8 0000 02 8300 00
You got the response
800E3C00080101001001040018010301 9000
This decodes to
80 0E (Response Message Template Format 1)
3C00 (Application Interchange Profile)
08010100 10010400 18010301 (Application File Locator)
Consequently, the Application File Locator contains the following three entries:
08010100: SFI = 1, first record = 1, last record = 1, records involved in offline data authentication = 0
10010400: SFI = 2, first record = 1, last record = 4, records involved in offline data authentication = 0
18010301: SFI = 3, first record = 1, last record = 3, records involved in offline data authentication = 1
Consequently, you can read those record with the READ RECORD commands:
00 B2 010C 00
00 B2 0114 00
00 B2 0214 00
00 B2 0314 00
00 B2 0414 00
00 B2 011C 00
00 B2 021C 00
00 B2 031C 00