I based the file on https://en.wikipedia.org/wiki/ICO_(file_format) and https://www.w3.org/TR/PNG/. I will translate the .ico file from how it looks in my hex editor into some kind of pseudo-binary (the order of the bytes are as written out):
ICONDIR{
uint16_t idReserved : 00 00
uint16_t idType : 00 01
uint16_t idCount : 00 01
ICONDIRENTRY{
uint8_t bWidth : 01
uint8_t bHeight : 01
uint8_t bColorCount : 00
uint8_t bReserved : 00
uint16_t wPlanes : 00 00
uint16_t wBitCount : 00 20
uint32_t dwBytesInRes : 00 00 00 49
uint32_t dwImageOffset : 00 00 00 16
}
}
PNG{
uint8_t PNGSignature[8] : 89 50 4E 47 0D 0A 1A 0A
IHDR{
uint32_t Length : 00 00 00 0D
uint8_t ChunkType[4] : 49 48 44 52 //IHDR
uint32_t Width : 00 00 00 01
uint32_t Height : 00 00 00 01
uint8_t BitDepth : 08 //8 bits
uint8_t ColourType : 06 //RGBA
uint8_t CompressionMethod : 00
uint8_t FilterMethod : 00
uint8_t InterlaceMethod : 00
uint32_t CRC32 : 1F 15 C4 89 //CRC32 of bits [ChunkType,...,InterlaceMethod]
}
IDAT{
uint32_t Length : 00 00 00 10
uint8_t ChunkType[4] : 49 44 41 54 //IDAT
ZLIB{
(CMF.CINFO = 0000,CMF.CM = 1000) : 08
(FLG.FLEVEL = 10 /*Slowest Algorithm*/
,FLG.FDICT = 0 /* No dictionary */
,FLG.FCHECK = 11001 /* 0000100010011001 = 2201 = 71 x 31 */) : 99
DEFLATE{
(BFINAL = 1 /* Last block */
,BTYPE = 00 /* No compression */
,<No compression ignored bytes = 00000>) : 80
uint16_t LEN : 00 05
uint16_t NLEN : FF FA
LITERAL_DATA_SCANLINE{
uint8_t FilterTypeByte : 00 // No filtering
PIXEL{
uint8_t R : FF
uint8_t G : 00
uint8_t B : 00
uint8_t A : FF
}
}
}
uint32_t ADLER32 : 00 AB 00 A2
}
uint32_t CRC32 : 02 EA 6B 91 //CRC32 of bits [ChunkType,ZLIB]
}
IEND{
uint32_t Length : 00 00 00 00
uint8_t ChunkType[4] : 49 45 4E 44
uint32_t CRC32 : AE 42 60 82 //CRC32 of [ChunkType]
}
}
PNG image (magnified to size 100x100):
Since the PNG can be displayed I guess there is some documentation I have not found/misinterpreted. Please point to the error if you see it!
I had missed the little-endian part... Correct version of the ICO part is:
ICONDIR{
uint16_t idReserved : 00 00
uint16_t idType : 01 00
uint16_t idCount : 01 00
ICONDIRENTRY{
uint8_t bWidth : 01
uint8_t bHeight : 01
uint8_t bColorCount : 00
uint8_t bReserved : 00
uint16_t wPlanes : 00 00
uint16_t wBitCount : 20 00
uint32_t dwBytesInRes : 49 00 00 00
uint32_t dwImageOffset : 16 00 00 00
}
}
Related
I'm implementing SHA-3 following the official FIPS-202 document in Verilog.
My state is represented by a one-dimensional register and I use a macro function to calculate the corresponding state index from the (x,y,z) coordinates in the document:
A[x, y, z] = S [W(5y + x) + z], W = 64 (p. 9)
I'm strictly following the guide on page 11 and came up with this:
// Macros for transforming dimensions
`define sub_1(x) (x == 0 ? 4 : x - 1)
`define add_1(x) (x == 4 ? 0 : x + 1)
`define sub_1_W(x) (x == 0 ? (W - 1) : x - 1)
`define s(x,y,z) ((W * ((5 * y) + x)) + z)
`define s_xz(x,z) ((W * x) + z)
// Wires
wire [0:(1600 - 1)] absorbed_data, after_theta;
wire [0:((5 * 64) - 1)] C, D;
genvar x, z;
for(x = 0; x < 5; x = x + 1) begin
for(z = (W - 1); z >= 0; z = z - 1) begin
// Step 1
assign C[`s_xz(x,z)] = absorbed_data[`s(x,0,z)] ^ absorbed_data[`s(x,1,z)] ^ absorbed_data[`s(x,2,z)] ^ absorbed_data[`s(x,3,z)] ^ absorbed_data[`s(x,4,z)];
// Step 2
assign D[`s_xz(x,z)] = C[`s_xz(`sub_1(x),z)] ^ C[`s_xz(`add_1(x),`sub_1_W(z)];
end
end
genvar x, y, z;
generate
for(x = 0; x < 5; x = x + 1) begin
for(y = 0; y < 5; y = y + 1) begin
for(z = 0; z < W; z = z + 1) begin
// Step 3
assign after_theta[`s(x,y,z)] = absorbed_data[`s(x,y,z)] ^ D[`s_xz(x,z)];
end
end
end
endgenerate
The issue I'm currently facing seems to be in the Theta function. For example for SHA-224 and an empty message should yield the intermediate results and the final output as shown in this document.
Strangely, I get the same absorbed_data (06 00 ... 00 80) but different values for C and D:
C
as is: 06 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 80 | 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00
to be: 00 00 00 00 00 00 00 06 | 00 00 00 00 00 00 00 00 | 80 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00
D
as is: 00 00 00 00 00 00 00 00 | 06 00 00 00 00 00 01 00 | 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 80 | 0c 00 00 00 00 00 00 00
to be: 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 07 | 00 00 00 00 00 00 00 00 | 80 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 0c
Firstly, for C the bit order seems to be different but not on the bit-level but on the byte-level (as 06 stays 06).
Secondly, for D I get 06 00 .. 01 00 whereas the correct result should be 00 .. 00 07. This is never possible for my implementation as, according to FIPS-202, the bit at z can only be shifted by one position ( (z - 1) mod w).
In the to-be case D will yield the correct result because 06 ^ (80 << 1) = 07.
In conclusion, I would say that my implementation behaves as one can expect from the definition in FIPS-202, correct?
Any idea what I'm doing wrong here?
Thanks in advance!
I think I found the solution.
It is described in appendix of FIPS 202 B.1 (starting on page 26). A hint on this topic is given on page 25:
The convention for interpreting hexadecimal strings as bit strings for the inputs and outputs of the SHA-3 examples is different from the convention for other functions on the examples page. The conversion functions between hexadecimal strings and SHA-3 bit strings are specified in Sec. B.1. For byte-aligned messages, the hexadecimal forms of the padding for the SHA-3 functions are described in Sec. B.2.
There is a good explanation on how to circumvent this issue on cryptologie.net.
I'm attempting to search for an arbitrarily long byte string in WinDbg and print out the address if an integer in the vicinity meets some criteria.
Pseudo-register $t0 contains the starting address I want to search.
Here's something that, based on the Windows docs, maybe could work (though it clearly doesn't).
.foreach (place { s -[1] #$t0 L?30000 00 00 00 00 00 20 00 00 }) { .if ( (place +0x8) <= 0x1388) { .printf "0x%x\n", place } }
Search
First, the search command doesn't quite work correctly. I only want the address of the match (not the data).
s -[1] #$t0 L?30000 00 00 00 00 00 20 00 00
The docs say that the 1 flag will only return the address. When I issue that command, WinDbg replies
^ Syntax error in 's -1 #$t0 L?30000 00 00 00 00 00 20 00 00 '
If I leave out the -1, it finds two matches.
What am I doing wrong here?
Condition
I don't think the condition is behaving the way I want. I want to look at the third dword starting at place, i.e. place+8, and verify that it's smaller than 5000 (decimal). The .if inside the .foreach isn't printing a meaningful value for place (i.e. the address returned from the search). I think it's dereferencing place first and comparing the value of that integer to 5000. How do I look at the value of, say, *(int*)(place+8)?
Documentation?
The docs are not helping me very much. They only have sparse examples, none of which correspond to what I need.
Is there better documentation somewhere besides MS's Hardware Dev Center?
you can start writing JavaScript for a more legible way of scripting
old way
0:000> s -b vect l?0x1000 4d
00007ff7`8aaa0000 4d 5a 90 00 03 00 00 00-04 00 00 00 ff ff 00 00 MZ..............
00007ff7`8aaa00d4 4d 90 80 d2 df f9 82 d3-4d 90 80 d2 52 69 63 68 M.......M...Rich
00007ff7`8aaa00dc 4d 90 80 d2 52 69 63 68-4c 90 80 d2 00 00 00 00 M...RichL.......
0:000> s -[1]b vect l?0x1000 4d
0x00007ff7`8aaa0000
0x00007ff7`8aaa00d4
0x00007ff7`8aaa00dc
using javascript
function search(addr,len)
{
var index = []
var mem = host.memory.readMemoryValues(addr,len)
for(var i = 0; i < len; i++)
{
if(mem[i] == 0x4d)
{
index.push(addr+i)
}
}
return index
}
executed will return address like which you can manipulate further
0:000> dx -r1 #$scriptContents.search(0x00007ff78aaa0000,1000)
#$scriptContents.search(0x00007ff78aaa0000,1000) : 140701160046592,140701160046804,140701160046812
length : 0x3
[0x0] : 0x7ff78aaa0000
[0x1] : 0x7ff78aaa00d4
[0x2] : 0x7ff78aaa00dc
improving the script a little to find something based on first result
we will try to find the index of Rich string that follows the character 'M'
modified script
function search(addr,len)
{
var index = []
var Rich = []
var result = []
var mem = host.memory.readMemoryValues(addr,len)
for(var i = 0; i < len; i++)
{
if(mem[i] == 0x4d)
{
index.push(addr+i)
var temp = host.memory.readMemoryValues(addr+i+4,1,4)
host.diagnostics.debugLog(temp +"\t")
if(temp == 0x68636952)
{
Rich.push(addr+i)
}
}
}
result.push(index)
result.push(Rich)
return result
}
result only the third occurance of char "M" is followed by Rich string
0:000> dx -r2 #$scriptContents.search(0x00007ff78aaa0000,1000)
3 3548576223 1751345490 #$scriptContents.search(0x00007ff78aaa0000,1000) : 140701160046592,140701160046804,140701160046812,140701160046812
length : 0x2
[0x0] : 140701160046592,140701160046804,140701160046812
length : 0x3
[0x0] : 0x7ff78aaa0000
[0x1] : 0x7ff78aaa00d4
[0x2] : 0x7ff78aaa00dc
[0x1] : 140701160046812
length : 0x1
[0x0] : 0x7ff78aaa00dc
0:000> s -b vect l?0x1000 4d
00007ff7`8aaa0000 4d 5a 90 00 03 00 00 00-04 00 00 00 ff ff 00 00 MZ..............
00007ff7`8aaa00d4 4d 90 80 d2 df f9 82 d3-4d 90 80 d2 52 69 63 68 M.......M...Rich
00007ff7`8aaa00dc 4d 90 80 d2 52 69 63 68-4c 90 80 d2 00 00 00 00 M...RichL.......
load the extensension jsprovider.dll .load jsprovider
write a script say foo.js
load the script .scriptload ...\path\foo.js
execute any functions inside the js you wrote with dx #$scriptContents.myfunc(myargs)
see below using cdb just for ease of copy paste windbg works just as is
F:\>type mojo.js
function hola_mojo ()
{
host.diagnostics.debugLog("hola mojo this is javascript \n")
}
F:\>cdb -c ".load jsprovider;.scriptload .\mojo.js;dx #$scriptContents.hola_mojo();q" cdb | f:\usr\bin\grep.exe -A 6 -i reading
0:000> cdb: Reading initial command '.load jsprovider;.scriptload .\mojo.js;dx #$scriptContents.hola_mojo();q'
JavaScript script successfully loaded from 'F:\mojo.js'
hola mojo this is javascript
#$scriptContents.hola_mojo()
quit:
If I read this part of the documentation
s [-[[Flags]Type]] Range Pattern
correctly, you cannot leave out Type when specifying flags. That's because the flags are inside two square brackets. Otherwise it would have been noted as s [-[Flags][Type]] Range Pattern.
Considering this, the example works:
0:000> .dvalloc 2000
Allocated 2000 bytes starting at 00ba0000
0:000> eb 00ba0000 01 02 03 04 05 06 07 08 09
0:000> eb 00ba1000 01 02 03 04 05 06 07 08 09
0:000> s -[1]b 00ba0000 L?2000 01 02 03 04 05 06 07 08
0x00ba0000
0x00ba1000
Also note that you'll have a hidden bug for the use of place: it should be ${place}. By default, that will work with the address (line break for readability on SO):
0:000> .foreach (place {s -[1]b 00ba0000 L?2000 01 02 03 04 05 06 07 08 })
{ .if ( (${place} +0x8) < 0xba1000) { .printf "0x%x\n", ${place} } }
0xba0000
In order to read a DWord from that address, use the dwo() MASM oerator (line break for readability on SO):
0:000> .foreach (place {s -[1]b 00ba0000 L?2000 01 02 03 04 05 06 07 08 })
{ .if ( (dwo(${place} +0x8)) < 0xba1000)
{ .printf "0x%x = 0x%x\n", ${place}, dwo(${place}+8) } }
0xba0000 = 0x9
0xba1000 = 0x9
I try to read barcode form scanner. I had got data from scanner and the format is binary. How do I conert binary to Ascii string?
The barcode type is code 39.
A1234 => [Barcode SCANNRT] => [perl] => binary => ?? A1234 ???
use Device::HID;
use Data::Hexdumper qw(hexdump);
my $dev = Device::HID->new(vendor => 0x04b4, product => 0x0100) or die "No such device !\n";
$dev->timeout = 0.1; # seconds (=100 ms)
my $buf;
my $len=128;
while(defined(my $in = $dev->read_data($buf, $len))){
if ($in == 0) {
next;
}
print hexdump(
data => $buf, # what to dump
suppress_warnings => false,
space_as_space=> true,
);
}
The input "A1234" binary output. How to convert to sting "A1234".
0x0000 : 02 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
0x0000 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
0x0000 : 00 00 1E 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
0x0000 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
0x0000 : 00 00 1F 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
0x0000 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
0x0000 : 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 : .. .............
0x0000 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
0x0000 : 00 00 21 00 00 00 00 00 00 00 00 00 00 00 00 00 : ..!.............
0x0000 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
0x0000 : 00 00 28 00 00 00 00 00 00 00 00 00 00 00 00 00 : ..(.............
0x0000 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
I change code to get hexadecimal for each package.
use Device::HID;
use Data::Hexdumper qw(hexdump);
my $dev = Device::HID->new(vendor => 0x04b4, product => 0x0100) or die "No such device !\n";
$dev->timeout = 0.1; # seconds (=100 ms)
my $buf;
my $len=128;
my $i=0;
while(defined(my $in = $dev->read_data($buf, $len))){
if ($in == 0) {
next;
}
$i++;
my $hex = unpack( 'H*', $buf );
print sprintf("%02d",$i)." => $hex\n";
}
The out is hexadecimal. I change code to output hexadecimal. I received 12 package.
How to convert to string 'A1234' ?
01 => 0200040000000000
02 => 0000000000000000
03 => 00001e0000000000
04 => 0000000000000000
05 => 00001f0000000000
06 => 0000000000000000
07 => 0000200000000000
08 => 0000000000000000
09 => 0000210000000000
10 => 0000000000000000
11 => 0000280000000000
12 => 0000000000000000
Split into 8 byte chunks (for your device, it depends on the device descriptor). Column 0 is control key (2nd bit indicates the shift key is pressed), column 2 is the usage code as per section 10 (page 53) of the USB HID Usage Tables doc:
https://www.usb.org/sites/default/files/documents/hut1_12v2.pdf
If the key is a 0, then just ignore it.
So this input:
0x0000 : 02 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
0x0000 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
0x0000 : 00 00 1E 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
0x0000 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
0x0000 : 00 00 1F 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
becomes:
02 04 (shift + a) = "A"
00 00 (ignore)
00 1E (1) = "1"
00 00 (ignore)
00 00 (ignore)
00 00 (ignore)
00 1F (2) = "2"
00 00 (ignore)
...and so on.
I'm doing some Office automation with MS Word from a C# application, and I'm finding that Word sometimes hangs. I can't reproduce the hang in a developer environment, so I'm hoping I can diagnose exactly why Word is hanging by taking a core dump and then analyzing it using WinDbg.
If I run kb, I get this stack trace (I've left off everything after the warning as it's probably irrelevant):
ChildEBP RetAddr Args to Child
003bc94c 762ed846 00037b72 00000008 00000000 user32!NtUserWaitMessage+0x15
003bc988 762eda5c 00047b12 00037b72 00000008 user32!DialogBox2+0x222
003bc9b4 762ed98a 59870000 0089aa30 00037b72 user32!InternalDialogBox+0xe5
003bc9d4 762ed70e 59870000 0089aa30 00037b72 user32!DialogBoxIndirectParamAorW+0x37
003bc9f4 59acdf5e 59870000 0089aa30 00037b72 user32!DialogBoxIndirectParamW+0x1b
WARNING: Stack unwind information not available. Following frames may be wrong.
So this seems to indicate that Word is hanging because it's showing a dialog box. How can I get the contents of that dialog box?
If I look at the memory at address 0089aa30, I see this:
........................3....
.M.i.c.r.o.s.o.f.t. .W.o.r.d.
........T.a.h.o.m.a..........
....P#.!.*...........O.K.....
...........PW.!.*...........&
.H.e.l.p..................P..
.............................
....P+...r.......M.S.O.U.N.I.
S.T.A.T...W.o.r.d. .c.a.n.n.o
.t. .o.p.e.n. .t.h.e. .e.x.i.
s.t.i.n.g. .f.i.l.e..... .(.N
.o.r.m.a.l.)................#
..+.........M.S.O.U.N.I.S.T.A
.T...2.0.0.5.2.1.............
So to me this says that the message in the dialog is "Word cannot open the existing file (Normal)".
Am I on the right track? Am I looking at the right bit of memory?
Is there any way to get the exact memory address of the message? (I feel like I'm guessing a bit, because the above message just happens to be close by in memory to a parameter to DialogBoxIndirectParam.) I have looked at the MSDN docs for DialogBoxIndirectParam, hoping to figure out exactly where in memory I should expect to see the dialog's message, but didn't get very far.
Edit: After seeing blabb's (absolutely incredible) answer, I have attempted to perform the same steps in WinDbg for my MS Word core dump. Here's the output:
0:000> ub 762ed98a
user32!DialogBoxIndirectParamAorW+0x1f:
762ed972 83c801 or eax,1
762ed975 50 push eax
762ed976 ff7518 push dword ptr [ebp+18h]
762ed979 ff7514 push dword ptr [ebp+14h]
762ed97c ff7510 push dword ptr [ebp+10h]
762ed97f ff750c push dword ptr [ebp+0Ch]
762ed982 ff7508 push dword ptr [ebp+8]
762ed985 e809000000 call user32!InternalDialogBox (762ed993)
0:000> .frame /r 2
02 003bc9b4 762ed98a user32!InternalDialogBox+0xe5
eax=00000000 ebx=00037b72 ecx=00000000 edx=00000000 esi=003bc97c edi=003bc918
eip=762eda5c esp=003bc990 ebp=003bc9b4 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
user32!InternalDialogBox+0xe5:
762eda5c 5f pop edi
0:000> dc /c 1 003bc990 l8
003bc990 00047b12 .{..
003bc994 00037b72 r{..
003bc998 00000008 ....
003bc99c 00000000 ....
003bc9a0 00000000 ....
003bc9a4 00037b72 r{..
003bc9a8 003bcb98 ..;.
003bc9ac 00000000 ....
I know I'm looking at the wrong bit of memory (i.e. the address I'm passing to dc is incorrect), but I don't know why. I used ".frame /r 2" to fetch the address of esp, what did I do wrong?
The InternalDialogBox Api Takes Six Arguments
C:\>cdb -c ".fnent user32!InternalDialogbox;q" cdb | grep Params
Params: 0n6 (0x18 bytes)
you can try deciphering this call by doing a backward disassembly on the return address on stack
0:000> kb 1
# ChildEBP RetAddr Args to Child
00 0017fad8 778be0d5 77860000 001ec4f0 00000000 USER32!InternalDialogBox
0:000> ub #$ra
USER32!SoftModalMessageBox+0x66d:
778be0b8 e87c48fdff call USER32!MessageBeep (77892939)
778be0bd 56 push esi
778be0be 53 push ebx
778be0bf 6848d68b77 push offset USER32!MB_DlgProc (778bd648)
778be0c4 ff75ac push dword ptr [ebp-54h]
778be0c7 ff75e4 push dword ptr [ebp-1Ch]
778be0ca ff35d0908c77 push dword ptr [USER32!hmodUser (778c90d0)]
778be0d0 e8a059fdff call USER32!InternalDialogBox (77893a75)
in a crash dump you can substitute address instead of register or you can
do .frame /r {frame number} to fetch the address of esp
0:000> dc /c 1 #esp l8
0017fadc 778be0d5 ...w
0017fae0 77860000 ...w
0017fae4 001ec4f0 ....
0017fae8 00000000 ....
0017faec 778bd648 H..w
0017faf0 0017fcd8 ....
0017faf4 00000000 ....
0017faf8 00000001 ....
1) The first argument is hModUser a global variable
2) The fourth argument is a DialogProc callback that is documented
3) 3rd and 6th argument are NULL
the second argument consits of an array of DLGTEMPLATE followed by DLGITEMTEMPLATE structure read the document for the format of this variable sized array
the fifth argument is MSGBOXPARAMS structure
a sample dump and deciphering the dump for the variable sized array as follows
0:000> db 1ec4f0 l f8
001ec4f0 c5 01 c8 80 00 00 00 00-02 00 1a 01 9b 00 a7 00 ................
001ec500 3e 00 00 00 00 00 54 00-68 00 69 00 73 00 20 00 >.....T.h.i.s. .
001ec510 69 00 73 00 20 00 4d 00-79 00 20 00 43 00 61 00 i.s. .M.y. .C.a.
001ec520 70 00 74 00 69 00 6f 00-6e 00 20 00 46 00 6f 00 p.t.i.o.n. .F.o.
001ec530 72 00 20 00 32 00 30 00-31 00 35 00 20 00 43 00 r. .2.0.1.5. .C.
001ec540 6f 00 6d 00 6d 00 75 00-6e 00 69 00 74 00 79 00 o.m.m.u.n.i.t.y.
001ec550 20 00 76 00 73 00 00 00-ff 7f 00 00 01 00 03 50 .v.s..........P
001ec560 00 00 00 00 71 00 2a 00-32 00 0e 00 01 00 ff ff ....q.*.2.......
001ec570 80 00 4f 00 4b 00 00 00-00 00 00 00 80 20 02 50 ..O.K........ .P
001ec580 00 00 00 00 07 00 0e 00-8c 00 09 00 ff ff ff ff ................
001ec590 82 00 54 00 68 00 69 00-73 00 20 00 69 00 73 00 ..T.h.i.s. .i.s.
001ec5a0 20 00 6d 00 79 00 20 00-66 00 69 00 72 00 73 00 .m.y. .f.i.r.s.
001ec5b0 74 00 20 00 54 00 65 00-73 00 74 00 20 00 77 00 t. .T.e.s.t. .w.
001ec5c0 69 00 74 00 68 00 20 00-32 00 30 00 31 00 35 00 i.t.h. .2.0.1.5.
001ec5d0 20 00 63 00 6f 00 6d 00-6d 00 75 00 6e 00 69 00 .c.o.m.m.u.n.i.
001ec5e0 74 00 79 00 00 00 00 00 t.y.....
0:000> dt ConsoleApplication1!DLGTEMPLATE 1ec4f0
+0x000 style : 0x80c801c5
+0x004 dwExtendedStyle : 0
+0x008 cdit : 2
+0x00a x : 0x11a
+0x00c y : 0x9b
+0x00e cx : 0xa7
+0x010 cy : 0x3e
0:000> du 1ec504
001ec504 ""
0:000> du 1ec506
001ec506 "This is My Caption For 2015 Comm"
001ec546 "unity vs"
0:000> dt ConsoleApplication1!DLGITEMTEMPLATE 1ec55c
+0x000 style : 0x50030001
+0x004 dwExtendedStyle : 0
+0x008 x : 0x71
+0x00a y : 0x2a
+0x00c cx : 0x32
+0x00e cy : 0xe
+0x010 id : 1
0:000> $$ 80 is a predfined button and the text is OK
0:000> dt ConsoleApplication1!DLGITEMTEMPLATE 1ec57c
+0x000 style : 0x50022080
+0x004 dwExtendedStyle : 0
+0x008 x : 7
+0x00a y : 0xe
+0x00c cx : 0x8c
+0x00e cy : 9
+0x010 id : 0xffff
0:000> $$ 82 is a predfined static text and the text is
0:000> du 1ec592
001ec592 "This is my first Test with 2015 "
001ec5d2 "community"
here is a MSGBOXPARAMSW dump
0:000> dt ConsoleApplication1!MSGBOXPARAMSW 0017fcd8
+0x000 cbSize : 0x28
+0x004 hwndOwner : (null)
+0x008 hInstance : (null)
+0x00c lpszText : 0x01172150 "This is my first Test with 2015 community"
+0x010 lpszCaption : 0x011720f8 "This is My Caption For 2015 Community vs"
+0x014 dwStyle : 0
+0x018 lpszIcon : (null)
+0x01c dwContextHelpId : 0
+0x020 lpfnMsgBoxCallback : (null)
+0x024 dwLanguageId : 0
EDIT
created a dump from taskmanager and loaded it
0:000> .shell -ci "version" grep DMP
Full memory user mini dump: C:\Users\HP\Desktop\cons.DMP
command line: 'windbg -z cons.DMP' Debugger Process 0x17CC
.shell: Process exited
just to be sure resetting the context record
0:000> .cxr
Resetting default scope
dumping stacktrace 9the frame of interest is not at top here)
0:000> kb 5
# ChildEBP RetAddr Args to Child
00 0028f6fc 778766c9 7789382a 00000000 00000000 ntdll!KiFastSystemCallRet
01 0028f700 7789382a 00000000 00000000 00000000 user32!NtUserWaitMessage+0xc
02 0028f734 77893b27 00aa0350 00000000 00000000 user32!DialogBox2+0x207
03 0028f758 778be0d5 77860000 002f63f0 00000000 user32!InternalDialogBox+0xcb
04 0028f7fc 778be659 00000000 69d52104 69d52108 user32!SoftModalMessageBox+0x68a
overriding local context for frame number of interest
0:000> .frame /c /r 04
04 0028f7fc 778be659 user32!SoftModalMessageBox+0x68a
eax=00000001 ebx=0028f958 ecx=0028f458 edx=77ad70f4 esi=005fab18 edi=00000001
eip=778be0d5 esp=0028f760 ebp=0028f7fc iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
user32!SoftModalMessageBox+0x68a:
778be0d5 8945e8 mov dword ptr [ebp-18h],eax ss:0023:0028f7e4=00000000
checking esp you can use esp as it is instead of groping for address
0:000> dc /c 1 #esp l 8
0028f760 77860000 ...w
0028f764 002f63f0 .c/.
0028f768 00000000 ....
0028f76c 778bd648 H..w
0028f770 0028f958 X.(.
0028f774 00000000 ....
0028f778 00000001 ....
0028f77c 0028f958 X.(.
dumping DLGTEMPLATE second arg
0:000> db 2f63f0 lf8
002f63f0 c5 01 c8 80 00 00 00 00-02 00 1a 01 9b 00 a7 00 ................
002f6400 3e 00 00 00 00 00 54 00-68 00 69 00 73 00 20 00 >.....T.h.i.s. .
002f6410 69 00 73 00 20 00 4d 00-79 00 20 00 43 00 61 00 i.s. .M.y. .C.a.
002f6420 70 00 74 00 69 00 6f 00-6e 00 20 00 46 00 6f 00 p.t.i.o.n. .F.o.
002f6430 72 00 20 00 32 00 30 00-31 00 35 00 20 00 43 00 r. .2.0.1.5. .C.
002f6440 6f 00 6d 00 6d 00 75 00-6e 00 69 00 74 00 79 00 o.m.m.u.n.i.t.y.
002f6450 20 00 76 00 73 00 00 00-ff 7f 00 00 01 00 03 50 .v.s..........P
002f6460 00 00 00 00 71 00 2a 00-32 00 0e 00 01 00 ff ff ....q.*.2.......
002f6470 80 00 4f 00 4b 00 00 00-00 00 00 00 80 20 02 50 ..O.K........ .P
002f6480 00 00 00 00 07 00 0e 00-8c 00 09 00 ff ff ff ff ................
002f6490 82 00 54 00 68 00 69 00-73 00 20 00 69 00 73 00 ..T.h.i.s. .i.s.
002f64a0 20 00 6d 00 79 00 20 00-66 00 69 00 72 00 73 00 .m.y. .f.i.r.s.
002f64b0 74 00 20 00 54 00 65 00-73 00 74 00 20 00 77 00 t. .T.e.s.t. .w.
002f64c0 69 00 74 00 68 00 20 00-32 00 30 00 31 00 35 00 i.t.h. .2.0.1.5.
002f64d0 20 00 63 00 6f 00 6d 00-6d 00 75 00 6e 00 69 00 .c.o.m.m.u.n.i.
002f64e0 74 00 79 00 00 00 00 00 t.y.....
typeinfo (you need proper private pdb or hack load a binary which you compiled into address space or add the DLGTEMPLATE struct into the official pdb for user32 from ms ( i thought i had a post explaining this in se but i cant seem to find) ill link it later if i find it or sitesearch google for how to add typeinfo to pdb in site:woodmann.com
0:000> dt cons!DLGTEMPLATE poi(#esp+4)
+0x000 style : 0x80c801c5
+0x004 dwExtendedStyle : 0
+0x008 cdit : 2
+0x00a x : 0n282
+0x00c y : 0n155
+0x00e cx : 0n167
+0x010 cy : 0n62
0:000> du poi(#esp+4)+16
002f6406 "This is My Caption For 2015 Comm"
002f6446 "unity vs"
edit 2 this is for a live session in dump mode you need to modify a pdb as you cant use execution commands
we are in a live dbg session we can use step commands which arent available in dmp mode
0:000> .tlist -c -v
0n3324 Msgbox.exe
Session: 1 User: HP-PC\HP Command Line: Msgbox.exe
lets search for some typeinfo we need
0:000> dt *!*DLGTEMPLATE*
0:000> $$ no the thype info is not available
0:000> $$ we know ole32.dll has it
0:000> $$ so lets hack load it
allocate some memory
0:000> .dvalloc 1000
Allocated 1000 bytes starting at 00020000
save the current eip
0:000> ? #eip
Evaluate expression: 2008221094 = 77b305a6
embed the modulename string at some address in the allocated memory
0:000> ea 20100 "ole32.dll"
0:000> db 20100 l20
00020100 6f 6c 65 33 32 2e 64 6c-6c 00 00 00 00 00 00 00 ole32.dll.......
00020110 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
Assemble a LoadLibraryA call inline
0:000> a 20000
00020000 push 20100
push 20100
00020005 call kernel32!LoadLibraryA
call kernel32!LoadLibraryA
0002000a
change eip to the detour address
0:000> r eip = 20000
single step to load a dll into the address space
0:000> p
eax=00000000 ebx=00000000 ecx=0026f80c edx=77ad70f4 esi=fffffffe edi=00000000
eip=00020005 esp=0026f824 ebp=0026f854 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
00020005 e852395877 call kernel32!LoadLibraryA (775a395c)
0:000> p
ModLoad: 77930000 77a8c000 C:\Windows\system32\ole32.dll
ModLoad: 75ee0000 75f81000 C:\Windows\system32\RPCRT4.dll
ModLoad: 77530000 7754f000 C:\Windows\system32\IMM32.DLL
ModLoad: 76030000 760fc000 C:\Windows\system32\MSCTF.dll
eax=77930000 ebx=00000000 ecx=77ae6570 edx=002b0174 esi=fffffffe edi=00000000
eip=0002000a esp=0026f828 ebp=0026f854 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
0002000a 0000 add byte ptr [eax],al ds:0023:77930000=4d
reset eip back
0:000> r eip = 77b305a6
we research the typeinfo and bingo we have it
0:000> dt *!*DLGTEMPLATE*
ole32!LPDLGTEMPLATEA
ole32!LPDLGTEMPLATE
ole32!LPDLGTEMPLATEW
ole32!LPCDLGTEMPLATE
ole32!LPCDLGTEMPLATEA
ole32!LPCDLGTEMPLATEW
ole32!DLGTEMPLATE
ole32!DLGTEMPLATE
I trying to write a menubar app to get control over my lights via Mac.
I'm using the system of milight (limitless, easybulbs...).
They have an open system were you can send commands via UDP.
I'm able to control my lights via python-limitless library in python, so I know the networking thing such as IP and port is right.
So I think I do anything wrong with this UDP stuff I never worked with.
I'm trying to use SwiftSocket library to send my commands but nothing happens, I've been trying it since 2 days.
Here ist what I'm trying:
let host = "192.168.2.102"
let port = 5987
var client: UDPClient!
#IBAction func lightOn(_ sender: NSButton) {
let bridgeon: [UInt8] = [0x31, 0x00, 0x00, 0x00, 0x03, 0x03, 0x00, 0x00, 0x00, 0x01]
let rgbwon: [UInt8] = [0x31, 0x00, 0x00, 0x07, 0x03, 0x01, 0x00, 0x00, 0x00, 0]
print("Licht an")
print(client.send(data: bridgeon))
sleep(1)
print(client.send(data: rgbwon))
sleep(1)
}
#IBAction func lightOff(_ sender: NSButton) {
print("Licht aus")
}
override func viewDidLoad() {
super.viewDidLoad()
client = UDPClient(address: host, port: Int32(port))
}
When I compare this with the complexity of the pythonlibrary I'm sure I forget something important. I haven't worked with networks yet so be lenient with me.
thanks and greetings.
I'm a bit late, but I hope it can help you :
Before sending your lighton request you have to send a first request to get, the wifi bridge session. You also need to compute what Milight called the "checksum" based on your request.
You also make sure about what kind of bulb you have, is it WW bulb or CW? I was stuck for severals days because I was sending wrong request..
I made an implementation, It's in php but you can use it same way in Objective-C.
Check it out : https://github.com/winosaure/MilightAPI
UPDATE :
According to limitlessled "documentation" (http://www.limitlessled.com/dev/) this is how a request is composed :
UDP Hex Send Format: 80 00 00 00 11 {WifiBridgeSessionID1}
{WifiBridgeSessionID2} 00 {SequenceNumber} 00 {COMMAND} {ZONE NUMBER}
00 {Checksum}
This is why you must get wifibridge session first then you need to calculate the checksum.
Let me take one example about how to turn on the light.
The documentation says that :
31 00 00 08 04 01 00 00 00 = Light ON
31 00 00 08 04 01 00 00 00 refer to {COMMAND} above.
So far the full request must be :
80 00 00 00 11 {WifiBridgeSessionID1} {WifiBridgeSessionID2} 00 {SequenceNumber} 00 31 00 00 08 04 01 00 00 00 {ZONE NUMBER} 00 {Checksum}
Now let's get the Wifibridge session. The documention says :
to get the WifiBridgeSessionID1 and WifiBridgeSessionID2 send this
command UDP.
SEND hex bytes: 20 00 00 00 16 02 62 3A D5 ED A3 01 AE 08
2D 46 61 41 A7 F6 DC AF (D3 E6) 00 00 1E <-- Send this to the ip
address of the wifi bridge v6
That's why I'm doing this:
private function getWifiBridgeSession()
{
$command = array (
0x20,0x00, 0x00,
0x00, 0x16, 0x02,
0x62, 0x3A, 0xD5,
0xED, 0xA3, 0x01,
0xAE, 0x08, 0x2D,
0x46, 0x61, 0x41,
0xA7, 0xF6, 0xDC,
0xAF, 0xD3, 0xE6,
0x00, 0x00, 0x1E);
return $this->sendCommand($command);
}
Once you send a UDP request with this command, you will get a result.
The Wifi Bridge session1 refers to the 20th byte of the response and WifiBridge Session2 will refer to the 21th byte response (Don't forget that we start to count from 0, so you must take something like "response[19]" and "response[20]").
Let's say, after sending this request I get this response :
28 00 00 00 11 00 02 AC CF 23 F5 7A D4 69 F0 3C 23 00 01 05 00
So my "WifiBridgesession1" is 0x05 and "Wifibridgesession2" is 0x00
So now our request to "turn on" the light is :
80 00 00 00 11 0x05 0x00 00 {SequenceNumber} 00 31 00 00 08 04 01 00 00 00 {ZONE NUMBER} 00 {Checksum}
So now we need to find out {SequenceNumber} {Zone Number} and {Checksum}
What is a "Sequence Number"?
The doc says :
Sequential byte just helps with keeping commands in the correct order,
and it helps to ignore duplicate packets already received. increment
this byte for each new command by 1.
So put what you want and increase this value to 1 for each request. (Personnally I always send 0x01).
"Zone number" refers to which zone you synchronized your light.
Valid List for {ZONE NUMBER} 0x00 All 0x01 Zone1 0x02 Zone2 0x03
Zone3 0x04 Zone4
Let's say, our "zone" is 0x01.
Almost done. we just need now to calculate the "checksum".
The doc says :
take the 9 bytes of the command, and 1 byte of the zone, and add the 0
= the checksum = (checksum & 0xFF) e.g. SUM((31 00 00 08 04 01 00 00 00)(command) 01(zone) 00) = 3F(chksum)
So the checksum for our command is :
31+00+00+08+04+01+00+00+00+01+00 = 0x54
I add all byte of the command (turn on) + 0x01 for the zone + 0x00
So now we have everything and the full request to turn on the light is :
80 00 00 00 11 05 00 00 01 00 31 00 00 08 04 01 00 00 00 01 00 54
That's it.
Note : Do not just copy and paste the request, I calculated the value based on example, the request to turn on the light will change each time, based on what you will calculate.
Maybe you got noticed that I wrote "00 31 00 00 08 04 01 00 00 00" to do the "turn on" command, this will work only for CW bulb. The doc does not specify that...
The same Command for WW bulb is 00 31 00 00 07 03 01 00 00 00
So the full command for WW bulb will be :
80 00 00 00 11 05 00 00 01 00 31 00 00 07 03 01 00 00 00 01 00 54
What is the difference between CW and WW bulb?
I can tell that CW refers to "Cold White" and WW to "Warm White". But as I am not an expert in "led bulb" I cannot explain more, I don't know why we need to write a different request for both, either.
Anyway I wish I was clear enough.
Let me know how things are working.