Saturday, August 30, 2014

Manually start SAMBA on HD300B

HD300B is a media player device made by HIMEDIA. Sometimes we connect HD300B with HDD to network at home but the device cannot display in Network Neighborhood of our computer with Windows. The reason is the SAMBA server in the device not started successfully. We can use the following way to start SAMBA.

Step 1. telnet HD300B.
HD300B support telnet but not SSH so telnet it. For example,
> telnet 192.168.1.7
The default password of root is hdpfans.

Step 2. Find the path of SAMBA.
> find / -name smbd
/usr/local/bin/package/samba/sbin

Step 3. Start SAMBA.
Please go to the path to stat samba.
>./smbd
>./nmbd

Now we can find that the HD300B device dislay in Network Neighborhood.

Friday, August 29, 2014

How does UEFI Fault Tolerant Write protocol work on Variable reclaiming process?

The FTW (Fault Tolerant Write) protocol is called when the variable reclaiming happens. Why does Variable driver use FTW during reclaiming? How does FTW work?

We know that variables are stored in ROM. When a variable is updated by SetVariable() calling, Variable driver appends a new variable in the tail and marks the old variable as invalid. Why not to update variable directly? The reason is the hardware characters of flash part. In Write operation, the bit in flash part can be changed from 1 to 0, but cannot be changed from 0 to 1. Erase operation is to erase a block in flash part with FF value. That is why the Variable driver needs to reclaim when the variable store is about full. Reclaiming means deleting invalid variables and combined all valid variables together. The simple reclaiming process is:
  1. Put all valid variables into memory.
  2. Erase variable store in ROM.
  3. Write all variables from memory to ROM.
There is a risk that if the platform is shut down unexpectedly in the step 3, the variables reclaiming are not completed to make platform crashed. To avoid the risk, the reclaiming process is updated as follows, I guess.
  1. Put all valid variables into memory.
  2. Set a flag to announce that the reclaiming start.
  3. Write all valid variables from memory to backup region in ROM
  4. Erase variable store in ROM.
  5. Write all variables from memory to variable store in ROM.
  6. Update the flag to indicate that the reclaiming is completed.
So if the platform is shut down unexpectedly in step 5 and the platform restarts, Don't worry. The platform will recover variables from backup region because it detects the reclaiming has not been completed. The recovery process is:
  1. Detect the flag that the reclaiming has not be completed yet.
  2. Restore variables from backup region to variable store.
  3. Update the flag to indicate that the reclaiming is completed.
Again, if the platform is shut down unexpectedly in step 2, the recovery steps are run again when the platform starts.

How does FTW support this idea? Variable driver uses FTW->Write() to write large data to implement step 2 - step 6 in reclaiming process.
  • The flag is updated in NV_FTW_WORKING.
  • The backup region is in NV_FTW_SPARE.
We can use a tool to set different variables to trigger variable reclaiming, and use another tool to dump NV_FTW_WORKING and NV_FTW_SPARE. How do we find the two regions? There are many ways to find them.

Method 1 - Dump ROM and search the signature of NV_FTW_WORKING

EFI_FAULT_TOLERANT_WORKING_BLOCK_HEADER->Signature

#define EDKII_WORKING_BLOCK_SIGNATURE_GUID \ 
{0x9e58292b, 0x7c68, 0x497d, {0xa0, 0xce, 0x65, 0x0, 0xfd, 0x9f, 0x1b, 0x95} }

Method 2 - Find the values of NV_FTW_WORKING and NV_FTW_SPARE in AutoGenFlashMap.h

The AutoGenFlashMap.h is generated by EDKII build system. We can find the values that we are interested.

#define _PCD_VALUE_PcdFlashNvStorageVariableBase    0xFFF90000U
#define _PCD_VALUE_PcdFlashNvStorageVariableSize    0x0001D000U
#define _PCD_VALUE_PcdFlashNvStorageFtwWorkingBase  0xFFFAE000U
#define _PCD_VALUE_PcdFlashNvStorageFtwWorkingSize  0x00002000U
#define _PCD_VALUE_PcdFlashNvStorageFtwSpareBase    0xFFFB0000U
#define _PCD_VALUE_PcdFlashNvStorageFtwSpareSize    0x00020000U

From the definitions, we know that the offset of FtwWorkingBase (NV_FTW_WORKING) is  FFFAE000h - FFF90000 = 1E000h

Furthermore, we can use a tool to dump the content in UEFI Shell. For example,
ToolA.efi -read -id 3 -lba 1 offset e000 -size 70

The tool consumes Firmware Volume Block protocols to dump data from ROM. I will describe it in another page.

Because the page is too long, please refer the page to observe the detail of reclaiming process.
http://countchu.blogspot.tw/2014/10/observe-reclaiming-process-of-edkii.html

I hope this page and the referred page provide you enough background knowledge of FTW and Variable reclaiming process.





Thursday, August 28, 2014

Use Debug Command to Dump BDA

We can use debug command in Windows prompt to dump BDA (BIOS Data Area.) The BDA is created at memory location 0040:000h with a 256 bytes or over.



The word in 40:0e is the segment address of EBDA. The address is 9ac0:0000. We can use debug to dump it.


The word in 40:13 is the system available memory size in Kbytes below 640k. The value is 0280h = 640. Therefore the memory size is 640k.

We can refer the following link for the detail of  BDA.
http://www.bioscentral.com/misc/bda.htm


Tuesday, August 26, 2014

Reveal File System of WD My Cloud

This page reveals the file system of the cloud HDD product, WD My Cloud. I poof that the product is just a mini PC with HDD where Linux installing. The page teaches us to use linux commands (df, fdisk, parted, mdadm) to reveal the secret.


I suppose the product is a mini PC. To proof it, I create a file, aa.txt in /etc/samba.

  > echo aaa > aa.txt
  
> shutdown -r now  

The aa.txt still exists after restarting. Therefore the rootfs is in HDD and the assumption is proofed.


Let's use df -ahT command to report file system. We make sure that sda4 is a partition in a HDD. We are interested in rootfs and /dev/root.

df
     -a     include dummy file systems
     -h     print size in human readable format
     -T     print file system type




The following commands show that the /dev/root is linked to a device named md1. So the next question is what/where is md1.

  > ls -al /dev/root                                    
  lrwxrwxrwx 1 root root 3 Aug 26 03:05 /dev/root -> md1
  > ls -al /dev/md1                                     
  brw-rw---T 1 root disk 9, 1 Aug 26 03:05 /dev/md1     


Please use fdisk -l to list partition tables. It appears that the HDD is parted as GPT.


Therefore we change to use parted -l to get more information of the partition tables on all block devices. It apears that ,sda1 and sda2 partitions are combined as RAID, and md1 is a RAID with 2048M bytes. We suppose that md1 is composed of sda1 and sda2 partitions.


We use mdadm --detail /dev/md1 to proof the assumption. The sda1 and sda2 partitions are combined as RAID named md1 where is rootfs.


We can use the following commands to get more information for each partition.
fdisk /dev/sda
fdisk /dev/sda1
fdisk /dev/sda2
fdisk /dev/sda3
fdisk /dev/sda4

Thursday, August 21, 2014

Use iPad to play movies in media server through SFTP.



We can build a simple media server by installing Fedora 20 in PC. The SFTP is default to enabled after booting Fedora.  We use SFTP as our simple media server.

We install FTPManager and nPlayer in iPad. FTPManager helps us manage files in media server through SFTP. We open nPlayer to play movies through SFTP. The following are framework.

  • X86 PC
    • Install Fedora 20. The SFTP service is default enabled.
    • Connect internet with fixed IP address via PPPoE.
  • iPad
    • Install FTPManager
    • Install nPlayer
Let's use nPlayer to play movies anywhere after it is installed in iPad/iPhone.


It displays all supported connection types. Please select SFTP.


Please create your SFTP sites.


After you select a SFTP site, the App displays the directories.


You can enter a directory and play a movie.









Wednesday, August 20, 2014

Install XBMC in Fedora 20




The following steps describe the process of installing XBMC in Fedora 20.

1. Install xbmc.
# yum install xbmc

2. Run xbmc.
# xbmc

If the following  error occurs. Please install ffmpeg or libvpx.
/usr/lib/xbmc/xbmc.bin: symbol lookup error: /lib/libavcodec.so.55: undefined symbol: vpx_codec_vp9_dx_algo

3. Install ffmpeg and libvpx.
# yum install ffmpeg\*
# yum install libvpx

4. Run xbmc again.
# xbmc

You can see the XBMC GUI display.

5. Setting IMDB as movie scraper.

The following VIDEO teach you how to set IMDB as movie scraper for XBMC.
http://youtu.be/RSOiPvScPyI

You can see it.





Tuesday, August 19, 2014

Explain the UEFI Secure Boot

The Secure Boot technology is defined by UEFI specification. BIOS uses RSA algorithm to check the integration of the booted OS and to verify if the booted OS is released by the OS vendor.  Let's show the algorithm of Secure Boot.

OS vendor signs OS Loader with Private Key:
{PublicKey, PrivateKey} = GenerateKeyPair ()
Digest = Hash (OsLoaderCode)
Signature = Encrypt (Digest, PrivateKey)
OsLoader = {OsLoaderCode, Signature}

BIOS Vendor enrolls signature into BIOS:
Db = {header, SigList, ...}
SigList = {Sig, ...}
Sig = {..., Cert}
Cert = {..., PublicKey}

BIOS verifies OS Loader before starting it.
Digest = Hash (OsLoaderBody)
Digest2 = Decrypt (Signature, PublicKey)
if (Digest == Digest2) {
  The OsLoader is verified successfully.
  Start the OsLoader.
}


Monday, August 18, 2014

How to backup iPad or iPhone in USB disk drive on Windows?

We always backup iPad or iPhone with iTunes on Windows. The backup data are stored in C drive. The backup path is for example.

C:\Users\[USER_NAME]\AppData\Roaming\Apple Computer\MobileSync

A problem is that there is often not enough space in the C drive. It seems that there is not an easy way to change the backup path to our USB disk drive. We can use the mklink command before running iTunes to solve the problem. For example,

mklink /j "C:\Users\[USER_NAME]\AppData\Roaming\Apple Computer\MobileSync" "F:\iPad Backup\MobileSync"

The F drive is a USB disk drive. We create a link of MobileSync under "Apple Computer" directory. It links to our MobileSync in the USB disk drive. When we run iTunes to backup, the data are really stored in F drive, not in C drive, even though iTunes only recognizes the path, "Apple Computer\MobileSync".