I have just started studying X86 Assembly Language.
My doubt -
When I am using the DOS DEBUG program to look at memory location, I am getting slightly different values on examining the same memory location using two different segment:offset addresses. I.e.-
Aren't D 40[0]:17 and D 41[0]:7 supposed to give exactly same output? since both of them give same address on adding segment + offset = 400+17 = 410+7 = 417H
The results which I get - (notice they are slightly different)
-D 40:17
0040:0010 00-00 00 1E 00 1E 00 0D 1C .........
0040:0020 44 20 20 39 34 05 34 05-3A 27 39 0A 0D 1C 44 20 D 94.4.:'9...D
0040:0030 20 39 34 05 30 0B 3A 27-31 02 37 08 0D 1C 00 00 94.0.:'1.7.....
0040:0040 93 00 C3 00 00 00 00 00-00 03 50 00 00 10 00 00 ..........P.....
0040:0050 00 18 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0040:0060 0F 0C 00 D4 03 29 30 00-00 00 00 00 91 DA 10 00 .....)0.........
0040:0070 00 00 00 00 00 00 08 00-14 14 14 14 01 01 01 01 ................
0040:0080 1E 00 3E 00 18 10 00 60-F9 11 0B 00 50 01 00 00 ..>....`....P...
0040:0090 00 00 00 00 00 00 10 .......
-D 41:7
0041:0000 00-00 00 2C 00 2C 00 44 20 ...,.,.D
0041:0010 20 39 34 05 31 02 3A 27-37 08 0D 1C 0D 1C 44 20 94.1.:'7.....D
0041:0020 20 39 34 05 30 0B 3A 27-31 02 37 08 0D 1C 00 00 94.0.:'1.7.....
0041:0030 08 00 C3 00 00 00 00 00-00 03 50 00 00 10 00 00 ..........P.....
0041:0040 00 18 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0041:0050 0F 0C 00 D4 03 29 30 00-00 00 00 00 1C DB 10 00 .....)0.........
0041:0060 00 00 00 00 00 00 08 00-14 14 14 14 01 01 01 01 ................
0041:0070 1E 00 3E 00 18 10 00 60-F9 11 0B 00 50 01 00 00 ..>....`....P...
0041:0080 00 00 00 00 00 00 10 .......
You are looking at the BIOS data area, whose contents changes over time since it contains things like the state of shift/control/alt keys, the read/write positions of the keyboard buffer and the timer.
Related
I want to write to a mifare classic 4k, using the following APDU command (UPDATE BINARY):
APDU = {FF D6 00 20 10 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0Fh}
It seems fine as a get a 90 00 result...
but when i read the card back I always got the following (even with different data...):
sector: 8 (block 32), auth OK
032: D5 41 00 EA 00 FF 13 3E 86 6A 00 00 00 00 69 FF
033: D5 41 00 EA 00 FF 13 3E 86 6A 00 00 00 00 69 FF
034: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
035: 00 00 00 00 00 00 FF 07 80 69 FF FF FF FF FF FF
where does this string D5 41 00 EA 00 FF 13 3E 86 6A 00 00 00 00 69 FF come from?
Note that i didn't change any setting on the card and was properly authenticated. It was a blank card and i didn't touch the trailer.
I m using a ACR122 reader (this command comes direct from the documentation of the reader...)
Ok i found my problem, i was setting the wrong size for the cbSendLength parameter in SCardTransmit.
Now i set the correct one (the whole size of the APDU command: 21) and it works fine.
Sorry.
I followed this tutorial to the letter, but I'll to explain in detail what steps I took exactly. I have an ECP5-evaluation 85k board.
I soldered bridges on R34/R35 (RX/TX) and R21 (connects LED D1 to RXD)
I used my windows installation to run the latest version of FT_PROG. In FT_PROG I went to FT_EEPROM -> Hardware Specific -> Port B -> Hardware and set it to RS232 and hit program. It completed succesfully according to the software.
Then I forwarded the USB port to my virtual box linux machine. It recognizes the board and I can succesfully run verilog files on it.
I ran ./raw_serial.sh to upload raw_serial.v to my board which is supposed to repeatedly print A to the serial monitor.
I then opened minicom on /dev/ttyUSB1 and it recognizes the device, baudrate is set correctly.
I then tried to use cu as follows: sudo chmod 666 /dev/ttyUSB1 && sudo cu -l /dev/ttyUSB2 -s 115200. It opens a terminal and says it is connected.
Led D1 is lighting up and both terminal programs indicate that the connection is succesful (I tried one of them at a time of course). Nothing is printed to the screen. When I use minicom and reupload raw_serial.v some <?> signs are printed to the screen but that's it. I tried turning echo on and off but nothing seems to work.
The following worked for me and it will probably work for others too. I'm assuming you're using openocd.
Do not use FT_PROG in windows, it doesn't seem to actually flash the FTDI chip. However, it lets you read back the hex dump that was supposed to be flashed to the chip. The hex dump for the unchanged EEPROM as it comes out of the box is as follows:
00000000 01 08 03 04 10 60 00 07 C0 FA 08 00 11 11 9A 10 .....`..Àú....š.
00000010 AA 3C E6 12 00 00 00 00 56 00 00 00 00 00 00 00 ª<æ.....V.......
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 00 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 02 03 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 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000090 00 00 00 00 00 00 00 00 00 00 10 03 4C 00 61 00 ............L.a.
000000A0 74 00 74 00 69 00 63 00 65 00 3C 03 4C 00 61 00 t.t.i.c.e.<.L.a.
000000B0 74 00 74 00 69 00 63 00 65 00 20 00 45 00 43 00 t.t.i.c.e. .E.C.
000000C0 50 00 35 00 20 00 45 00 76 00 61 00 6C 00 75 00 P.5. .E.v.a.l.u.
000000D0 61 00 74 00 69 00 6F 00 6E 00 20 00 42 00 6F 00 a.t.i.o.n. .B.o.
000000E0 61 00 72 00 64 00 12 03 46 00 54 00 32 00 55 00 a.r.d...F.T.2.U.
000000F0 59 00 54 00 4A 00 56 00 00 00 00 00 00 00 FC 27 Y.T.J.V.......ü'
I just post this here for future reference, we're not going to use the stock eeprom.
We need to flash the eeprom to RS232-HS mode. To do so, we must first change the hex dump of the eeprom accordingly. To put channel B in RS232-HS mode we need to change the last column of the last row from ' to |. Create a hex file called eeprom_RS232.bin with the following contents:
00000000 01 08 03 04 10 60 00 07 C0 FA 08 00 11 11 9A 10 .....`..Àú....š.
00000010 AA 3C E6 12 00 00 00 00 56 00 00 00 00 00 00 00 ª<æ.....V.......
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 00 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 02 03 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 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000090 00 00 00 00 00 00 00 00 00 00 10 03 4C 00 61 00 ............L.a.
000000A0 74 00 74 00 69 00 63 00 65 00 3C 03 4C 00 61 00 t.t.i.c.e.<.L.a.
000000B0 74 00 74 00 69 00 63 00 65 00 20 00 45 00 43 00 t.t.i.c.e. .E.C.
000000C0 50 00 35 00 20 00 45 00 76 00 61 00 6C 00 75 00 P.5. .E.v.a.l.u.
000000D0 61 00 74 00 69 00 6F 00 6E 00 20 00 42 00 6F 00 a.t.i.o.n. .B.o.
000000E0 61 00 72 00 64 00 12 03 46 00 54 00 32 00 55 00 a.r.d...F.T.2.U.
000000F0 59 00 54 00 4A 00 56 00 00 00 00 00 00 00 FC 27 Y.T.J.V.......ü|
Now, we need to flash this eeprom to our ECP5 using Anton's method. To do this, first create a file ftdi_RS232.conf with the following contents:
vendor_id=0x403
product_id=0x6010
filename="eeprom_RS232.bin"
flash_raw=true
With the following command we can flash to our ECP5: ftdi_eeprom --flash-eeprom ftdi_RS232.conf. Should we ever want to revert back to the stock eeprom, we can easily repeat this method with the hex dump given in step 1.
Now it's time to flash the verilog file. However, the device description of the ECP5 has changed from Lattice ECP5 Evaluation Board to Dual RS232-HS. We need to tell openocd to look for that specific device. Start by creating a file ecp5.cfg with the following contents:
# this supports ECP5 Evaluation Board
interface ftdi
ftdi_device_desc "Dual RS232-HS"
ftdi_vid_pid 0x0403 0x6010
# channel 1 does not have any functionality
ftdi_channel 0
# just TCK TDI TDO TMS, no reset
ftdi_layout_init 0xfff8 0xfffb
reset_config none
# default speed
adapter_khz 5000
# ECP5 device - LFE5UM5G-85F
jtag newtap ecp5 tap -irlen 8 -expected-id 0x81113043
Then, create your svf file as you usually do and flash it with the following command:
sudo --preserve-env=PATH env openocd -f ./ecp5.cfg -c "transport select jtag; init; svf raw_serial.svf; exit"
Finally, we can open a terminal to read the serial output of the ECP5. Personally, I like to use minicom: sudo chmod 666 /dev/ttyUSB0 && minicom -D /dev/ttyUSB0.
One more problem with the raw_serial.v example was that it doesn't use a baudrate of 115200 as the readme suggests but 19200. The clock that is connected to the FTDI chip runs at 12 MHz. If you want a baudrate of 115200 you need to send a bit every 12,000,000 / 115,200 ~= 104 ticks. This means you need to change line 14 to if (counter == 104) begin.
See NFC reader "SELECT (by AID)" APDU is not routed to Android device on debugging and eventual results. TL;DR the reader might simply be defunct.
I have ACR122U nfc reader. I try to run this example http://www.nfc-tools.org/index.php?title=Libnfc:APDU_example#apdu_example.c on my Ubuntu machine.
This is the log output I get when I tap my Android device (should be in HCE mode) to the reader:
./apdu_example
debug libnfc.general log_level is set to 3
debug libnfc.general allow_autoscan is set to true
debug libnfc.general allow_intrusive_scan is set to false
debug libnfc.general 0 device(s) defined by user
./apdu_example uses libnfc libnfc-1.7.1
debug libnfc.driver.acr122_usb device found: Bus 001 Device 088 Name ACS ACR122
debug libnfc.general 1 device(s) found using acr122_usb driver
debug libnfc.driver.acr122_usb 3 element(s) have been decoded from "acr122_usb:001:088"
debug libnfc.driver.acr122_usb TX: 62 00 00 00 00 00 00 01 00 00
debug libnfc.driver.acr122_usb RX: 80 02 00 00 00 00 00 00 81 00 3b 00
debug libnfc.driver.acr122_usb ACR122 PICC Operating Parameters
debug libnfc.driver.acr122_usb TX: 6f 05 00 00 00 00 00 00 00 00 ff 00 51 00 00
debug libnfc.driver.acr122_usb RX: 80 01 00 00 00 00 00 02 fe 00 00
debug libnfc.chip.pn53x GetFirmwareVersion
debug libnfc.driver.acr122_usb TX: 6f 07 00 00 00 00 00 00 00 00 ff 00 00 00 02 d4 02
debug libnfc.driver.acr122_usb RX: 80 08 00 00 00 00 00 02 fe 00 d5 03 32 01 06 07 90 00
debug libnfc.chip.pn53x SetParameters
debug libnfc.driver.acr122_usb TX: 6f 08 00 00 00 00 00 00 00 00 ff 00 00 00 03 d4 12 14
debug libnfc.driver.acr122_usb RX: 80 04 00 00 00 00 00 02 fe 00 d5 13 90 00
debug libnfc.general "ACS / ACR122U PICC Interface" (acr122_usb:001:088) has been claimed.
debug libnfc.chip.pn53x ReadRegister
debug libnfc.driver.acr122_usb TX: 6f 11 00 00 00 00 00 00 00 00 ff 00 00 00 0c d4 06 63 02 63 03 63 0d 63 38 63 3d
debug libnfc.driver.acr122_usb RX: 80 09 00 00 00 00 00 02 fe 00 d5 07 00 00 00 00 00 90 00
debug libnfc.chip.pn53x PN53X_REG_CIU_TxMode (Defines the transmission data rate and framing during transmission)
debug libnfc.chip.pn53x PN53X_REG_CIU_RxMode (Defines the transmission data rate and framing during receiving)
debug libnfc.chip.pn53x WriteRegister
debug libnfc.driver.acr122_usb TX: 6f 0d 00 00 00 00 00 00 00 00 ff 00 00 00 08 d4 08 63 02 80 63 03 80
debug libnfc.driver.acr122_usb RX: 80 04 00 00 00 00 00 02 fe 00 d5 09 90 00
debug libnfc.chip.pn53x RFConfiguration
debug libnfc.driver.acr122_usb TX: 6f 09 00 00 00 00 00 00 00 00 ff 00 00 00 04 d4 32 01 00
debug libnfc.driver.acr122_usb RX: 80 04 00 00 00 00 00 02 fe 00 d5 33 90 00
debug libnfc.chip.pn53x RFConfiguration
debug libnfc.driver.acr122_usb TX: 6f 09 00 00 00 00 00 00 00 00 ff 00 00 00 04 d4 32 01 01
debug libnfc.driver.acr122_usb RX: 80 04 00 00 00 00 00 02 fe 00 d5 33 90 00
debug libnfc.chip.pn53x RFConfiguration
debug libnfc.driver.acr122_usb TX: 6f 0b 00 00 00 00 00 00 00 00 ff 00 00 00 06 d4 32 05 ff ff ff
debug libnfc.driver.acr122_usb RX: 80 04 00 00 00 00 00 02 fe 00 d5 33 90 00
NFC reader: ACS / ACR122U PICC Interface opened
Polling for target...
debug libnfc.chip.pn53x ReadRegister
debug libnfc.driver.acr122_usb TX: 6f 13 00 00 00 00 00 00 00 00 ff 00 00 00 0e d4 06 63 02 63 03 63 05 63 38 63 3c 63 3d
debug libnfc.driver.acr122_usb RX: 80 0a 00 00 00 00 00 02 fe 00 d5 07 80 80 43 00 10 00 90 00
debug libnfc.chip.pn53x InListPassiveTarget
debug libnfc.chip.pn53x No timeout
debug libnfc.driver.acr122_usb TX: 6f 09 00 00 00 00 00 00 00 00 ff 00 00 00 04 d4 4a 01 00
debug libnfc.driver.acr122_usb RX: 80 0e 00 00 00 00 00 02 fe 00 d5 4b 01 01 08 03 20 04 01 02 03 04 90 00
Target detected!
=> a4 04 00 07 f0 01 02 03 04 05 06 00
debug libnfc.chip.pn53x InDataExchange
debug libnfc.chip.pn53x Timeout value: 5000
debug libnfc.driver.acr122_usb TX: 6f 14 00 00 00 00 00 00 00 00 ff 00 00 00 0f d4 40 01 a4 04 00 07 f0 01 02 03 04 05 06 00
res from transceive: -6
debug libnfc.chip.pn53x InDataExchange
debug libnfc.chip.pn53x Timeout value: 5000
debug libnfc.driver.acr122_usb TX: 6f 14 00 00 00 00 00 00 00 00 ff 00 00 00 0f d4 40 01 a4 04 00 07 f0 01 02 03 04 05 06 00
Basically I can see that my Android device is seen by the reader as I can see the UID (01 02 03 04) (or another UID if I tap another device). After that transmitting select AID apdu just timeouts and I can see no relevant response in my Android logs.
On the Android device I have an application installed with the AID I am trying to select - f0 01 02 03 04 05 06.
Can this be a problem with this particular reader? There are other ADPUs which also seem to stop the reader from responding, e.g. FF 00 00 00 02 D4 04 just gives me no response. Can I diagnose the hardware somehow?
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.