[coreboot] ultimate VGABIOS extraction! +NEW working way for AMD laptop's discrete GPU

[Mike Banon]

hi Nico and Peter, my friend wrote to Belkasoft and we just got a
reply (please scroll down to see it) which confirms that these dump
file offsets are not the physical addresses. We were already sure
about that : these addresses were different for each dump and a number
of "ghosts" was different; also "cat /proc/iomem" tells about just 1
Video ROM, which belongs to Integrated GPU and is situated at low
memory area 0xc0000

Some memory areas visible at "iomem" seem difficult to dump - even if
we boot with iomem=relaxed, while trying dd under root we are getting
"operation not permitted"

Yes it should be somehow possible to dump this discrete Video BIOS ROM
at Linux, but (as you could see by my previous message) we already
wasted a lot of time without any result . If you also have Lenovo
G505S with discrete graphics - maybe you could achieve more success
than us. Meanwhile we are completely satisfied with this Windows-only
solution, but only for these reasons:

1) dumped AtomBIOS ROM for integrated GPU at Windows - was the same as
at Linux, most likely there is the same situation with discrete GPU -
in which case it shouldn't matter which OS you are using to dump

2) since these AtomBIOS ROMs could be disassembled with AtomDis: when
we will (soon) upload our extracted discrete Video BIOS files, with
sha256 checksums, everyone will be able to verify that there are no
backdoors; so only a few people would feel a real need to temporarily
install Windows just to reproduce our steps. This inconvenient "last
resort" procedure is needed to be done just once for any computer that
could not dump discrete GPU VBIOS by coreboot wiki's 5 methods

3) we believe that the security of computer with open source OS
running at hardware with proprietary UEFI/BIOS (with its' Intel iPXE
boot agents even at this AMD hardware without ME or PSP, and other
dark secrets) - is not much higher than of the same computer with
closed source OS, as long as they have never been connected to the
Internet since their installation ; in which case they are both a fine
platform for VBIOS extraction

== Question of my friend:

... about the size of RAM Capturer's memory dumps:

if 8GB RAM (8192MB) is installed to laptop, the dumps are 8944MB size
if 16GB RAM (16384MB) is installed to laptop, the dumps are 17136MB size

At both cases, a size of dump was by 752MB larger than a size of RAM,
so I think that : in addition to RAM this dump also contains some
other volatile memories at unclear order

Please could you tell the approximate memory map of Capturer's memory
dumps? Not hoping for any specific numbers (I understand that the
exact values are hardware specific) , I just would like to know : in
what sequential order what different memory areas are dumped inside
this file ?

== Answer from Belkasoft:

Thank you for your request. Our RAM Capturer uses API calls to get
memory known to the operating system, and the OS returns information
on all available memory including pagefile.sys. The page file usually
occupies several parts of the common memory address space, and can't
be separated from the actual RAM. That's why the total size of a dump
becomes greater than the size of RAM. Unfortunately there is no way to
determine which bytes come from RAM and which ones from the page file.

Best regards,
Mike Banon

On Sat, Jul 8, 2017 at 10:56 PM, Peter Stuge <peter at stuge.se> wrote:
> Nico Huber wrote:
>> > 0x42D3B3000 - working integrated graphics ROM !!!
>> >
>> > 0x42D305020 - working discrete graphics ROM (first working copy, the same)
>> > 0x42E40DCD0 - working discrete graphics ROM (second working copy, the same)
>>
>> nice work! If these are physical addresses, dumping from Linux should
>> come easy: Boot with `iomem=relaxed` in the kernel command line and then
>> as root execute:
>>
>>     # dd bs=1 skip=$addr count=64K if=/dev/mem of=dumped.rom
>>
>> where $addr is the physical address.
>>
>> Would be interesting to know, if these lie within a reserved BIOS area
>> of the RAM.
>
> Run this to find out:
>
> cat /proc/iomem
>
>
>> If you can confirm that they are physical addresses, please
>> append the output of `dmesg`.
>
>
> //Peter
>
> --
> coreboot mailing list: coreboot at coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot