Wireshask - Get rtmp url from this stream? - http

I have been use to listen to a radio for quite a long time from WMP. But then they changed their structure and move to FMS server, which stream RTMP. I can only listen from their website. As much as posible I could like to get the RTMP url so that I could fire up my VLC.
http://vov.vn/RadioPlayer.aspx?c=vov3
This is the player, the channel is VOV3.
I try to use wireshark but I couldn't get any URL, host or request URI from it.
Inspect into the stream packets, it's all MP3, and the port is 8080 (http-alt). IP is 123.30.50.46
However there are several interesting packets from the capture:
0080 00 07 5f 72 65 73 75 6c 74 00 3f f0 00 00 00 00 .._resul t.?.....
0090 00 00 03 00 06 66 6d 73 56 65 72 02 00 0e 46 4d .....fms Ver...FM
00a0 53 2f 34 2c 30 2c 33 2c 34 30 31 30 00 0c 63 61 S/4,0,3, 4010..ca
00b0 70 61 62 69 6c 69 74 69 65 73 00 40 6f e0 00 00 pabiliti es.#o...
00c0 00 00 00 00 04 6d 6f 64 65 00 3f f0 00 00 00 00 .....mod e.?.....
00d0 00 00 00 00 09 03 00 05 6c 65 76 65 6c 02 00 06 ........ level...
00e0 73 74 61 74 75 73 00 04 63 6f 64 65 02 00 1d 4e status.. code...N
00f0 65 74 43 6f 6e 6e 65 63 74 69 6f 6e 2e 43 6f 6e etConnec tion.Con
0100 6e 65 63 74 2e 53 75 63 63 65 73 73 00 0b 64 65 nect.Suc cess..de
0110 73 63 72 69 70 74 69 6f 6e 02 00 15 43 6f 6e 6e scriptio n...Conn
0120 65 63 74 69 6f 6e 20 73 75 63 63 65 65 64 65 64 ection s ucceeded
0130 2e 00 0e 6f 62 6a 65 63 74 45 6e 63 6f 64 69 6e ...objec tEncodin
0140 67 00 00 00 00 00 00 00 00 00 00 04 64 61 74 61 g....... ....data
0150 08 00 00 00 00 00 07 76 65 72 73 69 6f 6e 02 00 .......v ersion..
0160 0a 34 2c 30 2c 33 2c 34 30 31 30 00 00 09 00 00 .4,0,3,4 010.....
0070 02 00 08 6f 6e 53 74 61 74 75 73 00 00 00 00 00 ...onSta tus.....
0080 00 00 00 00 05 03 00 05 6c 65 76 65 6c 02 00 06 ........ level...
0090 73 74 61 74 75 73 00 04 63 6f 64 65 02 00 14 4e status.. code...N
00a0 65 74 53 74 72 65 61 6d 2e 50 6c 61 79 2e 52 65 etStream .Play.Re
00b0 73 65 74 00 0b 64 65 73 63 72 69 70 74 69 6f 6e set..des cription
00c0 02 00 1b 50 6c 61 79 69 6e 67 20 61 6e 64 20 72 ...Playi ng and r
00d0 65 73 65 74 74 69 6e 67 20 76 6f 76 33 2e 00 07 esetting vov3...
00e0 64 65 74 61 69 6c 73 02 00 04 76 6f 76 33 00 08 details. ..vov3..
00f0 63 6c 69 65 6e 74 69 64 02 00 08 70 41 41 37 41 clientid ...pAA7A
0050 08 6f 6e 53 74 61 74 75 73 00 00 00 00 00 00 00 .onStatu s.......
0060 00 00 05 03 00 05 6c 65 76 65 6c 02 00 06 73 74 ......le vel...st
0070 61 74 75 73 00 04 63 6f 64 65 02 00 14 4e 65 74 atus..co de...Net
0080 53 74 72 65 61 6d 2e 50 6c 61 79 2e 53 74 61 72 Stream.P lay.Star
0090 74 00 0b 64 65 73 63 72 69 70 74 69 6f 6e 02 00 t..descr iption..
00a0 15 53 74 61 72 74 65 64 20 70 6c 61 79 69 6e 67 .Started playing
00b0 20 76 6f 76 33 2e 00 07 64 65 74 61 69 6c 73 02 vov3... details.
00c0 00 04 76 6f 76 33 00 08 63 6c 69 65 6e 74 69 64 ..vov3.. clientid
00d0 02 00 08 70 41 41 37 41 52 44 41 00 00 09 04 00 ...pAA7A RDA.....
00e0 00 00 00 00 18 12 01 00 00 00 02 00 11 7c 52 74 ........ .....|Rt
00f0 6d 70 53 61 6d 70 6c 65 41 63 63 65 73 73 01 00 mpSample Access..
0100 01 00 04 00 00 00 00 01 44 12 01 00 00 00 02 00 ........ D.......
0110 0a 6f 6e 4d 65 74 61 44 61 74 61 03 00 06 61 75 .onMetaD ata...au
0120 74 68 6f 72 02 00 00 00 09 63 6f 70 79 72 69 67 thor.... .copyrig
0130 68 74 02 00 00 00 0b 64 65 73 63 72 69 70 74 69 ht.....d escripti
0140 6f 6e 02 00 00 00 08 6b 65 79 77 6f 72 64 73 02 on.....k eywords.
0150 00 00 00 06 72 61 74 69 6e 67 02 00 00 00 05 74 ....rati ng.....t
0160 69 74 6c 65 02 00 00 00 0a 70 72 65 73 65 74 6e itle.... .presetn
0170 61 6d 65 02 00 06 43 75 73 74 6f 6d 00 0c 63 72 ame...Cu stom..cr
0180 65 61 74 69 6f 6e 64 61 74 65 02 00 19 54 68 75 eationda te...Thu
0190 20 41 75 67 20 32 35 20 31 38 3a 32 34 3a 31 33 Aug 25 18:24:13
01a0 20 32 30 31 31 0a 00 0b 61 75 64 69 6f 64 65 76 2011... audiodev
01b0 69 63 65 02 00 1f 53 6f 75 6e 64 20 42 6c 61 73 ice...So und Blas
01c0 74 65 72 20 58 2d 46 69 20 58 74 72 65 6d 65 20 ter X-Fi Xtreme
01d0 41 75 64 69 6f 00 0f 61 75 64 69 6f 73 61 6d 70 Audio..a udiosamp
01e0 6c 65 72 61 74 65 00 40 e5 88 80 00 00 00 00 00 lerate.# ........
01f0 0d 61 75 64 69 6f 63 68 61 6e 6e 65 6c 73 00 40 .audioch annels.#
0200 00 00 00 00 00 00 00 00 10 61 75 64 69 6f 69 6e ........ .audioin
0210 70 75 74 76 6f 6c 75 6d 65 00 40 51 40 00 00 00 putvolum e.#Q#...
0220 00 00 00 0c 61 75 64 69 6f 63 6f 64 65 63 69 64 ....audi ocodecid
0230 02 00 04 2e 6d 70 33 00 0d 61 75 64 69 6f 64 61 ....mp3. .audioda
0240 74 61 72 61 74 65 00 40 60 00 00 00 00 00 00 00 tarate.# `.......
Could someone be able to get the URL from this stream?

Just been on a huge mission round the houses with Wireshark and eventually reached a dead end because it never does a DNS lookup for the RTMP stream. Then I realised that it must therefore be hard-coded with an IP address. If you view the source on the page you will find this...
so.addParam('flashvars','&file=vov3.flv&streamer=rtmp://123.30.50.46:8080/live&skin=/Images/modieus.swf&autostart=true');
So I guess the URL would be
rtmp://123.30.50.46:8080/live/vov3.flv
I can't get it to work in my VLC but I think that is a problem with my VLC rather than the URL.
If you need any more info about the the stream or generally want to have a play, check this out.

Related

Detect tcp protocol, or fresh idea to reverse it

im trying to reverse one app, and wanted to ask, maybe some one can help with fresh idea, or already know what is used here.
So the case, i have client and server, now i have written mitm app, and i can see the packets.
Tha packets order is
s2c: sending rsa key
c2s: sending some always static data, encrypted with rsa
s2c: sending some response, seems like an packet without body (im here)
c2s: sending data, and here is problem, that this packet is not encrypted as packet 2
c2s: sending response
this is packet header
50 50 00 00 40 00 50 00 00 00 00 00 ... rest is body
lets divide it
50 50 - this is always same
00 00 - this is some packet flag, cause always after packet 3, it becomes x04 00
40 00 - this is length 100%
50 00 - packet code i think
00 00 00 00 - i dont know what i this
body - is not readable, but also is not encrypted with rsa
here is example of stream
**s2c packet 1**
2023/01/24 21:32:56 Received: 176
00000000 *50 50 00 00 a4 00 01 00 00 00 00 00* a2 00 2d 2d |PP............--|
00000010 2d 2d 2d 42 45 47 49 4e 20 52 53 41 20 50 55 42 |---BEGIN RSA PUB|
00000020 4c 49 43 20 4b 45 59 2d 2d 2d 2d 2d 0a 4d 45 63 |LIC KEY-----.MEc|
00000030 43 51 51 43 71 49 4e 36 37 76 45 52 47 37 34 49 |CQQCqIN67vERG74I|
00000040 64 77 38 6d 76 6c 66 6d 45 31 38 31 31 56 74 2b |dw8mvlfmE1811Vt+|
00000050 53 76 66 67 73 36 43 68 59 51 78 4e 5a 52 57 74 |Svfgs6ChYQxNZRWt|
00000060 7a 31 6f 62 50 53 69 34 62 75 78 72 41 0a 5a 6d |z1obPSi4buxrA.Zm|
00000070 6d 77 32 4e 69 38 44 59 74 67 6d 77 54 74 48 51 |mw2Ni8DYtgmwTtHQ|
00000080 66 6b 6d 35 65 59 2f 76 63 54 41 67 49 44 43 51 |fkm5eY/vcTAgIDCQ|
00000090 3d 3d 0a 2d 2d 2d 2d 2d 45 4e 44 20 52 53 41 20 |==.-----END RSA |
000000a0 50 55 42 4c 49 43 20 4b 45 59 2d 2d 2d 2d 2d 0a |PUBLIC KEY-----.|
2023/01/24 21:32:56 RSA Key chaged - here i changed key to my
**c2s packet 2**
2023/01/24 21:32:56 Received: 76
00000000 *50 50 00 00 40 00 50 00 00 00 00 00* 97 4a 85 34 |PP..#.P......J.4|
00000010 e6 e0 f8 56 d6 5b 12 a4 4b 3f e2 f3 c7 b4 a1 fc |...V.[..K?......|
00000020 c7 fe b8 88 bc b7 8b 93 89 c2 7f 02 09 7b 52 4a |.............{RJ|
00000030 23 be a4 47 eb b8 02 f5 0a 62 9a 88 15 13 12 de |#..G.....b......|
00000040 a4 94 2c 3a 0a 34 47 bb 13 6f d4 ae |..,:.4G..o..|
2023/01/24 21:32:56 Header: 76
00000000 *50 50 00 00 40 00 50 00 00 00 00 00* |PP..#.P.....|
2023/01/24 21:32:56 Encoded with my key
00000000 *97 4a 85 34 e6 e0 f8 56 d6 5b 12 a4* 4b 3f e2 f3 |.J.4...V.[..K?..|
00000010 c7 b4 a1 fc c7 fe b8 88 bc b7 8b 93 89 c2 7f 02 |................|
00000020 09 7b 52 4a 23 be a4 47 eb b8 02 f5 0a 62 9a 88 |.{RJ#..G.....b..|
00000030 15 13 12 de a4 94 2c 3a 0a 34 47 bb 13 6f d4 ae |......,:.4G..o..|
2023/01/24 21:32:56 Decoded body
00000000 29 00 00 00 23 48 00 00 be 18 00 00 84 67 00 00 |)...#H.......g..|
2023/01/24 21:32:56 Encoded with original key
00000000 0a cb d2 7f f6 a3 8b 57 2c 6b e8 6d ed f0 c1 36 |.......W,k.m...6|
00000010 e4 c8 00 9d ca 55 41 62 ef 4b 72 91 7c fc 7b 1d |.....UAb.Kr.|.{.|
00000020 e4 5c f0 2b ce 86 01 79 ae b8 13 dd 51 a0 30 c5 |.\.+...y....Q.0.|
00000030 6f 77 fa 11 ed 03 7b 2c 77 7c 5b 7e 61 6f 86 9d |ow....{,w|[~ao..|
**s2c packet 3**
2023/01/24 21:32:56 Received: 12
00000000 *50 50 00 00 00 00 02 00 00 00 00 00* |PP..........|
**c2s packet 4**
2023/01/24 21:32:56 Not decoding next packet
2023/01/24 21:32:56 Received: 174
00000000 *50 50 04 00 a2 00 01 30 00 00 00 00* 00 9f 53 ab |PP.....0......S.|
00000010 c8 58 49 ea 4d fa 18 f4 f1 fc 9a 3c 04 ca 11 94 |.XI.M......<....|
00000020 ab ec ba 1d c6 f0 5d e0 1f d6 87 2d de 0c 97 eb |......]....-....|
00000030 29 b7 d1 dc 48 38 f4 63 74 29 e2 ea 9f 81 a8 59 |)...H8.ct).....Y|
00000040 47 75 32 0d 53 0e 55 3e cd 7b 89 d9 c3 22 d5 39 |Gu2.S.U>.{...".9|
00000050 c4 18 a5 c7 e2 eb 3a 9e 72 13 36 c3 52 f5 e6 7d |......:.r.6.R..}|
00000060 9b bf 37 06 e5 e9 4c 74 ac 85 37 85 94 81 37 67 |..7...Lt..7...7g|
00000070 f9 28 60 c7 0a ca 4c 5a 57 20 d6 ce 7c 91 58 6b |.(`...LZW ..|.Xk|
00000080 56 af 96 a8 e4 b5 8c 19 2e 9a 8c fa a6 c2 08 24 |V..............$|
00000090 ab 97 5d be 74 c2 19 d2 bd f1 93 5f a5 65 c5 7c |..].t......_.e.||
000000a0 fa bb 46 07 80 fd b6 79 5c 19 6f 65 54 35 |..F....y\.oeT5|
**s2c packet 5**
2023/01/24 21:32:56 Received: 174
00000000 *50 50 04 00 a2 00 01 40 00 00 00 00* 00 9e e7 03 |PP.....#........|
00000010 1b aa 67 36 1e 6f 34 20 c3 7c a9 85 93 74 b7 53 |..g6.o4 .|...t.S|
00000020 cc 10 68 90 ec 41 54 68 bb 9e 3d 41 c9 3f db 41 |..h..ATh..=A.?.A|
00000030 09 b9 ae 6a 9b f9 5c 0f 47 c6 4b bd 94 08 20 b0 |...j..\.G.K... .|
00000040 2e f2 6e 40 11 b6 14 8b e0 51 89 db 0c e0 c8 5b |..n#.....Q.....[|
00000050 92 1f a3 08 90 05 5c b5 bb bb 50 c0 3e f6 ee e8 |......\...P.>...|
00000060 63 bd 23 74 53 24 8f a3 0b 4e 72 12 a0 0e ac 96 |c.#tS$...Nr.....|
00000070 03 2c e8 31 6a 34 10 84 63 7a e1 32 42 d3 69 17 |.,.1j4..cz.2B.i.|
00000080 73 df a4 89 35 90 0f 92 06 d7 3b 2e 3c 3d 6e 7e |s...5.....;.<=n~|
00000090 db 73 cb f0 96 95 df 84 af 20 b7 7b 7c 64 61 a9 |.s....... .{|da.|
000000a0 b2 0e 9d 1e bc 57 73 5f f0 bc a5 aa b8 36 |.....Ws_.....6|
Maybe some one can identify protocol by packet header, cause i havent seen something similar before.
Thank you
i know that only packet 2 is encrypted, cause i changed rsa key to my key, and decoded data, its not work with other packets.

Recovering local storage from Firefox extension

I'm trying to recover vault storage from MetaMask for Firefox on a broken Mac, but only have file system access so can't follow the usual recovery steps here.
I've also tried copying the extension storage to a fresh install, but MetaMask won't launch.
On another computer, I've followed the usual recovery method linked to get a known-good export, which looks something like:
{
...
"KeyringController": {
"vault": "{\"data\":\"wLLUOXsS8u82TEDMjT1UNNtpANP2Eu6VfqbhHFTI3s+xKomLCXxnRtoPKlOlUDBPM7sOtIr8qoJofBqREfO9pN50vaEt3jw9sqUOk7Xdi0GHLpndlJvTmkI15aGk6udWc5MX/CW+F1KfJZbW7VpSMrrQPpfjULidxBLDfKac/wF9gF8pY4w1s9puVEgCgXAHYsX9bbR68vqMDLZmpr6NG5QCkFg0clLx6d6tddmMEg11hv+CrGI=\",\"iv\":\"8zjDMB77cQa1HX1B0gs+pQ==\",\"salt\":\"8VHAOfYllhPFs7zTgCr1PuZm7a4v8IFhoeqa2+7ZThQ=\"}"
},
...
}
I've found the idb folder for the extension under ~/Library/Application Support/Firefox/Profiles/profileid/storage/default/extensionid, and dumped the main blob to file. Searching through this, I was able to find the vault part of the configuration:
0000ac70 72 69 6e 67 4e 5f 01 25 60 1e 40 14 2c 76 61 75 |ringN_.%`.#.,vau|
0000ac80 6c 74 00 00 00 55 01 00 00 0e d0 50 f4 02 02 7b |lt...U.....P...{|
0000ac90 00 22 00 64 00 61 00 74 00 61 00 22 00 3a 00 22 |.".d.a.t.a.".:."|
0000aca0 00 77 00 4c 00 4c 00 55 00 4f 00 58 00 73 00 53 |.w.L.L.U.O.X.s.S|
0000acb0 00 38 00 75 00 38 00 32 00 54 00 45 00 44 00 4d |.8.u.8.2.T.E.D.M|
0000acc0 00 6a 00 54 00 31 00 55 00 4e 00 4e 00 74 00 70 |.j.T.1.U.N.N.t.p|
0000acd0 00 41 00 4e 00 50 00 32 00 45 00 75 00 36 00 56 |.A.N.P.2.E.u.6.V|
0000ace0 00 66 00 71 00 62 00 68 00 48 00 46 00 54 00 49 |.f.q.b.h.H.F.T.I|
0000acf0 00 33 00 73 00 2b 00 78 00 4b 00 6f 00 6d 00 4c |.3.s.+.x.K.o.m.L|
0000ad00 00 43 00 58 00 78 00 6e 00 52 00 74 00 6f 00 50 |.C.X.x.n.R.t.o.P|
0000ad10 00 4b 00 6c 00 4f 00 6c 00 55 00 44 00 42 00 50 |.K.l.O.l.U.D.B.P|
0000ad20 00 4d 00 37 00 73 00 4f 00 74 00 49 00 72 00 38 |.M.7.s.O.t.I.r.8|
0000ad30 00 71 00 6f 00 4a 00 6f 00 66 00 42 00 71 00 52 |.q.o.J.o.f.B.q.R|
0000ad40 00 45 00 66 00 4f 00 39 00 70 00 4e 00 35 00 30 |.E.f.O.9.p.N.5.0|
0000ad50 00 76 00 61 00 45 00 74 00 33 00 6a 00 77 00 39 |.v.a.E.t.3.j.w.9|
0000ad60 00 73 00 71 00 55 00 4f 00 6b 00 37 00 58 00 64 |.s.q.U.O.k.7.X.d|
0000ad70 00 69 00 30 00 47 00 48 00 4c 00 70 00 6e 00 64 |.i.0.G.H.L.p.n.d|
0000ad80 00 6c 00 4a 00 76 00 54 00 6d 00 6b 00 49 00 31 |.l.J.v.T.m.k.I.1|
0000ad90 00 35 00 61 00 47 00 6b 00 36 00 75 00 64 00 57 |.5.a.G.k.6.u.d.W|
0000ada0 00 63 00 35 00 4d 00 58 00 2f 00 43 00 57 00 2b |.c.5.M.X./.C.W.+|
0000adb0 00 46 00 31 00 4b 00 66 00 4a 00 5a 00 62 00 57 |.F.1.K.f.J.Z.b.W|
0000adc0 00 37 00 56 00 70 00 53 00 4d 00 72 00 72 00 51 |.7.V.p.S.M.r.r.Q|
0000add0 00 50 00 70 00 66 00 6a 00 55 00 4c 00 69 00 64 |.P.p.f.j.U.L.i.d|
0000ade0 00 78 00 42 00 4c 00 44 00 66 00 4b 00 61 00 63 |.x.B.L.D.f.K.a.c|
0000adf0 00 2f 00 77 00 46 00 39 00 67 00 46 00 38 00 70 |./.w.F.9.g.F.8.p|
0000ae00 00 59 00 34 00 77 00 31 00 73 00 39 00 70 00 75 |.Y.4.w.1.s.9.p.u|
0000ae10 00 56 00 45 00 67 00 43 00 67 00 58 00 41 00 48 |.V.E.g.C.g.X.A.H|
0000ae20 00 59 00 73 00 58 00 39 00 62 00 62 00 52 00 36 |.Y.s.X.9.b.b.R.6|
0000ae30 00 38 00 76 00 71 00 4d 00 44 00 4c 00 5a 00 6d |.8.v.q.M.D.L.Z.m|
0000ae40 00 70 00 72 00 36 00 4e 00 47 00 35 00 51 00 43 |.p.r.6.N.G.5.Q.C|
0000ae50 00 6b 00 46 00 67 00 30 00 63 00 6c 00 4c 00 78 |.k.F.g.0.c.l.L.x|
0000ae60 00 36 00 64 00 36 00 74 00 64 00 64 00 6d 00 4d |.6.d.6.t.d.d.m.M|
0000ae70 00 45 00 67 00 31 00 31 00 68 00 76 00 2b 00 43 |.E.g.1.1.h.v.+.C|
0000ae80 00 72 00 47 00 49 00 3d 00 22 00 2c 00 22 00 69 |.r.G.I.=.".,.".i|
0000ae90 00 76 2d f8 10 38 00 7a 00 6a 25 e2 c8 42 00 37 |.v-..8.z.j%..B.7|
0000aea0 00 37 00 63 00 51 00 61 00 31 00 48 00 58 00 31 |.7.c.Q.a.1.H.X.1|
0000aeb0 00 42 00 30 00 67 00 73 00 2b 00 70 00 51 00 3d |.B.0.g.s.+.p.Q.=|
0000aec0 00 3d 00 22 00 2c 00 22 00 73 00 61 00 6c 00 74 |.=.".,.".s.a.l.t|
0000aed0 15 44 f0 52 56 00 48 00 41 00 4f 00 66 00 59 00 |.D.RV.H.A.O.f.Y.|
0000aee0 6c 00 6c 00 68 00 50 00 46 00 73 00 37 00 7a 00 |l.l.h.P.F.s.7.z.|
0000aef0 54 00 67 00 43 00 72 00 31 00 50 00 75 00 5a 00 |T.g.C.r.1.P.u.Z.|
0000af00 6d 00 37 00 61 00 34 00 76 00 38 00 49 00 46 00 |m.7.a.4.v.8.I.F.|
0000af10 68 00 6f 00 65 00 71 00 61 00 32 00 2b 00 37 00 |h.o.e.q.a.2.+.7.|
0000af20 5a 00 54 00 68 00 51 05 6c 04 7d 00 19 01 61 70 |Z.T.h.Q.l.}...ap|
Reconstructing it, I was almost able to get the correct data but a few characters are incorrect:
data (extract): wLLUOXsS8u82TEDMjT1UNNtpANP2Eu6VfqbhHFTI3s+xKomLCXxnRtoPKlOlUDBPM7sOtIr8qoJofBqREfO9pN50vaEt3jw9sqUOk7Xdi0GHLpndlJvTmkI15aGk6udWc5MX/CW+F1KfJZbW7VpSMrrQPpfjULidxBLDfKac/wF9gF8pY4w1s9puVEgCgXAHYsX9bbR68vqMDLZmpr6NG5QCkFg0clLx6d6tddmMEg11hv+CrGI=
data (correct): wLLUOXsS8u82TEDMjT1UNNtpANP2Eu6VfqbhHFTI3s+xKomLCXxnRtoPKlOlUDBPM7sOtIr8qoJofBqREfO9pN50vaEt3jw9sqUOk7Xdi0GHLpndlJvTmkI15aGk6udWc5MX/CW+F1KfJZbW7VpSMrrQPpfjULidxBLDfKac/wF9gF8pY4w1s9puVEgCgXAHYsX9bbR68vqMDLZmpr6NG5QCkFg0clLx6d6tddmMEg11hv+CrGI=\
iv (extract): 8zj%B77cQa1HX1B0gs+pQ==
iv (correct): 8zjDMB77cQa1HX1B0gs+pQ==
salt (extract): DRVHAOfYllhPFs7zTgCr1PuZm7a4v8IFhoeqa2+7ZThQl
salt (correct): 8VHAOfYllhPFs7zTgCr1PuZm7a4v8IFhoeqa2+7ZThQ=\
Comparing the two IVs in hex, you can see how close they are but one nibble is missing, and one is incorrect:
correct: 38 7a 6a 44 4d 42 37 37 63 51 61 31 48 58 31 42 30 67 73 2b 70 51 3d 3d
extract: 38 7a 6a 25 42 37 37 63 51 61 31 48 58 31 42 30 67 73 2b 70 51 3d 3d
For the salt, the correct one is offset by one nibble and missing a couple:
correct: 38 56 48 41 4f 66 59 6c 6c 68 50 46 73 37 7a 54 67 43 72 31 50 75 5a 6d 37 61 34 76 38 49 46 68 6f 65 71 61 32 2b 37 5a 54 68 51 3d 5c
original: 44 52 56 48 41 4f 66 59 6c 6c 68 50 46 73 37 7a 54 67 43 72 31 50 75 5a 6d 37 61 34 76 38 49 46 68 6f 65 71 61 32 2b 37 5a 54 68 51 6c
Obviously the wallet above is now burned and won't be used, but any advice on how to repeat this for the recovered wallet would be really helpful.

Understanding of TCP packets reordering

I'm trying to filter duplicated/lost packets from TCP sniffing (using pcap), but I stopped at the understanding of seq/ack. Here are my logs with relative seq/ack:
CLIENT->SERVER/Seq=0;Ack=0/SYN/P.size:0; No data in TCP. Size: 66/66 -> 20 E7 1E 61 15 5B 4E 1D 00 00 00 00 80 02 F7 D3 4D 03 00 00 02 04 05 B4 01 03 03 06 01 01 04 02 | No payload
SERVER->CLIENT/Seq=0;Ack=1/ACK+SYN/P.size:0; No data in TCP. Size: 58/58 -> 1E 61 20 E7 C4 9D 5B 6B 15 5B 4E 1E 60 12 20 00 2D D1 00 00 02 04 05 B4 | No payload
CLIENT->SERVER/Seq=1;Ack=1/ACK/P.size:0; No data in TCP. Size: 54/54 -> 20 E7 1E 61 15 5B 4E 1E C4 9D 5B 6C 50 10 01 6D 64 21 00 00 | No payload
SERVER->CLIENT/Seq=1;Ack=268/ACK/P.size:0; No data in TCP. Size: 54/54 -> 1E 61 20 E7 C4 9D 5B 6C 15 5B 4F 29 50 10 5B 40 09 43 00 00 | No payload
CLIENT->SERVER/Seq=1;Ack=1/ACK+PSH/P.size:267; 20 E7 1E 61 15 5B 4E 1E C4 9D 5B 6C 50 18 01 6D AF 0B 00 00 | 0B 01 00 EA 02 00 00 09 07 54 56 03 09 0B 01 07 02 54 54 56 07 00 02 55 56 00 51 00 53 57 04 07 55 08 54 01 07 01 53 00 56 55 56 01 06 05 04 51 03 08 51 08 51 56 04 54 06 55 08 02 09 51 56 01 53 06 55 04 53 00 56 56 53 01 09 02 09 01 51 54 51 09 55 56 09 03 04 07 05 55 04 06 55 04 06 09 04 51 01 08 08 06 05 52 06 04 01 07 54 03 06 52 55 06 55 55 51 01 02 04 54 03 55 54 01 57 51 55 05 52 05 54 07 51 51 55 07 02 53 53 00 52 05 52 07 01 54 00 03 05 05 08 06 05 05 06 03 00 0D 08 01 07 09 03 51 03 07 53 09 51 06 07 54 0A 50 56 02 52 04 05 55 51 02 53 00 08 54 04 52 56 06 02 09 00 08 03 53 56 01 05 00 55 06 08 56 04 0D 06 07 52 06 07 04 0A 06 01 04 54 04 00 05 02 04 54 00 09 52 53 05 04 01 04 05 05 01 52 51 52 0D 06 51 08 09 54 53 00 0D 01 02 03 54 53 01 05 03 08 56 54 07 02 54 0B 06 DC 4F 61 4F
CLIENT->SERVER/Seq=267;Ack=1/ACK/P.size:0; No data in TCP. Size: 54/54 -> 20 E7 1E 61 15 5B 4F 28 C4 9D 5B 6C 50 10 01 6D 63 17 00 00 | No payload
SERVER->CLIENT/Seq=1;Ack=268/ACK+PSH/P.size:20; 1E 61 20 E7 C4 9D 5B 6C 15 5B 4F 29 50 18 5B 40 3A C6 00 00 | 14 00 00 01 E0 41 9A F0 98 F5 A4 37 01 00 00 00 01 00 00 00
CLIENT->SERVER/Seq=268;Ack=21/ACK/P.size:0; No data in TCP. Size: 54/54 -> 20 E7 1E 61 15 5B 4F 29 C4 9D 5B 80 50 10 01 6D 63 02 00 00 | No payload
SERVER->CLIENT/Seq=21;Ack=305/ACK/P.size:0; No data in TCP. Size: 54/54 -> 1E 61 20 E7 C4 9D 5B 80 15 5B 4F 4E 50 10 5B 40 09 0A 00 00 | No payload
CLIENT->SERVER/Seq=268;Ack=21/ACK+PSH/P.size:37; 20 E7 1E 61 15 5B 4F 29 C4 9D 5B 80 50 18 01 84 6B AF 00 00 | 25 00 32 DF 4C C6 2A 51 18 85 82 AC 27 D8 7A 06 44 DF F7 27 BD FC 59 43 3B E7 19 53 33 37 78 7B 93 81 38 51 CB
CLIENT->SERVER/Seq=304;Ack=21/ACK/P.size:0; No data in TCP. Size: 54/54 -> 20 E7 1E 61 15 5B 4F 4D C4 9D 5B 80 50 10 01 84 62 C7 00 00 | No payload
SERVER->CLIENT/Seq=21;Ack=305/ACK+PSH/P.size:328; 1E 61 20 E7 C4 9D 5B 80 15 5B 4F 4E 50 18 5B 40 AD 89 00 00 | 48 01 F3 B3 29 D9 41 E1 45 1B D3 98 0B 6E CF CC FD 18 F8 B9 23 3B 66 93 37 62 AA E9 7A 43 E2 B9 88 1F FF 77 80 70 E8 1D B9 8E 46 61 F2 F3 52 3E 0F 98 78 3B A1 51 C9 1E BA 8D 45 63 F0 F1 50 F9 F1 67 87 9E 3A C8 50 9D CB 03 34 63 CD C6 B0 FF 7A 4D ED 9F 36 F5 5E 98 43 FC 74 5A 8D 9E 3F 07 BC 10 F3 B2 28 D8 40 81 25 12 DA FD 6E 6F CE A2 93 04 E4 A5 3F CF 57 A2 06 31 F9 DE 4D 4C ED 81 B0 27 C7 86 1C EC 74 81 25 12 DA FD 6E 6F CE A2 93 04 E4 A5 3F CF 57 A2 06 31 F9 DE 4D 4C ED 81 B0 27 C7 86 1C EC 74 81 25 12 DA FD 6E 6F CE A2 93 04 E4 A5 3F CF 57 33 86 71 B9 8A 17 C7 66 1E 21 67 87 7A 95 B4 2C D9 7D 4A 82 A5 36 37 96 8B DB 85 65 24 BE 4E D6 23 87 B0 78 5F CC CD 6C 00 31 A6 46 07 9D 6D F5 00 A4 93 5B 7C EF EE 4F 23 12 85 65 24 BE 4E D6 23 87 B0 78 3F AE AF 0E 5E 6F F8 18 65 FF 0F 97 22 86 B1 79 5E CD CC 6D 01 30 A7 47 F3 76 86 1E EB 4F 78 B0 93 00 01 A0 CC FD 6A 8A C9 53 A3 3B B...
CLIENT->SERVER/Seq=305;Ack=349/ACK/P.size:0; No data in TCP. Size: 54/54 -> 20 E7 1E 61 15 5B 4F 4E C4 9D 5C C8 50 10 01 84 61 7E 00 00 | No payload
CLIENT->SERVER/Seq=305;Ack=349/ACK/P.size:0; No data in TCP. Size: 54/54 -> 20 E7 1E 61 15 5B 4F 4E C4 9D 5C C8 50 10 01 9B 61 67 00 00 | No payload
CLIENT->SERVER/Seq=304;Ack=349/ACK/P.size:0; No data in TCP. Size: 54/54 -> 20 E7 1E 61 15 5B 4F 4D C4 9D 5C C8 50 10 01 B2 61 51 00 00 | No payload
SERVER->CLIENT/Seq=349;Ack=305/ACK+PSH/P.size:7; 1E 61 20 E7 C4 9D 5C C8 15 5B 4F 4E 50 18 5B 40 05 3F 00 00 | 07 00 67 24 BE 4E D6
On the line 5
SERVER->CLIENT/Seq=1;Ack=268/ACK/P.size:0; No data in TCP. Size: 54/54 -> 1E 61 20 E7 C4 9D 5B 6C 15 5B 4F 29 50 10 5B 40 09 43 00 00 | No payload
server sends ACK with 268, while client sends those 267-length size data only on the next line. Why order is broken here??
As I understand, fisrt client should send seq1/ack1/L=267, and then server should resp with seq1/Ack268.
Or does it mean, that I have to implement whole logic for packet exchange in TCP protocol (including selective ACKs?)

Squid proxy discarding request made with netcat, but not curl

I need to make a REST call within a RHEL kickstart %pre script, and thus I am limited to using netcat (since the wget packaged in the RHEL %pre environment can't configure the HTTP method). I'd of course love to use curl (since it has the lovely -X option) but alas it's not available in the %pre environment.
That said, here's a relevant curl command and, importantly, the exact stream of bytes it sends to the server:
$ curl -X POST http://pkrizak-globalpxe.anonycom.com/univac/api/record/pkrizak-sles10.anonycom.com/_install_log --data-binary '[ ]' --trace /tmp/foo.log
$ cat /tmp/foo.log (truncated)
== Info: About to connect() to pkrizak-globalpxe.anonycom.com port 80 (#0)
== Info: Trying 10.46.174.117... == Info: connected
== Info: Connected to pkrizak-globalpxe.anonycom.com (10.46.174.117) port 80 (#0)
=> Send header, 312 bytes (0x138)
0000: 50 4f 53 54 20 2f 75 6e 69 76 61 63 2f 61 70 69 POST /univac/api
0010: 2f 72 65 63 6f 72 64 2f 70 6b 72 69 7a 61 6b 2d /record/pkrizak-
0020: 73 6c 65 73 31 30 2e 61 63 6f 63 79 63 6f 6d 2e sles10.anonycom.
0030: 63 6f 6d 2f 5f 69 6e 73 74 61 6c 6c 5f 6c 6f 67 com/_install_log
0040: 20 48 54 54 50 2f 31 2e 31 0d 0a 55 73 65 72 2d HTTP/1.1..User-
0050: 41 67 65 6e 74 3a 20 63 75 72 6c 2f 37 2e 31 39 Agent: curl/7.19
0060: 2e 37 20 28 78 38 36 5f 36 34 2d 72 65 64 68 61 .7 (x86_64-redha
0070: 74 2d 6c 69 6e 75 78 2d 67 6e 75 29 20 6c 69 62 t-linux-gnu) lib
0080: 63 75 72 6c 2f 37 2e 31 39 2e 37 20 4e 53 53 2f curl/7.19.7 NSS/
0090: 33 2e 31 34 2e 33 2e 30 20 7a 6c 69 62 2f 31 2e 3.14.3.0 zlib/1.
00a0: 32 2e 33 20 6c 69 62 69 64 6e 2f 31 2e 31 38 20 2.3 libidn/1.18
00b0: 6c 69 62 73 73 68 32 2f 31 2e 34 2e 32 0d 0a 48 libssh2/1.4.2..H
00c0: 6f 73 74 3a 20 70 6b 72 69 7a 61 6b 2d 67 6c 6f ost: pkrizak-glo
00d0: 62 61 6c 70 78 65 2e 61 63 6f 63 79 63 6f 6d 2e balpxe.anonycom.
00e0: 63 6f 6d 0d 0a 41 63 63 65 70 74 3a 20 2a 2f 2a com..Accept: */*
00f0: 0d 0a 43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 ..Content-Length
0100: 3a 20 33 0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 70 : 3..Content-Typ
0110: 65 3a 20 61 70 70 6c 69 63 61 74 69 6f 6e 2f 78 e: application/x
0120: 2d 77 77 77 2d 66 6f 72 6d 2d 75 72 6c 65 6e 63 -www-form-urlenc
0130: 6f 64 65 64 0d 0a 0d 0a oded....
=> Send data, 3 bytes (0x3)
0000: 5b 20 5d [ ]
== Info: HTTP 1.0, assume close after body
<= Recv header, 24 bytes (0x18)
I've truncated the rest, but suffice to say that the transaction continues without problems.
Now, sending the exact same stream of bytes using netcat:
$ ./mypost.sh | hexdump -C
00000000 50 4f 53 54 20 2f 75 6e 69 76 61 63 2f 61 70 69 |POST /univac/api|
00000010 2f 72 65 63 6f 72 64 2f 70 6b 72 69 7a 61 6b 2d |/record/pkrizak-|
00000020 73 6c 65 73 31 30 2e 61 63 6f 63 79 63 6f 6d 2e |sles10.anonycom.|
00000030 63 6f 6d 2f 5f 69 6e 73 74 61 6c 6c 5f 6c 6f 67 |com/_install_log|
00000040 20 48 54 54 50 2f 31 2e 31 0d 0a 55 73 65 72 2d | HTTP/1.1..User-|
00000050 41 67 65 6e 74 3a 20 63 75 72 6c 2f 37 2e 31 39 |Agent: curl/7.19|
00000060 2e 37 20 28 78 38 36 5f 36 34 2d 72 65 64 68 61 |.7 (x86_64-redha|
00000070 74 2d 6c 69 6e 75 78 2d 67 6e 75 29 20 6c 69 62 |t-linux-gnu) lib|
00000080 63 75 72 6c 2f 37 2e 31 39 2e 37 20 4e 53 53 2f |curl/7.19.7 NSS/|
00000090 33 2e 31 34 2e 33 2e 30 20 7a 6c 69 62 2f 31 2e |3.14.3.0 zlib/1.|
000000a0 32 2e 33 20 6c 69 62 69 64 6e 2f 31 2e 31 38 20 |2.3 libidn/1.18 |
000000b0 6c 69 62 73 73 68 32 2f 31 2e 34 2e 32 0d 0a 48 |libssh2/1.4.2..H|
000000c0 6f 73 74 3a 20 70 6b 72 69 7a 61 6b 2d 67 6c 6f |ost: pkrizak-glo|
000000d0 62 61 6c 70 78 65 2e 61 63 6f 63 79 63 6f 6d 2e |balpxe.anonycom.|
000000e0 63 6f 6d 0d 0a 41 63 63 65 70 74 3a 20 2a 2f 2a |com..Accept: */*|
000000f0 0d 0a 43 6f 6e 74 65 6e 74 2d 6c 65 6e 67 74 68 |..Content-length|
00000100 3a 20 33 0d 0a 43 6f 6e 74 65 6e 74 2d 74 79 70 |: 3..Content-typ|
00000110 65 3a 20 61 70 70 6c 69 63 61 74 69 6f 6e 2f 78 |e: application/x|
00000120 2d 77 77 77 2d 66 6f 72 6d 2d 75 72 6c 65 6e 63 |-www-form-urlenc|
00000130 6f 64 65 64 0d 0a 0d 0a 5b 20 5d |oded....[ ]|
0000013b
...doesn't work:
$ ./mypost.sh | nc pkrizak-globalpxe.anonycom.com 80
$ # no response
The tricky bit here is that there is a squid (reverse) proxy listening on port 80 of the host I'm connecting to. So I'm not actually talking to Apache or Nginx or even my custom Perl application -- I'm trying to talk to Squid (which when approached with curl actually forwards the request properly to my application). And apparently something is different about how curl talks to Squid than how nc is talking to squid, despite the content of the request being identical.
I've tried changing the request to use HTTP/1.0 and even tried leaving the HTTP/ part off, but that does not help.
I'm really baffled at this point -- what is going on under the hood that I'm missing? Why is netcat behaving differently?
Turns out this is an oddity in the way that netcat behaves when piped data on STDIN.
After tracing the packets with wireshark, I found that netcat, after sending the data piped to STDIN, immediately sends a FIN,ACK packet to the server. The squid server, naturally, aborts processing of the request upon receipt of the FIN,ACK packet and closes the connection.
This behavior can be avoided by using the -i option to netcat, which specifies an interval time between transactions. Using -i 1, for example, waits one second before sending the FIN,ACK after sending its data. This is long enough for the squid proxy to return with an answer.
Another solution is to have the script generating the input to STDIN pause after writing out the HTTP POST information. A simple sleep 1 at the end of the script appears to be sufficient to get the proxy to complete the request.

HTTP 400 on IIS 6.0

I'm trying to create HTTP request to XML service and I'm getting 400 errors from IIS server.
This request WORKS:
T 192.168.0.10:52584 -> 193.189.144.141:80 [AP]
50 4f 53 54 20 2f 73 63 72 69 70 74 73 2f 58 4d POST /scripts/XM
4c 5f 49 6e 74 65 72 66 61 63 65 2e 64 6c 6c 20 L_Interface.dll
48 54 54 50 2f 31 2e 30 0d 0a HTTP/1.0..
###
T 192.168.0.10:52584 -> 193.189.144.141:80 [AP]
48 6f 73 74 3a 20 77 77 77 31 2e 67 6e 74 2e 6c Host: www1.gnt.l
74 0d 0a 43 6f 6e 74 65 6e 74 2d 74 79 70 65 3a t..Content-type:
20 61 70 70 6c 69 63 61 74 69 6f 6e 2f 78 2d 77 application/x-w
77 77 2d 66 6f 72 6d 2d 75 72 6c 65 6e 63 6f 64 ww-form-urlencod
65 64 0d 0a 43 6f 6e 74 65 6e 74 2d 6c 65 6e 67 ed..Content-leng
74 68 3a 20 37 33 0d 0a 43 6f 6e 6e 65 63 74 69 th: 73..Connecti
6f 6e 3a 20 63 6c 6f 73 65 0d 0a 0d 0a 4d 66 63 on: close....Mfc
49 53 41 50 49 43 6f 6d 6d 61 6e 64 3d 44 65 66 ISAPICommand=Def
61 75 6c 74 26 55 53 45 52 4e 41 4d 45 3d 73 65 ault&USERNAME=se
63 72 65 74 26 50 41 53 53 57 4f 52 44 3d 73 65 cret&PASSWORD=se
63 72 65 74 26 43 48 45 43 4b 3d 73 65 63 72 65 cret&CHECK=secre
74 26 58 4d 4c 3d 0d 0a 0d 0a t&XML=....
Although this one DOESN'T WORK:
T 192.168.0.10:52592 -> 193.189.144.141:80 [AP]
50 4f 53 54 20 2f 73 63 72 69 70 74 73 2f 58 4d POST /scripts/XM
4c 5f 49 6e 74 65 72 66 61 63 65 2e 64 6c 6c 20 L_Interface.dll
48 54 54 50 2f 31 2e 30 0d 0a 43 6f 6e 74 65 6e HTTP/1.0..Conten
74 2d 54 79 70 65 3a 20 61 70 70 6c 69 63 61 74 t-Type: applicat
69 6f 6e 2f 78 2d 77 77 77 2d 66 6f 72 6d 2d 75 ion/x-www-form-u
72 6c 65 6e 63 6f 64 65 64 0d 0a 43 6f 6e 74 65 rlencoded..Conte
6e 74 2d 4c 65 6e 67 74 68 3a 20 37 32 0d 0a 48 nt-Length: 72..H
6f 73 74 3a 20 77 77 77 31 2e 67 6e 74 2e 6c 74 ost: www1.gnt.lt
0d 0a 55 73 65 72 2d 41 67 65 6e 74 3a 20 50 79 ..User-Agent: Py
74 68 6f 6e 2d 75 72 6c 6c 69 62 2f 31 2e 31 37 thon-urllib/1.17
0d 0a 0d 0a 58 4d 4c 3d 26 55 53 45 52 4e 41 4d ....XML=&USERNAM
45 3d 73 65 63 72 65 74 26 50 41 53 53 57 4f 52 E=secret&PASSWOR
44 3d 73 65 63 72 65 74 26 4d 66 63 49 53 41 50 D=secret&MfcISAP
49 43 6f 6d 6d 61 6e 64 3d 44 65 66 61 75 6c 74 ICommand=Default
26 43 48 45 43 4b 3d 63 68 65 63 6b &CHECK=check
Exact error message:
HTTP/1.1 400 Bad Request.
Server: Microsoft-IIS/6.0.
X-Powered-By: ASP.NET.
Date: Wed, 13 Jul 2011 20:53:07 GMT.
Connection: close.
.
Any ideas where's the issue?
Resolved by changing order of arguments.
Made MfcISAP=Default the first argument

Resources