I am trying to display the video my (PAUL) drone is sending to my over a UDP connection.
Frames look like (hexdump):
00 00 01 a1 00 1d 00 03
90 1a 00 00 a0 8a dc 0c
00 00 00 00 03 00 00 00
d0 02 40 02 00 04 00 00
90 1a 00 00 19 00 ......
Frames always start (trough my observation) with:
00 00 01 a
Are these NAL units?
I am want to display this in VLC player but don't know how to stream it to the VLC media player.
It looks a lot like a valid h.264 bitstream, but its not. 00 00 01 does look like a start code, But after a start code the first bit MUST be 0. a in binary is 1010 hence not valid.
Related
I am using the MusicSequenceFileCreate method to generate a MIDI file from a beat-based MusicSequence. In iOS 16.0.2 devices, the file that is created has a Sysex MIDI message added (not by me) to the file at time 0:
f0 2a 11 67 40 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00 00 00 00 00 00 00 f7
Sysex messages are manufacturer dependent, a file with this Sysex message can't be read into apps like Nanostudio, Ableton, Zenbeats, which is a problem. It can only be read by GarageBand. Is there a way for MusicSequenceFileCreate to not add this Sysex MIDI message and basically work like it worked before iOS 16?
My project is swift-only (for the code I wrote, at least). At the start of the app, I download some json to show content. I deserialize this content with swift 4 Coder protocol. This has worked for some time, but just now I got an unexpected stack-buffer-overflow error:
==44088==ERROR: AddressSanitizer: stack-buffer-overflow
while deserializing one of the objects, in one of the background threads.
Based on this, I have 2 questions:
How can I ensure this doesn't happen again?
Is there a way to reproduce it?
More info:
I have this summary, but I'm not sure what to make of it:
SUMMARY: AddressSanitizer: stack-buffer-overflow JsonClass.swift in _T06MyApp11JsonClassVACs7Decoder_p4from_tKcfC
Shadow bytes around the buggy address:
0x100026a904d0: 00 02 f2 f2 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00
0x100026a904e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100026a904f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100026a90500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100026a90510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x100026a90520: 00 00 00 00 00 00 00 00 00 00 00 00 00 00[f2]f2
0x100026a90530: f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 00 00
0x100026a90540: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100026a90550: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100026a90560: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100026a90570: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
EDIT:
It reproduced every time (in the simulator). Then I cleaned the build and deleted the derived data folder and it didn't happen since. I'd still like to know if I need to worry for a bug in production...
First I'll briefly answer your questions
How can I ensure this doesn't happen again?
This specific defect you can fix and write unit tests for to prevent having a regression. In general, however, mistakes happen; you cannot prevent them, only mitigate them. Use tools and warnings to try and identify them early on. You are already doing a good thing by employing Address Sanitizer (you should also check out Undefined Behavior Sanitizer and Thread Sanitizer).
Is there a way to reproduce it?
Address Sanitizer will report it 100% of the time it happens. Unfortunately, it sounds like it depends on what data you are working with. Maybe try some malformed data to try and coax it into happening. You can write Unit Tests (be sure to build your tests with Asan enabled) with various types of data. Can't say more without seeing code.
What is the problem?
You definitely have a bug. Asan does not report false positives. It sounds like it might only happen for bad data, but you should never trust you will always have good data.
It is not easy to help you fix your problem without seeing code. Asan reporting a stack buffer overflow is usually one of these things (in my experience):
Allocating a variable on the stack and keeping a reference to it. When the stack frame it was allocated in is destroyed the reference is no longer valid.
Having an array on the stack and going out of bounds.
(rarely) An improper cast of a stack object to an object larger size and accessing a "member" that is beyond the stack top.
If you are running though Xcode it should break when Asan aborts. you should be able to see the stack trace and find where in your code this is happening.
Additional tools to help identify the problem
Compiler warnings
Turn these on and up as much as possible. Often when you do things like take a reference to something with automatic storage duration the compiler can warn you about it.
Clang Static Analyzer
This is also built into Xcode and can be ran by the Product -> Analyize menu. This should populate issues it find in the "issue navigator" on the left column of Xcode. Clang is pretty good at identifying memory errors
31==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffcfa87e770
at pc 0x000000344049 bp 0x7ffcfa87e6b0 sp 0x7ffcfa87e6a8
READ of size 1 at 0x7ffcfa87e770 thread T0
#3 0x7f35b846e0b2 (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
Address 0x7ffcfa87e770 is located in stack of thread T0 at offset 80 in frame
This frame has 3 object(s):
[32, 33) 'ref.tmp'
[48, 80) 'agg.tmp' <== Memory access at offset 80 overflows this variable
[112, 144) 'agg.tmp8'
HINT: this may be a false positive if your program uses some custom stack, unwind mechanism, swapcontext or vfork.
(longjmp and C++ exceptions *are* supported)
Shadow bytes around the buggy address:
0x10001f507c90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10001f507ca0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10001f507cb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10001f507cc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10001f507cd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x10001f507ce0: 00 00 00 00 f1 f1 f1 f1 01 f2 00 00 00 00[f2]f2
0x10001f507cf0: f2 f2 00 00 00 00 f3 f3 f3 f3 f3 f3 00 00 00 00
0x10001f507d00: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
0x10001f507d10: 04 f2 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10001f507d20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10001f507d30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==31==ABORTING
i am also suffering from the same problem in leet code.
I am trying to filter packets where the 15th byte (i.e. the 1st payload byte after the 14 byte header) is a specific value, either 0x00 or 0x01.
The packets I am interested in are raw ethernet, i.e. at the logical-link control layer so I also filter on LLC as the protocol
Here is what I tried:
llc && (frame[14:1] == 00 || frame[14:1] == 01)
this comes up green so I'm pretty sure the syntax is correct. Its only displaying packets where Protocol is LLC but its also letting through packets where the 15th byte is 0x02 which I want to avoid
Any ideas how I can succesfully target the 15th byte value, or to put it another way, the 1st byte value of the payload?
example packet (copied from wireshark) where 15th byte is 0x00:
0000 01 01 01 01 01 01 02 02 02 02 02 02 00 0e 00 05 ................
0010 00 00 00 05 00 00 00 00 00 00 00 01 ............
example packet where 15th byte is 0x01:
0000 02 02 02 02 02 02 01 01 01 01 01 01 00 0a 01 05 ................
0010 00 00 00 0d 00 00 00 f1 00 00 00 00 00 00 00 00 ................
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0030 00 00 00 00 00 00 00 00 00 00 00 00 ............
I'd like to have wireshark display both these packets
There is a 3rd type of packet where the 15th byte is 0x02:
0000 02 02 02 02 02 02 01 01 01 01 01 01 00 39 02 ec .............9..
0010 41 61 02 a2 21 44 2b 0c 00 02 00 1c 0c 02 00 00 Aa..!D+.........
0020 00 00 00 00 00 00 00 00 00 00 00 ee 91 20 04 46 ............. .F
0030 22 44 2b cc 01 03 00 00 00 00 00 00 00 00 00 00 "D+.............
0040 00 00 00 00 00 00 00 .......
This type of packet I would like to exclude with the filter. My filter above still displays these 0x02 packets.
Here is the wireshark display filter requested:
llc and (frame[14] == 0 or frame[14] == 1)
Wireshark counts the first byte in each frame as byte 0, so the 15th byte is frame[14]. You do not need the colon for a single byte (as described in the docs). and and && are equivalent. or and || are also equivalent.
Please,
I am trying to write a simple Binary Block to mifare 1k tag with a ACR122U reader.
I am trying write to block 01, 5 bytes, text:'teste' and read it back.
But I always get an error 6300 when update this block.
Any thoughts?
I am using windows 8.1/delphi xe8.
My log is:
SCardEstablishContext succeeded.
Card State changed in ACS ACR122U PICC Interface 0 to available
New reader found: ACS ACR122U PICC Interface 0
Card inserted in ACS ACR122U PICC Interface 0
ATR = 3B 8F 80 01 80 4F 0C A0 00 00 03 06 03 00 01 00 00 00 00 6A
SCardConnect (shared) succeeded.
Active Protocol: T=1
ISO 14443 A, Part3 Card Type: Mifare Standard 1K is detected
Sending APDU to card: FF 82 00 01 06 FF FF FF FF FF FF
SCardTransmit succeeded.
Card response status word: 9000 (OK)
Sending APDU to card: FF 86 00 00 05 01 00 01 60 01
SCardTransmit succeeded.
Card response status word: 9000 (OK)
Sending APDU to card: FF 86 00 00 05 01 00 01 60 01
SCardTransmit succeeded.
Card response status word: 9000 (OK)
Sending APDU to card: FF D6 00 01 05 74 65 73 74 65
SCardTransmit succeeded.
Card response status word: 6300 (State of non-volatile memory changed.)
This is easily resolved by reading the documentation.
You're writing to a block and you have to provide a complete block of information. The only option for Lc is x04 or x10 - four bytes or sixteen bytes. For the Mifare 1K, it's prettly clear that you need to supply 16 bytes. You have only 5 bytes of data, so pad the rest with zeros.
| CMD | block1 | 16 bytes | data ...
FF D6 00 01 10 74 65 73 74 65 00 00 00 00 00 00 00 00 00 00 00
My wifi sniff device can output data to a raw file. But it may begin with the middle of a frame, and each frame starts right after another. A pcap file must contain packet headers, which I don't have. So I tried to discard the half complete frame at the beginning of the file, and put the rest into a pcap file with one packet. Then wireshark can analyze the first frame, even with wrong packet size.
My question is how to make wireshark analyze the remaining frames ?
Edit: This is a sample pcap with 2 frame, but without the second packet header
00000000 D4 C3 B2 A1 02 00 04 00 00 00 00 00 00 00 00 00 Ôò¡............
00000010 FF FF 00 00 69 00 00 00 05 00 00 00 00 00 00 00 ÿÿ..i...........
00000020 80 00 00 00 80 00 00 00 08 02 00 00 01 00 5E 00 €...€.........^.
00000030 00 FC E8 94 F6 3C 5F 40 20 68 9D 9A 4B D7 70 73 .üèâ€Ã¶<_# h.Å¡K×ps
00000040 AA AA 03 00 00 00 08 00 46 00 00 20 38 F8 00 00 ªª......F.. 8ø..
00000050 01 02 48 D5 C0 A8 01 66 E0 00 00 FC 94 04 00 00 ..HÕÀ¨.fà ..üâ€...
00000060 16 00 09 03 E0 00 00 FC 08 02 00 00 01 00 5E 7F ....à ..ü......^.
00000070 FF FA E8 94 F6 3C 5F 40 20 68 9D 9A 4B D7 F0 75 ÿúèâ€Ã¶<_# h.Å¡K×ðu
00000080 AA AA 03 00 00 00 08 00 46 00 00 20 38 F9 00 00 ªª......F.. 8ù..
00000090 01 02 39 D6 C0 A8 01 66 EF FF FF FA 94 04 00 00 ..9ÖÀ¨.fïÿÿúâ€...
000000A0 16 00 FA 04 EF FF FF FA ..ú.ïÿÿú
My question is how to make wireshark analyze the remaining frames ?
Detect the beginnings and ends of frames in your bit sequence, and put each frame into a separate record in the pcap file.
If there's nothing in the bit sequence to allow your software to determine where one frame ends and another frame begins, there's nothing in the bit sequence to allow Wireshark to do so, so if you want to have Wireshark analyzer frames past the first frame, you are FORCED to ensure that there's something in the bit stream to determine frame boundaries, and you might as well have your software break the bit stream into frames.