#persistent
SetTimer, CheckTime, 0 ;check ms all the time
Return
CheckTime:
if (A_Now == 2022 01 19 10 00 00 and A_MSec == 000)
SendInput {Enter}
Sleep, 100
Return
Hi, I can't figure out what it's wrong. Is this even possible?
I want to reduce sending that button to below 00.100Z in Unix milliseconds
Related
I'm trying to understand protocol buffer encoding method, when translating message to binary(or hexadecimal) format, I can't understand how the embedded message is encoded.
I guess maybe it's related to memory address, but I can't find the accurate relationship.
Here is what i've done.
Step 1: I defined two messages in test.proto file,
syntax = "proto3";
package proto_test;
message Education {
string college = 1;
}
message Person {
int32 age = 1;
string name = 2;
Education edu = 3;
}
Step 2: And then I generated some go code,
protoc --go_out=. test.proto
Step 3: Then I check the encoded format of the message,
p := proto_test.Person{
Age: 666,
Name: "Tom",
Edu: &proto_test.Education{
College: "SOMEWHERE",
},
}
var b []byte
out, err := p.XXX_Marshal(b, true)
if err != nil {
log.Fatalln("fail to marshal with error: ", err)
}
fmt.Printf("hexadecimal format:% x \n", out)
fmt.Printf("binary format:% b \n", out)
which outputs,
hexadecimal format:08 9a 05 12 03 54 6f 6d 1a fd 96 d1 08 0a 09 53 4f 4d 45 57 48 45 52 45
binary format:[ 1000 10011010 101 10010 11 1010100 1101111 1101101 11010 11111101 10010110 11010001 1000 1010 1001 1010011 1001111 1001101 1000101 1010111 1001000 1000101 1010010 1000101]
what I understand is ,
08 - int32 wire type with tag number 1
9a 05 - Varints for 666
12 - string wire type with tag number 2
03 - length delimited which is 3 byte
54 6f 6d - ascii for "TOM"
1a - embedded message wire type with tag number 3
fd 96 d1 08 - ? (here is what I don't understand)
0a - string wire type with tag number 1
09 - length delimited which is 9 byte
53 4f 4d 45 57 48 45 52 45 - ascii for "SOMEWHERE"
What does fd 96 d1 08 stands for?
It seems like that d1 08 always be there, but fd 96 sometimes change, don't know why. Thanks for answering :)
Add
I debugged the marshal process and reported a bug here.
At that location I/you would expect the number of bytes in the embedded message.
I have repeated your experiment in Python.
msg = Person()
msg.age = 666
msg.name = "Tom"
msg.edu.college = "SOMEWHERE"
I got a different result, the one I would expect. A varint stating the size of the embedded message.
0x08
0x9A, 0x05
0x12
0x03
0x54 0x6F 0x6D
0x1A
0x0B <- Equals to 11 decimal.
0x0A
0x09
0x53 0x4F 0x4D 0x45 0x57 0x48 0x45 0x52 0x45
Next I deserialized your bytes:
msg2 = Person()
str = bytearray(b'\x08\x9a\x05\x12\x03\x54\x6f\x6d\x1a\xfd\x96\xd1\x08\x0a\x09\x53\x4f\x4d\x45\x57\x48\x45\x52\x45')
msg2.ParseFromString(str)
print(msg2)
The result of this is perfect:
age: 666
name: "Tom"
edu {
college: "SOMEWHERE"
}
The conclusion I come to is that there are some different ways of encoding in Protobuf. I do not know what is done in this case but I know the example of a negative 32 bit varint. A positive varint is encoded in five bytes, a negative value is cast as a 64 bit value and encoded to ten bytes.
As a beginner in PIC programming I try to understand an existing and running code. In that code I find.
movf c10m,w ;Read 10th of min count
movwf bcd_in ;Set counter code here
Where to find the destination flag d?
I understand that data of c10m goes into w with movf. The behaviour of movf depends on a destination flag d. But I can not find the whereabout of the flag and how to manipulate.
The direction bit is normally decided by the second operand. This is described but not very clearly in the microchip manual (it uses FSR which is an indrection register). The instruction means move file the contents of the file register. If d=0, the destination is W; if d=1, it is the register itself.
The format of the command is
MOVF file,d
where d=0 or 1 but most assemblers will accept W in place of d. Note that it does not check the contents of W. It is not that complex. It does not matter what is in W, it will get overwritten.
; d Before After
; W TMR0 Z W TMR0 Z
MOVF TMR0,W ; 0 ?? 25 ? 25 25 0
MOVF TMR0,W ; 0 ?? 00 ? 00 00 1
MOVF TMR0,0 ; 0 ?? 25 ? 25 25 0 same as MOVF TMR0,W
MOVF TMR0,1 ; 1 ?? 25 ? ?? 25 0
MOVF TMR0,1 ; 1 ?? 00 ? ?? 00 1
Moving a file register to itself will cause the zero flag to be set if the value is zero.
I'm looking into suggestions on how to convert a 64-bit die revision field into a 32-bit MAC address I can use a for a wireless application to avoid collisions.
The die information is
struct {
uint32_t lot;
uint16_t X_coordinate;
uint16_t Y_coordinate;
}
I don't know the range of coordinates, but based on a few samples, I think the coordinates are limited to < 256. That effectly reduces the space by 2 bytes. But the lot number is fully populated.
I'm going to try this (pseudocode to make it readable, I'm leaving the casts out)
MAC = X_coordinate | Y_coordinate << 8 | lot << 16;
and throw away the top 16 bits of the lot and the top 8 bits of the coordinates. I feel though that maybe I should XOR in the top 16 bits of the lot somewhere, but I have no experience with this in the real world.
Here is a sample of die revision information: little endian byte dump
lot/wafer ID X coordinate Y coordinate
C3 1B B0 46 20 00 22 00
CB 8B 94 46 14 00 32 00
CB 8B 94 46 27 00 1E 00
B9 F7 80 6F 20 00 08 00
INTRO
I'm trying to reverse engineer a binary data file containing sms messagges.
The file is named ems.idx4 and was created with a software named LG PhoneManager around 5 years ago as a backup archive of sms messagges for a LG mobile.
I don't know which language was used to write LG PhoneManager, but in the binary file I read strings like "CObTree", "CFolder", "CMessage": maybe this clue means nothing, maybe it suggests that Cobol/.net/whatever language was used.
PROBLEM
I decoded the entire structure of the binary file, which is quite plain tho.
The only part I couldn't decode is date and time of single messagges.
I identified the binary part where date and time are encoded and I got a few decoded examples (thanks to the content of the message).
Binary data in hex:
[0x10] D0 74 C4 FE 3F 42 E3 40 F1 64 [0x7] 2 [0x13] 1 [0x6] 6C [0x2] is 2007/12/25 some time after 23:58 GMT+1
[0x10] 2B 25 CA 19 2F 43 E3 40 F1 64 [0x7] 2 [0x13] 1 [0x6] 6C [0x2] is 2008/01/02 some time after 10:48 GMT+1
[0x10] AA C0 2C 6E 35 43 E3 40 F1 64 [0x7] 2 [0x13] 1 [0x6] 6C [0x2] is 2008/01/02 some time after 16:03 GMT+1
[0x10] EE 04 71 F2 B6 43 E3 40 F1 64 [0x7] 2 [0x13] 1 [0x6] 6C [0x2] is 2008/01/06 some time after 14:31 GMT+1
[0x10] 60 2C F9 45 4E 4F E3 40 F1 64 [0x7] 2 [0x13] 1 [0x6] 6C [0x2] is 2008/04/08 some time after 10:32 GMT+1
[0x10] 5D 84 01 14 74 64 E3 40 F1 64 [0x7] 2 [0x13] 1 [0x6] 6C [0x2] is 2008/11/11 some time after 14:53 GMT+1
where [0xN] means a sequence of N zeros.
Any idea?
UPDATE
Using this tool: http://www.digital-detective.co.uk/freetools/decode.asp
I realized it is Windows 64 bit OLE date / time format.
According to that tool:
D0 74 C4 FE 3F 42 E3 40 means exactly 26/12/2007 00:59
Any idea what the math behind this Windows 64 bit OLE date / time format?
It's a double precision floating point number representing the number of days (and fractional days) since the epoch December 30, 1899.
If you're on Windows you can use the VariantTimeToSystemTime function to get it into a more usable format:
unsigned char timeBytes[] = {0xD0,0x74,0xC4,0xFE,0x3F,0x42,0xE3,0x40};
double timeDouble = *(double*)&timeBytes;
SYSTEMTIME systemTime;
VariantTimeToSystemTime(timeDouble, &systemTime);
If you're not using Windows, I suspect you'd need to do the conversion manually. Let me know in the comments if you need any help with that.
Ok, I found my way!
The first 8 bytes after [0x10] are a OLE date in little endian hex.
I converted them to a regular datetime in python with:
import datetime
import math
from struct import unpack
def ole_date_bin_to_datetime(ole_date_bin):
"""
Converts a OLE date from a binary 8 bytes little endian hex form to a datetime
"""
#Conversion to OLE date float, where:
# - integer part: days from epoch (1899/12/30 00:00)
# - decimal part: percentage of the day, where 0,5 is midday
date_float = unpack('<d', ole_date_bin)[0]
date_decimal, date_integer = math.modf(date_float)
date_decimal = abs(date_decimal)
date_integer = int(date_integer)
#Calculate the result
res = datetime.datetime(1899, 12, 30) + datetime.timedelta(days=date_integer) #adding days to epoch
res = res + datetime.timedelta(seconds = 86400*date_decimal) #adding percentage of the day
return res
if __name__ == "__main__":
print ole_date_bin_to_datetime('\xd0\x74\xc4\xfe\x3f\x42\xe3\x40')
How can I get the NFC contactless reader ACR122U to behave as a tag (card emulation mode)?
The prospectus claims that the device can do card emulation, but the SDK does not seem to provide an example or documentation for this feature.
Does anybody know how to do this?
Is there additional software required?
Please note that my target platform is MS Windows.
Thanks in advance
For "Card Emulation" or in other words, "Configure as target and wait for initiators", please refer to here: http://code.google.com/p/nfcip-java/source/browse/trunk/nfcip-java/doc/ACR122_PN53x.txt
** Command to PN532 **
0xd4 0x8c TgInitAsTarget instruction code
0x00 Acceptable modes
(0x00 = allow all, 0x01 = only allow to be
initialized as passive, 0x02 = allow DEP only)
_6 bytes (_MIFARE_)_:
0x08 0x00 SENS_RES
0x12 0x34 0x56 NFCID1
0x40 SEL_RES
_18 bytes (_Felica_)_:
0x01 0xfe 0xa2 0xa3 0xa4 0xa5 0xa6 0xa7
NFCID2
0xc0 0xc1 0xc2 0xc3 0xc4 0xc5 0xc6 0xc7
?
0xff 0xff System parameters?
0xaa 0x99 0x88 0x77 0x66 0x55 0x44 0x33 0x22 0x11
NFCID3
0x00 ?
0x00 ?
This is the response when an initiator activated this target:
** Response from PN532 **
0xd5 0x8d TgInitAsTarget response code
0x04 Mode
(0x04 = DEP, 106kbps)
Let me know if it works!
Also you can try to send the following ADPU in HEX to put the reader in "Card emulation" mode:
FF 00 00 00 27 D4 8C 00 08 00 12 34 56 40 01 FE A2 A3 A4 A5 A6 A7 C0 C1 C2 C3 C4 C5 C6 C7 FF FF AA 99 88 77 66 55 44 33 22 11 00 00
For getting the ACR122 (or rather the PN532 NFC controller chip inside it) into card emulation mode, you would do about the following:
ReadRegister:
> FF000000 08 D406 6305 630D 6338
< D507 xx yy zz 9000
Update register values:
xx = xx | 0x004; // CIU_TxAuto |= InitialRFOn
yy = yy & 0x0EF; // CIU_ManualRCV &= ~ParityDisable
zz = zz & 0x0F7; // CIU_Status2 &= ~MFCrypto1On
WriteRegister:
> FF000000 11 D408 6302 80 6303 80 6305 xx 630D yy 6338 zz
< D509 9000
SetParameters:
> FF000000 03 D412 30
< D513 9000
TgInitAsTarget
> FF000000 27 D48C 05 0400 123456 20 000000000000000000000000000000000000 00000000000000000000 00 00
< D58D xx ... 9000
Where xx should be equal to 0x08.
Communicate using a sequence of TgGetData and TgSetData commands:
> FF000000 02 D486
< D587 xx <C-APDU> 9000
Where xx is the status code (should be 0x00 for success) and C-APDU is the command sent from the reader.
> FF000000 yy D48E <R-APDU>
< D587 xx 9000
Where yy is 2 + the length of the R-APDU (response) and xx is the status code (should be 0x00 for success).
You can use LibNFC. It has example code for this.
I still never got this working properly in Windows unfortunately. You will probably have to compile libnfc for specific drivers.
Also, the ACR122u seems to be pretty poorly supported by many libraries. Apparently it's not really designed for this use. There are particular issues for card emulation too (such as the timeout). We really all need to stop by the ACR122u. I just bought what was popular and easy to get hold of but regret it now.
To future browsers/searchers coming across this: please check the compatibility section on the libnfc site and buy something that they recommend!