Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to find framebuffer? #4

Open
InvisiBot opened this issue Jun 6, 2021 · 1 comment
Open

How to find framebuffer? #4

InvisiBot opened this issue Jun 6, 2021 · 1 comment

Comments

@InvisiBot
Copy link

Hello. I have a TV LG 24MT49S-PZ, WebOS 3.8
Screen resolution: 1366x768, but interface resolution: 1920x1080.
Before making dumps of memory, I opened the cinema app to understand what image I'm looking for.

Photo of a TV screen

I made a memory dump using memdump (armel binary from deb package).
memdump > /tmp/usb/sda/sda1/dump1
dump1 file has a size of 401MB (420478976 bytes). It is strange because the free -m shows 660MB RAM.
GIMP cannot open this file. And I tried to open with FFMPEG.
ffplay.exe -framerate 1 -f rawvideo -pixel_format rgba -video_size 1920x1080 -i I:\dump1
For 51 frames (1920x1080x4=8294400 bytes for 1 frame), I saw digital noise and several scraps of images. It does not look like Framebuffer, I think this is a disk cache.

Screens dump1 06-06-2021_17-03-59 06-06-2021_17-04-05 06-06-2021_17-04-11 06-06-2021_17-04-21

I started looking for the remaining 220MB.

cat /proc/iomem
20200000-392fffff : System RAM - dec: 538968064-959447039 (420478975 bytes) # memdump sees only this region
  20208000-20ae5f5b : Kernel code - dec: 539000832-548298587 (9297755 bytes)
  20b6a000-20d0fe9b : Kernel data - dec: 548839424-550567579 (1728155 bytes)
4e400000-5fffffff : System RAM - dec: 1312817152-1610612735 (297795583 bytes)
fd201a00-fd201bfc : Mstar-ehci-2.1
fd34a000-fd34b100 : Mali_PP1
................................ etc .....

To check the availability of certain areas of memory, I used hexdump:
hexdump -C -v -n 128 -s 0x20200000 /dev/mem or hexdump -C -v -n 128 -s 538968064 /dev/mem
So I found two more areas of memory that are missing in /proc/iomem

39400000-4ADFF000 - dec: 960495616-1256189952 (295694336 bytes)
4C400000-4E400000 - dec: 1279262720-1312817152 (33554432 bytes)

To get a dump of these memory regions I used dd:
dd if=/dev/mem of=/media/nfs/dump2 skip=960495616 bs=1
dd if=/dev/mem of=/media/nfs/dump3 skip=1279262720 bs=1
After some time (1-2 hours), dd stops:
dd: /dev/mem: Bad address
or
Segmentation fault
And I have dump2 and dump3 files.
ffmpeg sees only noises in dump2.
But dump3 besides noise has several images.

Screens dump3 06-06-2021_19-01-13 06-06-2021_19-01-24

However, these images are not similar to Framebuffer. In my understanding, Framebuffer has a screen image of 1920x1080x4 = 8294400 bytes
How can I find the Framebuffer offset in these dumps?
Perhaps you could watch my dumps and find offset in the file with Framebuffer?

Additional Information:
cat /proc/iomem https://pastebin.com/Y0rQEvMk
cat /proc/meminfo https://pastebin.com/0biR3WrM
fbset https://pastebin.com/krmjZ4bK
dmesg https://pastebin.com/ZM73KqDu

dumps (373MB):
https://disk.yandex.ru/d/EAKxJrbHtlumCw
or
https://drive.google.com/file/d/1VhF3yZGmMT4T3Dhm-HIR4YdqZUzdUymd/view

@DavidBuchanan314
Copy link
Owner

For me, the framebuffer was not inside any of the ranges listed in /proc/iomem, so I don't think it would have shown up in memdump dumps.

To open the dumps in GIMP, give them a .data file extension, and it should Just Work.

I wrote a small python script to mmap 1MB sub-sections of /dev/mem, and then dump them to a file. I dumped the entire 4GiB address space in this way. A couple of memory ranges caused the TV to freeze or reboot, but I just rebooted and continued after the problematic area.

Unfortunately I don't have a copy of that python script any more, but there wasn't much to it. I'll see if I can find it again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants