Trying to understand PNG format.
Consider this PNG Image:
The Image is taken from here
In Hex Editor , it looks like this:
89 50 4E 47 0D 0A 1A 0A 00 00 00 0D 49 48 44 52 00 00 00 80 00 00 00 44 08 02 00 00 00
C6 25 AA 3E 00 00 00 C2 49 44 41 54 78 5E ED D4 81 06 C3 30 14 40 D1 B7 34 DD FF FF 6F
B3 74 56 EA 89 12 6C 28 73 E2 AA 34 49 03 87 D6 FE D8 7B 89 BB 52 8D 3B 87 FE 01 00 80
00 00 10 00 00 02 00 40 00 00 08 00 00 01 00 20 00 00 04 00 80 00 00 10 00 00 02 00 40
00 00 08 00 00 01 00 20 00 00 00 D4 5E 6A 64 4B 94 F5 98 7C D1 F4 92 5C 5C 3E CF 9C 3F
73 71 58 5F AF 8B 79 5B EE 96 B6 47 EB F1 EA D1 CE B6 E3 75 3B E6 B9 95 8D C7 CE 03 39
C9 AF C6 33 93 7B 66 37 CF AB BF F9 C9 2F 08 80 00 00 10 00 00 02 00 40 00 00 08 00 00
01 00 20 00 00 04 00 80 00 00 10 00 00 02 00 40 00 00 08 00 00 01 00 20 00 00 8C 37 DB
68 03 20 FB ED 96 65 00 00 00 00 49 45 4E 44 AE 42 60 82
Equivalent characters:
‰PNG........IHDR...€...D.....Æ%ª>...ÂIDATx^íÔ..Ã0.#Ñ·4Ýÿÿo³tVê‰.l(sâª4I.‡ÖþØ{‰
»R.;‡þ..€.......#....... ....€.......#....... ...Ô^jdK”õ˜|Ñô’\\>Ïœ?sqX_¯
‹y[î–¶GëñêÑζãu;湕.ÇÎ.9ɯÆ3“{f7Ï«¿ùÉ/.€.......#....... ....€.......#....... ..Œ7Ûh.
ûí–e....IEND®B`‚
The same is shown in following Screenshot of the HEX Editor:
I am trying to reverse engineer this image to extract the header part and the RGB pixel values. I read about the PNG and also here , and so far I have noted the following about this Image:
The IHDR chunk must appear FIRST. It contains:
Width: 4 bytes
Height: 4 bytes
Bit depth: 1 byte
Color type: 1 byte
Compression method: 1 byte
Filter method: 1 byte
Interlace method: 1 byte
Below I am starting reading the HEX Data in sequence:
1- First 8-bytes: This is the 8-Byte signature
89 50 4E 47 0D 0A 1A 0A
Equivalently this is : %PNG as can be seen in HEX Editor
A valid PNG image must contain an IHDR chunk, one or more IDAT chunks, and an IEND chunk.
2- Chunk: Length
00 00 00 0D
3-Chunk: Chunk Type
49 48 44 52
Which is IHDR.
http://www.w3.org/TR/PNG-Chunks.html
4- Chunk: Width of the Image (in Decimal 128)
00 00 00 80
5- Chunk: Height of the image (in Decimal 68)
00 00 00 44
6- Chunk: BIT DEPTH (1 byte )
08
7- Chunk: Color Type
02
8- Compression method
00
9- Filter method:
00
10- Interlace method:
00
11- What is the following data?
C6 25 AA 3E 00 00 00 C2
12-- IDAT
49 44 41 54
13- What is this data (after IDAT):
78 5E ED D4 81 06 C3 30 14 40 D1 B7 34 DD FF FF 6F B3 74 56 EA 89 12 6C 28 73 E2 AA 34 49 03 87 D6 FE D8 7B 89 BB 52 8D 3B 87 FE 01 00 80 00 00 10 00 00 02 00 40 00 00 08 00 00 01 00 20 00 00 04 00 80 00 00 10 00 00 02 00 40 00 00 08 00 00 01 00 20 00 00 00 D4 5E 6A 64 4B 94 F5 98 7C D1 F4 92 5C 5C 3E CF 9C 3F 73 71 58 5F AF 8B 79 5B EE 96 B6 47 EB F1 EA D1 CE B6 E3 75 3B E6 B9 95 8D C7 CE 03 39 C9 AF C6 33 93 7B 66 37 CF AB BF F9 C9 2F 08 80 00 00 10 00 00 02 00 40 00 00 08 00 00 01 00 20 00 00 04 00 80 00 00 10 00 00 02 00 40 00 00 08 00 00 01 00 20 00 00 8C 37 DB 68 03 20 FB ED 96 65 00 00 00 00
14- IEND:
49 45 4E 44
15- Last 4 bytes
AE 42 60 82
What are these ?
Can some help me understand, points 11, 13 and 15 above? And where are the Pixel values? The Image is having (128 x 68 pixels)
Purpose of knowing these details:
Once I know these details, I will generate my own 16 bit PNG image. I already have pixel values, so my job would be to introduce headers etc.
I dont know if there is software that can perform this job.
UPDATE
I understand now because of compression, I would not be able to locate the pixel values.
I got the idea that I can write a file in OpenCV and save it as png. Well now my direct question is: I have a binary file having gray-scale 16 bit-pixel values. Can I write this in OpenCV as 16 bit PNG ?
Although it might be interesting to learn about what PNG Images actually are, and how the image is actually represented in the file, you don't need to know this to generate a PNG file.
Note that PNG uses lossless compression, which means you won't get two bytes per pixel.
You can generate your image in a program and output it in PNG format using many of the libraries that there are out there.
For example, you can make your image in OpenCV and then output it with imWrite. One of the parameters can make it output to a PNG.
If you have the gray-scale 16-bit pixel values, then you can put them into a Mat.
Then convert that to an IplImage: Converting cv::Mat to IplImage*
Then you can output it to a file.
Just for completeness (eboix's answer is right on the spot)
11- What is the following data?
C6 25 AA 3E 00 00 00 C2
Each chunk ends with a CRC (4 bytes), and starts with 4 bytes that tell its length.
So, C6 25 AA 3E is the CRC of the previous chunk (IHDR) and 00 00 00 C2 (194) is the length of the following (IDAT) chunk.
In the same way, the last 4 bytes is the CRC of the IEND chunk.
I did not look too carefully but from looking at the structure...
Q11.
C6 25 AA 3E = CRC32
00 00 00 C2 = Size of next chunk
Q13.
check the png spec's you referred to earlier that looks like the IDAT chunk you allready know the compression applied to it!
Q15.
AE 42 60 82 = CRC32
Related
I'm developing a minimal x86-64 OS from scratch and I am attempting to detect memory to be able to map the higher half of the virtual address space to all physical memory available.
From this link: https://www.kernel.org/doc/html/latest/x86/x86_64/mm.html, I think this is what the Linux kernel does also. Probably to be able to reach all physical addresses if the need arises at some point.
ffff888000000000 | -119.5 TB | ffffc87fffffffff | 64 TB | direct mapping of all physical memory (page_offset_base)
I want to do the same in my kernel but I need to detect the amount of physical memory installed currently on my system. I can always use the Memory Map returned by UEFI but this doesn't necessarily tell me how much memory is actually installed.
I'm emulating on QEMU and I thought of locating the SMBIOS table to do that. If I print memory from 0xf0000 to 0xfffff, I don't find the signature of the SMBIOS table:
(gdb) dump memory result.bin 0xf0000 0xfffff
user#user-System-Product-Name:~$ hexdump -C result.bin
00000000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
0000fd00 ff ff ff ff ff ff ff ff 2e 06 a0 1b 79 c7 82 45 |............y..E|
0000fd10 85 66 33 6a e8 f7 8f 09 08 aa 01 08 f8 02 00 f8 |.f3j............|
0000fd20 0c 00 00 19 00 00 00 00 00 00 00 00 d4 02 00 19 |................|
0000fd30 31 c0 2d 00 10 00 00 3d 00 00 00 ff 72 33 81 78 |1.-....=....r3.x|
0000fd40 10 78 e5 8c 8c 75 eb 81 78 14 3d 8a 1c 4f 75 e2 |.x...u..x.=..Ou.|
0000fd50 81 78 18 99 35 89 61 75 d9 81 78 1c 85 c3 2d d3 |.x..5.au..x...-.|
0000fd60 75 d0 83 78 24 00 75 ca 89 c3 03 58 20 75 c3 eb |u..x$.u....X u..|
0000fd70 09 b8 bf bf bf bf 89 c5 eb fe 89 c5 e9 37 02 00 |.............7..|
0000fd80 00 31 db 89 de 89 e8 66 8b 5d 30 01 d8 72 3b eb |.1.....f.]0..r;.|
0000fd90 03 40 72 36 85 c0 74 32 83 c0 07 72 2d 24 f8 8a |.#r6..t2...r-$..|
0000fda0 58 17 f6 c3 20 74 ea 8b 48 14 81 e1 ff ff ff 00 |X... t..H.......|
0000fdb0 09 c9 74 dd 01 c1 74 02 72 d7 80 78 12 03 75 06 |..t...t.r..x..u.|
0000fdc0 eb 17 85 c0 75 06 89 c8 eb ca 31 c0 89 c6 85 f6 |....u.....1.....|
0000fdd0 75 02 74 fe e9 e4 01 00 00 85 c0 74 5f 83 c0 18 |u.t........t_...|
0000fde0 39 c8 73 58 80 78 03 10 74 1b 80 78 03 12 74 32 |9.sX.x..t..x..t2|
0000fdf0 8b 18 81 e3 ff ff ff 00 01 d8 72 40 83 c0 03 72 |..........r#...r|
0000fe00 3b 24 fc eb db 83 c0 04 66 81 38 4d 5a 75 2d 0f |;$......f.8MZu-.|
0000fe10 b7 58 3c 01 c3 81 3b 50 45 00 00 75 1f 03 43 28 |.X<...;PE..u..C(|
0000fe20 eb 1f 83 c0 04 89 c3 66 81 3b 56 5a 75 0e 03 43 |.......f.;VZu..C|
0000fe30 08 83 c0 28 0f b7 5b 06 29 d8 eb 05 b8 00 00 00 |...(..[.).......|
0000fe40 00 e9 7c ff ff ff eb 60 0f 20 e0 0f ba e8 05 0f |..|....`. ......|
0000fe50 22 e0 b9 80 00 00 c0 0f 32 0f ba e8 08 0f 30 0f |".......2.....0.|
0000fe60 20 c0 0f ba e8 1f 0f 22 c0 ea 70 fe ff ff 18 00 | ......"..p.....|
0000fe70 e9 4d 01 00 00 b8 00 00 00 80 0f a2 3d 1f 00 00 |.M..........=...|
0000fe80 80 7c 21 b8 1f 00 00 80 0f a2 0f ba e0 01 73 14 |.|!...........s.|
0000fe90 b9 31 01 01 c0 0f 32 0f ba e0 00 73 07 89 d8 83 |.1....2....s....|
0000fea0 e0 3f eb 02 31 c0 eb 02 eb cb 31 d2 85 c0 74 06 |.?..1.....1...t.|
0000feb0 83 e8 20 0f ab c2 b9 00 18 00 00 31 c0 89 04 8d |.. ........1....|
0000fec0 fc ff 7f 00 e2 f7 c7 05 00 00 80 00 23 10 80 00 |............#...|
0000fed0 89 15 04 00 80 00 c7 05 00 10 80 00 23 20 80 00 |............# ..|
0000fee0 89 15 04 10 80 00 c7 05 08 10 80 00 23 30 80 00 |............#0..|
0000fef0 89 15 0c 10 80 00 c7 05 10 10 80 00 23 40 80 00 |............##..|
0000ff00 89 15 14 10 80 00 c7 05 18 10 80 00 23 50 80 00 |............#P..|
0000ff10 89 15 1c 10 80 00 b9 00 08 00 00 89 c8 48 c1 e0 |.............H..|
0000ff20 15 05 e3 00 00 00 89 04 cd f8 1f 80 00 89 14 cd |................|
0000ff30 fc 1f 80 00 e2 e5 b8 00 00 80 00 0f 22 d8 e9 05 |............"...|
0000ff40 ff ff ff fa bb 00 f0 8e db bb 7a ff 2e 66 0f 01 |..........z..f..|
0000ff50 17 66 b8 23 00 00 40 0f 22 c0 66 ea 62 ff ff ff |.f.#..#.".f.b...|
0000ff60 10 00 b8 40 06 00 00 0f 22 e0 66 b8 08 00 8e d8 |...#....".f.....|
0000ff70 8e c0 8e e0 8e e8 8e d0 eb 39 1f 00 80 ff ff ff |.........9......|
0000ff80 00 00 00 00 00 00 00 00 ff ff 00 00 00 93 cf 00 |................|
0000ff90 ff ff 00 00 00 9b cf 00 ff ff 00 00 00 9b af 00 |................|
0000ffa0 bf 42 50 eb 0a bf 41 50 eb 05 66 89 c4 eb 02 eb |.BP...AP..f.....|
0000ffb0 f9 eb 90 e9 78 fd ff ff e9 c4 fd ff ff e9 84 fe |....x...........|
0000ffc0 ff ff b8 ff ff ff ff 48 21 c6 48 21 c5 48 21 c4 |.......H!.H!.H!.|
0000ffd0 48 89 e0 ff e6 90 90 90 90 90 90 90 90 90 90 90 |H...............|
0000ffe0 eb c3 90 90 90 90 90 90 00 00 00 00 56 54 46 00 |............VTF.|
0000fff0 90 90 eb ac 90 90 90 90 90 90 90 90 90 90 90 |...............|
0000ffff
I did try to add the -smbios type=0 flag when I launch QEMU from the command line.
I was wondering how the Linux kernel, when it runs within QEMU, does to detect memory and hardware. Does it use ACPI tables instead? I think SMBIOS is much more easy to use.
Is SMBIOS reliable enough so that operating-systems that run on newer hardware can assume its presence?
I'm implementing a PNG encoder in VHDL for learning purposes. It works with image sizes from 1x1 to 4x4. At the image size of 5x5 there is a behaviour I can't understand:
When encoding raw data with values 0...24, the encoding works. However, when using raw data with values 255...231, it generates a broken image.
Input values 0...24:
> hexdump -C png_encoder/gen/test_img_no_compression_5x5.png
00000000 89 50 4e 47 0d 0a 1a 0a 00 00 00 0d 49 48 44 52 |.PNG........IHDR|
00000010 00 00 00 05 00 00 00 05 08 00 00 00 00 a8 04 79 |...............y|
00000020 39 00 00 00 4c 49 44 41 54 78 01 00 04 00 fb ff |9...LIDATx......|
00000030 00 00 01 02 00 04 00 fb ff 03 04 00 05 00 04 00 |................|
00000040 fb ff 06 07 08 09 00 04 00 fb ff 00 0a 0b 0c 00 |................|
00000050 04 00 fb ff 0d 0e 00 0f 00 04 00 fb ff 10 11 12 |................|
00000060 13 00 04 00 fb ff 00 14 15 16 01 02 00 fd ff 17 |................|
00000070 18 0b a4 01 2d d5 1f a2 6d 00 00 00 00 49 45 4e |....-...m....IEN|
00000080 44 ae 42 60 82 |D.B`.|
00000085
> pngcheck -vv png_encoder/gen/test_img_no_compression_5x5.png
File: png_encoder/gen/test_img_no_compression_5x5.png (133 bytes)
chunk IHDR at offset 0x0000c, length 13
5 x 5 image, 8-bit grayscale, non-interlaced
chunk IDAT at offset 0x00025, length 76
zlib: deflated, 32K window, superfast compression
row filters (0 none, 1 sub, 2 up, 3 avg, 4 paeth):
0 0 0 0 0 (5 out of 5)
chunk IEND at offset 0x0007d, length 0
No errors detected in png_encoder/gen/test_img_no_compression_5x5.png (3 chunks, -432.0% compression).
Input values 255...231:
> hexdump -C png_encoder/gen/test_img_no_compression_5x5.png
00000000 89 50 4e 47 0d 0a 1a 0a 00 00 00 0d 49 48 44 52 |.PNG........IHDR|
00000010 00 00 00 05 00 00 00 05 08 00 00 00 00 a8 04 79 |...............y|
00000020 39 00 00 00 4c 49 44 41 54 78 01 00 04 00 fb ff |9...LIDATx......|
00000030 00 ff fe fd 00 04 00 fb ff fc fb 00 fa 00 04 00 |................|
00000040 fb ff f9 f8 f7 f6 00 04 00 fb ff 00 f5 f4 f3 00 |................|
00000050 04 00 fb ff f2 f1 00 f0 00 04 00 fb ff ef ee ed |................|
00000060 ec 00 04 00 fb ff 00 eb ea e9 01 02 00 fd ff e8 |................|
00000070 e7 6a 21 17 bc 9a 17 87 e7 00 00 00 00 49 45 4e |.j!..........IEN|
00000080 44 ae 42 60 82 |D.B`.|
00000085
> pngcheck -vv png_encoder/gen/test_img_no_compression_5x5.png
File: png_encoder/gen/test_img_no_compression_5x5.png (133 bytes)
chunk IHDR at offset 0x0000c, length 13
5 x 5 image, 8-bit grayscale, non-interlaced
chunk IDAT at offset 0x00025, length 76
zlib: deflated, 32K window, superfast compression
row filters (0 none, 1 sub, 2 up, 3 avg, 4 paeth):
zlib: inflate error = -3 (data error)
(0 out of 5)
ERRORS DETECTED in png_encoder/gen/test_img_no_compression_5x5.png
How to interpret the error message zlib: inflate error = -3 (data error)?
I read https://www.zlib.net/zlib_how.html, but didn't find more specific information. My first guess was the row filters are incorrect, but since both files are structured the same, this is unlikely. Is there something wrong with the ADLER32 calculation in the second case (possibly some overflow)?
It was an overflow in the ADLER32 checksum calculation. Specifically, there were two 16 bit numbers added and truncated before applying the modulo with 65521. Unfortunately my ADLER32 unittest didn't catch it, yet.
However, the error message was shown several times during the implementation and I was always not sure about the cause. If anybody could elaborate the error message or explain how to get a better error message, I would be glad to hear it.
I'm currently working on an old MS-DOS application, which uses DMI to identify the hardware. It worked fine in the past, but it seems to provide invalid data on newer systems (e.g. Skylake). As stated in the spec, we are scanning 0xF0000-0xFFFFF for the "SM" anchor string, this is still working as expected.
But now it seems that the data located at the "Structure table adress" (stored at offset 0x18h in the) are invalid (see dumps below). Tools like dmidecoe deliver correct information (however, it uses GetSystemFirmwareTable() on Windows). What I am doing wrong here?
EDIT (clarify situation)
On an older system I get expected data (dump is done in FreeDOS' debug98 utility) - following come from an IvyBridge system (3rd gen.):
-d F000:04C0
F000:04C0 5F 53 4D 5F 03 1F 02 07-77 00 00 00 00 00 00 00 _SM_....w.......
F000:04D0 5F 44 4D 49 5F E0 6E 04-10 BA 0E 00 17 00 27 00 _DMI_.n.......'.
F000:04E0 1E 66 60 68 00 F0 1F B8-90 D0 83 C0 0F 24 F0 A3 .f`h.........$..
F000:04F0 1D 03 B9 00 E0 2B C8 79-02 33 C9 89 0E 1F 03 33 .....+.y.3.....3
F000:0500 C0 66 2E 8B 1E 63 00 66-83 FB 00 74 0B 66 81 FB .f...c.f...t.f..
F000:0510 00 00 0E 00 72 02 8B C3-A3 19 03 F7 D0 A3 1B 03 ....r...........
F000:0520 66 61 1F C3 00 1E 50 68-00 F0 1F 0B DB 74 28 F7 fa....Ph.....t(.
F000:0530 C3 80 00 74 1C 2E 80 3E-24 05 00 75 43 83 F9 3E ...t...>$..uC..>
-d E000:BA10
E000:BA10 00 18 00 00 01 02 00 F0-03 7F 80 98 89 3F 01 00 .............?..
E000:BA20 00 00 03 0D 04 06 FF FF-41 6D 65 72 69 63 61 6E ........American
E000:BA30 20 4D 65 67 61 74 72 65-6E 64 73 20 49 6E 63 2E Megatrends Inc.
E000:BA40 00 42 51 37 37 52 31 31-31 00 30 37 2F 30 35 2F .BQ77R111.07/05/
E000:BA50 32 30 31 33 00 00 01 1B-01 00 01 02 03 04 00 00 2013............
E000:BA60 01 26 60 24 00 05 00 06-00 07 00 08 00 09 06 05 .&`$............
E000:BA70 06 20 00 20 00 20 00 30-30 30 30 30 31 32 36 36 . . . .000001266
E000:BA80 30 32 34 00 20 00 20 00-00 02 0F 02 00 01 02 03 024. . .........
Newer systems - in this case a Skylake based one (6th gen.) data are different. In the adress the SMI structure points to i do not get the expected data (I expcted to see the BIOS strings, but they are not there):
-d f000:05e0
F000:05E0 5F 53 4D 5F F3 1F 03 00-8C 01 00 00 00 00 00 00 _SM_............
F000:05F0 5F 44 4D 49 5F 15 CE 07-00 90 1D 87 1A 00 30 00 _DMI_.........0.
F000:0600 5F 53 4D 33 5F 4A 18 03-00 00 01 00 CE 07 00 00 _SM3_J..........
F000:0610 00 90 1D 87 00 00 00 00-00 00 00 00 00 00 00 00 ................
F000:0620 1E 66 60 68 00 F0 1F B8-00 C6 83 C0 0F 24 F0 A3 .f`h.........$..
F000:0630 8E 03 B9 00 E0 2B C8 79-02 33 C9 89 0E 90 03 33 .....+.y.3.....3
F000:0640 C0 66 2E 8B 1E 63 00 66-83 FB 00 74 0B 66 81 FB .f...c.f...t.f..
F000:0650 00 00 0E 00 72 02 8B C3-A3 8A 03 F7 D0 A3 8C 03 ....r...........
-d 871d:9000
871D:9000 76 06 D1 E9 73 08 8A 05-A4 88 44 FF 74 08 8B 05 v...s.....D.t...
871D:9010 A5 89 44 FE E2 F8 5F 5E-5D C2 04 00 55 8B EC 4C ..D..._^]...U..L
871D:9020 4C 56 57 83 7E 04 02 73-2D 83 7E 04 02 74 03 E9 LVW.~..s-.~..t..
871D:9030 18 01 8B 46 06 03 06 AC-10 8B F8 50 FF 76 06 FF ...F.......P.v..
871D:9040 16 AE 10 59 59 0B C0 7F-03 E9 FE 00 FF 76 06 57 ...YY........v.W
871D:9050 E8 9D FF E9 F4 00 8B 46-04 48 F7 2E AC 10 8B 56 .......F.H.....V
871D:9060 06 03 D0 8B FA 8B 46 04-D1 E8 F7 2E AC 10 8B 56 ......F........V
871D:9070 06 03 D0 8B F2 57 56 FF-16 AE 10 59 59 0B C0 7E .....WV....YY..~
Your SMBIOS structures are located at physical address 0x871d9000 (as seen from offset f000:0610, or offset x10 from the '_SM3_' anchor string), as Michael Petch points out.
This is a minor point but could be important depending on how your software is constructed. Keep in mind this is a SMBIOS 3.0 conforming structure (per the "_SM3_" anchor string) and that the structure table address can be on any 64-bit address. To ensure your software works in all systems, you should use the _SM3_ structure table address when present and enable your software to read any 64-bit physical address using big-real mode or other mechanism. When the _SM3_ structure is not present, then revert back to your old software flow.
As for why you are just now seeing this, is this the first time you have encountered a data structure that is above 1MB physical address?
I am working with neural network to classify images.
I have some files generated by a CytoVision Platform. I would like to use the images in those files but I need to extract them somehow.
These .slide files contain several images of apparently 16kb each one.
I have developed a program in C that I am currently running on linux to extract each 16kb in files. I should build a header in order to use those images.
I don't know which format they have.
If I look at the entire file as a bitmap with FileAlyzer I can see this:
File as a bitmap
This link should allow anyone to download an example file:
https://ufile.io/2ibdq
This is what it seems to be one image header:
42 4D 31 00 00 00 00 00 40 8F 40 05 00 9E 5F 98 D7 47 60 A1 40 01 04 4D 65 74 31 00 00 00 00 00 40 8F 40 05 00 64 31 2E 29 B5 46 DC 40 01 04 4D 65 74 32 00 00 00 00 00 40 8F 40 05 00 87 7D 26 70 88 C0 C5 40 01 04 4D 65 74 33 00 00 00 00 00 40 8F 40 05 00 C8 97 53 05 BB 0D 0F 41 01 04 54 65 78 31 00 00 00 00 00 00 D0 40 05 00 00 00 00 00 00 40 5C 40 07 04 54 65 78 32 00 00 00 00 00 00 D0 40 05 00 00 00 00 00 00 00 44 40 07 04 54 65 78 33 00 00 00 00 00 00 D0 40 05 00 00 00 00 00 00 90 76 40 07 04 54 65 78 34 00 00 00 00 00 00 D0 40 05 00 00 00 00 00 00 F4 CD 40 07 0A 43 68 72 6F 6D 73 41 72 65 61 00 00 00 00 00 4C BD 40 05 00 F3 76 84 D3 82 85 74 40 07 08 42 6F 75 6E 64 61 72 79 00 00 00 00 00 88 B3 40 05 00 D9 CE F7 53 E3 AD 7E 40 07 04 41 72 65 61 00 00 00 00 00 88 B3 40 05 00 20 EF 55 2B 13 0B 85 40 07 07 4F 62 6A 65 63 74 73 00 00 00 00 00 00 69 40 05 00 00 00 00 00 00 00 18 40 03 04 43 69 72 63 00 00 00 00 00 40 8F 40 05 00 9D E5 51 0E 5C 34 65 40 03 03 42 47 52 00 00 00 00 00 40 8F 40 05 00 7D 0C CE C7 E0 AC 86 40 03 04 54 65 78 35 00 00 00 00 00 00 D0 40 05 00 00 00 00 00 00 00 53 40 07 04 41 52 41 54 00 00 00 00 00 40 8F 40 05 00 86 89 F7 23 A7 79 7E 40 07 05 43 6C 61 73 73 00 00 00 00 00 00 F0 3F 05 00 00 00 00 00 00 00 F0 BF 00 01 00 00 00 01 00 00 00
With notepad++ I can see the previous hex like this:
BM1 #? ??G`?Met1 #? d1.)??Met2 #? ?&p?bMet3 #? ?S?ATex1 ? #\#Tex2 ? D#Tex3 ? ?#Tex4 ? ??
ChromsArea L? ???t#Boundary ?# ???~#Area ?# ?bObjects i# #Circ #? ?Q\4e#BGR #? }??#Tex5 ? S#ARAT #? Ð??~#Class ?? ?? #
Hope someone can give me an idea about the format of the images and what info I can extract from the header.
I want to reverse old .exe file; I'm 90% sure it is Delphi (class names are being with 'T' => "TCommonDialog")
I can't load file into IDR (becouse it is not valid PE-executable?) jet still .exe works just fine and icon is showing just right.
I was trying to maniupulate header but every time I just corrupt .exe
Header with MZ:
00000000 4d 5a 00 01 01 00 00 00 08 00 10 00 ff ff 08 00 |MZ..............|
00000010 00 01 00 00 00 00 00 00 40 00 00 00 00 00 00 00 |........#.......|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 |................|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000080
Further is longer header, but with NE; I was trying to change it to PE.
At this point I don't know what am I doing, I just mess with everything
00000000 4e 45 06 01 17 07 5a 00 00 00 00 00 0a 03 16 00 |NE....Z.........|
00000010 00 20 00 40 0e 00 01 00 00 00 16 00 16 00 0c 00 |. .#............|
00000020 0e 00 40 00 f0 00 9f 06 a9 06 c1 06 71 08 00 00 |..#.........q...|
00000030 0e 00 04 00 00 00 02 00 00 00 00 00 00 00 0a 03 |................|
00000040 e4 36 cc 3d 10 1d cd 3d e5 3a 47 3e 10 1d 47 3e |.6.=...=.:G>..G>|
00000050 d3 3e 6f 3f 10 1d 70 3f d6 42 96 3f 10 1d 97 3f |.>o?..p?.B.?...?|
00000060 d9 46 20 3a 10 1d 21 3a 8f 4a 09 33 10 1d 0a 33 |.F :..!:.J.3...3|
00000070 cd 4d 99 30 10 1d 9a 30 df 50 1c 33 10 1d 1c 33 |.M.0...0.P.3...3|
00000080 17 54 7b 9a 10 1d 7b 9a d3 5d 33 3c 10 1d 33 3c |.T{...{..]3<..3<|
00000090 90 00 17 3a 50 1d 17 3a 57 04 c1 2f 50 1d c1 2f |...:P..:W../P../|
000000a0 5b 07 2c 41 50 1d 2d 41 77 0b b9 66 50 1d ba 66 |[.,AP.-Aw..fP..f|
000000b0 f5 11 28 70 50 1d 28 70 1f 19 cc 22 50 1d cc 22 |..(pP.(p..."P.."|
000000c0 55 1b 00 6f 50 1d 00 6f 6c 22 84 7a 50 1d 85 7a |U..oP..ol".zP..z|
000000d0 45 2a 31 51 50 1d 31 51 65 2f 8d 30 50 0d 8d 30 |E*1QP.1Qe/.0P..0|
000000e0 99 32 c6 1f 50 0d c6 1f eb 34 5d 1f 59 0d 8c 2f |.2..P....4].Y../|
000000f0 04 00 03 80 01 00 00 00 00 00 a9 61 30 00 10 1c |...........a0...|
00000100 01 80 00 00 00 00 0e 80 01 00 00 00 00 00 d9 61 |...............a|
00000110 10 00 10 1c e4 03 00 00 00 00 0a 80 18 00 00 00 |................|
00000120 00 00 e9 61 30 00 30 1c ed 03 00 00 00 00 19 62 |...a0.0........b|
00000130 10 11 30 1c f1 03 00 00 00 00 29 73 80 04 30 1c |..0.......)s..0.|
00000140 fb 03 00 00 00 00 a9 77 40 00 30 1c 04 04 00 00 |.......w#.0.....|
00000150 00 00 e9 77 f0 04 30 1c 11 04 00 00 00 00 d9 7c |...w..0........||
00000160 30 00 30 1c 1c 04 00 00 00 00 09 7d 80 00 30 1c |0.0........}..0.|
00000170 25 04 00 00 00 00 89 7d e0 00 30 1c 39 04 00 00 |%......}..0.9...|
00000180 00 00 69 7e 40 00 30 1c 48 04 00 00 00 00 a9 7e |..i~#.0.H......~|
00000190 c0 01 30 1c 54 04 00 00 00 00 69 80 d0 05 30 1c |..0.T.....i...0.|
000001a0 5b 04 00 00 00 00 39 86 50 00 30 1c 65 04 00 00 |[.....9.P.0.e...|
000001b0 00 00 89 86 60 00 30 1c 72 04 00 00 00 00 e9 86 |....`.0.r.......|
000001c0 50 00 30 1c 80 04 00 00 00 00 39 87 50 00 30 1c |P.0.......9.P.0.|
000001d0 8f 04 00 00 00 00 89 87 40 00 30 1c 9c 04 00 00 |........#.0.....|
000001e0 00 00 c9 87 50 00 30 1c a9 04 00 00 00 00 19 88 |....P.0.........|
000001f0 40 00 30 1c b6 04 00 00 00 00 59 88 50 00 30 1c |#.0.......Y.P.0.|
00000200 c3 04 00 00 00 00 a9 88 50 00 30 1c d1 04 00 00 |........P.0.....|
00000210 00 00 f9 88 50 00 30 1c de 04 00 00 00 00 49 89 |....P.0.......I.|
00000220 40 00 30 1c eb 04 00 00 00 00 89 89 70 01 30 1c |#.0.........p.0.|
00000230 f8 04 00 00 00 00 f9 8a 90 00 30 1c 00 05 00 00 |..........0.....|
00000240 00 00 02 80 17 00 00 00 00 00 89 8b 10 00 30 1c |..............0.|
00000250 05 05 00 00 00 00 99 8b 10 00 30 1c 0d 05 00 00 |..........0.....|
00000260 00 00 a9 8b 10 00 30 1c 18 05 00 00 00 00 b9 8b |......0.........|
00000270 10 00 30 1c 1f 05 00 00 00 00 c9 8b 10 00 30 1c |..0...........0.|
00000280 29 05 00 00 00 00 d9 8b 10 00 30 1c 33 05 00 00 |).........0.3...|
00000290 00 00 e9 8b 10 00 30 0c 3c 05 00 00 00 00 f9 8b |......0.<.......|
000002a0 10 00 30 0c 45 05 00 00 00 00 09 8c 10 00 30 1c |..0.E.........0.|
000002b0 4c 05 00 00 00 00 19 8c 10 00 30 1c 51 05 00 00 |L.........0.Q...|
000002c0 00 00 29 8c 10 00 30 1c 57 05 00 00 00 00 39 8c |..)...0.W.....9.|
000002d0 10 00 30 1c 5c 05 00 00 00 00 49 8c 10 00 30 1c |..0.\.....I...0.|
000002e0 63 05 00 00 00 00 59 8c 20 00 30 1c 68 05 00 00 |c.....Y. .0.h...|
000002f0 00 00 79 8c 20 00 30 1c 6f 05 00 00 00 00 99 8c |..y. .0.o.......|
00000300 20 00 30 1c 74 05 00 00 00 00 b9 8c 20 00 30 1c | .0.t....... .0.|
00000310 79 05 00 00 00 00 d9 8c 20 00 30 1c 7f 05 00 00 |y....... .0.....|
00000320 00 00 f9 8c 20 00 30 1c 88 05 00 00 00 00 19 8d |.... .0.........|
00000330 20 00 30 1c 90 05 00 00 00 00 39 8d 20 00 30 1c | .0.......9. .0.|
00000340 98 05 00 00 00 00 59 8d 20 00 30 1c 9e 05 00 00 |......Y. .0.....|
00000350 00 00 79 8d 20 00 30 1c a6 05 00 00 00 00 01 80 |..y. .0.........|
00000360 06 00 00 00 00 00 99 8d 20 00 30 1c 01 80 00 00 |........ .0.....|
00000370 00 00 c9 8d 20 00 30 1c 02 80 00 00 00 00 f9 8d |.... .0.........|
00000380 20 00 30 1c 03 80 00 00 00 00 29 8e 20 00 10 1c | .0.......). ...|
00000390 04 80 00 00 00 00 59 8e 20 00 10 1c 05 80 00 00 |......Y. .......|
000003a0 00 00 89 8e 20 00 30 1c 06 80 00 00 00 00 0c 80 |.... .0.........|
000003b0 06 00 00 00 00 00 b9 8d 10 00 30 1c fb ff 00 00 |..........0.....|
000003c0 00 00 e9 8d 10 00 30 1c fc ff 00 00 00 00 19 8e |......0.........|
000003d0 10 00 30 1c fd ff 00 00 00 00 49 8e 10 00 30 1c |..0.......I...0.|
000003e0 fe ff 00 00 00 00 79 8e 10 00 30 1c ff ff 00 00 |......y...0.....|
000003f0 00 00 a9 8e 10 00 30 1c fa ff 00 00 00 00 06 80 |......0.........|
00000400 11 00 00 00 00 00 b9 8e 20 00 30 1c 01 8f 00 00 |........ .0.....|
00000410 00 00 d9 8e 20 00 30 1c 02 8f 00 00 00 00 f9 8e |.... .0.........|
00000420 20 00 30 1c 03 8f 00 00 00 00 19 8f 20 00 30 1c | .0......... .0.|
00000430 04 8f 00 00 00 00 39 8f 20 00 30 1c 05 8f 00 00 |......9. .0.....|
00000440 00 00 59 8f 20 00 30 1c 06 8f 00 00 00 00 79 8f |..Y. .0.......y.|
00000450 20 00 30 1c 07 8f 00 00 00 00 99 8f 10 00 30 1c | .0...........0.|
00000460 08 8f 00 00 00 00 a9 8f 10 00 30 1c 09 8f 00 00 |..........0.....|
00000470 00 00 b9 8f 20 00 30 1c 0a 8f 00 00 00 00 d9 8f |.... .0.........|
00000480 20 00 30 1c 0b 8f 00 00 00 00 f9 8f 20 00 30 1c | .0......... .0.|
00000490 f9 8f 00 00 00 00 19 90 20 00 30 1c fa 8f 00 00 |........ .0.....|
000004a0 00 00 39 90 10 00 30 1c fb 8f 00 00 00 00 49 90 |..9...0.......I.|
000004b0 10 00 30 1c fd 8f 00 00 00 00 59 90 10 00 30 1c |..0.......Y...0.|
000004c0 fe 8f 00 00 00 00 69 90 10 00 30 1c ff 8f 00 00 |......i...0.....|
000004d0
If you look at the information provided by fileformat.info, you'll see that this is very likely an NE executable. These also start with MZ, but the rest is different.
Reading the bytes at offsets 0000000C and 0000000D, this is probably a Windows 3.x Protected Mode program. If it is made with Delphi, that can only have been Delphi 1, which did not produce PE executables, but 16 bit Windows executables instead.