Re: [coreboot] ultimate VGABIOS extraction! +NEW working way for AMD laptop's discrete GPU
Hi,
On 07.07.2017 20:03, Mike Banon wrote:
=== ROM locations examples for 0x0 - 0x42F000000 dump made while 16GB RAM:
0x000512000 - broken integrated graphics ROM, first "ghost" 0x3250D9020 - broken integrated graphics ROM, second "ghost" 0x3578FB000 - broken integrated graphics ROM, third "ghost" 0x36B22A01C - broken integrated graphics ROM, fourth "ghost" 0x4122BD000 - broken integrated graphics ROM, fifth "ghost"
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. If you can confirm that they are physical addresses, please append the output of `dmesg`.
Nico
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.romwhere $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
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@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.romwhere $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@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
-
Mike Banon -
Nico Huber -
Peter Stuge