I record a series of small (10 sec) mov files from an iDevice. Are these files compatible with HLS media file format?
The HLS media format is MPEG2 TS, which is different from the MOV file that you create from the recording.
It's easy to convert an MOV to M2TS with a tool like ffmpeg:
ffmpeg -i input.mov -vcodec copy -acodec copy output.ts
Related
I'm trying to make a script or program that will take given bytes (given in hexadecimal), and convert them into a x86 instructions (For example c3 -> retq)
I've tried doing it by calling gcc -c on an assembly file just containing
retq
retq
and then using a script to insert bytes where it says "c3 c3", then using objdump -d to see what it says now. But it seems that it messes up the format of the file unless I only pass an instruction of the same size as the original instruction bytes.
I'm running it on a Raspbian Pi (A linux based operating system) using SSH, BASH terminal. I'm using BASH shell scripts and python, as well as the tools listed here, and gdb.
Disassemble flat binary file: objdump -D -b binary -m i386 foo.bin. Or create an object file using .byte directives from assembly source, e.g. put .byte 0xc3 into foo.s then gcc -c foo.s then objdump -d foo.o
Ok.
So i have been messing around with Assembly, and i was wondering: just HOW does a linkes ELF64 File look like, and can i directly write a linked file in plain-text? (like create a file e.G "main", write the hex-values of the system-calls, and then run it without linking or assembling.)
I have tried objdump -x main but i don't think, this is the entire ELF-File, because there is too less information, as i think.
Here the output:
main: Dateiformat elf64-x86-64
Inhalt von Abschnitt .text:
4000b0 b8040000 00bb0100 0000b9d0 006000ba .............`..
4000c0 0c000000 cd80b801 000000cd 80 .............
Inhalt von Abschnitt .data:
6000d0 48454c4c 4f2c2057 4f524c44 HELLO, WORLD
my Assembler Code:
section .data
msg: db "HELLO, WORLD"
len: equ $-msg
section .text
;write
mov eax, 4
mov ebx, 1
mov ecx, msg
mov edx, len
int 80h;
;quit
mov eax, 1
int 80h;
EDIT: My Compiler is finished now, I just stuck with assembler and let NASM/ld do the job
If you want to see the entire structure of your executable try:
objdump -D some_exe
and if you want to see your file in hex format do:
xxd some_exe
or
hexdump some_exe
can i directly write a linked file in plain-text?
Well... Theoretically you can if you know exactly the instructions of the executable and you write them in binary to a plaintext file.
For example, for any given executable exe_file you can do this:
touch temp_file plaintext_file
xxd -p exe_file > temp_file
xxd -p -r temp_file > plaintext_file
chmod u+x plaintext_file
The plaintext_file will be an executable exactly the same as your exe_file. If between steps 2 and 3 you modify the temp_file you are directly modifying the executable by hand, although it is not very likely to change something "specific", unless you have very deep understanding of elf64 format (which I don't and I'm not sure what can be achieved with this).
Note: I know step 1 is redundant, I used it for demonstrating that you are starting with 2 simple plaintext files.
I'm trying to install FFMPEG to Kali Linux 2.0
So far I've been trying to use the following commands:
git clone git://source.ffmpeg.org/ffmpeg.git ffmpeg
cd ffmpeg
./configure
make
make install
However when I try and make it I get the following errors:
libavcodec/x86/imdct36.asm:393: error: operation size not specified
library.mak:30: recipe for target 'libavcodec/x86/imdct36.o' failed
make: *** [libavcodec/x86/imdct36.o] Error 1
I'm really stumped as how to resolve this as my skill are only moderate...
I came across the answer just by chance, but
I needed to install YASM before compiling...
apt-get install yasm
this particular problem took a lot of tracking down, due to the large numbers of macros in the source. line 393 reads:
DEFINE_IMDCT
and looking for that macro, we find it at line 179. but it has numerous instructions in it, and conditionals, and any one of those could be the culprit. so first what we do is make V=1 to turn on verbose (normal) GNU make output. then we see:
jcomeau#aspire:~/rentacoder/jcomeau/floureon/ffmpeg$ nasm -f elf -DPIC -g -F dwarf -I./ -I.// -Pconfig.asm -I libavcodec/x86/ -o libavcodec/x86/imdct36.o libavcodec/x86/imdct36.asm
we change that to:
jcomeau#aspire:~/rentacoder/jcomeau/floureon/ffmpeg$ nasm -l /tmp/imdct36.lst -f elf -DPIC -g -F dwarf -I./ -I.// -Pconfig.asm -I libavcodec/x86/ -o libavcodec/x86/imdct36.o libavcodec/x86/imdct36.asm
to get a listing file. looking into the listing for the operation size not specified error, we find it at line 102741, at level <4> of the macro expansion. scrolling up, we find the level 2 instruction at line 102668 as extractps [%3 + %4], %1, 1 and the level 1 instruction at line 102583, STORE m6, m7, outq + 16*SBLIMIT, 4*SBLIMIT.
so we go back to libavcodec/x86/imdct36.asm, search for STORE, and find it at line 145. sure enough, we find 3 extractps instructions under it:
extractps [%3 + %4], %1, 1
extractps [%3 + 2*%4], %1, 2
extractps [%3 + 3*%4], %1, 3
we change them to:
extractps dword [%3 + %4], %1, 1
extractps dword [%3 + 2*%4], %1, 2
extractps dword [%3 + 3*%4], %1, 3
assuming 32-bit operands. and sure enough, it finishes the build after that, without having to install yasm.
how do I know it shouldn't be qword instead? I don't, but it doesn't make sense, since extractps only uses 32 bit destinations: "Extract a single-precision floating-point value from xmm2 at the source offset specified by imm8 and store the result to reg or m32. The upper 32 bits of r64 is zeroed if reg is r64." (http://www.felixcloutier.com/x86/EXTRACTPS.html).
I am trying to convert a bootloader I wrote in Assembly Language to an ISO image file. The following is the code from MikeOS bootloader. Here is my bootloader code:
BITS 16
start:
mov ax, 07C0h ; Set up 4K stack space after this bootloader
add ax, 288 ; (4096 + 512) / 16 bytes per paragraph
mov ss, ax
mov sp, 4096
mov ax, 07C0h ; Set data segment to where we're loaded
mov ds, ax
mov si, text_string ; Put string position into SI
call print_string ; Call our string-printing routine
jmp $ ; Jump here - infinite loop!
text_string db 'This is my cool new OS!', 0
print_string: ; Routine: output string in SI to screen
mov ah, 0Eh ; int 10h 'print char' function
.repeat:
lodsb ; Get character from string
cmp al, 0
je .done ; If char is zero, end of string
int 10h ; Otherwise, print it
jmp .repeat
.done:
ret
times 510-($-$$) db 0 ; Pad remainder of boot sector with 0s
dw 0xAA55 ; The standard PC boot signature
I typed the following command:
nasm -f bin -o boot.bin boot.asm
This command works fine and it gives a .bin output. Next I typed the following command:
dd if=boot.bin of=floppy.img count=1 bs=512
This also worked fine and gave me the .img output file. When I type this command:
dd if=boot.bin of=floppy.img skip seek=1 count=1339
I get the following error: dd: unrecognized operand ‘skip’. I read in the DD documentation that the skip attribute must have a number assigned to it. Any ideas what number should I type with skip attribute (Ex. skip=1).
Next I type the following command:
mkdosfs -C floppy.img 1440
I get the following error: mkdosfs: unable to create floppy.img. How do I fix the problems I am encountering? Is there another easier way I could convert my bootloader .bin file to an ISO image?
It appears you found your example for creating a bootable ISO image from this StackOverflow Answer. Unfortunately you picked an accepted answer that is incorrect in many ways. Pretend you never saw that answer.
On most Linux distros either a program called genisoimage or mkisofs exists. These days they are actually the same program. Whichever you have can be substituted in the examples below. My examples will assume the ISO creation utility is called genisoimage.
In your question you have some bootloader code in a file called boot.asm. You correctly assemble this to a boot sector binary image with:
nasm -f bin -o boot.bin boot.asm
This creates boot.bin which is your boot sector. The next step is to create a floppy disk image and place boot.bin in the first sector. You can do that with this:
dd if=/dev/zero of=floppy.img bs=1024 count=1440
dd if=boot.bin of=floppy.img seek=0 count=1 conv=notrunc
The first command simply makes a zero filled disk image equal to the size of a 1.44MB floppy (1024*1440 bytes). The second command places boot.bin into the first sector of floppy.img without truncating the rest of the file. seek=0 says seek to first sector (512 bytes is default size of a block for DD). count=1 specifies we only want to copy 1 sector (512 bytes) from boot.bin. conv=notrunc says that after writing to the output file, that the remaining disk image is to remain intact (not truncated).
After building a disk image as shown above, you can create an ISO image with these commands:
mkdir iso
cp floppy.img iso/
genisoimage -quiet -V 'MYOS' -input-charset iso8859-1 -o myos.iso -b floppy.img \
-hide floppy.img iso/
The commands above first create a sub-directory called iso that will contain the files to be placed onto the final CD-ROM image. The second command doesn't do anything more than copy our floppy.img into iso directory because we need that for booting. The third command does the heavy lifting and builds the ISO image.
-V 'MYOS' sets the volume label (It can be whatever you want)
-input-charset iso8859-1 sets the character set being used. Don't change it
-o myos.iso says the ISO image will be output to the file myos.iso
-b floppy.img says that our ISO will be bootable and the boot image being used is the file floppy.img
-hide floppy.img isn't needed but it hides the boot image from the final ISO's directory listing. If you were to mount this ISO and do an ls on it to list the files, floppy.img wouldn't appear.
iso/ on the end of the command is the directory that will be used to build the ISO image from. It needs to at least contain our bootable floppy image, but you can place any other files you wish into the iso/ directory.
The ISO image myos.iso that is generated can be booted. An example of using QEMU to launch such an image:
qemu-system-i386 -cdrom ./myos.iso
For CD; there's a specification ("El Torito") that describes how bootable CDs work; where the first 16 (2048-byte) sectors are unused, there's a "boot catalogue" that the firmware uses to decide which boot loader it should use (so you can have a single CD that boots very different systems - e.g. PC BIOS, UEFI, PowerPC, etc), then the boot loaders themselves.
For "PC BIOS" alone, there's 3 possibilities:
emulate a floppy disk (using a "floppy disk image" stored on CD)
emulate a hard disk (using a "hard disk image" stored on CD)
no emulation
The first 2 options are mostly for compatibly purposes only (crusty old OSs that don't support booting from CDs, like MS-DOS); and have performance implications (e.g. to emulate loading one 512-byte virtual sector, the firmware has to load a real 2048-byte sector and throw away the excess 1536 bytes). Any OS designed/written in the last 15+ years should be using "no emulation".
For "no emulation":
The firmware loads your entire boot loader (which can be up to about 512 KiB) and not just one sector
Sectors on CDs are 2048 bytes (and not 512 bytes); and should be loaded via. "int 0x13 extensions" (and not the old/limited "CHS disk functions" that you'd use for floppy)
There is no need for a BIOS Parameter Block (which should be considered mandatory for floppy disks)
There is no need for a partition table (which should be considered mandatory for hard disks, including GPT)
You'll probably want to support ISO9660 as the file system (to find the kernel and/or other files that the boot loader needs to load) and not FAT.
Also note that (in general) for "PC BIOS" you're probably going to want 5 different boot loaders (one for floppy, one for "MBR partitioned" hard disk, one for "GPT partitioned" hard disk, one for CD, and one for network boot). These cases are all different enough (and the "one 512-byte initial sector only" limitation for 3 of these cases is restrictive enough) to make the "all devices supported by one boot loader" idea a disaster.
To actually generate the ISO; you can use an existing tool (e.g. mkisofs), or you can write your own tool (ISO9660 and "El Torito" are both relatively easy to understand, and writing your own tool to generate an ISO can be done in less than 2 days, which is like a drop in the ocean for OS development projects).
I'm learning NASM and DEBUG using Windows XP (32-bit) for academic purposes. I'm struggling to get my first simple HelloWorld program to work. It's called prog1.asm.
Here is the code for my prog1.asm file:
bits 16
org 0x100 ; Start program at offset 100h
jmp main ; Jump to main program
message: db 'Hello world',0ah, 0dh,'$'
main: mov dx,message ; Start address of message
mov ah,09 ; Prepare for screen display
int 21h ; DOS interrupt 21h
int 20h ; Terminate program
This code above is just written out from the book that I've been using to study, as you're probably aware I'm like brand new to this. I have nasm.exe in the directory that I'm working with here.
When I'm in my directory, I run nasm -f prog1.asm -o progm1.com -l prog1.lst in an attempt to use the prog1.asm file to create the executable file prog1.com that is created by NASM and an output listing file prog1.lst also produced by NASM.
Running this command gives me the following error:
nasm: fatal: unrecognized output format 'prog1.asm' - use -hf for a list
type 'nasm -h'for help
If anyone is familiar with this problem and can help, it'd be much appreciated, let me know if more details are required.
-f option selects output format. Try this:
nasm prog1.asm -f bin -o progm1.com -l prog1.lst