Meet “badBIOS,” the mysterious Mac and PC malware that jumps airgaps

phantom150
I'll put my 2 cents in as a computer and security consultant.

Points I took out.
-The person allegedly infected is a "security consultant", this would dramaticly increase the likely-hood of him becoming coming into contact with the virus. Possibly from a high-profile client? This could be a result of poor quarantine standards, ie using the USB keys between jobs.

-The 'virus' is able to infect different vendors of BIOS, hardware and operating system. If the virus was able to flash itself onto specific hardware it would unlikely to work across an apple mac to a windows desktop due to major differences in hardware and software design. For example the attacks against Irans Nuclear plants which were designed to infect the simens SCADA control box, as opposed to a stray I-phone.

-BIOS are often limited in space as it is, when they boot they run a checksum to verify the are not corrupt. If they are they often boot off a secondary physical ROM(impossible to change) and load a safe BIOS then reflash the primary. For example modern Gigabyte motherboards.

-The complexity of the said program would have to be quite large, this would be impractical to be sent across audio waves however still possible due to the very slow bitrate. One would assume a new transmission standard would need to be created as TCP/IP is not designed for this. It still is possible however, I have seen people download firmware off devices such as cameras by cycling a flashing LED over the course of days. This certainly was not packet transfer though.

-Infecting BSD/Windows/Mac/Linux all in one virus, its hard to beleive this. This would be a huge and very powerful virus and be using many unreported vulnerabilities. Worth noting that many secure systems such as aircrafts operate on systems similar to BSD.

-Ipv6? Sounds like the author is using buzzwords. Any data transferred over the network could be analysed with a packet sniffer such as "Wireshark" non of the less. It appears the author does use a similar tool but does not mention the network interface he was capturing off (lan/wlan): Big clue of something sinister been hidden from us.

-As a security consultant, the last thing he would want to do is have a uncontained worm infecting every device in is lab for weeks on end! Nor would he sit on such virus's, he has financial incentives to report zero day attacks to anti-virus software firms for big rewards


In my experience
-Bios virus's do exist, however are very rare and only really seen pre 2000 on very specific hardware. This lead to hardware switches been installed on motherboards to prevent unauthorised changes. Countermeasures against BIOS virus's were very primitive against the complex safeguards today.

-Complex worms on UNIX systems do exist, for example in large university environments where appearingly random files are generated and cannot be traced to any specific process. Most of which the administrators have ignored and have been in operation for decades.

My view is that we are getting played. It sounds like an attempt to get self promotion of the company due to the large amount of buzz words and zero evidence. I would like to be proved wrong though.
Possibly the author just has a faulty hard disk or SSD, this would explain the cross platform corruption.

----

Barring the fact that the LIKELY CAUSE if the OP's misfortunes has more likely
to do with basic hardware failures than any virus, it is STILL POSSIBLE to create
a JIT (Just In Time) cross-compiler that can output the instruction sets of
MANY embedded controllers, DSP's, GPU's, or general CPU's.

You write malicious c-Code script that does it's nasty work, which then gets cross-compiled
via a BIOS virus to a hidden flash drive partition for each targeted platform (i.e. MAC, LINUX, WIN-OS)
and voila a poly-platform virus which can ITSELF contain another mini-cross compiler (less than 64 kilobytes
which is NOTHNG these days!) which then cross compiles to ANY OTHER targeted platforms.

It's all about TOP-TIER code writing skills...which SOME (very few!) do have!!!!!

reply to post by StargateSG7


a lots of 'blah blah', but you seem to skip few important details.

EVEN IF firmware embedded inside a chip (or loaded at runtime) has been compromised, the fact that the driver runs as a privileged code inside OS kernel (which isn't always the case) isn't everything - in case of many drivers (linux, *bsd) the driver's code is opensourced - and whatever the hardware chip - ANY of them, be it a soundcard, video card, or anything else - tries to do, the results are treated as data by the OS - because that's what they are. to run them as code on the CPU, the driver itself would have to be compromised - backdooring the hardware only isn't possible, unless it contains some code that gets executed directly on the CPU (and that's the case with BIOS/UEFI only), or it's the CPU itself. since the BIOS/UEFI code isn't big, it can be disassembled easily and checked for backdoors - so that rules those out. hardware chips containing backdoors are rather out of the question as well, because those would require backdoored drivers - and if you'll put a backdoor inside closed-source driver, there's no need to backdoor the hardware. backdoored drivers are out of the question as well though, because many OSes other than windows have their drivers opensourced, and even in case of windows the drivers should go through the certification process, so i guess they're checked for any malicious behaviour (and the fact that they're closed source, doesn't mean that they cannot be disassembled - they often are, so any backdoors would be discovered sooner or later anyway). the only possibility is the CPU - but the trouble i see with that is the fact that there's a not so small group of programmers tracking every change in current intel/amd architecture, down to the timings of every single opcode (for the purpose of writing faster code, doing benchmarks, optimizing compilers and so on), so unless there would be a separate specialized core, running in parallel, it would be detected - and even separate core would have some influence on memory access timings for example.

the rest of your claims are complete nonsense, trying to look technical while in reality being a mumbo-jumbo. you cannot get as high framerates as you claim from a webcam - as a matter of fact, those framerates go downhill when the lightning is insufficient, so often you cannot even get 30fps. in case of sound, mics built into laptops won't catch inaudible frequencies - those can barely catch full range of human voice. speakers? same thing - those have their frequency response cut off well below 20khz, those fancy 96khz/192khz sampling rates are possible on the line out, assuming you have a proper audio hardware connected.

i've been dealing with assembler programming at hardware level since over 20 years, including direct programming of hardware chips to maximize the software's potential, so i guess i know what i'm talking about. seriously, stop the FUD.

and when you're at it, minimize the amount of caps and exclamation points - it doesn't help you to gain credibility and makes you look like some kid that got all excited by some hacking articles and decided to spread his theories of doom without any facts to back them whatsoever.

Think this could be connected to this topic.

cryptome.org...

reply to post by JBA2848


probably a hoax, or a hearsay without any facts to back it up at best. there are features like ECC in case of DRAM, there is RAIM for servers - and while this one sounds a little bit like the stuff from that article, it was introduced in 2010 by IBM.

using some 'double-layer' flash memory for hardware components would be pointless for the reasons i've posted already, and in case of BIOS/UEFI, whatever gets executed by the CPU, is visible to the CPU, so it can be debugged/dumped to some file at runtime for later disassembly.

jedi_hamster
reply to post by StargateSG7

 

a lots of 'blah blah', but you seem to skip few important details.

EVEN IF firmware embedded inside a chip (or loaded at runtime) has been compromised, the fact that the driver runs as a privileged code inside OS kernel (which isn't always the case) isn't everything - in case of many drivers (linux, *bsd) the driver's code is opensourced - and whatever the hardware chip - ANY of them, be it a soundcard, video card, or anything else - tries to do, the results are treated as data by the OS - because that's what they are. to run them as code on the CPU, the driver itself would have to be compromised - backdooring the hardware only isn't possible, unless it contains some code that gets executed directly on the CPU (and that's the case with BIOS/UEFI only), or it's the CPU itself. since the BIOS/UEFI code isn't big, it can be disassembled easily and checked for backdoors - so that rules those out. hardware chips containing backdoors are rather out of the question as well, because those would require backdoored drivers - and if you'll put a backdoor inside closed-source driver, there's no need to backdoor the hardware. backdoored drivers are out of the question as well though, because many OSes other than windows have their drivers opensourced, and even in case of windows the drivers should go through the certification process, so i guess they're checked for any malicious behaviour (and the fact that they're closed source, doesn't mean that they cannot be disassembled - they often are, so any backdoors would be discovered sooner or later anyway). the only possibility is the CPU - but the trouble i see with that is the fact that there's a not so small group of programmers tracking every change in current intel/amd architecture, down to the timings of every single opcode (for the purpose of writing faster code, doing benchmarks, optimizing compilers and so on), so unless there would be a separate specialized core, running in parallel, it would be detected - and even separate core would have some influence on memory access timings for example.

the rest of your claims are complete nonsense, trying to look technical while in reality being a mumbo-jumbo. you cannot get as high framerates as you claim from a webcam - as a matter of fact, those framerates go downhill when the lightning is insufficient, so often you cannot even get 30fps. in case of sound, mics built into laptops won't catch inaudible frequencies - those can barely catch full range of human voice. speakers? same thing - those have their frequency response cut off well below 20khz, those fancy 96khz/192khz sampling rates are possible on the line out, assuming you have a proper audio hardware connected.

i've been dealing with assembler programming at hardware level since over 20 years, including direct programming of hardware chips to maximize the software's potential, so i guess i know what i'm talking about. seriously, stop the FUD.

and when you're at it, minimize the amount of caps and exclamation points - it doesn't help you to gain credibility and makes you look like some kid that got all excited by some hacking articles and decided to spread his theories of doom without any facts to back them whatsoever.

edit on 8-11-2013 by jedi_hamster because: (no reason given)

---


That's interesting...I've been getting up to 60 fps on the microsoft webcam 720p models simply
because I use a an actual direct-x FILTER *.ax file rather than that stupid Capture Frame command
which takes too damn long to capture a frame (up to 64 milliseconds per frame which is only 15 fps)
When I write a low-level driver code, I can do 60 fps OR FASTER since the interrupt clock timer on
MS-VIDEO is as low as 100 nanoseconds. While Windows IS NOT a realtime OS with interrupt accuracy
only down to about 16 milliseconds...it CAN be forced to a few microseconds using some trickery
in the main WinProc() loop which takes some serious OS hacking to attach to.

You don't actually NEED drivers at all....just monolithic assembler targeted towards a specific
chip or chipset...and like the p-Code used in some compilers, you can cross-assemble for
multiple chips or chipsets.

I should point out that almost ALL audio cards and webcam microphones can do 80 hz
to 18khz in and out but MOST adults can only hear WELL between about 600 hz to about 14000hz
and that hearing really falls off outside of those parameters. So communicating via soundcards can
take advantage of the generally POOR hearing of most 1st world adults to transfer data
just near the limits of general hearing. The data rates would be low at about 9600
bits per second or you could bump it up to 56k using multiple frequencies for
audio tokens. 96k/192khz sample rates are only on newer SoundBlaster Audigy and
above cards and thus are more professional media production oriented.

Lighting has ABSOLUTELY NOTHING to do with frame rate, its luminance and chroma
complexity within a macroblock and the X/Y axis movement within the 16x16 pixel macroblocks
used in most webcam compression algorithms that determine compression times.
For the most part, MANY webcam apps use the stupid Direct-X CaptureGraph
Grab Sample command to grab a bitmap-to-global-heap-memory buffer-then-compress
then-then-send-over-TCP/IP-or-UDP.

I directly access the USB/Firewire/SDI/HDMI streams BELOW the level of a Direct-X FilterGraph
so I can BYPASS the 16 millisecond interrupt latency issues and push bits directly to the graphics
card for display/output. The fastest frame rate i've gotten yet is over 300 fps 720p directly
to a giant RAM disk (256 gigabytes on a Tyan Thunder Mobo) so IT CAN BE DONE!
So of course they're only gonna get 15 fps using Grab Sample commands.

And regarding clock-tick level assembler code profiling...yes that would detect compromised code
IF you have the right debuggers and a scope attached to the PCI-x bus and RAM/CPU pins
but since most end-users won't have that---they are toast!

Not to mention that it is exceedingly easy to patch the Windows Kernel to give you specific
checksums that will pass the Microsoft Genuine Advantage checker AND allow Kernel-level
and Ring-0 code execution (i.e. fake driver signing) You can also patch the WinOS kernel
directly and inject ReadFile/WriteFile substitutes and Keyboard hooks BEFORE any driver code.

So I am not particularly causing FUD (Fear Uncertainty Doubt) into these comments but
merely indicating that IT IS possible to use UEFI/BIOS to inject assembler code into
an OS kernel ON-THE-FLY before any driver code AND patch the checksums and Digital
Signatures to prevent detection! Hardware patching is done at the ODM or Chip Foundry level
and I need not discuss that here other than it's expensive and technically DIFFICULT to do well.
NOT IMPOSSIBLE ----- Just difficult!

And as an aside....

I've been doing Pure Assembler programming since 1982 (starting at 12 years old) plus
DSP, Microcontroller and full blown 16-bit/32-bit/64-bit and 128-bit RISC/CISC CPU/GPU
HARDWARE CIRCUIT DESIGN since 1989 which puts my low-level hardware experience
at just a wee bit more than yours.....;-) :-)

Bet ya that PIC controller or that 68xxx chip you're programming is one of my designs!

--

P.S. The caps key and exclamation keys entice me....UNCONTROLLABLY!

reply to post by StargateSG7


you have two options:

option number one, provide links to your research, source code and everything that backs up your claims.
option number two, stop lying, because what you're throwing out here is a bunch of technical nonsense, designed to make you look smart while in reality it's just one fairytale after another. don't make me point out every single lie you've made in this thread with facts backed up by hardware and software specifications. just back off, kid. back off for your own good.

jedi_hamster
reply to post by StargateSG7

 

you have two options:

option number one, provide links to your research, source code and everything that backs up your claims.
option number two, stop lying, because what you're throwing out here is a bunch of technical nonsense, designed to make you look smart while in reality it's just one fairytale after another. don't make me point out every single lie you've made in this thread with facts backed up by hardware and software specifications. just back off, kid. back off for your own good.

---

What would you like me to back up with references?

Did I not in the last few pages PROVIDE links and pointers
to means and methods of hardware hacking AND UEFI/BIOS
code injection....see pages 15 to current to see my links.

What sort of source code would you like me to show you?
C++/ADA/Assembler/Delphi? What do you want it to do?

Let us make this PERSONAL...code against code!
Spec against Spec! CHIP MASK against CHIP MASK!!!!
Let the clash of function headers begin!
;-) :-)

I do favour writing drivers and code in Delphi XE
so the average person can READ IT and then
we convert to ADA once its fully debugged.

One thing I do is making sure my code can actually BE maintained!

reply to post by StargateSG7


your links prove absolutely nothing. there is not a single one of them giving any piece of your code. direct hardware access code written by you? something that bypasses regular hardware access methods like you've described? anything that validates something that you claim you DID, and that validates that YOU did it?

you want code? fine then. here's a little piece of code written by me some time ago. it's a very simple code, so a hacker like you with so many years of expertise in assembly programming will no doubt not only explain what it does, but also will describe the exact algorithm used and will point out the exact two assembly instructions missing from the very beginning of said code, required to make it work. go ahead, show us that you are who you claim to be.

wklej.org...

if you won't, you'll prove that all you're doing here is spreading lies. just because you've read some quotes on the web and catched few technical phrases that you think you understand, doesn't mean you can throw it all here, twisted by some sick doom fantasies to feed those without enough technical expertise with BS to make yourself feel worshipped as some sort of pseudo-hacker and whistleblower-wannabe. usually i'm ignoring trolls, but the amount of disinfo, hoaxes and outright crap you're trying to push down people's throats here is a disgrace to this community.

jedi_hamster
reply to post by StargateSG7

 

your links prove absolutely nothing. there is not a single one of them giving any piece of your code. direct hardware access code written by you? something that bypasses regular hardware access methods like you've described? anything that validates something that you claim you DID, and that validates that YOU did it?

you want code? fine then. here's a little piece of code written by me some time ago. it's a very simple code, so a hacker like you with so many years of expertise in assembly programming will no doubt not only explain what it does, but also will describe the exact algorithm used and will point out the exact two assembly instructions missing from the very beginning of said code, required to make it work. go ahead, show us that you are who you claim to be.

wklej.org...

if you won't, you'll prove that all you're doing here is spreading lies. just because you've read some quotes on the web and catched few technical phrases that you think you understand, doesn't mean you can throw it all here, twisted by some sick doom fantasies to feed those without enough technical expertise with BS to make yourself feel worshipped as some sort of pseudo-hacker and whistleblower-wannabe. usually i'm ignoring trolls, but the amount of disinfo, hoaxes and outright crap you're trying to push down people's throats here is a disgrace to this community.

edit on 9-11-2013 by jedi_hamster because: (no reason given)

---

This initial RGB Palette Setup entry challenge
is possible...I should note it is actually NOT easy...but first thing is first ...

PaletteSetup:
// indexed VGA palette setup


xor ax,ax // ax := ax XOR ax Bitwise XOR of the AX register



mov dx,03C8h // allow 256 entries in the indexed colour palette
out dx,al // read palette entry and put into DX register
inc dx // dx := dx + ONE // increment palette entry value by one.

// Once you've set up the 256 colour palette you can write palette entry values directly to
// to port 03c9h.

Bling:

push ax
inc ax
and al,0Fh
pop ax
push ax
ror ax,2
je ps1
ror ax,1

Procedure Bling( VAR First_Parameter: 8_Bit_Integer )

Begin

push ax // get ax from the procedure or function stack i.e. First_Parameter

ax := ax + 1; // increment ax (First_Parameter) by one.
// equivalent to First_Parameter := First_Parameter + ONE;


pop ax // put the incremented ax back onto the stack
// this assumes that First_Parameter is an OUT or VAR parameter
// meaning its value survives function/procedure exit.

// ====== Something really should go here since this POP and PUSH is a useless statement unless
// you are doing concurrent programming where his register is accessed by another routine or process
//setting another value and then you need to set a PROTECTED INSTRUCTIONS flag.

push ax // get First_Parameter again from the stack.



al := al AND FIFTEEN; // and al,0Fh = 8-bit register bitwise AND


ax := ax ROTATE_BITS_RIGHTWARDS_BY 2; // ror ax,2


if ax = ZERO then // je ps1
Goto PS1

ax := ax ROTATE_BITS_RIGHTWARDS_BY ONE; // ror ax,1
End;

==== This Doesn't seem so simple to me!

==== just piddling around here...will convert and rewrite as I see each routine ---
seems like a line , shape drawing or colour palette cycler --- not quite fully sure yet....
I convert to pascal and then will see what it actually does in terms of pixel manipulation


RUNNING THIS IN MY HEAD to see what each sub-routine actually does to an individual colour value
and/or palette index entry --- kinda hard to do when I'm not in front of my work computer in my compiler IDE.
and WHY you want to do it...have not assembled it --- doing it all in my head!

reply to post by StargateSG7


---

I know what you're going to say...but it's how I UNDERSTAND what other coders write.
I convert the labels to sub-routine blocks and parameterize them into pascal/c++ procedures
and functions and then re-write to something I can actually understand --- something like this:



[
Single-bit to 8-bit luminance level and greyscale conversion formulae.
]
Function Get_Brightness_Of_RGBA_Pixel( Pixel_To_Convert : RGBA_Pixel_Type;
How_To_Round_Number : Runtime_Identifier_Type =
USE_BANKERS_ROUNDING;
Default_Value_To_Return_Upon_Error : BYte = ZERO ): Byte;

Var
Brightness_Of_Pixel : RGBA_Colour_And_Alpha_Channel_Type;

Floating_Point_Conversion_Result : Floating_Point;

Begin
Try
[
Use the Full-Range 8-bits per channel RGBA Pixel to Greyscale Conversion Formula
using the JFIF/JPEG file format colour space standard which allows for a full-range
ZERO to 255 8-bit Unsigned Integer value for all Red, Green and Blue colour components.

See Website:
en.wikipedia.org...

The standard Full-Range JFIF YCbCr (Luminance, Chroma-Blue, Chroma-Red)
JFIF YCbCr to RGB and RGB to JFIF YCbCr Conversion formulae are stated as follows:

Convert RGB to JFIF YCbCr:
Y := ( 0.299000 * Red Channel ) + ( 0.587000 * Green Channel ) + ( 0.114000 * Blue Channel );
Cb := 128.0 + ( -0.168736 * Red Channel ) + ( -0.331264 * Green Channel ) + ( 0.500000 * Blue Channel );
Cr := 128.0 + ( 0.500000 * Red Channel ) + ( -0.418688 * Green Channel ) + ( -0.081312 * Blue Channel );

Convert JFIF YCbCr to RGB:
R := Y Channel + ( 1.40200 * ( Cr Channel - 128.0 );
G := Y Channel - ( 0.34414 * ( Cb Channel - 128.0 ) ) - ( 0.71414 * ( Cr Channel - 128.0 ) );
B := Y Channel + ( 1.77200 * ( Cb Channel - 128.0 ) );

These are non-linear formulae that are NOT GAMMA CORRECTED where gamma is equal to 1.0
CRT and LCD/OLED/LED gamma correction factors are usually set to 2.2 with a D65 white point.

The final result is to be clamped to fall within the JFIF YCbCr 8-bit UnSigned Integer Colour Space Luminance Range from ZERO to 255.
]
Floating_Point_Conversion_Result := ( 0.299 * Pixel_To_Convert.Red ) + ( 0.587 * Pixel_To_Convert.Green ) + ( 0.114 * Pixel_To_Convert.Blue );

[
After the full-range ZERO to 255 luminance/brightness value has been determined, then
compare if brightness is greater than 50%. If so, then set luminance/brightness to full white.
If brightness is less than 50% then set luminance/brightness to dark black.
This will give a 1-bit monochrome, Black & White pixel result.
]
if Floating_Point_Conversion_Result >= 128.0 then
Floating_Point_Conversion_Result := 255.0
else
Floating_Point_Conversion_Result := FLOATING_POINT_ZERO;

[
Ensure that the final result is within the range limits
of a valid RGBA colour space channel value after
being rounded up or down as specified by the user.
]
Brightness_Of_Pixel := Get_Rounded_And_Clipped_Signed_Integer_Number( Floating_Point_Conversion_Result, // Numeric Variable to round up or down.
How_To_Round_Number, // Method used to round final result. Default is to use the Banker's Rounding method.
DEFAULT_NUMBER_OF_DECIMAL_PLACES_OR_PLACE_DIGITS, // How many decimal places or place digits to round the final result to. Default is round to nearest whole number with no fractional portion present.
ONE, // Nearest MULTIPLE to round to. Default is to the nearest whole number value evenly divisible by ONE.
MINIMUM_RGBA_COLOUR_AND_ALPHA_TRANSPARENCY_VALUE, // Minimum allowable range limit to clip final result to.
MAXIMUM_RGBA_COLOUR_AND_ALPHA_TRANSPARENCY_VALUE, // Maximum allowable range limit to clip final result to.
Default_Value_To_Return_Upon_Error ); // Default value to return upon occurence of a low-level error or exception.


Except
[
Upon any low-level error, return the Extended_Boolean_Type value
passed to the Default_Value_To_Return_Upon_Error parameter which
is normally by default set to ZERO but can be set to any other
valid RGBA_Colour_And_Alpha_Channel_Type value.
]
Brightness_Of_Pixel := Default_Value_To_Return_Upon_Error;
End;

// Return the current value of the local Brightness_Of_Pixel variable as the final function result.
Exit( Brightness_Of_Pixel );
End;

I been working with computers for years and I have seen a lot of weird unexplained events happening to isolated computers. Machines both on and off the network. The only thing that I can explain it is extreme temp changes, static charge, excessive frequency cross talk.

I had a system not boot and was stuck at post saying ntldr not found etc. This was because the hd was very cold. Dew moisture can mess a drive up like this. It's best to keep a machine in controlled temp. In very cold it's best to keep the machine on. A hd should never be opened or serviced unless it is in a clean room environment. I have come across some HD's that are vacuum sealed or filled with a argon or nitrogen gas that acts as a anti-fog. On some old hd's like a 4.3G Along the edges is a metal sticky tape seal as you peel it off you can hear it go psssssst.

Another time I had a very strange static issue. A tech should always use a static strap working on electronics, but this problem was due to a poorly designed case. The top part of the case had a pwr/reset button surrounded by a plastic chrome casing. Just barely touching the chrome plastic that the reset button or power button was housed in would either turn it off/on or reboot the computer.

Another time I had a strange static issue actually infected the computer and jumped to the monitor as well. It was a old CRT dell model I still have it to this day and keep it as a talk piece lol. The onscreen adjustments screen will stay on and sometimes adjust itself and it's numbers whichever setting it happens to be on. So if it was selected to brightness then it's slider will adjust up and down. It's like it has a mind of it's own.

Another incident with a clients machine vacuuming close to the computer eventually zapped the computer dead where both the cpu and mobo has to be replaced. Never set a PC on the carpet.

Another incident involving the client wiring up his own network. During this process while plugging in the network jack it slipped out of his hand slid down the side of the computers chassis emitting sparks that blew out most of the components on the back of the IO plate including the on-board video.

reply to post by StargateSG7

 

This initial RGB Palette Setup entry challenge
is possible...I should note it is actually NOT easy...but first thing is first ...

right. you forgot about the two instructions missing, but i'll leave that to the end

reply to post by StargateSG7

 

xor ax,ax // ax := ax XOR ax Bitwise XOR of the AX register

oh rly? and how about ax = 0? because that's what xor does in this case - any assembler programmer would know that. FAIL.

reply to post by StargateSG7

 

mov dx,03C8h // allow 256 entries in the indexed colour palette
out dx,al // read palette entry and put into DX register
inc dx // dx := dx + ONE // increment palette entry value by one.

BS. out dx,al sends the index of the first color in al (so 0) to the port 03C8h, then inc dx increases the port number by one - all rgb entries go to that port afterwards, and palette index set to 0 via port 03C8h gets increased automatically after each 3 values (rgb). FAIL.

reply to post by StargateSG7

 

push ax // get ax from the procedure or function stack i.e. First_Parameter

ax := ax + 1; // increment ax (First_Parameter) by one.
// equivalent to First_Parameter := First_Parameter + ONE;


pop ax // put the incremented ax back onto the stack

seriously, kid? a programmer with years of expertise in assembler coding confuses push and pop? FAIL.

reply to post by StargateSG7

 

// ====== Something really should go here since this POP and PUSH is a useless statement unless
// you are doing concurrent programming where his register is accessed by another routine or process
//setting another value and then you need to set a PROTECTED INSTRUCTIONS flag.

or your statement is a bunch of useless BS because you have no idea about assembler programming - especially size-optimized coding, which you should be aware of when doing the stuff you've claimed to do.

bling: push ax - ax on the stack for future reference
inc ax - ax = ax+1
and al,0Fh - self-explanatory, sets cpu flag
pop ax - get old value of ax back
push ax - ax on the stack for future reference again
ror ax,2 - self-explanatory
je ps1 - conditional jump according to the flag set by and al,0Fh

ax gets backed up on the stack, then and is performed to set the flag for conditional jump, then ax gets restored before the jump.

once again, you FAIL.

reply to post by StargateSG7

 

==== This Doesn't seem so simple to me!

==== just piddling around here...will convert and rewrite as I see each routine ---
seems like a line , shape drawing or colour palette cycler --- not quite fully sure yet....
I convert to pascal and then will see what it actually does in terms of pixel manipulation


RUNNING THIS IN MY HEAD to see what each sub-routine actually does to an individual colour value
and/or palette index entry --- kinda hard to do when I'm not in front of my work computer in my compiler IDE.
and WHY you want to do it...have not assembled it --- doing it all in my head!

real assembler programmer with years of expertise would never, EVER, try to represent assembler code as some form of pseudo code like you did. it's actually easier to think in assembler directly (for higher level of abstraction there is C)... as long as you understand it. which you don't - this routine creates a palette of white-blue gradient-black bands, 16 colors wide, so that later when all points get decremented by 17 in every frame, points fade from white through blue to black. you FAIL.

reply to post by StargateSG7

 

I know what you're going to say...but it's how I UNDERSTAND what other coders write.
I convert the labels to sub-routine blocks and parameterize them into pascal/c++ procedures
and functions and then re-write to something I can actually understand --- something like this:

and what can i say? you're trying to rewrite my assembler code as some form of pseudocode to make you look smart and to make those that believed in your posts so far to think that you know what you're talking about. but you actually don't, you don't have the slightest idea what this code is about - you don't understand anything. FAIL.

i won't even comment the rest of your post - it's a random conversion routine copy-pasted from somewhere, while you didn't actually analyze the most of the remaining code i've pointed you at - and you've failed miserably at an attempt to analyze the first few lines. you know NOTHING about assembler programming, you've LIED to the ATS readers, and that proves that everything else that you've said - that was so heavily backed up by 'i did it', 'it is easy when you know how' - is nothing but a bunch of lies as well.

by looking at some variables in my code (320, 200) you should figure out what it does, more or less - you could google it and find it on github as well, together with first two lines, being video mode initialization:
mov al,13h
int 10h

if you would have ANY idea about assembler programming, you would immediately notice that this is a 16bit mode code (using some 32bit opcodes and fpu for random number generator and 3D calculations), using segment:offset addressing. that implies it should be running in a dos mode, and that it should be compiled to a .com file - if you would do that, you would know what it does.

and here it is:
www.pouet.net...

demoscene stuff - optimized for size, displaying a 3D starfield in old VGA 320x200x256 video mode, done in 256 bytes.

seriously, i didn't even laugh at your analysis - it's so pathetic attempt at fooling the ATS readers to believe that you have ANY knowledge whatsoever, while in reality you're just posting random bits of BS, made from some stuff you've found on the web and twisted to support your doom crap, that you should get banned from ATS, because spreading deliberate lies/hoaxes is against T&C here.

you're done here, kid. go tell your fairytales somewhere else, perhaps you'll find a community willing to believe your BS so that you won't get your ego burned. ATS isn't such community.

EOT

reply to post by sean


ntldr not found means that windows bootloader was screwed up by either a badly written software, stupid actions of the user or a virus (there are tons of viruses that do that).

when it comes to the crt monitor and its osd - it looks like some short circuit, probably just buttons failure.

as for the rest of your post, accidents happen - the more careless the user is, the most likely it is that weird things will happen that the user may be unable to explain.

jedi_hamster

reply to post by StargateSG7

 

This initial RGB Palette Setup entry challenge
is possible...I should note it is actually NOT easy...but first thing is first ...

right. you forgot about the two instructions missing, but i'll leave that to the end

reply to post by StargateSG7

 

xor ax,ax // ax := ax XOR ax Bitwise XOR of the AX register

oh rly? and how about ax = 0? because that's what xor does in this case - any assembler programmer would know that. FAIL.

reply to post by StargateSG7

 

mov dx,03C8h // allow 256 entries in the indexed colour palette
out dx,al // read palette entry and put into DX register
inc dx // dx := dx + ONE // increment palette entry value by one.

BS. out dx,al sends the index of the first color in al (so 0) to the port 03C8h, then inc dx increases the port number by one - all rgb entries go to that port afterwards, and palette index set to 0 via port 03C8h gets increased automatically after each 3 values (rgb). FAIL.

reply to post by StargateSG7

 

push ax // get ax from the procedure or function stack i.e. First_Parameter

ax := ax + 1; // increment ax (First_Parameter) by one.
// equivalent to First_Parameter := First_Parameter + ONE;


pop ax // put the incremented ax back onto the stack

seriously, kid? a programmer with years of expertise in assembler coding confuses push and pop? FAIL.

reply to post by StargateSG7

 

// ====== Something really should go here since this POP and PUSH is a useless statement unless
// you are doing concurrent programming where his register is accessed by another routine or process
//setting another value and then you need to set a PROTECTED INSTRUCTIONS flag.

or your statement is a bunch of useless BS because you have no idea about assembler programming - especially size-optimized coding, which you should be aware of when doing the stuff you've claimed to do.

bling: push ax - ax on the stack for future reference
inc ax - ax = ax+1
and al,0Fh - self-explanatory, sets cpu flag
pop ax - get old value of ax back
push ax - ax on the stack for future reference again
ror ax,2 - self-explanatory
je ps1 - conditional jump according to the flag set by and al,0Fh

ax gets backed up on the stack, then and is performed to set the flag for conditional jump, then ax gets restored before the jump.

once again, you FAIL.

reply to post by StargateSG7

 

==== This Doesn't seem so simple to me!

==== just piddling around here...will convert and rewrite as I see each routine ---
seems like a line , shape drawing or colour palette cycler --- not quite fully sure yet....
I convert to pascal and then will see what it actually does in terms of pixel manipulation


RUNNING THIS IN MY HEAD to see what each sub-routine actually does to an individual colour value
and/or palette index entry --- kinda hard to do when I'm not in front of my work computer in my compiler IDE.
and WHY you want to do it...have not assembled it --- doing it all in my head!

real assembler programmer with years of expertise would never, EVER, try to represent assembler code as some form of pseudo code like you did. it's actually easier to think in assembler directly (for higher level of abstraction there is C)... as long as you understand it. which you don't - this routine creates a palette of white-blue gradient-black bands, 16 colors wide, so that later when all points get decremented by 17 in every frame, points fade from white through blue to black. you FAIL.

reply to post by StargateSG7

 

I know what you're going to say...but it's how I UNDERSTAND what other coders write.
I convert the labels to sub-routine blocks and parameterize them into pascal/c++ procedures
and functions and then re-write to something I can actually understand --- something like this:

and what can i say? you're trying to rewrite my assembler code as some form of pseudocode to make you look smart and to make those that believed in your posts so far to think that you know what you're talking about. but you actually don't, you don't have the slightest idea what this code is about - you don't understand anything. FAIL.

i won't even comment the rest of your post - it's a random conversion routine copy-pasted from somewhere, while you didn't actually analyze the most of the remaining code i've pointed you at - and you've failed miserably at an attempt to analyze the first few lines. you know NOTHING about assembler programming, you've LIED to the ATS readers, and that proves that everything else that you've said - that was so heavily backed up by 'i did it', 'it is easy when you know how' - is nothing but a bunch of lies as well.

by looking at some variables in my code (320, 200) you should figure out what it does, more or less - you could google it and find it on github as well, together with first two lines, being video mode initialization:
mov al,13h
int 10h

if you would have ANY idea about assembler programming, you would immediately notice that this is a 16bit mode code (using some 32bit opcodes and fpu for random number generator and 3D calculations), using segment

ffset addressing. that implies it should be running in a dos mode, and that it should be compiled to a .com file - if you would do that, you would know what it does.

and here it is:
www.pouet.net...

demoscene stuff - optimized for size, displaying a 3D starfield in old VGA 320x200x256 video mode, done in 256 bytes.

seriously, i didn't even laugh at your analysis - it's so pathetic attempt at fooling the ATS readers to believe that you have ANY knowledge whatsoever, while in reality you're just posting random bits of BS, made from some stuff you've found on the web and twisted to support your doom crap, that you should get banned from ATS, because spreading deliberate lies/hoaxes is against T&C here.

you're done here, kid. go tell your fairytales somewhere else, perhaps you'll find a community willing to believe your BS so that you won't get your ego burned. ATS isn't such community.

EOT

edit on 10-11-2013 by jedi_hamster because: (no reason given)

-----

I actually DID NOT KNOW what your code was about. I do remember it was a VGA graphics
so I have attempted to REWRITE IT in Pascal-like code (which I really like!) to understand
what it does...IT 'S HOW I WORK!!! Reading your assembler code means NOTHING to me.
Just because I am familiar with assembler instructions doesn't mean I know TRULY what's
going on until I rewrite into my own "pseudo-code" to see what's happening...!!!

---

reply to post by jedi_hamster


Wi-Fi

reply to post by StargateSG7


----


While I admit at the beginning, I was confused as to WHY you were XORing with
itself (xor ax,ax) so I knew something was missing.....but until you explained
your were calling Interrupt 13h for BIOS VGA manipulation it made no sense to me.

When I first read your code I had actually had NO IDEA what it physically did
until I got down to the SCALC label and then I realized you were manipulating pixels
for some reason. I would NOT have known ANYTHING about banding or gradations until
I finished converting it to my own "pseudocode"...it's just the way I work.

In actually I was thinking MORE OF THE WHY of your individual lines of code
rather than it's final output...and as you have so APTLY illustrated on an
almost line-by-line basis, your diatribe merely outlines my LACK of current
ability to read old BIOS-based CGA/EGA/VGA graphics code in assembler format.

THERE IS NO INTENT TO DECEIVE ATS POSTERS! My response to your post was merely
to illustrate that while I do have coding abilities that are quite significant,
it seems that they are not as adequate as you have outlined in terms of pure
assembler. The strange thing...I actually had to look up what JE and ROR
instructions were...I had absolute no rememberance of ever using them.

....AND that RBG-to-Monochrome code actually IS MY OWN CODE.
I wrote the base part of it YEARS AGO for a graphics application
so it was NOT copy-and-pasted from somewhere other than MY OWN source files.

By the way, Windows Vista, 7/8 etc don't like REAL-MODE programs So I'm not sure
there wouldn't be any fatal exceptions if I assembled it to a DOS executable (*.COM)
and that would have REALLY confused me even more.

---

".... it's actually easier to think in assembler directly (for higher level of abstraction there is C)"

UHM NOPE...I grew up on Apple Basic and Peeking and Poking Commodore 64's so for ME personally
If I see assembler I rewrite to a higher level language to understand what it does. I just cannot
think directly in assembler other than at a line-by-line level translation....I think natively in Pascal/C++....and even then I think holistically as to the purpose of a WHOLE program....your
program when I first saw it...I hadn't a single clue as to what it did until I saw the (mov dx,03C8h)
instruction and only THEN did I know you were setting up a DOS VGA graphics program. Then reading
line-by-line I got SOME of the basic pixel manipulation .... but until I did that and translated your
code BACK to pseudo-code I wouldn't have had a clue as to what it did on a general level.

I should have known by the 320 by 200 pixel indexing that this was DOS graphics but I didn't
and WOULDN'T HAVE KNOWN until I got done translating....which for me ain't a short process!

...but I will admit one rather big thing...for assembler code writing I FIRST code in Pascal/C/C++,
THEN.....I goto the assembler output in the debugger and copy it over as an INLINE ASSEMBLER ROUTINE
then I rewrite my original C/C++ algorithm or code changing various variables, unwinding loops
by hand and then profile THAT newly compiled output against the copied inline code and then
I keep doing that copy-compiler-output-to-inline-routine-and-recompare against new version
until I understand how the compiler optimization gets me the best code possible (be it the
smallest OR fastest version of any given routine). This method allows me to let the compiler
write the assembler and leave me to figure out that YES you CAN inject disk read/write or
keyboard hook code into DLL drivers or even INTO THE KERNEL as a monolithic routine.
This method allowed me to find and get insight into entry points where I could insert a
CALL/RET or JMP/RET using my profiled code and finding out IF and WHERE there are CRC checks
done, Digital Signature Evaluations and MS Genuine Advantage checking which would detect
my modifications.

So while HELL YA we can inject good or NASTY virus code into drivers, bioses and kernels....
I must still somewhat apologetically, if not with maddening frustration,......

.......BOW TO YOUR SUPERIOR DOS REAL-MODE ASSEMBLER PROGRAMMING SKILLS !!!!

...BUT...I do know some MEAN Interrupt 21h programming...IN Delphi of course!

reply to post by StargateSG7


-----

P.S. when I get some SERIOUS hand-coded assembler TRAINING/RETRAINING...I think
I MIGHT STILL be able to whup ya some serious coding A*&%^*&&* .....he he he!

StargateSG7
reply to post by StargateSG7

 

-----

P.S. when I get some SERIOUS hand-coded assembler TRAINING/RETRAINING...I think
I MIGHT STILL be able to whup ya some serious coding A*&%^*&&* .....he he he!

----

AND FINALLY GETTING BACK ONTO TOPIC....YES it is DEFINITELY POSSIBLE to inject
NASTY Virus code written in almost any computer programming language (in Assembler,
Pascal, C/C++, BASIC or others!) into BIOS'es of graphics cards, network cards,
Motherboard UEFI/BIOS and into DLL's (Dynamic Link Libraries), Direct-X drivers,
Audio & Video Card apps and other places...The KEY issue to be aware of is that
WHILE MANY operating systems having something called a CRC (Cycle Redundancy Check),
General Virus and Malware detection, Digital Signature comparisons, hardware/software
checksums and other means and methods to DETECT compromised hardware and software,
THOSE VERY DETECTION METHODS CAN BE BYPASSED by modifying base level operating system
and driver or even BIOS code to jump past or even modify the code checkers themselves.

While TECHNICALLY DIFFICULT...when you compare how much MONEY the NSA has,
or almost any other intelligence agency in the world has ACCESS TO....You cannot
BE SURE that your code and hardware is MALWARE FREE...UNLESS....you build it
ALL YOURSELF...OS, CPU CHIP, BIOS'es, DRIVERS, etc.

THAT SAID....using Occam's Razor (among competing hypotheses, the hypothesis with the fewest assumptions should be selected. -- Wikipedia) the SIMPLEST EXPLANATION is USUALLY....the
correct one...so for the Original Poster's issues....I'm gonna say it's PROBABLY a combination
BASE hardware failure (bad CPU, RAM, DISK DRIVES, FANS, etc.) and basic but understandable
problems between Keyboard and Seat -- aka Operator Error !!!!

reply to post by jedi_hamster


Yeah typically that's what happens with ntldr, but not in this case. After warming it up fixed it. It was literally ice cold with moisture on it.

reply to post by StargateSG7


----

And for a final response to the lurking "Jedi Hamster" regarding credibility on ATS forums.

One should take with a GRAIN OF SALT claims of technical ability (of which mine are
generally significant if now dated as was shown by earlier posts!)....but I will leave you
with this cross-post from another thread which should illustrate that while ATS is an
EXCELLENT FORUM for conspiracy discussion, great care should be taken with specific
advice and commentary from ALL posters (INCLUDING MINE!) unless SOURCES have
been provided:

CROSS-POST:


jedi_hamster
reply to post by guardian0111

those unaware of the so called 'credibility' of StargateSG7 need to look no further:
www.abovetopsecret.com...
edit on 10-11-2013 by jedi_hamster because: (no reason given)



---

Just a response to a somewhat snide remark regarding credibility...MINE or anyone else's on ATS...

I SAY THIS.......

YOU MEAN I ACTUALLY HAVE CREDIBILITY ??? !!!!

1) I thought you KNEW I'm just a disinfo agent for the powers that be....

OR

2) that in fact, I work in an East Vancouver warehouse packing and mailing
VHS tapes of 1970's era XXX videos off to 3rd world countries....

OR

3) that I'm an old fogie dissin ya young folks who'll believe ALMOST ANYTHING i say...

OR

4) That in fact I actually DO KNOW assembler rather intimately but chose to mildly let the
resident coder keep his jollys...AND that I in fact DID design that PIC controller he's currently
working on and that I design, code and build 3D stacked CPU's for Artificial Intelligence systems....

OR

5) I'm a Canadian spook who works for large intelligence agencies in BOTH the U.S. and CANADA....

OR

6) I am just a 3rd year college B.Comm major from New York having a laugh at y'all on ATS !!!!!


Now WHICH ONE IS THE TRUTH?

You tell me!

Because on the Internet, I could ALSO BE a bored 45 year old stay-at-home
mother of three pretending to be some bigshot and you'd NEVER know it!!!!

DO NOT BELIEVE ANYTHING I or ANYONE SAYS with 100% certainty cuz
this AIN'T real life....it's just Memorex for bits and bytes!

----

That said...at least MANY of my links and sources do come SOMEWHAT legitimate places!

Personally...I like NUMBER TWO as my current occupation! --- It's the MOST REALISTIC of the bunch!