Lua on SunPlus digital photo frames

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Lua on SunPlus digital photo frames

Rena
I've been hacking one of these, and discovered a few references to Lua
in the firmware. Specifically a couple debug messages mentioning Lua
and what looks like a LUA_PATH string. However I can't find any actual
Lua scripts/bytecode. Has anyone else looked into this?

(FWIW, the company also goes by GeneralPlus, and makes the actual
chipset; you're unlikely to find their name on the outside of the
device, but lots of SP-prefixed things inside.)

--
Sent from my Game Boy.

Reply | Threaded
Open this post in threaded view
|

Re: Lua on SunPlus digital photo frames

Ką Mykolas
Could You share the firmware to take a look at? :}

On Sat, Jan 11, 2020 at 2:11 AM Rena <[hidden email]> wrote:

>
> I've been hacking one of these, and discovered a few references to Lua
> in the firmware. Specifically a couple debug messages mentioning Lua
> and what looks like a LUA_PATH string. However I can't find any actual
> Lua scripts/bytecode. Has anyone else looked into this?
>
> (FWIW, the company also goes by GeneralPlus, and makes the actual
> chipset; you're unlikely to find their name on the outside of the
> device, but lots of SP-prefixed things inside.)
>
> --
> Sent from my Game Boy.
>

Reply | Threaded
Open this post in threaded view
|

Re: Lua on SunPlus digital photo frames

Rena
On Fri., Jan. 10, 2020, 20:28 Ką Mykolas, <[hidden email]> wrote:
Could You share the firmware to take a look at? :}

On Sat, Jan 11, 2020 at 2:11 AM Rena <[hidden email]> wrote:
>
> I've been hacking one of these, and discovered a few references to Lua
> in the firmware. Specifically a couple debug messages mentioning Lua
> and what looks like a LUA_PATH string. However I can't find any actual
> Lua scripts/bytecode. Has anyone else looked into this?
>
> (FWIW, the company also goes by GeneralPlus, and makes the actual
> chipset; you're unlikely to find their name on the outside of the
> device, but lots of SP-prefixed things inside.)
>
> --
> Sent from my Game Boy.
>

I could if I knew where to upload a 4MB binary file.

I got into the UART and there is a "lua" command, but I couldn't get it to do anything. Giving it Lua code, filenames, gibberish, just no result at all. I suspect the Lua support is just an option that this particular firmware doesn't have.

These chips are also used in cheap/knockoff video games (notably the Vii), so maybe it works there?
Reply | Threaded
Open this post in threaded view
|

Re: Lua on SunPlus digital photo frames

BogdanM
Hi,

On Sat, Jan 11, 2020 at 10:27 PM Rena <[hidden email]> wrote:
On Fri., Jan. 10, 2020, 20:28 Ką Mykolas, <[hidden email]> wrote:
Could You share the firmware to take a look at? :}

On Sat, Jan 11, 2020 at 2:11 AM Rena <[hidden email]> wrote:
>
> I've been hacking one of these, and discovered a few references to Lua
> in the firmware. Specifically a couple debug messages mentioning Lua
> and what looks like a LUA_PATH string. However I can't find any actual
> Lua scripts/bytecode. Has anyone else looked into this?
>
> (FWIW, the company also goes by GeneralPlus, and makes the actual
> chipset; you're unlikely to find their name on the outside of the
> device, but lots of SP-prefixed things inside.)
>
> --
> Sent from my Game Boy.
>

I could if I knew where to upload a 4MB binary file.

I got into the UART and there is a "lua" command, but I couldn't get it to do anything. Giving it Lua code, filenames, gibberish, just no result at all. I suspect the Lua support is just an option that this particular firmware doesn't have.

These chips are also used in cheap/knockoff video games (notably the Vii), so maybe it works there?

You could upload it to Dropbox, GDrive or something similar.
Did you try running "strings" on the firmware image and see if anything interesting comes up (besides "lua" and "LUA_PATH")?
What does the LUA_PATH string look like?
You could also try running https://tools.kali.org/forensics/binwalk on the firmware image, it can't hurt :)

Best,
Bogdan
 
Reply | Threaded
Open this post in threaded view
|

Re: Lua on SunPlus digital photo frames

Russell Haley
In reply to this post by Rena
Sorry for the top post. 
You could put it in onedrive or Google drive or box and share a public link‎? You could also upload it to a github repo..

Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
From: Rena
Sent: Saturday, January 11, 2020 12:27 PM
To: Lua mailing list
Reply To: Lua mailing list
Subject: Re: Lua on SunPlus digital photo frames

On Fri., Jan. 10, 2020, 20:28 Ką Mykolas, <[hidden email]> wrote:
Could You share the firmware to take a look at? :}

On Sat, Jan 11, 2020 at 2:11 AM Rena <[hidden email]> wrote:
>
> I've been hacking one of these, and discovered a few references to Lua
> in the firmware. Specifically a couple debug messages mentioning Lua
> and what looks like a LUA_PATH string. However I can't find any actual
> Lua scripts/bytecode. Has anyone else looked into this?
>
> (FWIW, the company also goes by GeneralPlus, and makes the actual
> chipset; you're unlikely to find their name on the outside of the
> device, but lots of SP-prefixed things inside.)
>
> --
> Sent from my Game Boy.
>

I could if I knew where to upload a 4MB binary file.

I got into the UART and there is a "lua" command, but I couldn't get it to do anything. Giving it Lua code, filenames, gibberish, just no result at all. I suspect the Lua support is just an option that this particular firmware doesn't have.

These chips are also used in cheap/knockoff video games (notably the Vii), so maybe it works there?

Reply | Threaded
Open this post in threaded view
|

Re: Lua on SunPlus digital photo frames

Jeff Pohlmeyer


On Sat, Jan 11, 2020 at 2:52 PM Russell Haley <[hidden email]> wrote:
You could put it in onedrive or Google drive or box and share a public link‎? You could also upload it to a github repo..

Depending on the licensing restrictions it might be better to do it privately.

 - Jeff


Reply | Threaded
Open this post in threaded view
|

Re: Lua on SunPlus digital photo frames

Rena
On Sat, Jan 11, 2020 at 4:32 PM Jeff Pohlmeyer <[hidden email]> wrote:

>
>
>
> On Sat, Jan 11, 2020 at 2:52 PM Russell Haley <[hidden email]> wrote:
>>
>> You could put it in onedrive or Google drive or box and share a public link‎? You could also upload it to a github repo..
>>
> Depending on the licensing restrictions it might be better to do it privately.
>
>  - Jeff
>
>

I've put it up here for now:
https://drive.google.com/file/d/1xE5C_4EXPVPROwTBSr4chB5dOsxNNuXj/view?usp=sharing
If anyone complains about licensing, I'll remove it. The archive
contains the SPI flash dump, RAM dump (using UART commands),
uncompressed firmware image (from inside the flash), and Python
(sorry!) script I used to decompress it.

The flash layout is:
000000 bootloader (after C230 is empty)
010000 A:\ (internal files)
090000 C:\ (user files from USB)
360000 LZO firmware image
3DAE93 empty space?
3DAFFC "SPMF", more empty space
3E0000 "JFS", settings.dat? (B:\), empty space
3F0000 copy of 3E0000? maybe default settings, not sure why here tho
400000 EOF
A:\ and C:\ are FAT images stored in flash (A is the most interesting,
C is exposed when you plug in the USB).

binwalk and strings didn't find a lot. The only instances of "Lua",
"lua", "LUA", "auL", "aul", and "AUL" (in case it were byteswapped)
are in debug messages and the single interesting one:
A:\?.lua;A:\?.lc;C:\?.lua;C:\?.lc;
I also didn't find the bytes 19 93 0D 0A 1A 0A which are present in
every compiled Lua bytecode file. (I checked raw flash and
uncompressed firmware.) So it really does seem like there's no more
trace of Lua itself left in here...

This firmware does support some kind of module system though, so I
wonder if I could inject a Lua module from another firmware of the
same chip?

--
Sent from my Game Boy.

Reply | Threaded
Open this post in threaded view
|

Re: Lua on SunPlus digital photo frames

Sean Conner
It was thus said that the Great Rena once stated:
>
> I also didn't find the bytes 19 93 0D 0A 1A 0A which are present in
> every compiled Lua bytecode file. (I checked raw flash and
> uncompressed firmware.) So it really does seem like there's no more
> trace of Lua itself left in here...

  Dosn't mean it's not there.  At work, I embed Lua in one of our programs
and all the Lua scripts are compressed [1]---I have a custom loader that will do
the decompression upon loading.  I go over the technique here:

        http://boston.conman.org/2013/03/22.1
        http://boston.conman.org/2013/03/23.1

  -spc

[1] They are also embedded into the executable.

Reply | Threaded
Open this post in threaded view
|

Re: Lua on SunPlus digital photo frames

BogdanM
In reply to this post by Rena


On Sun, Jan 12, 2020 at 12:34 AM Rena <[hidden email]> wrote:
On Sat, Jan 11, 2020 at 4:32 PM Jeff Pohlmeyer <[hidden email]> wrote:
>
>
>
> On Sat, Jan 11, 2020 at 2:52 PM Russell Haley <[hidden email]> wrote:
>>
>> You could put it in onedrive or Google drive or box and share a public link‎? You could also upload it to a github repo..
>>
> Depending on the licensing restrictions it might be better to do it privately.
>
>  - Jeff
>
>

I've put it up here for now:
https://drive.google.com/file/d/1xE5C_4EXPVPROwTBSr4chB5dOsxNNuXj/view?usp=sharing
If anyone complains about licensing, I'll remove it. The archive
contains the SPI flash dump, RAM dump (using UART commands),
uncompressed firmware image (from inside the flash), and Python
(sorry!) script I used to decompress it.

The flash layout is:
000000 bootloader (after C230 is empty)
010000 A:\ (internal files)
090000 C:\ (user files from USB)
360000 LZO firmware image
3DAE93 empty space?
3DAFFC "SPMF", more empty space
3E0000 "JFS", settings.dat? (B:\), empty space
3F0000 copy of 3E0000? maybe default settings, not sure why here tho
400000 EOF
A:\ and C:\ are FAT images stored in flash (A is the most interesting,
C is exposed when you plug in the USB).

binwalk and strings didn't find a lot. The only instances of "Lua",
"lua", "LUA", "auL", "aul", and "AUL" (in case it were byteswapped)
are in debug messages and the single interesting one:
A:\?.lua;A:\?.lc;C:\?.lua;C:\?.lc;
I also didn't find the bytes 19 93 0D 0A 1A 0A which are present in
every compiled Lua bytecode file. (I checked raw flash and
uncompressed firmware.) So it really does seem like there's no more
trace of Lua itself left in here...

This firmware does support some kind of module system though, so I
wonder if I could inject a Lua module from another firmware of the
same chip?

--
Sent from my Game Boy.


If there is a Lua interpreter in there, it is probably compressed somewhere (or encrypted, but that wouldn't make a lot of sense I guess). Looking at the dumps alone, I couldn't find strings that you'd expect to find in a compiled Lua interpreter (like "__index"). However, given the fact that you were unable to make the "lua" command do anything useful, I think that your initial guess is probably corect and there isn't actually any Lua interpreter in the image.
Reply | Threaded
Open this post in threaded view
|

Re: Lua on SunPlus digital photo frames

Egor Skriptunoff-2
In reply to this post by Rena
On Sun, Jan 12, 2020 at 1:34 AM Rena wrote:
I also didn't find the bytes 19 93 0D 0A 1A 0A which are present in
every compiled Lua bytecode file.


Only Lua 5.2+ bytecodes contain this string.
Lua 5.1 does not.
Reply | Threaded
Open this post in threaded view
|

Re: Lua on SunPlus digital photo frames

William Ahern
In reply to this post by Sean Conner
On Sat, Jan 11, 2020 at 05:54:25PM -0500, Sean Conner wrote:

> It was thus said that the Great Rena once stated:
> >
> > I also didn't find the bytes 19 93 0D 0A 1A 0A which are present in
> > every compiled Lua bytecode file. (I checked raw flash and
> > uncompressed firmware.) So it really does seem like there's no more
> > trace of Lua itself left in here...
>
>   Dosn't mean it's not there.  At work, I embed Lua in one of our programs
> and all the Lua scripts are compressed [1]---I have a custom loader that will do
> the decompression upon loading.  I go over the technique here:
>
> http://boston.conman.org/2013/03/22.1
> http://boston.conman.org/2013/03/23.1
>
>   -spc
>
> [1] They are also embedded into the executable.

I've done the same thing and, like you, transformed and compressed each Lua
file individually with a simple Makefile rule. However, especially with
precompiled bytecode chunks (which are larger than their text source), this
turned out to create larger executables if there are too many short Lua
source files (e.g. wrappers) and not enough long source files. In my case,
which I suspect isn't uncommon, if would be better to compress all the
source files together. But it makes the code more complex. I independently
wrote code very similar to yours, which I doubt is a coincidence as that's
the most obvious, elegant, and, in particular, transparent way to do it.

For now I just disable bytecode precompiling, and compression partly offsets
the cost of all the additional luaopen_ functions. I don't have enough long
Lua source files for compression to pay real dividends.

I guess it also matters that I *embed* an inflate implementation to avoid an
external dependency.

  https://github.com/madler/zlib/blob/master/contrib/puff/puff.c

It's small, but again I don't have any big Lua source files to offset the
cost.

Reply | Threaded
Open this post in threaded view
|

Re: Lua on SunPlus digital photo frames

Rena
On Mon, Jan 13, 2020 at 10:02 AM William Ahern
<[hidden email]> wrote:

>
> On Sat, Jan 11, 2020 at 05:54:25PM -0500, Sean Conner wrote:
> > It was thus said that the Great Rena once stated:
> > >
> > > I also didn't find the bytes 19 93 0D 0A 1A 0A which are present in
> > > every compiled Lua bytecode file. (I checked raw flash and
> > > uncompressed firmware.) So it really does seem like there's no more
> > > trace of Lua itself left in here...
> >
> >   Dosn't mean it's not there.  At work, I embed Lua in one of our programs
> > and all the Lua scripts are compressed [1]---I have a custom loader that will do
> > the decompression upon loading.  I go over the technique here:
> >
> >       http://boston.conman.org/2013/03/22.1
> >       http://boston.conman.org/2013/03/23.1
> >
> >   -spc
> >
> > [1]   They are also embedded into the executable.
>
> I've done the same thing and, like you, transformed and compressed each Lua
> file individually with a simple Makefile rule. However, especially with
> precompiled bytecode chunks (which are larger than their text source), this
> turned out to create larger executables if there are too many short Lua
> source files (e.g. wrappers) and not enough long source files. In my case,
> which I suspect isn't uncommon, if would be better to compress all the
> source files together. But it makes the code more complex. I independently
> wrote code very similar to yours, which I doubt is a coincidence as that's
> the most obvious, elegant, and, in particular, transparent way to do it.
>
> For now I just disable bytecode precompiling, and compression partly offsets
> the cost of all the additional luaopen_ functions. I don't have enough long
> Lua source files for compression to pay real dividends.
>
> I guess it also matters that I *embed* an inflate implementation to avoid an
> external dependency.
>
>   https://github.com/madler/zlib/blob/master/contrib/puff/puff.c
>
> It's small, but again I don't have any big Lua source files to offset the
> cost.
>

Well, I started reverse engineering the actual code, and found that
indeed the "lua" command does absolutely nothing. Oh well. Maybe I'll
find another SunPlus device that actually has it.

--
Sent from my Game Boy.