How to load a bmp file in visual studio 2010 - visual-studio-2010

I am pretty new to Visual Studio C++. I am trying to load a bmp file from my system with specific path and show it on picture control in mfc, but m unable to do so. Can any one guide me here. I tried the following but i am getting an error..
Code:
filePath = "images/0000.4d.bmp";
ASSERT(filePath);
HBITMAP hBitmap= NULL;
hBitmap = (HBITMAP) LoadImage (
0,
filePath,
IMAGE_BITMAP,
0, 0,
LR_LOADFROMFILE | LR_CREATEDIBSECTION | LR_DEFAULTSIZE);
IDB_PICTURE2.LoadBitmapW(MAKEINTRESOURCE(hBitmap));
m_picture.SetBitmap(IDB_PICTURE2);
The error occurs when I am trying to load the bmp file. Thank you.
Error:
Detected memory leaks!
Dumping objects ->
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {525} normal block at 0x0034B848, 54 bytes long.
Data: < x > 84 CF B1 78 12 00 00 00 12 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp(4500) : {518} client block at 0x0034B708, subtype c0, 56 bytes long.
a CObject object at $0034B708, 56 bytes long
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {511} normal block at 0x0034B1C8, 42 bytes long.
Data: < x > 84 CF B1 78 0C 00 00 00 0C 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\occmgr.cpp(195) : {510} normal block at 0x0034B170, 24 bytes long.
Data: < > E8 03 00 00 00 00 00 00 E9 03 00 00 00 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\occmgr.cpp(181) : {509} normal block at 0x0034B120, 16 bytes long.
Data: < > FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00
c:\documents and settings\raja hadi ashraf\my documents\visual studio 2010\projects\mirrorimage\mirrorimage\mirrorimage.cpp(59) : {505} client block at 0x0034AFB0, subtype c0, 12 bytes long.
a CObject object at $0034AFB0, 12 bytes long
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {494} normal block at 0x0034CDF8, 22 bytes long.
Data: < x > 84 CF B1 78 02 00 00 00 02 00 00 00 01 00 00 00
Object dump complete.
The program '[0x62C] mirrorImage.exe: Native' has exited with code 3 (0x3).

First test that your hBitmap that it's not NULL then just call:
m_picture.SetBitmap( hBitmap );
Other:
IDB_PICTURE2 is just a #define in your resource.h file. At compile time it'll just be replaced with a number, ie it's not a class you can call methods on.
MAKEINTRESOURCE is for converting a resource id into a LPCTSTR for use with methods. It does not turn a hBitmap into a resource.
The 'error' you list is just some debug information. It's not the actual error. If LoadBitmap returns NULL call GetLastError for extra information.

Related

fail to open device with multiple interface usb device on windows

I am trying to use the webusb api to connect my USB device which basically is a digitizer. the usb version is 2.0.
I have successed to request the device in chrome but failed to open the device with the error Access Deny.
request device
the usb device has 3 interface: 2 HID and 1 USB (winusb loaded). here is the information shown in xusb:
Using libusb v1.0.23.11397
Opening device 2D80:1010...
libusb: warning [hid_open] could not open HID device in R/W mode (keyboard or mouse?) - trying without
Device properties:
bus number: 1
port path: 14 (from root hub)
speed: 12 Mbit/s (USB FullSpeed)
Reading device descriptor:
length: 18
device class: 0
S/N: 3
VID:PID: 2D80:1010
bcdDevice: 0100
iMan:iProd:iSer: 1:2:3
nb confs: 1
Reading BOS descriptor: 1 caps
Unknown BOS device capability 05:
Reading first configuration descriptor:
nb interfaces: 3
interface[0]: id = 0
interface[0].altsetting[0]: num endpoints = 1
Class.SubClass.Protocol: 03.01.01
endpoint[0].address: 81
max packet size: 0040
polling interval: 01
interface[1]: id = 1
interface[1].altsetting[0]: num endpoints = 1
Class.SubClass.Protocol: 03.01.01
endpoint[0].address: 82
max packet size: 0040
polling interval: 01
interface[2]: id = 2
interface[2].altsetting[0]: num endpoints = 1
Class.SubClass.Protocol: FF.00.00
endpoint[0].address: 83
max packet size: 0040
polling interval: 00
Claiming interface 0...
Claiming interface 1...
Claiming interface 2...
Reading string descriptors:
String (0x01): ""
String (0x02): ""
String (0x03): "******"
Reading Extended Compat ID OS Feature Descriptor (wIndex = 0x0004):
libusb: warning [hid_submit_control_transfer] unsupported HID control request
libusb: warning [hid_submit_control_transfer] unsupported HID control request
00000000 28 00 00 00 00 01 04 00 01 00 00 00 00 00 00 00 (...............
00000010 02 01 57 49 4e 55 53 42 00 00 00 00 00 00 00 00 ..WINUSB........
00000020 00 00 00 00 00 00 00 00 ........
Reading Extended Properties OS Feature Descriptor (wIndex = 0x0005):
libusb: warning [hid_submit_control_transfer] unsupported HID control request
libusb: warning [hid_submit_control_transfer] unsupported HID control request
00000000 8e 00 00 00 00 01 05 00 01 00 84 00 00 00 01 00 ................
00000010 00 00 28 00 44 00 65 00 76 00 69 00 63 00 65 00 ..(.D.e.v.i.c.e.
00000020 49 00 6e 00 74 00 65 00 72 00 66 00 61 00 63 00 I.n.t.e.r.f.a.c.
00000030 65 00 47 00 55 00 49 00 44 00 00 00 4e 00 00 00 e.G.U.I.D...N...
00000040 7b 00 31 00 44 00 34 00 42 00 32 00 33 00 36 00 {.1.D.4.B.2.3.6.
00000050 35 00 2d 00 34 00 37 00 34 00 39 00 2d 00 34 00 5.-.4.7.4.9.-.4.
00000060 38 00 45 00 41 00 2d 00 42 00 33 00 38 00 41 00 8.E.A.-.B.3.8.A.
00000070 2d 00 37 00 43 00 36 00 46 00 44 00 44 00 44 00 -.7.C.6.F.D.D.D.
00000080 44 00 37 00 45 00 32 00 36 00 7d 00 00 00 D.7.E.2.6.}...
Releasing interface 0...
Releasing interface 1...
Releasing interface 2...
Closing device...
the first hid interface is used to report digitizer which i think it is already claimed by the system. I guess that is the issue because I have tried to remove the two hid interface and repeat the process. this time the device was opened successfully.
however the same issue is not presented on Mac OS.
so i am wonder if anyone has any suggestion to solve the issue on windows?
It is possible that this is a Chrome issue. I have been working on a new backend for connecting to USB devices on Windows that should be more reliable, especially for complex composite devices.
Please install Chrome canary-channel (at least version 84.0.4110.2) from https://www.google.com/chrome/canary/ and try turning on the “Enable new USB backend” in flag in chrome://flags.
Let me know if this resolves the issue.

RFID MIFARE 1K memory contents

Below is a dump from the sample card that came with the RC522, I have omitted the repeating parts.
What exactly is the data stored at the first block of every sector? In this case FF 07 80 69 FF FF FF FF FF FF.
Also what are those bytes after the ATQA bytes, that simply count from 62 to 69?
(fyi this card is in its factory state; it has not been written to by any system- however other new cards from other sources have the same bytes written)
And what exactly is the memory of a Mifare card used for in the usual application? (I have read that most access control systems only read the UID.)
mfrc522.PICC_DumpToSerial
Card UID: C1 44 53 63
Card SAK: 08
PICC type: MIFARE 1KB
Sector Block 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 AccessBits
15 63 00 00 00 00 00 00 FF 07 80 69 FF FF FF FF FF FF [ 0 0 1 ]
62 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 0 0 0 ]
61 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 0 0 0 ]
60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 0 0 0 ]
...
0 3 00 00 00 00 00 00 FF 07 80 69 FF FF FF FF FF FF [ 0 0 1 ]
2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 0 0 0 ]
1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 0 0 0 ]
0 C1 44 53 63 B5 08 04 00 62 63 64 65 66 67 68 69 [ 0 0 0 ]
The last block of each sector (i.e. block 3, block 7, ... block 63) is the sector trailer. It contains the access keys and the access conditions for the sector. See Mifare 1K authentication keys for the exact format and Locking mechanism of Mifare Classic 1K / Mifare Access condition calculation on how the access bits are calculated.
The first block of the first sector (block 0) is the manufacturer block. It usually contains anti-collision parameters and some manufacturer specific data. I don't think that NXP ever published any information about the exact format of that data. I'm a bit surprised that your card contains the sequence 62 63 64 65 66 67 68 69 there, since usually there was some information about IC production there (batch number, production data, etc.)

Generate a Bookmark file from a classic Mac Alias record

For an app that has been around for many years, and which has stored the classic Alias records in files, I like to recreate Alias files pointing to the same file now, without having to resolve the Alias first (because the destination may be unavailable at that moment).
Supposedly this should accomplish this:
CFDataRef aliasRecord = ... ; // contains the Alias Record data, see below for an example
CFURLRef url = ... ; // initialized with a file URL
CFDataRef bmData = CFURLCreateBookmarkDataFromAliasRecord (NULL, aliasRecord);
CFError error;
bool ok = CFURLWriteBookmarkDataToFile (bmData, url, 0, &error);
However, the write function fails, and the error says "The file couldn’t be saved."
If I instead create bookmark data using CreateBookmarkData, the write succeeds.
How do I make this work? I'd try writing an old style Alias file with the data in the resource fork if that wasn't so utterly deprecated.
Here's an example alias record I'd have in the aliasRecord object - I can resolve this using the classic Alias Manager FSResolveAlias function, so I know that it is indeed valid.
00 00 00 00 01 12 00 02 00 01 06 54 54 73 4D 42
50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 CC 31 2F 12 48 2B 00 00 01 A5
F3 9B 03 74 6D 70 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 01 AC 1C 67 D1 FE B7 D0 00 00 00 00 00 00
00 00 FF FF FF FF 00 00 09 20 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 07 70 72 69 76 61 74
65 00 00 10 00 08 00 00 CC 31 12 F2 00 00 00 11
00 08 00 00 D1 FE 9B B0 00 00 00 01 00 04 01 A5
F3 9B 00 02 00 13 54 54 73 4D 42 50 3A 70 72 69
76 61 74 65 3A 00 74 6D 70 00 00 0E 00 08 00 03
00 74 00 6D 00 70 00 0F 00 0E 00 06 00 54 00 54
00 73 00 4D 00 42 00 50 00 12 00 0B 70 72 69 76
61 74 65 2F 74 6D 70 00 00 13 00 01 2F 00 FF FF
00 00
CFURLCreateBookmarkDataFromAliasRecord() doesn't create the bookmark data with the kCFURLBookmarkCreationSuitableForBookmarkFile option required by CFURLWriteBookmarkDataToFile().
CFURLCreateBookmarkDataFromAliasRecord() was intended as a way to convert alias records stored a program's own data files to bookmarks with no I/O.
Before CFURLWriteBookmarkDataToFile(), Finder Alias files (bookmark files) were created by the Finder. Those files contained an Alias resource (containing known properties that could be obtained from the Alias resource with FSCopyAliasInfo()) and icon resources. Apple needed the bookmark data in the files written by CFURLWriteBookmarkDataToFile() to provide the same properties. The kCFURLBookmarkCreationSuitableForBookmarkFile option enforces that requirement.
If you have an AliasHandle and want to create a new-style Alias file with bookmark data, you'll need to:
(1) resolve the AliasHandle to an FSRef, create a CFURLRef from the FSRef, and then create the bookmark data using the kCFURLBookmarkCreationSuitableForBookmarkFile option,
or
(2) you'll need to resolve the bookmark data created with CFURLCreateBookmarkDataFromAliasRecord(), and then create a new bookmark data using the kCFURLBookmarkCreationSuitableForBookmarkFile option.
However, you've indicated you'd like to handle this without resolving the AliasHandle, so the only solution is to create an old-style Finder Alias file. Although I know you already know how to accomplish that, it's described at How do I create a Finder alias within an application?.
The first time a user resolves/opens that old-style Alias file with the Finder, the Finder will detect the Alias file needs to be updated (i.e., CFURLCreateByResolvingBookmarkData() will return with isStale == true) and the Finder will create a new bookmark to the Alias file's target and re-write the Alias file. CFURLCreateBookmarkDataFromFile() will continue to support old-style Alias files as long as possible for backwards compatibility.

Issues with bootloader

I am in the process of learning Assembly, and I tried writing my own bootloader. It works fine on VirtualBox , but it doesn't work on a actual PC.
On pc 'Hello World!' doesn't get printed.
This is the code is use:
BITS 16
ORG 0x7C00
jmp boot_sector
;------------------------------
OEMLabel db "FLOPPYDR"
BytesPerSector dw 512
SectorsPerCluster db 1
ReservedForBoot dw 1
NumberOfFats db 2
RootDirEntries dw 224
LogicalSectors dw 2880
MediumByte db 0xF0
SectorsPerFat dw 9
SectorsPerTrack dw 18
Sides dw 2
HiddenSectors dd 0
LargeSectors dd 0
DriveNo dw 0
Signature db 41
VolumeID dd 0x00
VolumeLabel db "FLOPPYDRIVE"
FileSystem db "FAT12"
;##############################
boot_sector:
;##############################
mov ax, 0x0000 ; Set up the stack
mov ss, ax ; Is this done correctly?
mov sp, 0x7C00 ; (I dont quite understand)
int 0x10 ; Set video mode
int 0x13 ; Reset the drive
mov ah, 0x02 ; Read more sectors
mov al, 2 ; Read two extra sectors,
mov bx, main_sector ; starting from the second.
mov ch, 0 ;
mov cl, 2 ; dl has been set already (?)
mov dh, 0 ;
int 0x13 ;
mov [bootdev], dl ; Store original dl in bootdev
jmp main_sector ; Go to the main sector (0x200 I think)
times 510 - ($ - $$) db 0 ; Fill in the rest of the sector with 0s
dw 0xAA55 ; and 0xAA55 at the end for signature
;##############################
main_sector:
;##############################
jmp Start
;------------------------------
bootdev db 0
msg db 'Hello World!', 10, 13, 0
;------------------------------
print_string:
mov ah, 0x0E
mov bh, 0
cmp al, 0
jne .loop
mov bl, 0x0F
.loop:
lodsb
cmp al, 0
je .end
int 0x10
jmp .loop
.end:
ret
;------------------------------
Start:
mov si, msg
call print_string
hlt
times 512 - ($ - main_sector) db 0
I've also commented in some questions, but these are not my main question (well, maybe me not knowing the answer causes the problem). Why doesn't this work on a real PC?
To compile I use nasm -f bin boot.asm -o boot.bin and to create a virtual floppydisk file I use mkfile 1474560 floppy.flp
Then I open up floppy.flp using HexEdit and replace the first 64 lines (0x00 - 0x3F) with the content of the boot.bin file (opened using HexEdit).
E9 38 00 46 4C 4F 50 50 59 44 52 00 02 01 01 00
02 E0 00 40 0B F0 09 00 12 00 02 00 00 00 00 00
00 00 00 00 00 00 29 00 00 00 00 46 4C 4F 50 50
59 44 52 49 56 45 46 41 54 31 32 B8 00 00 8E D0
BC 00 7C CD 10 CD 13 B4 02 B0 02 BB 00 7E B5 00
B1 02 B6 00 CD 13 88 16 03 7E E9 A3 01 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA <-- End of first sector
E9 24 00 00 48 65 6C 6C 6F 20 57 6F 72 6C 64 21
0A 0D 00 B4 0E B7 00 3C 00 75 02 B3 0F AC 3C 00
74 04 CD 10 EB F7 C3 BE 04 7E E8 E6 FF F4 00 00 (The rest is just 0's).
This is the Terminal when I burn floppy.flp to the USB drive:
Last login: Wed Sep 23 12:10:48 on ttys000
MacBook-Air:~ sasha$ cd ~/Desktop
MacBook-Air:Desktop sasha$ diskutil list
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *121.3 GB disk0
1: Apple_HFS 209.7 MB disk0s1
2: Apple_CoreStorage 120.5 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3
/dev/disk1
#: TYPE NAME SIZE IDENTIFIER
0: Apple_HFS Macintosh HD *120.1 GB disk1
Logical Volume on disk0s2
8CD6A846-395D-4C97-A5DE-0A7ABA9F1C99
Unencrypted
/dev/disk2
#: TYPE NAME SIZE IDENTIFIER
0: Apple_partition_scheme *17.1 MB disk2
1: Apple_partition_map 32.3 KB disk2s1
2: Apple_HFS Flash Player 17.1 MB disk2s2
/dev/disk3
#: TYPE NAME SIZE IDENTIFIER
0: FLOPPYDRIVE *1.0 GB disk3
MacBook-Air:Desktop sasha$ diskutil unmountdisk /dev/disk3
Unmount of all volumes on disk3 was successful
MacBook-Air:Desktop sasha$ sudo dd bs=512 if=floppy.flp of=/dev/disk3
Password:
2880+0 records in
2880+0 records out
1474560 bytes transferred in 0.843982 secs (1747146 bytes/sec)
MacBook-Air:Desktop sasha$
I've written about bootloaders at some length recently on Stackoverflow. Most issues that involve the situation where it works on one emulator or VM but not on another (or physical hardware) usually come down to making false assumptions about the state of the segment registers when the BIOS jumps to your code. Under some emulators the segment registers may have more sane values in them, but that usually isn't the case. From my previous answer I had these two tips that seem to apply here:
When the BIOS jumps to your code you can't rely on DS,ES,SS,SP registers having valid or expected values. They should be set up appropriately when your bootloader starts.
The direction flag used by lodsb, movsb etc could be either set or cleared. If the direction flag is set improperly SI/DI registers may be adjusted in the wrong direction. Use STD/CLD to set it to the direction you wish (CLD=forward/STD=backwards). In this case the code assumes forward movement so one should use CLD. More on this can be found in an instruction set reference
Your assembly code is set to compile and link assuming an origin point of 0x7C00 (via ORG 0x7C00). Your code that accesses variables like msg and bootdev will be made with the assumption that their memory address will be absolute within the segment (DS). This means that if you have an invalid DS segment then you could be addressing variables, data, and labels at the wrong locations. As an example:
mov [bootdev], dl
has an implicit reference to DS and is equivalent to addressing it with an explicit DS segment:
mov [ds:bootdev], dl
If DS has some random value in it then you'll likely be accessing memory in places you don't expect. For some environments DS might just be zero so your code will work.
How do you know which segment to use? The bootloader is loaded by the BIOS at physical memory 0x0000:0x7C00(segment:offset) . Your origin point (Set with ORG directive) matches the offset so that means in your case DS should be set to zero.
In your code ES should also be set to zero. The reason is that INT 0x13 AH=0x02 (disk read) says:
ES:BX Buffer Address Pointer
Imagine if ES is set to random garbage, the disk read will likely read into memory you didn't intend. So just like DS, ES must also be set. You've written your bootloader and kernel in the same file with the origin point of 0x7C00 so again you just need to use an ES segment set to zero.
When setting up your stack you can set ES and DS appropriately.
mov ax, 0x0000 ; Set up the stack
mov ss, ax ; Is this done correctly?
mov sp, 0x7C00 ; (I dont quite understand)
mov ds, ax ; Set DS to 0 because that is what your code needs
mov es, ax ; ES the same as DS.
cld ; Read my tip #2
You did ask if you set your stack properly. There is nothing wrong with it. Your instructions effectively set up a a stack that grows downward from 0x0000:0x7C00 just below the area occupied by your bootloader. That leaves about 27kb (0x7C00-0x1000) of stack space. 4k is plenty for BIOS calls and your current code. The first 0x1000 of memory are generally for interrupt table/BIOS data area etc.
One other bug I noticed in your code was when you try to reset the disk drive:
int 0x10 ; Set video mode
int 0x13 ; Reset the drive
You set AX to zero above these 2 lines. INT 0x10 AH=0x00 (set video mode) has the side effect of returning information in AX. Since AX can be clobbered your call to INT 0x13 AH=0x00 will likely be wrong. You need to clear AH (or all of AX) prior to calling int 0x13 to reset the drive. The code should look like:
int 0x10 ; Set video mode
xor ax,ax ; clear AX (AH=0)
int 0x13 ; Reset the drive
There is a minor issue at the top of your program and would likely only be a problem if you put this bootloader on a properly formatted FAT12 disk image and tried to mount it in your OS. You have:
jmp boot_sector
;------------------------------
OEMLabel db "FLOPPYDR"
The disk structure you have within your bootloader should have OEMLabel starting from the 4th byte. jmp boot_sector could be encoded as a 2 or 3 byte instruction by NASM. Use short to force a 2 byte encoding followed by a NOP (1 byte instruction). This will place OEMLabel at the 4th byte in the file. It could look like this:
jmp short boot_sector
nop
;------------------------------
OEMLabel db "FLOPPYDR"
Alternatively you can encode a JMP that may be 2 or 3 bytes when encoded and pad it with NOP if necessary using NASM's TIMES directive so that OEMLabel always starts at the 4th byte:
jmp boot_sector
times 3-($-$$) nop
;------------------------------
OEMLabel db "FLOPPYDR"
A trick to avoid using hexedit to manually insert the bootloader code at the beginning of a disk image is to use dd. You can use dd to overwrite the first 1024 bytes and keep the rest intact. Try dd if=boot.bin of=floppy.flp bs=512 count=2 conv=notrunc . This should open up floppy.flp write 2 512 byte sectors containing the 1024 bytes from boot.bin without truncating the file (conv=notrunc)
When a bootloader is started the contents of almost all registers (including segment registers) is "undefined". The only register that actually does have a known value is DL (which contains the BIOS' drive number for the disk).
All instructions that refer to memory use an implied or explicit segment register. For example, both mov [bootdev], dl and lodsb rely on the (implied) DS segment register, which is never set and is still undefined.
Like all undefined values, it's possible (due to pure luck) for them to be a value that makes things work by accident. Your code would work if the BIOS happened to leave the value 0x0000 in DS.

SSH: Understanding Algorithm Negotiation

I'm currently writing an ssh honeypot in Java as a personal project. I'm having trouble understanding the algorithm negotiation. To be precise, the structure of the received data from the client. Here is what I receive, with my personal annotations:
00 00 07 AC == packet length
08 == padding length
14 == SSH_MSG_KEXINIT
6C 31 89 77 EB 54 E1 8B D4 B1 35 08 FD 52 65 6E == cookie
00 00 00 D4 == string length
kex algorithms in byte form
00 00 01 67 == string length
server host key algorithms in byte form
00 00 00 E9 == string length
encryption_algorithms_client_to_server in byte form
00 00 00 E9 == string length
encryption_algorithms_server_to_client in byte form
00 00 01 92 == string length
mac_algorithms_client_to_server in byte form
00 00 01 92 == string length
mac_algorithms_server_to_client in byte form
00 00 00 1A == string length
compression_algorithms_client_to_server in byte form
00 00 00 1A == string length
compression_algorithms_server_to_client in byte form
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Information about the negotiation can be found here:
rfc4253
There are two things I don't fully understand:
The padding: How is it calculated? According to rfc4253, there should be a random padding (8 bytes in this case). I don't see it anywhere. Moreover, the size of the packet length + padding length + payload + padding should be a multiple of 8, which isn't the case here. (?)
The packet length: If I just sum up everything after the packet length, I get 0x797. Adding the 8 byte padding (wherever it is), I get 0x79F. Am I correct in thinking that the languages for client->server and server->client, although not defined, still take 4 byte each? That gets me to 0x7A7. If I now add the boolean and the reserved 4 bytes (see packet structure), I finally get 0x7AC. Is that correct? That would mean the trailing zeros have the following structure:
00 00 00 00 == length of string for language_client_to_server
00 00 00 00 == length of string for language_server_to_client
00 == boolean first_kex_packet_follows
00 00 00 00 == reserved
rest: garbage?

Resources