Assembley language help needed

[MikeHunt79]

I was wondering if this is possible with a little code modification?

All I want to do is change the value of a single byte in memory when my computer boots up from 00 to FF.

Right now I'm doing it manually with a program called RW Everything, but I want it to be automatic. The value is in the 'embedded controller', FWIW.

I've been looking at modding the BIOS file, but the computer in question is a laptop which uses a compressed (Insyde) bios to flash, so modding it seems impossible.

I was wondering if it's possible to do this some other way? Or is BIOS modification the only option? How easy would it be to code a simple Windows prog which could be loaded on bootup?

 

[NickK]

Surely creating a c program where you write 0xff to the pointer location?

The main point is that the program would need to be run with the right permissions to update that area of the memory.

 

[tntcoder]

Surely creating a c program where you write 0xff to the pointer location?

The main point is that the program would need to be run with the right permissions to update that area of the memory.

Yer, im sure that's the most sensible approach.

Is the memory location static? Modern operating systems randomize memory locations every bootup, but I guess that might not be an issue if its in embedded memory.

Just whack the memory address in a pointer and modify accordingly

unsigned char *mem = (unsigned char*)0xAABBCCDD
*mem = 0xFF;

 

[Lightnix]

Could you modify a bootloader (like GRUB) to do it?

 

[matja]

Could you modify a bootloader (like GRUB) to do it?

This could be a good way, you'd have to modify grub or use a com32 module, but grub2 supports writing to arbitary values in memory before starting an os (write_byte <address> <value>), so you could have something like :

menuentry "Windows" {
set root=(hd0,1)
write_byte 0x12345678 0xff
chainloader +1
}

 

[MikeHunt79]

Surely creating a c program where you write 0xff to the pointer location?

The main point is that the program would need to be run with the right permissions to update that area of the memory.

Right now I've got a great little program called RW Everything which runs whenever I boot up. It runs a batch file which changed to mem location and works, but a little standalone program would be better.

I have no experience of C or C++ however, only java where you cannot directly address mem locations, I'll have a look at some example C code.

Yer, im sure that's the most sensible approach.

Is the memory location static? Modern operating systems randomize memory locations every bootup, but I guess that might not be an issue if its in embedded memory.

Just whack the memory address in a pointer and modify accordingly

unsigned char *mem = (unsigned char*)0xAABBCCDD
*mem = 0xFF;

Well, I've now figured out how to achieve something similar by writing some values to IO ports, in fact writing to the IO ports works better but I only found about it today after reading the release notes for my BIOS update.

I need to send 0x12 to IO port 0x6C and send 0x01 to IO port 0x68. This should work better than using mem locations, because as you mentioned, mem locations can vary while IO port do not.

Could you modify a bootloader (like GRUB) to do it?

This is my next step. My bootloader is open source, so I'm trying to add a few lines of ASM in.

After reading around, the IN and OUT commands are used to write to IO ports, instead of the normal MOV command.

in = read from IO port
out = write to IO port
Syntax = OUT <port> <data>

So, if I'm sending 0x12 to IO port 0x6C and sending 0x01 to IO port 0x68, then this is what I've added to the source code:

OUT 0x6C 0x12
OUT 0x68 0x01

That's as far as I've got so far, right now I'm wading thru the readme files of the bootloader trying to work out how to compile the source.

Does my 2 lines of code look like it will work? I'm no expert in ASM, and it was years since I last used it...

 

[NickK]

Sorry, I only did 6502, 68000 and ARM assembler..

 

[MikeHunt79]

Sorry, I only did 6502, 68000 and ARM assembler..

No problem, I think I'm going to have to do it in C anyway, as the source only has enough space for 2 more bytes of ASM, which is not enough for my additions.

Expect a "C help needed" thread at some point if I don't figure out how to do it on my own!

 

[RobH]

I probably can't help you out here but I'm curious at what you're actually doing, what does changing that memory address do and what is the aim of your project?

-Rob

 

[MikeHunt79]

I've eventually done it! Turns out I had to delve into a bit of C, but it works.

I found that C has an 'asm' command which allows assembler commands to be used within C code.

So, using this little subroutine:

static inline void outbbb(int port, u_int8_t data) {
	asm volatile("outb %0,%w1" :: "a" (data), "d" (port));
}

I was able to send hex values directly to the IO ports, and it all worked the first time I managed to compile with no errors (this is my first experience using C!).

I probably can't help you out here but I'm curious at what you're actually doing, what does changing that memory address do and what is the aim of your project?

-Rob

Nothing dodgy I can assure you!

It's kind of a long story, I have an Acer Aspire One netbook, and the old BIOS was buggy. So buggy in fact that it used to get corrupted randomly on reboot, and had to restore it using a USB stick pretty often.

So, I updated to the latest and greatest BIOS, and it fixed the self corruption issue. However, Acer also decided to remove the lower brightness settings on the later BIOS' because some of the screens used to flicker on lower brightness settings. This made my little netbook pretty painful on the eyes at night as well as killing the amount of time it can be used on battery power. Catch 22...

After a little experimenting with RW Everything I found that changing certain values in memory would re-enable the lower brightness settings, but it was a pain to run it everytime I booted up.

After (eventually) reading the release notes for the BIOS update, I found that I can also reenable the lower brightness settings by sending certain hex values to specific IO ports... which had lead me into adding to the source of the bootloader I'm using...

Anyway, my screen now has all it's brightness settings again, and I'm now no longer have a BIOS which corrupts itself, and I've learnt how to code C in the process so I'm happy.