Code Monkey home page Code Monkey logo

lvg's Introduction

LVG (Lion Vector Graphics)

Build Status CircleCI Build Status Coverity Scan Build Status

LVG is a lightweight flash player replacement. Basic idea: we have some assets in a package and sctipts that renders them. It's designed to use a very small runtime (around 200kb without video codecs) for player and runs on android, ios, web and more.

Currently it uses C script to load and render assets. Why C script? Because C compiler is small, and runtime written in C, so no other language is needed and script can be compiled in to a save the space. Another reason is compatibility: lvg only exposes small API and opengl, with other scripting laguages we must do all from scratch, including GUI. But there are huge amount of already-written C code. Usually author prefer C++, but there also some reasons to use pure C for whole project:

  • We do not need to include libstdc++ for Android shared objects, which saves some .apk space (shared objects libs also usually duplicated for each supported architectue in .apk).
  • This reduces size of emscripten compiled WASM code (it's already relatively heavy).
  • Native C++ builds needs some attention for small code too. It's definetly possible to write small code with C++, but we need something like minicrt for each platform/compiler. See farbrauch code for example or something similar.
  • C++ code produces much more noisy .map files which makes profile/map file analysis bit more complicated. Projects like chromium also uses objects analysis tools (like dump-static-initializers.py), there also less noise with such tools.
  • Code can be ported to specific OS'es more easily.

Following assets currently supported:

  • SVG vector images (loaded using NanoSVG)
  • Raster images (loaded using stb_image.h)
  • MP3 files (loaded using minimp3)
  • Flash SWF files (can contain vector, raster, video and audio). All swf video codecs (h263,vp6,flashsv,flashsv2,h264) costs additional ~600kb.
  • Scripts using tcc or picoc

Render can be done using following backends:

Current Status

Works:

  • SVG, image, mp3 resources with tcc scripting.
  • SWF: shapes, images, video, audio (mp3, adpcm, pcm), limited action script 2 support, limited morph shapes support.

Not works:

  • SWF: clip layers
  • SWF: interpret action script 3
  • SWF: bitmap filters
  • SWF: network access

Demos

Basic svg demo (images clickable):

SVG Screenshot

NanoVG demo incapsulated in lvg:

NanoVG Screenshot

Nuklear GUI demo:

Nuklear Screenshot

Flash swf demo:

Flash Screenshot

Building

For now windows executables builds only on linux host using mingw. For windows and linux install all build dependencies with the following command:

apt-get install -qq -y git cmake meson yasm libglfw3-dev libsdl2-dev libavcodec-dev mingw-w64 wget

For macos brew must be installed:

brew install meson upx glfw sdl2 ffmpeg tcc

LVG uses meson as build system. Actual building with the following commands in project directory:

mkdir build
cd build
meson ..
ninja

Configuring

LVG can be configured to use different backends for platform, audio and video. You can see current configuration by executing mesonconf (or meson configure for newer meson versions) in build directory:

meson configure
...
Project options:
  Option        Description   Current Value Possible Values
  ------        -----------   ------------- ---------------
  AUDIO_SDL     AUDIO_SDL     true          [True, False]
  ENABLE_AUDIO  ENABLE_AUDIO  true          [True, False]
  ENABLE_SCRIPT ENABLE_SCRIPT true          [True, False]
  ENABLE_VIDEO  ENABLE_VIDEO  true          [True, False]
  PLATFORM_GLFW PLATFORM_GLFW true          [True, False]
  PLATFORM_SDL  PLATFORM_SDL  false         [True, False]
  RENDER_NANOVG RENDER_NANOVG true          [True, False]
  RENDER_NVPR   RENDER_NVPR   true          [True, False]
  SCRIPT_TCC    SCRIPT_TCC    true          [True, False]
  VIDEO_FFMPEG  VIDEO_FFMPEG  true          [True, False]
...

You can change configuration using meson commands. Example:

mesonconf -DENABLE_SCRIPT=False

Future

  • Use other scripting lanuages like luajit, JerryScript, muJS, mu, avian, ImpalaJIT, mochascript and AngelScript.
  • Speed up action script with jit like sljit.
  • Shaders and 3D support.
  • Parallel shape\image decoding and use file compression with parallel decoding support (like pbzip2).
  • More audio\video\codec backends.
  • SWF frame interpolation to get more fps than encoded in file. [Done]
  • Better than swf storage format using draco-like compression based on ANS.

Interesting graphics libraries

Flash related projects

LVG is developed and maintained by https://github.com/lieff

lvg's People

Contributors

lieff avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

lvg's Issues

Future?

This is a neat endeavor! But how does the future plans look like?

Btw. in the section Interesting graphics libraries in readme I couldn't find the most advanced (yet very lightweight) library as of now: Blend2D (quality superior to even Antigrain; performance close to theoretical limit; ARM support is still alpha/beta though).

scripting issues

tcc:
tcc needs heavy modifications for web, needs modifications to sandbox file io, ABI issues.

picoc:
picoc do not supports floats (only doubles), function pointers, slow.

Possible alternatives:

Ideally we need script->bytecode translator (reuse AVM1?), so player needs support only bytecode, easy sandbox, normal speed, compiler fixes do not affects already installed players.

Useful links:
https://github.com/r-lyeh-archived/scriptorium
https://github.com/dbohdan/embedded-scripting-languages

Crashes when parsing LVG and SWF files

Hi team,

Some crashes were found while fuzz testing of the lvg_test binary which can be triggered via malformed LVG and SWF files. Although these malformed files only crash the program, they could potentially be crafted further into security issues where these kinds of files would be able compromise the process's memory through memory corruption, so hardening the code to prevent these kinds of bugs would be great to mitigate such issues.

See details below for repro and debug information.

Repro
crash.lvg.txt

$ lvg_test crash.lvg
Segmentation fault (core dumped)

$ gdb -q lvg_test
Reading symbols from lvg_test...
(No debugging symbols found in lvg_test)

(gdb) r crash.lvg
Starting program: lvg_test crash.lvg
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x000055555558710c in ?? ()

(gdb) bt
#0  0x000055555558710c in  ()
#1  0x00000006555bdb88 in  ()
#2  0x00007fffefb5a000 in  ()
#3  0x0000000000000000 in  ()

(gdb) i r
rax            0x0                 0
rbx            0x800005b5b7a1      140737584150433
rcx            0x7fffefb5a000      140737215045632
rdx            0x6                 6
rsi            0x55555558e285      93824992469637
rdi            0x7fffefb859f4      140737215224308
rbp            0x7fffefb859c6      0x7fffefb859c6
rsp            0x7fffffffe140      0x7fffffffe140
r8             0x7fffffffe298      140737488347800
r9             0x1                 1
r10            0x5555555badf0      93824992652784
r11            0x6                 6
r12            0x0                 0
r13            0x6                 6
r14            0x0                 0
r15            0x55555558e285      93824992469637
rip            0x55555558710c      0x55555558710c
eflags         0x10246             [ PF ZF IF RF ]
cs             0x33                51
ss             0x2b                43
ds             0x0                 0
es             0x0                 0
fs             0x0                 0
gs             0x0                 0
(gdb) x/i $rip
=> 0x55555558710c:	cmpl   $0x4034b50,(%rbx)

(gdb) exploitable
Description: Possible stack corruption
Short description: PossibleStackCorruption (7/22)
Hash: 74993a72678549a3afd2dedf9f67d2c5.74993a72678549a3afd2dedf9f67d2c5
Exploitability Classification: EXPLOITABLE
Explanation: GDB generated an error while unwinding the stack and/or the stack contained return addresses that were not mapped in the inferior's process address space and/or the stack pointer is pointing to a location outside the default stack region. These conditions likely indicate stack corruption, which is generally considered exploitable.
Other tags: AccessViolation (21/22)

Repro
crash.swf.txt

$ lvg_test crash.swf
free(): invalid next size (fast)
Aborted (core dumped)

$ gdb -q lvg_test
Reading symbols from lvg_test...
(No debugging symbols found in lvg_test)

(gdb) r crash.swf
Starting program: lvg_test crash.swf
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
free(): invalid next size (fast)

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50

(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007ffff7dd5859 in __GI_abort () at abort.c:79
#2  0x00007ffff7e403ee in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff7f6a285 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#3  0x00007ffff7e4847c in malloc_printerr (str=str@entry=0x7ffff7f6c600 "free(): invalid next size (fast)") at malloc.c:5347
#4  0x00007ffff7e49d2c in _int_free (av=0x7ffff7f9bb80 <main_arena>, p=0x5555555bb4b0, have_lock=0) at malloc.c:4249
#5  0x0000555555586c3b in  ()
#6  0x00007fffffffe298 in  ()
#7  0x0000000000000176 in  ()
#8  0x0000000000000000 in  ()

(gdb) i r
rax            0x0                 0
rbx            0x7fffefb8be40      140737215249984
rcx            0x7ffff7df618b      140737351999883
rdx            0x0                 0
rsi            0x7fffffffddc0      140737488346560
rdi            0x2                 2
rbp            0x7fffffffe110      0x7fffffffe110
rsp            0x7fffffffddc0      0x7fffffffddc0
r8             0x0                 0
r9             0x7fffffffddc0      140737488346560
r10            0x8                 8
r11            0x246               582
r12            0x7fffffffe030      140737488347184
r13            0x10                16
r14            0x7ffff7ffb000      140737354117120
r15            0x1                 1
rip            0x7ffff7df618b      0x7ffff7df618b <__GI_raise+203>
eflags         0x246               [ PF ZF IF ]
cs             0x33                51
ss             0x2b                43
ds             0x0                 0
es             0x0                 0
fs             0x0                 0
gs             0x0                 0

(gdb) x/i $rip
=> 0x7ffff7df618b <__GI_raise+203>:	mov    0x108(%rsp),%rax

(gdb) exploitable
Description: Possible stack corruption
Short description: PossibleStackCorruption (7/22)
Hash: 75e3432b00f849a15e4751fc016bf27b.2d530e50f9061d0333ac98fc1ba1d5f2
Exploitability Classification: EXPLOITABLE
Explanation: GDB generated an error while unwinding the stack and/or the stack contained return addresses that were not mapped in the inferior's process address space and/or the stack pointer is pointing to a location outside the default stack region. These conditions likely indicate stack corruption, which is generally considered exploitable.
Other tags: HeapError (10/22), AbortSignal (20/22)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.