Test assembly code on a mac - macos

A while back I was following some tutorials an assembly. I was running it all on a windows machine, compiling with NASM and then writing the compiled code to a floppy disk, then reboot and try the code. This process was long and time consuming and sadly was not on a mac. When I found out that Xcode for mac installed NASM I immediately tried to compile some code. The code compiled fine. The issue is testing it. On a mac I have no floppy (not like I want to use one) so Im not sure how to test this. I looked in to Q (kju) and found it would only emulate things on an ISO file. So I guess what Im asking is is it possible to install the compiled code on an ISO file for testing? (Note: the code when compiled forms a .bin file)
Thanks for any help

I don't know exactly what you are trying to test (a boot loader maybe?) but you don't need to reboot or boot from a disk just to run assembled code (unless it is a boot loader or something).
Either way, if you need to "reboot" to test, I suggest running an emulator. Sun VirtualBox is super easy to use and free and emulates a standard x86 architecture (including floppy drives)! So that may work for you in the short term. If you ever want to create an ISO image in the future, you can do that with the command line utility hdiutil. In a terminal window, type man hdiutil or visit the online man page for more information on using that to create all kinds of disk images.

Related

How can I remove the need of wpcap.dll in my go program?

I use gopacket in my program. on linux, it runs perfectly.
But on windows the whole program crashes if i did not install WinPcap before.
My plan was to check if WinPcap is installed, and if not to inform the user that he needs this to use 100% of all features.
But i dont come to this point. i cant use gopacket if WinPcap is not available. I mean... not a single line of code of it (=> crash)
Has anyone an idea how i can solve this? im do not need gopacket actually. My plan was, if it is installed, fine, super! If not, dont care... do other things.
But now i have 2 choices... remove gopacket totally or find a way to start my program without the need of wpcap.dll. at least to tell the user that he needs it.
Please help me :(
You're wrong in that you are «not [using] a single line of code of it»: it's not hard to see that
its Windows-specific code calls into winpcap.dll.
What is more fun, is that
its Unix-specific code calls into libpcap.so, and this means you have it working on your local system simply due to the fact you have libpcap package installed (or whatever it's named in your code).
All this means that currently your program is not really portable
anyway (I mean, in the sense you supposedly think it is portable).
You can run something like
$ ldd ./yourbinary
and see it printing a reference to libpcap.so of some version.
There are several ways to solve this.
The easiest is to just try shipping winpcap.dll with your binary. Windows by default looks for DLLs in the current directory of the application trying to load them. Since gopacket uses cgo, it means the winpcap.dll is attempted to be linked it at the application startup, so the application has no chance of changing its working directory before that library is attempted to be found and linked in.
A more complicated approach is to make (or obtain) a static version of the winpcap library (remember that DLL is a library, just a special form of it) and then jump around building gopacket so that it picks that static library.
Install Npcap in "Wpcap API compatibility mode".

Trying to use Mac dll (bundle) on Wine

I'm currently trying to achieve (for my internship) to use Mac OS dll which are named Bundle (everthing is named bundle on mac ...) because the string comparison fonction from Wine is not working properly (gérard = gerard for example). It causes problems on databases because of the duplications.
Using a DLL to use the native comparison fonction of the OS would settle this problem. But unfortunately, there aren't a lot of documentations to implement properly a working Bundle DLL.
Until now (with my tutor), we succeeded to create a ".bundle" (which works perfectly fine) and then a ".so" but when using it under Wine, we got this error "Bad EXE Format for %1" which tell us that our dll is not in the right format because Wine need a spec file to use native DLL.
We found documentations to make a spec file on WineHQ website but we can't overcome this phase by just following the instructions here(click sur "next" to have the following steps in the bottom right corner ...).
Has anyone ever succeeded (the only one person I saw do it, did it in 2005 ...) to use mac OS DLL on wine and could help us ?
Any help most appreciated.

As far as I know, you can't compile Swift on Windows, so how does SwiftStub compile code on Windows?

I initially thought that there was some way to be able to run Swift on Windows using emulators, or some other program that allowed Windows to compile and run Swift, but after browsing here a few times I learned that there is no(legal) way to do it. So how is it possible that you can do this at SwiftStub thru your internet browser?
You can check it out here:http://swiftstub.com/
Easily! They compile and run code on a Macintosh Server on their end, and just feed you the result in a web-based app. You're not running the code, they are. You just get to see the end result.

"Hacking: The Art of Exploitation" - Assembly Inconsistencies in book examples vs. my system's gcc

I am studying "Hacking: The Art of Exploitation". I am trying to follow the code examples, but for some reason the assembly codes simply does not match the one on my actual Linux (running on Virtual Box as Guest). I have made sure that I have installed 32 bit Linux OS. Is there any args that I can pass to gcc that lets me compile the code into an assembly that matches closely with the ones given in the book?
I would be fine reconciling the code differences between the book & what I see if they were minor, but the difference I see is stark. I somehow don't like to run the code from the "Preconfigured incubator environment" as this inhibits my skill development.
I've actually been in the same boat--for the last week or two I've tried a ton of ways to produce comparable assembly code in my normal development environment (LMDE), including chroot, compiling with the -m32 flag, installing an x86 ubuntu, etc, and nothing really worked. Today I found http://www.nostarch.com/hackingCD.htm and I followed the instructions and was able to get the livecd to boot in vmware workstation 10. Here's what I did:
Download the iso from the link above (though it should work with the
livecd as well)
Create a .vmx file and copy and paste the config from the link
I took out the section defining the cdrom device, since I was using an iso
Open the file with VmWare Workstation--if you are using the iso, go to "Edit VM Settings" and set up a cdrom device and point it to the iso
VM booted without any issues
I know this isn't as convenient as going through the examples in your main OS/system, and that you were trying to avoid using the LiveCD, but after doing a lot of research I've discovered that this is an extremely common issue and hopefully this answer helps someone. Using the LiveCD might not be ideal but it is still a heck of a lot better than dual booting.
for some reason the assembly codes simply does not match the one on my actual linux
The most likely reason is that the book was published in 2008, and used then-stable GCC (you can see GCC release history here).
GCC that you are using now is likely much newer, and so generates significantly different (and one hopes better) code.
Is there any args that I can pass to gcc that lets me compile the code into an assembly that matches closely with the ones given in the book?
No. You can try to compile and install a version from 2008, perhaps 4.2.3 or 4.3.0, and check whether that gives you closer output.
P.S. It looks like the first revision of the book is from 2003, and it's unlikely that the authors rebuilt all of their examples for the second edition in 2008, so perhaps try GCC 3.3 instead?
This is why the book comes with a LiveCD with a linux distro and all of the example source code from the book on there. All of the examples in the book match exactly with what will happen in the LiveCD.
Just run the included LiveCD using VirtualBox or VMware and follow along with the book using that. If you don't have the CD, it can be downloaded from a torrent provided by No Starch (linked from their website)
it doesn´t matter whether the output of gcc is different, the only thing it changes is the memory addresses; plus, you said u r using a VM to run it, meaning that the memory u will get is dummy memory, try booting the iso and run it directly, it will almost the same.
https://www.youtube.com/watch?v=pIN7oFkz5rM

.ASM file debugging tool

I am wondering which debugging tool I can use for an assembly program and how to use it.
I have written a simple bootloader in assembly. However, it is not quite working properly as I wished, even though I think the logic is correct. So, I am trying to use a debugger so that I can step through the bootloader, checking the register status and etc.
I tried GDB on Ubuntu, compiling my .asm to .elf and .o (Do I need to do it? If yes, what is the next step?) Also, I read that there is an internal debugger in Bochs simulator, but I can't quite find any document how to use it. I also have Visual Studio 2010, windbg, but I don't know how to use it for .asm file debugging.
If you have done this before, it would be an easy answer. Any help would be really appreciated.
Sincerely
If you want to debug bootloader code, you obviously need to run it in the same environment that the code itself is going to run in. As I'm sure you already know, bootloader code is executed in real mode once the BIOS finishes doing the POST. The bootloader is then loaded into memory at 7c00h and a jump to that address is executed.
Obviously, this kind of environment cannot be reliably emulated once you've got your computer running and a "real" operating system already loaded, since by that time your CPU is in protected mode (or long mode, if it's AMD64). Your only option at this point is to use QEMU or Bochs in order to emulate a real PC inside your operating system. I've used Bochs to debug some bootloader code I've written in the past and it worked quite well. Check the manual pages for more detailed instructions.

Resources