hobbygenius.co.uk Report : Visit Site

Technical data of the hobbygenius.co.uk

Geo IP provides you such as latitude, longitude and ISP (Internet Service Provider) etc. informations. Our GeoIP service found where is host hobbygenius.co.uk. Currently, hosted in Netherlands and its service provider is Go Daddy Netherlands B.V. .

HTTP Header Analysis

HTTP Header information is a part of HTTP protocol that a user's browser sends to called Apache containing the details of what the browser wants and will accept back from the web server.

DNS

HtmlToText

home blog tutorials projects reverse engineering the atmel sam-ba bootloader: part 3 by george sephton on july 18, 2017 at 8:05 am now that we’ve been over the functionality of the sam-ba® bootloader , i’m going to finish this series with the analysis of the bootloader, including a detailed look at what’s actually going on behind the scenes. although i won’t be showing the code for my adapted bootloader, i’m hoping that there’s enough information in these posts to allow anyone to easily adapt the sam-ba bootloader for their own application. sam-ba analysis we now have a complete understanding of how the sam-ba system works. let’s now look at exactly what happens when we connect our saml21 to the sam-ba pc software. we can’t begin to adapt the sam-ba system until we know exactly what the software will be doing. i used a serial monitoring application to see the data being transferred from pc to bootloader. connecting when first clicking connect in the sam-ba software, it will load up the tcl file associated with the selected board. these can be found in the sam-ba installation software in the tcl_lib folder. if we open the saml21_xplained_pro folder, we see the tcl file used to tell the sam-ba software how to connect to our saml21 bootloader, and also the .bin file of the compiled applet. note that when we looked at the applet source code previously, the makefile with it tells the compiler to output the compiled flash applet to here. the tcl file tells the software what memories are available for that chip, what device id to expect and where the application start address is etc. the customisation of this can all be found in atmel’s application note at09423 (sam-ba overview and customization process) . we’ll be looking at this later on. initialization when connecting, to the bootloader, the software first sends: i don’t know why it sends 0x80 twice, but the # (0x23) is sent to tell the bootloader we are connecting via usart: normal mode once the bootloader has received that, the sam-ba monitor is ready to go. we then need to enter it into normal mode: which the bootloader will respond with 0a 0d (\n\r) : device id next the software queries the device id: 77 34 31 30 30 32 30 31 38 2c 34 23 (w41002018,4#) the w command is used to read a word from the device: as i mentioned before, every memory location in the saml21 has a unique address, regardless of memory type. we can look in the saml21 datasheet to see what address is at 0x41002018. from here we can see that address 0x41002018 is something to do with the dsu (device service unit). from the datasheet: the accepted device ids are defined in our tcl file: here we can also set what memory location has to be read in order to retrieve the device id: 1 set cidr _ addr 0x41002018 if we now look at the data the saml21 bootloader returns: 0f 01 81 10 (...) we have the device id of the saml21j18b, which is on the accepted list. note that if the device id is not on the accepted list, the software will stop trying to connect: setting the sam-ba gui now that the sam-ba is ready to connect, it starts to initialise the user interface required. i won’t go over everything in the tcl file, since most of it can be left the way it is, but note the following: here we can set our scripts that are available to the user, and we also set three vital things: applet address: this is where the applet application is loaded to. note that the saml21’s sram starts at address 0x20000000 and ends at address 0x22007fff. applet mailbox address: this is the location of the mailbox used to communicate between the bootloader and the applets. i won’t go into detail about this since it’s quite complex, but essentially the linker file for our applet tells the compiler where to put the mailbox and once compiled it comes out at 0x20001040. applet file name: this is the compiled output that we talk about before. note that these parameters are directly related to the parameters set in our linker file (found in the sam-ba install directory under applets > saml21 > sam-ba_applets > linker_script. there’s a lot to see in the tcl file, but i’m going to leave it there. later on we’ll remove some of the scripts that are available to the user, but that will be the only change to this file. send the applets application now we’re ready to send the application to be stored in sram. we saw in the last section that this will sent to location 0x20001000. the sam-ba software starts this process by sending the s command, used to send files to the bootloader: 53 32 30 30 30 31 30 30 30 2c 30 30 30 30 30 39 31 30 23 (s20001000,00000910#) we saw before that the first parameter sent is the location to store the file we’re going to send, and the second parameter tell the bootloader how many bytes of data are going to be sent. (note that parameters are always sent as hex). in this case we are going to send 2320 bytes of data to be stored starting at location 0x20001000. once the bootloader receives this, it will call the getdata_xmd function, either usb_getdata_xmd() or usart getdata_xmd() , and wait until all the data has arrived. the __asm(“nop”); line at the bottom of this function occurs after all the data has arrived, so we need to look inside the function usart getdata_xmd() to see how our data is handled: note that as data comes in, it looks at the start of each packet to see if it’s a start of header: soh (0x01) or an end of transmission: eot (0x04). it then uses the getpacket() function to retrieve the data from the packet and place it into memory. when i was analysing this code, it became apparent that a lot of this was unnecessarily over complicated. so instead, i primarily focused on the data being sent and used the bootloader code as a reference: after the s command is sent, a c (0x43) is returned as a response, telling the software that the bootloader is ready to start receiving the data. remember that up until now we have been dealing with commands that always end in a #. packets don’t follow this trend, and instead are always the same length: 0x85 (133) bytes long. packets are arranged as follows: byte data 0 this is always 0x01 – start of header, this is how the bootloader knows that this is a packet and not an eot, or esc etc. 1 this is our packet counter starting at 1 and, in this instance, ending at 19 – i’ll explain where 19 comes from in a bit. 2 this is the inverse of the packet counter, so the inverse of 0x01 is 0xff, 0x02 is 0xfe etc. 3-130 this the data we are sending (128 bytes) 131-132 this is a checksum of the data we have just sent note that packets have to be 133 bytes and thus data has to be sent in multiples of 128. in our case, we are sending 2320 bytes of data; if we divide this by 128, we get 18 remainder 16. that means we will send 18 full packets of 128 bytes of data and 1 final packet of 16 bytes of data. let’s look at the final packet: the highlighted bytes are our final 16 bytes of data. we saw before that the bootloader keeps count of how many bytes of data to expect, so although it will receive this whole packet, it will disregard the remaining 112 bytes. once all the data has been sent, the bootloader will send an end of transmission byte (eot): 04 (eot) which the software will acknowledge: 06 (ack) initializing the applets once we have our application in sram, we need to initialise it. if we look at the structure of the mailbox our application uses: we can see the first thing in the structure is the command, following by the status and then we have a union which defines the input variables depending on the operation. since we want to be initialising the application, we’ll only focus on the initialisation input. let’s take a look at the command sent to the bootloader at this point: here we are writing some data to locations in sram: 0x00000000 at location 0x20001040 0x00000001 at location 0x20001048 0x00000001 at location 0x2000104c 0x00000000 at location 0x20001050 if we remember that the mailbox starts at 0x20

URL analysis for hobbygenius.co.uk

http://hobbygenius.co.uk/blog/1622
http://hobbygenius.co.uk/blog/1633
http://hobbygenius.co.uk/blog/1695
http://hobbygenius.co.uk/author/george
http://hobbygenius.co.uk/category/projects/
http://hobbygenius.co.uk/blog/980
http://hobbygenius.co.uk/category/blog/
http://hobbygenius.co.uk/category/tutorials/

Whois Information

Whois is a protocol that is access to registering information. You can reach when the website was registered, when it will be expire, what is contact details of the site with the following informations. In a nutshell, it includes these informations;

Domain name:
hobbygenius.co.uk

Data validation:
Nominet was able to match the registrant's name and address against a 3rd party data source on 11-Jul-2017

Registrar:
GoDaddy.com, LLP. [Tag = GODADDY]
URL: http://uk.godaddy.com

Relevant dates:
Registered on: 25-Apr-2011
Expiry date: 25-Apr-2019
Last updated: 28-Nov-2017

Registration status:
Registered until expiry date.

Name servers:
ns75.domaincontrol.com
ns76.domaincontrol.com

WHOIS lookup made at 13:00:13 26-Jun-2018

--
This WHOIS information is provided for free by Nominet UK the central registry
for .uk domain names. This information and the .uk WHOIS are:

Copyright Nominet UK 1996 - 2018.

You may not access the .uk WHOIS or use any data from it except as permitted
by the terms of use available in full at https://www.nominet.uk/whoisterms,
which includes restrictions on: (A) use of the data for advertising, or its
repackaging, recompilation, redistribution or reuse (B) obscuring, removing
or hiding any or all of this notice and (C) exceeding query rate or volume
limits. The data is provided on an 'as-is' basis and may lag behind the
register. Access may be withdrawn or restricted at any time.

  REFERRER http://www.nominet.org.uk

  REGISTRAR Nominet UK

SERVERS

  SERVER co.uk.whois-servers.net

  ARGS hobbygenius.co.uk

  PORT 43

  TYPE domain

DOMAIN

SPONSOR
GoDaddy.com, LLP. [Tag = GODADDY]
URL: http://uk.godaddy.com
Relevant dates:

  CREATED 25-Apr-2011

  CHANGED 28-Nov-2017

STATUS
Registered until expiry date.

NSERVER

  NS75.DOMAINCONTROL.COM 216.69.185.48

  NS76.DOMAINCONTROL.COM 173.201.75.48

  NAME hobbygenius.co.uk

DISCLAIMER
This WHOIS information is provided for free by Nominet UK the central registry
for .uk domain names. This information and the .uk WHOIS are:
Copyright Nominet UK 1996 - 2018.
You may not access the .uk WHOIS or use any data from it except as permitted
by the terms of use available in full at https://www.nominet.uk/whoisterms,
which includes restrictions on: (A) use of the data for advertising, or its
repackaging, recompilation, redistribution or reuse (B) obscuring, removing
or hiding any or all of this notice and (C) exceeding query rate or volume
limits. The data is provided on an 'as-is' basis and may lag behind the
register. Access may be withdrawn or restricted at any time.

  REGISTERED no

Mistakes

The following list shows you to spelling mistakes possible of the internet users for the website searched .